From owner-namedroppers@ops.ietf.org Fri Feb 1 06:16:51 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16405 for ; Fri, 1 Feb 2002 06:16:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16WbQI-000CaA-00 for namedroppers-data@psg.com; Fri, 01 Feb 2002 03:00:02 -0800 Received: from randy by psg.com with local (Exim 3.33 #1) id 16WbQH-000Ca4-00 for namedroppers@ops.ietf.org; Fri, 01 Feb 2002 03:00:01 -0800 To: namedroppers@ops.ietf.org Subject: list policy Message-Id: From: Randy Bush Date: Fri, 01 Feb 2002 03:00:01 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk namedroppers@ops.ietf.org is the mailing list for the ietf dnsext wg. see for the wg charter. messages should be on topics appropriate to the dnsext wg, which are various discussion of the dns protocols or administrivia of the wg itself. the list is moderated. calls for papers, announcements of events not directly relevant to the dns protocols, etc. are not appropriate. discussion of problems with particular implementations, announcements of releases, sites' misconfigurations, etc. should be done on mailing lists for the particular implementations. there is a wg for dns operational practice, dnsop, whose charter can be found at . there is a mailing list for discussion of whose implementation is better, and why someone else's is broken. it is weenie-war@ops.ietf.org. all discussions of such nature should occur there or on /dev/null. unlike the namedroppers list, weenie-war@ops.ietf.org is not archived. questions or concerns related to the acceptance or rejection of specific messages to the namedroppers mailing list should first be discussed with the wg chairs, with followup appeals using the normal appeals process of rfc 2026 (i.e., follup with area directors, then iesg, etc.). there is a mailing list for the discussion of ietf processes, which includes any general discussion of the moderation of ietf mailing lists. it is poised@lists.tislabs.com --- NOTE WELL: All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Feb 3 00:16:05 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13364 for ; Sun, 3 Feb 2002 00:16:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16XEdD-000Jka-00 for namedroppers-data@psg.com; Sat, 02 Feb 2002 20:51:59 -0800 Received: from irwell.zetnet.co.uk ([194.247.47.48] helo=zetnet.co.uk) by psg.com with esmtp (Exim 3.33 #1) id 16XEdC-000JkU-00 for namedroppers@ops.ietf.org; Sat, 02 Feb 2002 20:51:58 -0800 Received: from zetnet.co.uk (bts-0518.dialup.zetnet.co.uk [194.247.50.6]) by zetnet.co.uk (8.11.3/8.11.3/Debian 8.11.2-1) with ESMTP id g134pqT14858 for ; Sun, 3 Feb 2002 04:51:52 GMT Message-ID: <3C5B599C.2949C0D4@zetnet.co.uk> Date: Sat, 02 Feb 2002 03:14:36 +0000 From: David Hopwood X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en-GB,en,fr-FR,fr,de-DE,de,ru MIME-Version: 1.0 To: namedroppers Subject: Re: Wildcards and Opt-In References: <3C580CA0.F64E3A7B@isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Daniel Massey wrote: > The use of wildcards in DNSSEC is somewhat awkward at best and > I think it becomes a severe problem if Opt-In is used. > > Suppose you have a entry such as: > *.edu. MX 10 mail.junk.edu > SIG by edu. > > Now suppose a query for nge.isi.edu MX returns: > nge.isi.edu. MX 10 mail.junk.edu > SIG by edu. (with label = 1) > > Is this a valid answer or a response from an attacker? It's invalid. To be valid, according to RFC2535, the response would also need to prove that neither nge.isi.edu nor *.isi.edu are signed. (If isi.edu does not exist, it can do that with a single signed NXT.) If the query was for foo.bar.nge.isi.edu, it would need to prove that none of foo.bar.nge.isi.edu, *.bar.nge.isi.edu, *.nge.isi.edu, or *.isi.edu are signed (again, if isi.edu does not exist then this can be done with a single signed NXT). An interesting case is what happens if isi.edu exists but neither nge.isi.edu nor *.isi.edu does. Is the *.edu wildcard supposed to be a valid match for nge.isi.edu in that case? I don't think it should be, but I think I'm disagreeing with RFC2535 about that: # Furthermore, if a wildcard expansion is returned in a response, in # general one or more NXTs needs to also be returned in the authority ^^^^^^^ # section to prove that no more specific name (including possibly more ^^^^^^^^^^^^^^^^^^^^^^^ # specific wildcards in the zone) existed on which the response should ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ # have been based. I.e. what I think the resolver should require is a single NXT record that proves that *nothing* under isi.edu (i.e. the domain one level more specific than the wildcard entry) is signed: i.edu. NXT j.edu NS KEY SOA ; Opt-In i.edu. SIG NXT 1 2 ( ;type-cov=NXT, alg=1, labels=2 ... ) where i.edu < isi.edu and isj.edu <= j.edu [sic]; as opposed to having to possibly handle multiple NXT records proving that there are no wildcards at each level. - -- David Hopwood Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/ RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01 Nothing in this message is intended to be legally binding. If I revoke a public key but refuse to specify why, it is because the private key has been seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQEVAwUBPFtZRzkCAxeYt5gVAQF7EQf/S8WNHcCobx95SMB04FJXlu0eeoVEzujM +ciAsiTdjVdu6bDYP716bJ/PJpyJU2BRs8l89HK3ZlRAvvCs01/DoTKYjCrGPG97 B+XrtksVEm4qaiyI0b/OaJxEMI3+ewbD3lz8MVAjyOKBC4r3Fb1BTrwA17DVpeuC 2fTQiGF3qICfhryNdTOTH79S1wSX+39dreN6JaKYzji//mU+P1BNIpwqRxRCdV2S 3C1jQ5JotiIB8b1XGSwYLYS/BX74rboKejDa48vRIOOxegFNoUenUTZAP3aN925m V5fXe8p+b2p+21LUExeGePa6VPFiqEKh39/1c1jDzeoBzdp9YhlkAA== =iWMU -----END PGP SIGNATURE----- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Feb 3 00:20:30 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13403 for ; Sun, 3 Feb 2002 00:20:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16XErR-000KFD-00 for namedroppers-data@psg.com; Sat, 02 Feb 2002 21:06:41 -0800 Received: from irwell.zetnet.co.uk ([194.247.47.48] helo=zetnet.co.uk) by psg.com with esmtp (Exim 3.33 #1) id 16XErQ-000KF7-00 for namedroppers@ops.ietf.org; Sat, 02 Feb 2002 21:06:40 -0800 Received: from zetnet.co.uk (bts-0518.dialup.zetnet.co.uk [194.247.50.6]) by zetnet.co.uk (8.11.3/8.11.3/Debian 8.11.2-1) with ESMTP id g1356bT16397 for ; Sun, 3 Feb 2002 05:06:38 GMT Message-ID: <3C5B5D12.903F25F9@zetnet.co.uk> Date: Sat, 02 Feb 2002 03:29:22 +0000 From: David Hopwood X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en-GB,en,fr-FR,fr,de-DE,de,ru MIME-Version: 1.0 To: namedroppers Subject: Re: Wildcards and Opt-In References: <3C580CA0.F64E3A7B@isi.edu> <3C5B599C.2949C0D4@zetnet.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- I wrote: > I.e. what I think the resolver should require is a single NXT record that > proves that *nothing* under isi.edu (i.e. the domain one level more > specific than the wildcard entry) is signed: > > i.edu. NXT j.edu NS KEY SOA ; Opt-In > i.edu. SIG NXT 1 2 ( ;type-cov=NXT, alg=1, labels=2 ... ) > > where i.edu < isi.edu and isj.edu <= j.edu [sic]; Correction: where i.edu < isi.edu < j.edu, and j.edu is not a subdomain of isi.edu. (isj.edu was supposed to be the next name in canonical order after isi.edu that is not a subdomain of isi.edu, but it isn't, and the above is a better way of expressing it). - -- David Hopwood Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/ RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01 Nothing in this message is intended to be legally binding. If I revoke a public key but refuse to specify why, it is because the private key has been seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQEVAwUBPFtc2jkCAxeYt5gVAQFrkgf/YqvGlLIBvYhimaDn7udZZm5CYe4JZvVe bEllG1SEyy54t97k0dzNY3B6sLHWtdwX+nSSYdlY8u/YCN/Q/IEmUclC9QGev+br u85+2pO6Vb/OZKLrkacIAF4Ix3MQuAO5QfrTxXIJ5jFnp61ly1kFMxCJa/3rr8qC 6J2ZuHOjuwR0GeOToFWzVwYDgDManENQUJ3C3nT0BcxzPJOnwI3A9iKvXUheM0VI p9/8sr2s76H17KdPZQme+E16us/YprbBZWiatDN1aFbOQpwFSS2PpAHevUD8G9oI Wrt+QZWCnP6s5+XmQ5b94vpNSsAxSWtzkJl6eiqX1oGDEo/BnMeFzg== =0HNn -----END PGP SIGNATURE----- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 5 08:28:04 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29231 for ; Tue, 5 Feb 2002 08:28:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Y5Iy-0004PS-00 for namedroppers-data@psg.com; Tue, 05 Feb 2002 05:06:36 -0800 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.33 #1) id 16Y5Ix-0004PF-00 for namedroppers@ops.ietf.org; Tue, 05 Feb 2002 05:06:35 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA09296; Tue, 5 Feb 2002 06:06:32 -0700 (MST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g15D6TM28047; Tue, 5 Feb 2002 14:06:29 +0100 (MET) Date: Tue, 5 Feb 2002 14:02:37 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: Comments on draft-ietf-dnsext-gss-tsig-04.txt To: Levon Esibov Cc: Erik Nordmark , Stuart Kwan , Praerit Garg , James Gilroy , randyhall@lucent.com, Jeff Westhead , namedroppers@ops.ietf.org In-Reply-To: "Your message with ID" <4AEE3169443CDD4796CA8A00B02191CD03251FAA@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Looks ok. Please submit the 05 version to internet-drafts and when it appears I'll ask to have the IETF-wide last call started. Thanks, Erik to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 5 10:39:54 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04416 for ; Tue, 5 Feb 2002 10:39:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Y7Y2-0007kr-00 for namedroppers-data@psg.com; Tue, 05 Feb 2002 07:30:18 -0800 Received: from mailb.microsoft.com ([131.107.3.123] helo=mail3.microsoft.com) by psg.com with esmtp (Exim 3.33 #1) id 16Y7Y2-0007kk-00 for namedroppers@ops.ietf.org; Tue, 05 Feb 2002 07:30:18 -0800 Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.4617); Tue, 5 Feb 2002 07:30:04 -0800 Received: from 157.54.8.109 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 05 Feb 2002 07:30:04 -0800 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 5 Feb 2002 07:30:04 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 5 Feb 2002 07:30:03 -0800 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3588.0); Tue, 5 Feb 2002 07:27:50 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6132.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Comments on draft-ietf-dnsext-gss-tsig-04.txt Date: Tue, 5 Feb 2002 07:27:50 -0800 Message-ID: <4AEE3169443CDD4796CA8A00B02191CD03251FE9@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: Comments on draft-ietf-dnsext-gss-tsig-04.txt Thread-Index: AcGuRZyjYbEoT3DkSKSUdJiGHkBNxwAFDDng From: "Levon Esibov" To: "Erik Nordmark" Cc: "Stuart Kwan" , "Praerit Garg" , "James Gilroy" , , "Jeff Westhead" , X-OriginalArrivalTime: 05 Feb 2002 15:27:50.0496 (UTC) FILETIME=[AC0D4E00:01C1AE59] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA04416 Great! Thanks! I submitted the 05 version and I'll let you know as soon as it appears. Regards, Levon. -----Original Message----- From: Erik Nordmark [mailto:Erik.Nordmark@eng.sun.com] Sent: Tuesday, February 05, 2002 5:03 AM To: Levon Esibov Cc: Erik Nordmark; Stuart Kwan; Praerit Garg; James Gilroy; randyhall@lucent.com; Jeff Westhead; namedroppers@ops.ietf.org Subject: RE: Comments on draft-ietf-dnsext-gss-tsig-04.txt Looks ok. Please submit the 05 version to internet-drafts and when it appears I'll ask to have the IETF-wide last call started. Thanks, Erik to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 6 09:09:20 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20298 for ; Wed, 6 Feb 2002 09:09:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16YSLO-0003z1-00 for namedroppers-data@psg.com; Wed, 06 Feb 2002 05:42:38 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.33 #1) id 16YSLN-0003yv-00 for namedroppers@ops.ietf.org; Wed, 06 Feb 2002 05:42:37 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19541; Wed, 6 Feb 2002 08:42:33 -0500 (EST) Message-Id: <200202061342.IAA19541@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-gss-tsig-05.txt Date: Wed, 06 Feb 2002 08:42:33 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart 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 : GSS Algorithm for TSIG (GSS-TSIG) Author(s) : S. Kwan, P. Garg, J. Gilroy, L. Esibov, J. Westhead, R. Hall Filename : draft-ietf-dnsext-gss-tsig-05.txt Pages : 21 Date : 05-Feb-02 The TSIG protocol provides transaction level authentication for DNS. TSIG is extensible through the definition of new algorithms. This document specifies an algorithm based on the Generic Security Service Application Program Interface (GSS-API) (RFC2743). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-gss-tsig-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-gss-tsig-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-gss-tsig-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020205140712.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-gss-tsig-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-gss-tsig-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020205140712.I-D@ietf.org> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 8 11:30:12 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13774 for ; Fri, 8 Feb 2002 11:30:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16ZDWg-000D4I-00 for namedroppers-data@psg.com; Fri, 08 Feb 2002 08:05:26 -0800 Received: from is1-50.antd.nist.gov ([129.6.50.251]) by psg.com with esmtp (Exim 3.33 #1) id 16ZDWf-000D4C-00 for namedroppers@ops.ietf.org; Fri, 08 Feb 2002 08:05:25 -0800 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by is1-50.antd.nist.gov (8.9.3/8.9.3) with SMTP id LAA25962 for ; Fri, 8 Feb 2002 11:05:22 -0500 (EST) Message-ID: <003201c1b0b9$c08d2b40$b9370681@antd.nist.gov> From: "Scott Rose" To: "DNSEXT WG Mailing list" Subject: expired SIGs in an active zone Date: Fri, 8 Feb 2002 11:00:38 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is some issues that came up in a small group discussion (WG chairs, DNSSEC editors, etc). that all of us thought should be taken to namedroppers - given the content. The question is how should authoritative servers handle expired SIG records, since they are unique compared to the rest of DNS data. Some of the special processing of expired SIG records we thought needed attention are both protocol changes and implementation changes. Someone (me and some other unlucky volunteers) will try to pull a draft out of the consensus of the group so the protocol changes are on record and in the new RFC2535bis drafts. Protocol changes: Def: An expired SIG is a SIG record who's "expiration" section is in the past. not who's TTL has expired. -When dealing with expired SIG records in an authoritative zone, the server SHOULD drop them from the zone when the SIG expires. This entails the server periodically checking SIG expiration times. - Servers should avoid placing expired SIGs in DNS responses. NOTE: <- this isn't a SHOULD NOT since it might prove more difficult for servers to implement than resolvers to ignore expired SIGs Some other warning/on line signing might occur, but that is not a protocol issue, but an operational one. Open question: Should deleting expired SIG records require an updating of the zone serial number? (I think "no" personally, but there are open issues). So this is another debate for those of us that have tired of the Opt-In debate (and give the Verisign guys a chance to catch their breaths ;-) Scott =============================================================== Scott Rose Advanced Network Technologies Division NIST ph: 301-975-8439 fax: 301-590-0932 http://www.antd.nist.gov =============================================================== to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 8 11:58:38 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14684 for ; Fri, 8 Feb 2002 11:58:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16ZEAm-000FPE-00 for namedroppers-data@psg.com; Fri, 08 Feb 2002 08:46:52 -0800 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.33 #1) id 16ZEAl-000FP8-00 for namedroppers@ops.ietf.org; Fri, 08 Feb 2002 08:46:51 -0800 Received: from x50 (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.11.6/8.11.6) with SMTP id g18Gkki00730; Fri, 8 Feb 2002 17:46:46 +0100 Date: Fri, 8 Feb 2002 17:46:46 +0100 From: "Olaf M. Kolkman" To: "Scott Rose" Cc: namedroppers@ops.ietf.org Subject: Re: expired SIGs in an active zone Message-Id: <20020208174646.0cffabf3.olaf@ripe.net> In-Reply-To: <003201c1b0b9$c08d2b40$b9370681@antd.nist.gov> References: <003201c1b0b9$c08d2b40$b9370681@antd.nist.gov> Organization: RIPE NCC X-Mailer: Sylpheed version 0.7.0 (GTK+ 1.2.9; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Fri, 8 Feb 2002 11:00:38 -0500 "Scott Rose" wrote: > Protocol changes: > Def: An expired SIG is a SIG record who's "expiration" section is in > the past. not who's TTL has expired. Agreed: the expiration date is a 'crypto' parameter, the TTL is a 'database optimalization' parameter. > -When dealing with expired SIG records in an authoritative zone, the > server SHOULD drop them from the zone when the SIG expires. This > entails the server periodically checking SIG expiration times. > > - Servers should avoid placing expired SIGs in DNS responses. > NOTE: <- this isn't a SHOULD NOT since it might prove more difficult for > servers to implement than resolvers to ignore expired SIGs > Some other warning/on line signing might occur, but that is not a > protocol issue, but an operational one. I am confused: What is the difference between SHOULD avoid and SHOULD NOT? Don't you mean that this isn't a MUST NOT? > > Open question: Should deleting expired SIG records require an updating of > the zone serial number? (I think "no" personally, but there are open > issues). If you want a consistent view of the DNS and you allow some servers not to drop expired SIGs then you want the secondaries to pick up the zone without expired SIGs.. hence increase the serial. Otherwise I am (still) agnostic on this. > So this is another debate for those of us that have tired of the Opt-In > debate (and give the Verisign guys a chance to catch their breaths ;-) I am (still) not agnostic on this :-) --Olaf --------------------------------------------| Olaf M. Kolkman | www.ripe.net/disi to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 8 12:22:09 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15805 for ; Fri, 8 Feb 2002 12:22:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16ZEZF-000Gua-00 for namedroppers-data@psg.com; Fri, 08 Feb 2002 09:12:09 -0800 Received: from pacific-carrier-annex.mit.edu ([18.7.21.83]) by psg.com with esmtp (Exim 3.33 #1) id 16ZEZE-000GuG-00 for namedroppers@ops.ietf.org; Fri, 08 Feb 2002 09:12:08 -0800 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id MAA03486; Fri, 8 Feb 2002 12:12:06 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id MAA23827; Fri, 8 Feb 2002 12:11:57 -0500 (EST) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id MAA08122; Fri, 8 Feb 2002 12:11:50 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id MAA17371; Fri, 8 Feb 2002 12:11:49 -0500 (EST) To: "Olaf M. Kolkman" Cc: "Scott Rose" , namedroppers@ops.ietf.org Subject: Re: expired SIGs in an active zone References: <003201c1b0b9$c08d2b40$b9370681@antd.nist.gov> <20020208174646.0cffabf3.olaf@ripe.net> From: Derek Atkins Date: 08 Feb 2002 12:11:49 -0500 In-Reply-To: <20020208174646.0cffabf3.olaf@ripe.net> Message-ID: Lines: 78 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I think it can be dangerious to (automatically) remove expired SIGs from a zone, or to drop them from responses. In all things security, it is the verifier who has the final say of whether to believe something. Knowing that a pieces of data was signed, but the sig is expired, is very different than believing a piece of data is unsigned. The two are not equivalent. I also feel that a DNS server that is authoritative for a zone that contains expired sigs should syslog an error every time a request is made that would reply with an expired SIG. Operators should be warned continuously if they allow their signatures to expire. -derek "Olaf M. Kolkman" writes: > On Fri, 8 Feb 2002 11:00:38 -0500 > "Scott Rose" wrote: > > > Protocol changes: > > Def: An expired SIG is a SIG record who's "expiration" section is in > > the past. not who's TTL has expired. > > Agreed: the expiration date is a 'crypto' parameter, the TTL is a > 'database optimalization' parameter. > > > -When dealing with expired SIG records in an authoritative zone, the > > server SHOULD drop them from the zone when the SIG expires. This > > entails the server periodically checking SIG expiration times. > > > > > - Servers should avoid placing expired SIGs in DNS responses. > > NOTE: <- this isn't a SHOULD NOT since it might prove more difficult for > > servers to implement than resolvers to ignore expired SIGs > > Some other warning/on line signing might occur, but that is not a > > protocol issue, but an operational one. > > I am confused: What is the difference between SHOULD avoid and SHOULD > NOT? Don't you mean that this isn't a MUST NOT? > > > > > > > Open question: Should deleting expired SIG records require an updating of > > the zone serial number? (I think "no" personally, but there are open > > issues). > > If you want a consistent view of the DNS and you allow some servers > not to drop expired SIGs then you want the secondaries to pick up the > zone without expired SIGs.. hence increase the serial. > > Otherwise I am (still) agnostic on this. > > > > So this is another debate for those of us that have tired of the Opt-In > > debate (and give the Verisign guys a chance to catch their breaths ;-) > > I am (still) not agnostic on this :-) > > > > --Olaf > > > --------------------------------------------| Olaf M. Kolkman > | www.ripe.net/disi > > > > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 8 12:48:06 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17096 for ; Fri, 8 Feb 2002 12:48:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16ZEvw-000IFO-00 for namedroppers-data@psg.com; Fri, 08 Feb 2002 09:35:36 -0800 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.33 #1) id 16ZEvv-000IEw-00 for namedroppers@ops.ietf.org; Fri, 08 Feb 2002 09:35:35 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id AACC328EB3 for ; Fri, 8 Feb 2002 09:35:28 -0800 (PST) (envelope-from vixie@as.vix.com) From: Paul Vixie To: "DNSEXT WG Mailing list" Subject: Re: expired SIGs in an active zone In-Reply-To: Message from "Scott Rose" of "Fri, 08 Feb 2002 11:00:38 EST." <003201c1b0b9$c08d2b40$b9370681@antd.nist.gov> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.1 Date: Fri, 08 Feb 2002 09:35:28 -0800 Message-Id: <20020208173528.AACC328EB3@as.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Def: An expired SIG is a SIG record who's "expiration" section is in the > past. not who's TTL has expired. fine, so far. but after that we get into several kinds of disagreement: > -When dealing with expired SIG records in an authoritative zone, the server > SHOULD drop them from the zone when the SIG expires. This entails the > server periodically checking SIG expiration times. this is just impossible. authority servers do not auto-edit zones. if you really mean this then you'll have to structure it as a dynamic update and increment the serial number and show the change in IXFRs and so forth. but i for one would never, ever, (ever) turn this functionality on in my servers. > - Servers should avoid placing expired SIGs in DNS responses. NOTE: > <- this isn't a SHOULD NOT since it might prove more difficult for > servers to implement than resolvers to ignore expired SIGs Some other > warning/on line signing might occur, but that is not a protocol issue, > but an operational one. if you really want this behaviour then you'll have to ratchet down the TTL as the expiry gets closer in time. otherwise you'll have cached SIGs "floating around" whose signatures are expired but not their DNS TTL's, and you won't have solved whatever problem you're worried about. but if you plan to ratchet down your TTL's in authority responses, then every time you do it you'll have changed the zone's identity, and you'll have to autoincrement the serial number and show this delta in IXFR's. i went through all of this logic for a different purpose (see attached) and was told by the committee that my draft had completely proved that the implementation complexity was just unimaginably higher than anybody had thought. > Open question: Should deleting expired SIG records require an updating of > the zone serial number? (I think "no" personally, but there are open > issues). > > So this is another debate for those of us that have tired of the Opt-In > debate (and give the Verisign guys a chance to catch their breaths ;-) i've got to say that last time i participated in a secret-handshake meeting in a smoke filled back room that had the result of making a recommendation to the namedroppers committee, we did a better job explaining our motives in public than you've done here. what are the motives? 2535 requires the clients and servers to have securely synchronized clocks. that means a client, of either direct authoritative data or recursively cached data, will know whether the signature is expired or not. why are you protecting the client from something it HAS to be able to deal with ANYWAY? btw, here's another copy of DEFUPD for those whose nightmares have stopped: -------- DNSIND Working Group Paul Vixie (ISC) INTERNET-DRAFT May 1996 Amends: RFC 1035, [UPDATE] Deferred Dynamic Updates in the Domain Name System (DNS DEFUPD) Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract Not all applications that perform dynamic updates using the protocol specified in [UPDATE] want their updates applied immediately. A case in point is [DHCP], wherein the DHCP lease time should control the lifetime of associated DNS data even if the DHCP client or server is not available at the time the DHCP lease expires. The essence of this proposal is that DNS Dynamic Updates should be deferrable for some time delay period, after which they will be executed normally. Furthermore, RRs added or updated by a deferred update can have expiration times specified for them, as enforced by the automatic Dynamic Updates. Automatic serial number changes (as in [UPDATE]), dynamic zone slave notification (see [NOTIFY]) and incremental zone transfer (see [IXFR]) will jointly see to it that the zone changes are propagated with expedience. Expires November 1996 [Page 1] INTERNET-DRAFT DNS DEFUPD May 1996 1 - New Assigned Numbers Opcode: DEFUPD (6?) RRtype: TUU (34?) RRtype: TUE (35?) 2 - Message Format The format and encoding of a DEFUPD is identical to that of UPDATE as defined in [UPDATE 2], except that the Opcode is DEFUPD rather than UPDATE, and there are two new RR types that can be used in the Additional Data section. 2.1 - Additional Data Section: TUU RR In addition to the optional uses described in [UPDATE 2.6], a DEFUPD request's Additional Data section can include a TUU (Time Until Update) RR as follows: Owner: same as ZNAME (see [UPDATE 2.3]) Class: same as ZCLASS (see [UPDATE 2.3]) Type: TUU (new RRtype for this protocol) TTL: deferral time, relative, in seconds RDLENGTH: 0 RDATA: empty Of particular note is the TTL, which contains the relative time delay, in seconds, starting from the time this DEFUPD is received by the primary master, before operations contained in the Update Section (see [UPDATE 2.5]) will actually be performed. Expires November 1996 [Page 2] INTERNET-DRAFT DNS DEFUPD May 1996 2.2 - Additional Data Section: TUE RR In addition to the optional uses described in [UPDATE 2.6], a DEFUPD request's Additional Data section can include a TUU (Time Until Expiry) RR as follows: Owner: same as ZNAME (see [UPDATE 2.3]) Class: same as ZCLASS (see [UPDATE 2.3]) Type: TUE (new RRtype for this protocol) TTL: expiry time, relative, in seconds RDLENGTH: 0 RDATA: empty Of particular note is the TTL, which contains the expiration time delay, in seconds, starting from the time this DEFUPD is received by the primary master, of all RRs added or updated by operations in the Update Section (see [UPDATE 2.5]). 3 - Server Behavior A server, upon receiving a DEFUPD request, will first scan the request's Additional Data section in search of TUU or TUE RRs. If no RRs of either type TUU or TUE are found, then this request will be processed as a normal UPDATE with no special behaviour. If any TUU or TUE RRs are found, then processing continues as follows. 3.1 - Verify TUU RR If any TUU RRs are found in the Additional Data section, this update will be processed with Deferral as explained below. If more than one TUU RR is found, signal FORMERR to requestor. The TUU RR's owner name and class are compared to ZNAME and ZCLASS; if a mismatch occurs, signal FORMERR to requestor. The TUU RR's RDLENGTH/RDATA is ignored by implementations of this specification, but future specifications may make use of this field. 3.2 - Verify TUE RR If any TUE RRs are found in the Additional Data section, this update will be processed with Expiry as explained below. If more than one TUE RR is found, signal FORMERR to requestor. The TUE RR's owner name and class are compared to ZNAME and ZCLASS; if a mismatch occurs, signal FORMERR to requestor. The TUE RR's RDLENGTH/RDATA is ignored by implementations of this specification, but future specifications may make use of this field. Expires November 1996 [Page 3] INTERNET-DRAFT DNS DEFUPD May 1996 3.3 - Deferral If a TUU RR was specified in the Additional Data section, this update will be processed with Deferral. Deferral means that the update will not be applied synchronously to the requestor's transaction cycle, but instead will be applied asynchronously at some potentially later time. The delay period is measured in seconds and expressed in the TUU's TTL. 3.3.1 - Store Deferred Update Subject to per-server, per-zone, and per-RRset quotas, this UPDATE message is stored, persistently, on the name server. If per-RRset quotas are implemented, it is recommended that a DEFUPD ``count against'' all RRsets mentioned in the Update Section. If an implementation defined quota is exceeded by this deferred update, or if persistent storage is unavailable, signal SERVFAIL to requestor (leaving the zone in its former state). Note that even a deferred update whose TUU's TTL is zero (0), specifying immediate application, should be subject to quotas if the name server implements quotas. 3.3.2 - Send Early Response Signal NOERROR to requestor. 3.3.3 - Apply Deferred Update When a period of time equal to or greater than the TUU's TTL (measured in seconds) has elapsed since a DEFUPD was first received at the primary master, the DEFUPD message is applied to the zone as an UPDATE would be, except that no error can be signalled to the requestor. Thus, all errors not found and reported at the time the DEFUPD request was received are silent, affecting only the continued processing of the deferred update. Note that all sections are processed, including those processed before the deferred update were stored. Thus, prerequisites must hold before and after the deferral period. Expires November 1996 [Page 4] INTERNET-DRAFT DNS DEFUPD May 1996 3.4 - Expiry Processing When a DEFUPD is applied, either during the requestor's transaction cycle or following the optional Deferral period, the inclusion of a TUE RR in the Additional Data section will cause this update to be processed with Expiry. Expiry as expressed in the TUE's TTL is the time, in seconds, before all RRs added or modified by the Update Section will be automatically deleted by the primary master server. This time is relative to the time the DEFUPD message is processed, which might be after the delay period specified by a TUU RR. 3.4.1 - Initial TTL Limits The TTL of all added or updated RRs in the Update Section will be maximized silently to one half of the Expiry time. This will cause downstream caching name servers to purge RRsets containing this RR at least once before expiry. 3.4.2 - TTL Half Life Each time an RR's expiry reaches half of its previous value, that RR's TTL will be reduced to half of its previous value, until the TTL reaches a value less than or equal to sixty (60), i.e., one minute of real time, at which time the TTL will not be automatically reduced further by the primary master. It should be noted that RRs held in a server's memory need not be swept for half life processing, as long as the TTL changes appear when the RR next becomes externally visible, and as long as the ``zone has changed'' processing (see below) is done at the time of the half life expiration. Whenever the TTL is automatically reduced by this process, the zone will be considered ``changed'' for the purpose of automatic SOA SERIAL increment (see [UPDATE 3.6]) and real time zone slave notification (see [NOTIFY]). Expires November 1996 [Page 5] INTERNET-DRAFT DNS DEFUPD May 1996 3.4.3 - Automatic Deletion When the time since an RR was added or updated by a DEFUPD with Expiry exceeds the TUE's TTL as specified in that update, all RRs added or updated by that DEFUPD's Update Section will be automatically deleted by the primary master. This deletion can be deferred until the deleted RRs would next become visible, so long as the ``zone has changed'' processing (see below) is done at the time of expiration (i.e., when the automatic deletion is first deferred.) Whenever automatic deletion occurs, the zone will be considered ``changed'' for the purpose of automatic SOA SERIAL increment (see [UPDATE 3.6]) and real time zone slave notification (see [NOTIFY]). 3.5 - Requirements for Persistence Stored deferred updates should persist across name server restarts. 3.5.1 - Restarts and Deferral In the event of a name server restart, all deferred updates whose TUU has expired must take effect before any network requests are processed using data from the affected zone, and before any Expiry processing takes place on RRs in the affected zone. 3.5.2 - Restarts and Expiry In the event of a name server restart, all expiries must be checked as of the current time before any network responses are generated using data from the affected zone. If an RR's expiry time has been reached while the name server was not running, that RR will be deleted. Otherwise, the RR's TTL will be set to one half of the time remaining before expiration, and half life processing as specified in Section 3.4.2 will be restarted. If any RR is deleted or if an RR's TTL is changed during startup, then the zone will be considered ``changed'' for the purpose of automatic SOA SERIAL increment (see [UPDATE 3.6]) and real time zone slave notification (see [NOTIFY]). Expires November 1996 [Page 6] INTERNET-DRAFT DNS DEFUPD May 1996 4 - Requestor Behaviour A requestor will generate and transmit a DEFUPD request as specified in [UPDATE 4], except that TUU and TUE RRs can be included in the Additional Data section. 4.1. The TUU RR, if specified, must have an owner name and class equal to the ZNAME and ZCLASS (see [UPDATE 2.3]). The TTL should be set to the delay, measured in seconds, before this update should be processed by the primary master. RDLENGTH should be set to 0, and RDATA should therefore be empty. 4.2. The TUE RR, if specified, must have an owner name and class equal to the ZNAME and ZCLASS (see [UPDATE 2.3]). The TTL should be set to the delay, measured in seconds, before all RRs added or changed by the Update Section will be automatically deleted by the primary master. This delay is measured starting from the time the update is applied, which could follow a deferral delay if a TUU RR was also included in this update. 5 - Notes on Resource Consumption A TUE RR will require the primary master will initiate an automatic update approximately O(log2(TTL)) times over the life of an expiring RR. Even for massively sized zones, this is not considered an inappropriate load on the primary master server itself. The network bandwidth consumed due to the use of TUE RRs is more noticeable, although for massively sized zones, the bandwidth requirements should flatten somewhat as many RRs will be automatically updated during any given cycle of NOTIFY and AXFR/IXFR. 6 - Security Considerations This protocol suffers the same abject and intentional lack of security as [UPDATE], from which it inherits its basic semantics. In the absence of DNS Secure Updates, this protocol should not be used outside of an enterprise network, and only with great care within an enterprise network. Expires November 1996 [Page 7] INTERNET-DRAFT DNS DEFUPD May 1996 7 - Discussion Items for DNSIND and Namedroppers Should the server's response to a DEFUPD include an opaque cookie called a ``deferred update ID'' which could be used in future DEFUPD requests to cancel or replace a previous deferred update? Should automatic updates caused by a TUE RR be required to be batched up and processed at some minimum interval? For example, if we only checked for half life and expiration once per minute, this might drastically reduce the number of NOTIFY/AXFR/IXFR cycles caused by any given zone. We would have to recommend that all zones in a given server not be synchronized to the same timer, lest a server with many zones cause all of its zones to change and require NOTIFY/AXFR/IXFR in the same second. Astute readers will have noticed that this proposal is a precise superset of [UPDATE], and by adding the optional behaviour and definitions of TUU and TUE to [UPDATE], we could do away with the separate Opcode for DEFUPD. This was only possible up until the time [UPDATE] went to proposed standard, but hopefully the intent was clear. 8 - References [RFC1035] P. Mockapetris, ``Domain Names - Implementation and Specification,'' RFC 1035, USC/Information Sciences Institute, November 1987. [IXFR] M. Ohta, ``Incremental Zone Transfer,'' Internet Draft, February 1996, . [NOTIFY] P. Vixie, ``A Mechanism for Prompt Notification of Zone Changes,'' Internet Draft, March 1996, . [UPDATE] P. Vixie (Ed), et al, ``Dynamic Updates in the Domain Name System,'' Internet Draft, March 1996, . [DHCP] Y. Rechter, ``Interaction between DHCP and DNS,'' Internet Draft, February 1996, . Expires November 1996 [Page 8] INTERNET-DRAFT DNS DEFUPD May 1996 9 - Acknowledgements Yakov Rechter assisted in the design of this protocol. Robert Elz assisted in the requirements definition. 10 - Author's Addresses Paul Vixie Internet Software Consortium Star Route Box 159A Woodside, CA 94062 +1 415 747 0204 Expires November 1996 [Page 9] to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 8 13:13:56 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18059 for ; Fri, 8 Feb 2002 13:13:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16ZFNc-000K16-00 for namedroppers-data@psg.com; Fri, 08 Feb 2002 10:04:12 -0800 Received: from 208-59-114-172.c3-0.129-ubr1.lnh-129.md.cable.rcn.com ([208.59.114.172] helo=ogud.com) by psg.com with esmtp (Exim 3.33 #1) id 16ZFNb-000K0t-00 for namedroppers@ops.ietf.org; Fri, 08 Feb 2002 10:04:11 -0800 Received: from oemcomputer.ogud.com (ns.dc.ogud.com [10.20.30.6]) by ogud.com (8.11.3/8.11.3) with ESMTP id g18I3uD38004; Fri, 8 Feb 2002 13:04:04 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <5.1.0.14.2.20020208123717.03268ca0@localhost> X-Sender: post@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 08 Feb 2002 13:01:52 -0500 To: "Scott Rose" , "DNSEXT WG Mailing list" From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: expired SIGs in an active zone In-Reply-To: <003201c1b0b9$c08d2b40$b9370681@antd.nist.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 11:00 AM 2/8/2002, Scott Rose wrote: >Some of the special processing of expired SIG records we thought needed >attention are both protocol changes and implementation changes. Someone (me >and some other unlucky volunteers) will try to pull a draft out of the >consensus of the group so the protocol changes are on record and in the new >RFC2535bis drafts. > >Protocol changes: This is not strictly protocol change, more a protocol clarification, the current RFC's do not talk about what authoritative server do if they detect expired signatures. >Def: An expired SIG is a SIG record who's "expiration" section is in the >past. not who's TTL has expired. > >-When dealing with expired SIG records in an authoritative zone, the server >SHOULD drop them from the zone when the SIG expires. This entails the >server periodically checking SIG expiration times. There is another issue here, what to do with expired signatures on load, IMHO the expired SIG should be dropped. >- Servers should avoid placing expired SIGs in DNS responses. >NOTE: <- this isn't a SHOULD NOT since it might prove more difficult for >servers to implement >than resolvers to ignore expired SIGs Some other warning/on line signing >might occur, but that is not a protocol issue, but an operational one. > >Open question: Should deleting expired SIG records require an updating of >the zone serial number? (I think "no" personally, but there are open >issues). This is the BIG ISSUE, AXFR-clarify clearly outlaws any changes in contents of a zone without updating SOA, (this is a requirement to be able to support IXFR). In this case only the primary master for the zone can purge expired signatures and when it purges expired SIGs SOA serial number MUST be updated in order to enable IXFR update to other authoritative servers and/or to trigger AXFR. Having said this, purging is now only possible by servers that have zone signing key on-line. This brings us to what gets put into the answers: Principle: Servers should never put known bad data into answers. From this principle authoritative servers should not put expired signatures into answers. Recursive security aware servers MUST NOT cache these signatures. Q1: Is it good enough to have the recursive servers purge the expired signatures? Q2: What should a authoritative server do when it detects that ALL signatures for the SOA or the whole zone are expired ? My answer: Same as if the SOA was malformed, refuse to load the zone. Olafur to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 8 13:21:22 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18403 for ; Fri, 8 Feb 2002 13:21:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16ZFUE-000KS6-00 for namedroppers-data@psg.com; Fri, 08 Feb 2002 10:11:02 -0800 Received: from dsl092-066-067.bos1.dsl.speakeasy.net ([66.92.66.67] helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.33 #1) id 16ZFUD-000KS0-00 for namedroppers@ops.ietf.org; Fri, 08 Feb 2002 10:11:01 -0800 Received: from thrintun.hactrn.net (localhost [127.0.0.1]) by thrintun.hactrn.net (Postfix) with ESMTP id AA5D41B65 for ; Fri, 8 Feb 2002 13:10:59 -0500 (EST) Date: Fri, 08 Feb 2002 13:10:59 -0500 Message-ID: <86bsez974c.wl@thrintun.hactrn.net> From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: expired SIGs in an active zone In-Reply-To: <003201c1b0b9$c08d2b40$b9370681@antd.nist.gov> References: <003201c1b0b9$c08d2b40$b9370681@antd.nist.gov> User-Agent: Wanderlust/2.4.1 (Stand By Me) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Um, -why- does SIG need this special processing? Current model is that TTLs and the SOA parameters control whether or not the resolver sees the SIGs, while expiration time is a separate thing that the verifier has to check anyway. If this is broken, please explain how. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 8 13:48:08 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19135 for ; Fri, 8 Feb 2002 13:48:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16ZFtX-000M30-00 for namedroppers-data@psg.com; Fri, 08 Feb 2002 10:37:11 -0800 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.33 #1) id 16ZFtW-000M2u-00 for namedroppers@ops.ietf.org; Fri, 08 Feb 2002 10:37:10 -0800 Received: from localhost (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 74E2C31925; Fri, 8 Feb 2002 10:37:09 -0800 (PST) Date: Fri, 8 Feb 2002 19:36:43 +0100 (CET) From: Roy Arends X-X-Sender: To: Paul Vixie Cc: DNSEXT WG Mailing list Subject: Re: expired SIGs in an active zone In-Reply-To: <20020208173528.AACC328EB3@as.vix.com> Message-ID: <20020208192947.O51014-100000@node10c4d.a2000.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 8 Feb 2002, Paul Vixie wrote: > > - Servers should avoid placing expired SIGs in DNS responses. NOTE: > > <- this isn't a SHOULD NOT since it might prove more difficult for > > servers to implement than resolvers to ignore expired SIGs Some other > > warning/on line signing might occur, but that is not a protocol issue, > > but an operational one. > > if you really want this behaviour then you'll have to ratchet down the > TTL as the expiry gets closer in time. otherwise you'll have cached SIGs > "floating around" whose signatures are expired but not their DNS TTL's, > and you won't have solved whatever problem you're worried about. but if > you plan to ratchet down your TTL's in authority responses, then every > time you do it you'll have changed the zone's identity, and you'll have > to autoincrement the serial number and show this delta in IXFR's. Not to mention: - Regenerate SOA sig's - Resign the RRsets which TTL values has changed - Drop the RRset which had the associated dropped SIG (or use Opt-In) - Regenerate NXT records - Resign NXT records Roy Arends Nominum to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 8 15:21:17 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23509 for ; Fri, 8 Feb 2002 15:21:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16ZHMi-0001Pf-00 for namedroppers-data@psg.com; Fri, 08 Feb 2002 12:11:24 -0800 Received: from is1-50.antd.nist.gov ([129.6.50.251]) by psg.com with esmtp (Exim 3.33 #1) id 16ZHMh-0001PZ-00 for namedroppers@ops.ietf.org; Fri, 08 Feb 2002 12:11:23 -0800 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by is1-50.antd.nist.gov (8.9.3/8.9.3) with SMTP id PAA02470 for ; Fri, 8 Feb 2002 15:11:21 -0500 (EST) Message-ID: <00fe01c1b0dc$1dc79f80$b9370681@antd.nist.gov> From: "Scott Rose" To: "DNSEXT WG Mailing list" References: <20020208192947.O51014-100000@node10c4d.a2000.nl> Subject: Re: expired SIGs in an active zone Date: Fri, 8 Feb 2002 15:06:38 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Forgot about the NXT stuff. Then dropping the SIGs results in masive zone changes (every NXT record - assuming all SIG records expire at the same time for a given RRset). So expired SIGs shouldn't be dropped, but should they be excluded in responses? The servers job of checking every SIG in a response it sends out would be a larger cost than passing it on to the clients to check. But should this be enforced by the protocol? (i.e. "A security aware server MUST NOT place expired SIG records in a response") Scott ----- Original Message ----- From: "Roy Arends" To: "Paul Vixie" Cc: "DNSEXT WG Mailing list" Sent: Friday, February 08, 2002 1:36 PM Subject: Re: expired SIGs in an active zone > On Fri, 8 Feb 2002, Paul Vixie wrote: > > > > - Servers should avoid placing expired SIGs in DNS responses. NOTE: > > > <- this isn't a SHOULD NOT since it might prove more difficult for > > > servers to implement than resolvers to ignore expired SIGs Some other > > > warning/on line signing might occur, but that is not a protocol issue, > > > but an operational one. > > > > if you really want this behaviour then you'll have to ratchet down the > > TTL as the expiry gets closer in time. otherwise you'll have cached SIGs > > "floating around" whose signatures are expired but not their DNS TTL's, > > and you won't have solved whatever problem you're worried about. but if > > you plan to ratchet down your TTL's in authority responses, then every > > time you do it you'll have changed the zone's identity, and you'll have > > to autoincrement the serial number and show this delta in IXFR's. > > Not to mention: > - Regenerate SOA sig's > - Resign the RRsets which TTL values has changed > - Drop the RRset which had the associated dropped SIG (or use Opt-In) > - Regenerate NXT records > - Resign NXT records > > Roy Arends > Nominum > > > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 8 16:00:23 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24631 for ; Fri, 8 Feb 2002 16:00:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16ZHzS-0003l5-00 for namedroppers-data@psg.com; Fri, 08 Feb 2002 12:51:26 -0800 Received: from sentry.gw.tislabs.com ([192.94.214.100]) by psg.com with esmtp (Exim 3.33 #1) id 16ZHzR-0003ky-00 for namedroppers@ops.ietf.org; Fri, 08 Feb 2002 12:51:25 -0800 Received: by sentry.gw.tislabs.com; id PAA17421; Fri, 8 Feb 2002 15:56:48 -0500 (EST) Received: from dhcp1.netsec.tislabs.com(199.171.39.21) by sentry.gw.tislabs.com via smap (V5.5) id xmaa17412; Fri, 8 Feb 02 15:56:15 -0500 X-Sender: lewis@pop.gw.tislabs.com Message-Id: In-Reply-To: <86bsez974c.wl@thrintun.hactrn.net> References: <003201c1b0b9$c08d2b40$b9370681@antd.nist.gov> <003201c1b0b9$c08d2b40$b9370681@antd.nist.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 8 Feb 2002 15:49:57 -0500 To: Rob Austein From: Edward Lewis Subject: Re: expired SIGs in an active zone Cc: namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Rob's message led me to ramble thusly, not necessarily a direct response to his question: The issue is what happens when an authoritative server receives a query. If the CD bit is on, then the authoritative server will return whatever it has, old, good, future sigs and all. With the CD bit off, the authoritative server (perhaps) answer with data only if there is a current signature to cover it. We haven't defined the semantics of an RRset that has no current signature in a signed zone. (I.e, all SIGs have expired, are in the future, or both.) At a cache server, the same treatment should happen. A cache server should always issue queries with the CD bit on. The question is whether the cache server holds answers that fail it's policy. If they are held, then I could get bad data with a CD query, if not I can't. In the former, perhaps the data would pass my policy and it would be nice if the cache had it to give me. The issue is whether the data is checked on arrival or on departure. On arrival is more efficient (as data may be retrieved more often than it arrives). On departure (with no CD bit) is more accurate. Even if the data has a bit set on arrival (in server memory) regarding the result, this won't guarantee an approximation of checking on departure as the validation depends on external items (other keys). At 1:10 PM -0500 2/8/02, Rob Austein wrote: >Um, -why- does SIG need this special processing? Current model is >that TTLs and the SOA parameters control whether or not the resolver >sees the SIGs, while expiration time is a separate thing that the >verifier has to check anyway. If this is broken, please explain how. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 8 16:58:14 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26111 for ; Fri, 8 Feb 2002 16:58:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16ZIsy-0007Gc-00 for namedroppers-data@psg.com; Fri, 08 Feb 2002 13:48:48 -0800 Received: from dsl092-066-067.bos1.dsl.speakeasy.net ([66.92.66.67] helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.33 #1) id 16ZIsx-0007GW-00 for namedroppers@ops.ietf.org; Fri, 08 Feb 2002 13:48:47 -0800 Received: from thrintun.hactrn.net (localhost [127.0.0.1]) by thrintun.hactrn.net (Postfix) with ESMTP id D32941CAA for ; Fri, 8 Feb 2002 16:48:46 -0500 (EST) Date: Fri, 08 Feb 2002 16:48:46 -0500 Message-ID: <867kpnlk5d.wl@thrintun.hactrn.net> From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: expired SIGs in an active zone In-Reply-To: References: <003201c1b0b9$c08d2b40$b9370681@antd.nist.gov> <86bsez974c.wl@thrintun.hactrn.net> User-Agent: Wanderlust/2.4.1 (Stand By Me) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Assuming that I understood Ed's explanation, this looks like a classic end-to-end vs middlebox problem. I don't really believe in the middlebox flavor of DNSSEC anyway (see "Betrayal By Trusted Server" in draft-ietf-dnsext-dns-threats-00), so further hairing up the protocol to support the middlebox case seems ill-advised to me. Another way of looking at the same thing is that this is a layering issue. TTL controls the low-level caching behavior, which is hop-by-hop. Signatures are at a higher layer and are strictly end-to-end (data generator to data consumer). to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 8 17:00:11 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26150 for ; Fri, 8 Feb 2002 17:00:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16ZIkX-0006gz-00 for namedroppers-data@psg.com; Fri, 08 Feb 2002 13:40:05 -0800 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.33 #1) id 16ZIkV-0006gO-00 for namedroppers@ops.ietf.org; Fri, 08 Feb 2002 13:40:03 -0800 Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA02540; Fri, 8 Feb 2002 16:39:53 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA17924; Fri, 8 Feb 2002 16:39:51 -0500 (EST) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id QAA17216; Fri, 8 Feb 2002 16:39:50 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id QAA28870; Fri, 8 Feb 2002 16:39:49 -0500 (EST) To: "Scott Rose" Cc: "DNSEXT WG Mailing list" Subject: Re: expired SIGs in an active zone References: <20020208192947.O51014-100000@node10c4d.a2000.nl> <00fe01c1b0dc$1dc79f80$b9370681@antd.nist.gov> From: Derek Atkins Date: 08 Feb 2002 16:39:49 -0500 In-Reply-To: <00fe01c1b0dc$1dc79f80$b9370681@antd.nist.gov> Message-ID: Lines: 25 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk "Scott Rose" writes: > Forgot about the NXT stuff. Then dropping the SIGs results in masive zone > changes (every NXT record - assuming all SIG records expire at the same time > for a given RRset). > > So expired SIGs shouldn't be dropped, but should they be excluded in > responses? The servers job of checking every SIG in a response it sends out > would be a larger cost than passing it on to the clients to check. Yes, they should be included in responses. > But should this be enforced by the protocol? (i.e. "A security aware server > MUST NOT place expired SIG records in a response") IMHO: Absolutely not. The server should definitely complain about expired SIGs, but it should still place them in the response. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 8 17:30:38 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26645 for ; Fri, 8 Feb 2002 17:30:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16ZJNm-0009Cx-00 for namedroppers-data@psg.com; Fri, 08 Feb 2002 14:20:38 -0800 Received: from sentry.gw.tislabs.com ([192.94.214.100]) by psg.com with esmtp (Exim 3.33 #1) id 16ZJNl-0009Cr-00 for namedroppers@ops.ietf.org; Fri, 08 Feb 2002 14:20:37 -0800 Received: by sentry.gw.tislabs.com; id RAA19264; Fri, 8 Feb 2002 17:26:00 -0500 (EST) Received: from dhcp1.netsec.tislabs.com(199.171.39.21) by sentry.gw.tislabs.com via smap (V5.5) id xma019254; Fri, 8 Feb 02 17:25:14 -0500 X-Sender: lewis@pop.gw.tislabs.com Message-Id: In-Reply-To: <867kpnlk5d.wl@thrintun.hactrn.net> References: <003201c1b0b9$c08d2b40$b9370681@antd.nist.gov> <86bsez974c.wl@thrintun.hactrn.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 8 Feb 2002 17:18:59 -0500 To: Rob Austein From: Edward Lewis Subject: Re: expired SIGs in an active zone Cc: namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 4:48 PM -0500 2/8/02, Rob Austein wrote: >Assuming that I understood Ed's explanation, this looks like a classic >end-to-end vs middlebox problem. I don't really believe in the >middlebox flavor of DNSSEC anyway (see "Betrayal By Trusted Server" in >draft-ietf-dnsext-dns-threats-00), so further hairing up the protocol >to support the middlebox case seems ill-advised to me. Not complete sure of understanding myself either, you definitely hit the issue right. If the end unit of the process did the validation, there's no question that the servers along the way should just send all they get - good or bad. This benefit would be that any end point could see what is clear across the network (minus the latency of the speed of light/packets). We've inserted this telephony notion of a dumb end unit that relies on something in the core of the network, and therein lies the problem. >Another way of looking at the same thing is that this is a layering >issue. TTL controls the low-level caching behavior, which is >hop-by-hop. Signatures are at a higher layer and are strictly >end-to-end (data generator to data consumer). Yes. But now we need to decide if the consumer is the last name server to see the data or the stub resolver. (Keeping in mind that the last name server may be the source.) Thinking deeper, it seems the check on send (if the Checking Disabled is off) would achieve the goal of pushing the check as close to the end unit as possible. However, it has been rightly noted that check on send is less efficient than check on receipt. For the implementors of servers, checking on send is much less palatable than sending on receive for reasons that are solid from a software engineering point of view. But it seems to me that checking on send has other benefits, including enabling pushing the decision of good/bad as close to the periphery as possible. Perhaps some servers should refuse to answer queries with the CD bit is set to on. This would allow servers, such as the roots, remain able to run in an answer-only mode with no computation required. ? -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 8 22:00:05 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00922 for ; Fri, 8 Feb 2002 22:00:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16ZNV1-000Pcw-00 for namedroppers-data@psg.com; Fri, 08 Feb 2002 18:44:23 -0800 Received: from roam.psg.com ([147.28.4.2]) by psg.com with esmtp (Exim 3.33 #1) id 16ZNV0-000Pcq-00 for namedroppers@ops.ietf.org; Fri, 08 Feb 2002 18:44:22 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16ZNUz-0000r8-00 for namedroppers@ops.ietf.org; Fri, 08 Feb 2002 18:44:21 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200202081735.JAA16115@gulag.araneus.fi> In-Reply-To: <003201c1b0b9$c08d2b40$b9370681@antd.nist.gov> References: <003201c1b0b9$c08d2b40$b9370681@antd.nist.gov> Date: Fri, 8 Feb 2002 09:35:57 -0800 (PST) To: "Scott Rose" Cc: "DNSEXT WG Mailing list" Subject: Re: expired SIGs in an active zone From: gson@nominum.com (Andreas Gustafsson) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Scott Rose writes: > -When dealing with expired SIG records in an authoritative zone, the server > SHOULD drop them from the zone when the SIG expires. This entails the > server periodically checking SIG expiration times. > > - Servers should avoid placing expired SIGs in DNS responses. > NOTE: <- this isn't a SHOULD NOT since it might prove more difficult for > servers to implement > than resolvers to ignore expired SIGs Some other warning/on line signing > might occur, but that is not a protocol issue, but an operational one. What is this change supposed to accomplish? If SIGs have expired, resolution will fail whether they are included in the response or not. It seems to me that omitting them would only make it harder for the client administrator to diagnose the cause of the resolution failure. -- Andreas Gustafsson, gson@nominum.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 8 22:04:46 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00985 for ; Fri, 8 Feb 2002 22:04:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16ZNf0-0000JP-00 for namedroppers-data@psg.com; Fri, 08 Feb 2002 18:54:42 -0800 Received: from roam.psg.com ([147.28.4.2]) by psg.com with esmtp (Exim 3.33 #1) id 16ZNez-0000JJ-00 for namedroppers@ops.ietf.org; Fri, 08 Feb 2002 18:54:41 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16ZNey-0000sM-00 for namedroppers@ops.ietf.org; Fri, 08 Feb 2002 18:54:40 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200202082038.PAA24020@ietf.org> To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: The IESG SUBJECT: Last Call: GSS Algorithm for TSIG (GSS-TSIG) to Proposed Standard Date: Fri, 08 Feb 2002 15:38:29 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The IESG has received a request from the DNS Extensions Working Group to consider GSS Algorithm for TSIG (GSS-TSIG) as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by February 22, 2002. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dnsext-gss-tsig-05.txt to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 8 23:12:40 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02661 for ; Fri, 8 Feb 2002 23:12:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16ZOdP-0004WG-00 for namedroppers-data@psg.com; Fri, 08 Feb 2002 19:57:07 -0800 Received: from dsl092-066-067.bos1.dsl.speakeasy.net ([66.92.66.67] helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.33 #1) id 16ZOdO-0004WA-00 for namedroppers@ops.ietf.org; Fri, 08 Feb 2002 19:57:06 -0800 Received: from thrintun.hactrn.net (localhost [127.0.0.1]) by thrintun.hactrn.net (Postfix) with ESMTP id D2DB31CAA for ; Fri, 8 Feb 2002 22:57:05 -0500 (EST) Date: Fri, 08 Feb 2002 22:57:05 -0500 Message-ID: <86lme3i9ym.wl@thrintun.hactrn.net> From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: expired SIGs in an active zone In-Reply-To: References: <003201c1b0b9$c08d2b40$b9370681@antd.nist.gov> <86bsez974c.wl@thrintun.hactrn.net> User-Agent: Wanderlust/2.4.1 (Stand By Me) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Yes. But now we need to decide if the consumer is the last name server to > see the data or the stub resolver. (Keeping in mind that the last name > server may be the source.) The consumer is the application, but the DNS-speaking-entity closest to the application is the resolver. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Feb 10 06:26:01 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05393 for ; Sun, 10 Feb 2002 06:26:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Zrf1-000BEp-00 for namedroppers-data@psg.com; Sun, 10 Feb 2002 02:56:43 -0800 Received: from h150n1fls31o887.telia.com ([213.66.164.150] helo=snout.autonomica.se) by psg.com with esmtp (Exim 3.33 #1) id 16Zrf0-000BEi-00 for namedroppers@ops.ietf.org; Sun, 10 Feb 2002 02:56:42 -0800 Received: by snout.autonomica.se (Postfix, from userid 1211) id 36ADBF89; Sun, 10 Feb 2002 11:56:52 +0100 (CET) To: Olafur Gudmundsson Cc: DNSEXT mailing list Subject: Re: IETF-53 DNSEXT agenda requests References: <20020131124220.R4197-100000@hlid.dc.ogud.com> From: Johan Ihren Date: 10 Feb 2002 11:56:50 +0100 In-Reply-To: Olafur Gudmundsson's message of "Thu, 31 Jan 2002 12:46:13 -0500 (EST)" Message-ID: <2cn0yh8v0t.fsf@snout.autonomica.se> Lines: 15 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) Emacs/20.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Olafur Gudmundsson writes: > I have requested a 2.5 hour slot and we are currently scheduled to > meet on Monday night (again). Grumble. This is just about the worst slot of the entire week. While I fully realize the problems of scheduling an IETF in an optimal fashion I still think it's *really* unfortunate to have the only DNSEXT session at a time when most of the europeans are counting sheep... Johan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Feb 10 13:10:34 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08813 for ; Sun, 10 Feb 2002 13:10:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Zy8q-000ITA-00 for namedroppers-data@psg.com; Sun, 10 Feb 2002 09:51:56 -0800 Received: from 208-59-114-172.c3-0.129-ubr1.lnh-129.md.cable.rcn.com ([208.59.114.172] helo=ogud.com) by psg.com with esmtp (Exim 3.33 #1) id 16Zy8p-000IT2-00 for namedroppers@ops.ietf.org; Sun, 10 Feb 2002 09:51:55 -0800 Received: from oemcomputer.ogud.com (ns.dc.ogud.com [10.20.30.6]) by ogud.com (8.11.6/8.11.6) with ESMTP id g1AHpgj15945; Sun, 10 Feb 2002 12:51:42 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <5.1.0.14.2.20020210124449.02c57bd0@localhost> X-Sender: post@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 10 Feb 2002 12:47:08 -0500 To: Johan Ihren , Olafur Gudmundsson From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: IETF-53 DNSEXT agenda requests Cc: DNSEXT mailing list In-Reply-To: <2cn0yh8v0t.fsf@snout.autonomica.se> References: <20020131124220.R4197-100000@hlid.dc.ogud.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 05:56 AM 2/10/2002, Johan Ihren wrote: >Olafur Gudmundsson writes: > > > I have requested a 2.5 hour slot and we are currently scheduled to > > meet on Monday night (again). > >Grumble. This is just about the worst slot of the entire week. While I >fully realize the problems of scheduling an IETF in an optimal fashion >I still think it's *really* unfortunate to have the only DNSEXT >session at a time when most of the europeans are counting sheep... Cheer up, the meeting is currently on Monday MORNING while you are still awake, but while all the people from the pacific region are still asleep and it will move a few more times before finding a resting place. Olafur to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Feb 10 15:14:07 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10267 for ; Sun, 10 Feb 2002 15:14:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16a0C5-000LKV-00 for namedroppers-data@psg.com; Sun, 10 Feb 2002 12:03:25 -0800 Received: from roam.psg.com ([147.28.4.2]) by psg.com with esmtp (Exim 3.33 #1) id 16a0C4-000LKP-00 for namedroppers@ops.ietf.org; Sun, 10 Feb 2002 12:03:25 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16a0Bn-0005HI-00; Sun, 10 Feb 2002 12:03:07 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Cc: Johan Ihren , DNSEXT mailing list Subject: Re: IETF-53 DNSEXT agenda requests References: <20020131124220.R4197-100000@hlid.dc.ogud.com> <5.1.0.14.2.20020210124449.02c57bd0@localhost> Message-Id: Date: Sun, 10 Feb 2002 12:03:07 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit it will change at least three times. if we bitch a lot, we could get friday. randy to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Feb 10 16:18:17 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10863 for ; Sun, 10 Feb 2002 16:18:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16a1D1-000Msl-00 for namedroppers-data@psg.com; Sun, 10 Feb 2002 13:08:27 -0800 Received: from dt0b4n7d.maine.rr.com ([24.95.12.125] helo=nic-naa.net) by psg.com with esmtp (Exim 3.33 #1) id 16a1Cz-000Msa-00; Sun, 10 Feb 2002 13:08:25 -0800 Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.6/8.11.1) with ESMTP id g1B013r08100; Sun, 10 Feb 2002 16:01:08 -0800 (PST) (envelope-from brunner@nic-naa.net) Message-Id: <200202110001.g1B013r08100@nic-naa.net> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Randy Bush cc: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= , Johan Ihren , DNSEXT mailing list , brunner@nic-naa.net Subject: Re: IETF-53 DNSEXT agenda requests In-Reply-To: Message from Randy Bush of "Sun, 10 Feb 2002 12:03:07 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 10 Feb 2002 16:01:03 -0800 From: Eric Brunner-Williams in Portland Maine Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > it will change at least three times. if we bitch a lot, we could get > friday. the afternoon session, neh? eric to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 11 00:29:55 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17568 for ; Mon, 11 Feb 2002 00:29:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16a8bS-00082O-00 for namedroppers-data@psg.com; Sun, 10 Feb 2002 21:02:10 -0800 Received: from 96-1.nat.psu.ac.th ([202.28.96.1] helo=brandenburg.cs.mu.OZ.AU) by psg.com with esmtp (Exim 3.33 #1) id 16a8bN-00081C-00 for namedroppers@ops.ietf.org; Sun, 10 Feb 2002 21:02:09 -0800 Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g1B52jG04656; Mon, 11 Feb 2002 12:02:47 +0700 (ICT) From: Robert Elz To: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= cc: "Scott Rose" , "DNSEXT WG Mailing list" Subject: Re: expired SIGs in an active zone In-Reply-To: <5.1.0.14.2.20020208123717.03268ca0@localhost> References: <5.1.0.14.2.20020208123717.03268ca0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Date: Mon, 11 Feb 2002 12:02:45 +0700 Message-ID: <4654.1013403765@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id AAA17568 Date: Fri, 08 Feb 2002 13:01:52 -0500 From: Ólafur Guðmundsson Message-ID: <5.1.0.14.2.20020208123717.03268ca0@localhost> This has been one of the wildest suggestions I've seen recently, even on namedroppers. | This brings us to what gets put into the answers: | Principle: Servers should never put known bad data into answers. That's certainly true. But an expired SIG isn't "known bad data" it is just data that you're not expecting will be of value to the receiver. If we start asking servers to edit their responses based upon what they believe that is actually going to be useful, or the even the server's theory of what is "bad", then we really are making a mess. Just consider another example - suppose a server is authoritative for its own name. That is, it holds its own A records. Suppose some client requests the server's A records. Since the server is monitoring its interfaces to watch for incoming packets, it is entirely believable that it might know that one of its addresses is not working right now. That is, that A record is "bad" (by some definition of bad anyway). Are you suggesting that in such circumstances, the server should omit that A record from its reply? More than that, the best way to diagnose the DNS is to send queries at servers, and evaluate the responses. The reason this works is that that's the one way that you can see exactly what the server is telling the world (no gazing at config files will ever achieve that). However, if servers start editing their responses, because the data is no longer useful, how is it ever going to be possible to really diagnose what is happening, and why? | From this principle authoritative servers should not put expired | signatures into answers. Recursive security aware servers MUST NOT | cache these signatures. No. If it is in the zone, it is valid data. That it might be useless to its user is irrelevant. Servers MUST serve the data they have been configured with, correct or not, useful or not. Anything else is anarchy. | Q1: Is it good enough to have the recursive servers purge the expired | signatures? A server implementation that noticed that a large bunch of signatures have expired could do an auto-update I guess, and delete them (and do everything else an automatic update of a zone file would do). This will not, and cannot, remove the sigs that it sent out a few seconds ago, and nor should the server start playing TTL tricks to cause those to be expired early (and certainly not without being certain that all the server for the zone are playing the exact same tricks - the TTL is a part of the RR, all authoritative servers for a zone must issue the same TTLs for the same RRs in answers). | Q2: What should a authoritative server do when it detects that | ALL signatures for the SOA or the whole zone are expired ? | My answer: Same as if the SOA was malformed, refuse to load the zone. This one is certainly just a quality of implementation issue. Different users are likely to want different results. A good implementation is likely to have a (per-zone probably) switch that can configure what will happen there (generate SERVFAIL, generate non auth answers, just act as if nothing happened and return expired SIGs, ...) kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 11 10:01:27 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04489 for ; Mon, 11 Feb 2002 10:01:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16aHgn-000NBy-00 for namedroppers-data@psg.com; Mon, 11 Feb 2002 06:44:17 -0800 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.33 #1) id 16aHgm-000NBs-00 for namedroppers@ops.ietf.org; Mon, 11 Feb 2002 06:44:16 -0800 Received: by as.vix.com (Postfix, from userid 716) id B878F28EB3; Mon, 11 Feb 2002 06:44:15 -0800 (PST) To: namedroppers@ops.ietf.org Subject: Re: expired SIGs in an active zone References: <5.1.0.14.2.20020208123717.03268ca0@localhost> <4654.1013403765@brandenburg.cs.mu.OZ.AU> From: Paul Vixie Date: 11 Feb 2002 06:44:15 -0800 In-Reply-To: <4654.1013403765@brandenburg.cs.mu.OZ.AU> Message-ID: Lines: 19 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Just consider another example - suppose a server is authoritative for its > own name. That is, it holds its own A records. Suppose some client= > requests the server's A records. Since the server is monitoring its > interfaces to watch for incoming packets, it is entirely believable that > it might know that one of its addresses is not working right now. That > is, that A record is "bad" (by some definition of bad anyway). Are you > suggesting that in such circumstances, the server should omit that A > record from its reply? i know you're trying to show a deliberate absurdity here, but you apparently don't know that a number of local- and wide-area load balancing products now on the market do EXACTLY that kind of editing. the designers of these products believe that DNS is a mapping function rather than a distributed coherent autonomous reliable database. there is no Truth to these implementations, only Opinion. so while it is absurd, it's not a good example of absurdity, because it's quite widespread and has even been spoken of with respect by some. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 11 11:09:45 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07505 for ; Mon, 11 Feb 2002 11:09:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16aInE-000PSO-00 for namedroppers-data@psg.com; Mon, 11 Feb 2002 07:55:00 -0800 Received: from pigeon.verisign.com ([65.205.251.71]) by psg.com with esmtp (Exim 3.33 #1) id 16aInE-000PSF-00; Mon, 11 Feb 2002 07:55:00 -0800 Received: from vhqpostal-gw2.verisign.com (verisign.com [65.205.251.56]) by pigeon.verisign.com (8.9.3/BCH1.7.1) with ESMTP id HAA09084; Mon, 11 Feb 2002 07:45:15 -0800 (PST) Received: by vhqpostal-gw2.verisign.com with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Feb 2002 07:55:59 -0800 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F40586995A@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Randy Bush'" , =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson?= Cc: Johan Ihren , DNSEXT mailing list Subject: RE: IETF-53 DNSEXT agenda requests Date: Mon, 11 Feb 2002 07:55:43 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1B314.8FA270F0" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1B314.8FA270F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Make sure the secretariat knows that DNSEXT is a security group with significant impact on other security area meetings. It is therefore very important that DNSEXT meet before SAAG (thurs afternoon) Phill Phillip Hallam-Baker FBCS C.Eng. Principal Scientist VeriSign Inc. pbaker@verisign.com 781 245 6996 x227 > -----Original Message----- > From: Randy Bush [mailto:randy@psg.com] > Sent: Sunday, February 10, 2002 3:03 PM > To: =D3lafur Gu=F0mundsson > Cc: Johan Ihren; DNSEXT mailing list > Subject: Re: IETF-53 DNSEXT agenda requests >=20 >=20 > it will change at least three times. if we bitch a lot, we could get > friday. >=20 > randy >=20 > to unsubscribe send a message to=20 > namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 ------_=_NextPart_000_01C1B314.8FA270F0 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C1B314.8FA270F0-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 11 13:38:20 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13602 for ; Mon, 11 Feb 2002 13:38:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16aL9t-0004z5-00 for namedroppers-data@psg.com; Mon, 11 Feb 2002 10:26:33 -0800 Received: from 208-59-114-172.c3-0.129-ubr1.lnh-129.md.cable.rcn.com ([208.59.114.172] helo=ogud.com) by psg.com with esmtp (Exim 3.33 #1) id 16aL9t-0004yz-00 for namedroppers@ops.ietf.org; Mon, 11 Feb 2002 10:26:33 -0800 Received: from oemcomputer.ogud.com (mail.dc.ogud.com [10.20.30.6]) by ogud.com (8.11.6/8.11.6) with ESMTP id g1BIQHj18575 for ; Mon, 11 Feb 2002 13:26:18 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <5.1.0.14.2.20020211131303.00a50aa0@localhost> X-Sender: post@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 11 Feb 2002 13:24:15 -0500 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: DNSSEC editing process Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA13602 The DNSEXT working group has started a rewrite of the DNSSEC specification into a documents that better reflect the protocol and allow a test plan to be constructed from the specification. To accomplish this, a team of volunteers has been formed to generate the documents. The document editing team is tasked with documenting the protocol as specified in RFC's generated by this group (and id's that have been passed on by the working group to the IESG). The editors are NOT ALLOWED to make ANY changes in the protocol. If clarifications are needed due to conflicting definitions, imprecise specification the editors MUST bring these issues to the attention of the working group on the namedroppers mailing list. To assist the editors, a small group of people with good understanding of DNSSEC have been recruited to review document drafts and answer questions that the editors have. For simplified communication a mailing list has been created, anyone can send messages to the editors via this mailing list DNSSEC-editors@east.isi.edu. Archive of this mailing list will be made available. Please send minor corrections, comments, suggestions about the DNSSECbis documents to dnssec-editors. All major issues should be brought up on namedroppers, editors MAY forward any correspondence to namedroppers, without asking permission, if they deem the issues raised require wider attention. DNSEXT co-chair Ólafur Guðmundsson approves new members on the dnssec-editors malling list. DNSSEC-editors is NOT a design group, it is a document maintenance group. The current members of the mailing list are: Editors: Dan Massey Scott Rose Matt Larson Roy Arends Advisors: Donald Eastlake Brian Wellington Edward Lewis Randy Bush Olafur Gudmundsson to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 11 14:12:09 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14304 for ; Mon, 11 Feb 2002 14:12:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16aLhb-0006CW-00 for namedroppers-data@psg.com; Mon, 11 Feb 2002 11:01:23 -0800 Received: from 208-59-114-172.c3-0.129-ubr1.lnh-129.md.cable.rcn.com ([208.59.114.172] helo=ogud.com) by psg.com with esmtp (Exim 3.33 #1) id 16aLha-0006CP-00 for namedroppers@ops.ietf.org; Mon, 11 Feb 2002 11:01:22 -0800 Received: from oemcomputer.ogud.com (mail.dc.ogud.com [10.20.30.6]) by ogud.com (8.11.6/8.11.6) with ESMTP id g1BJ16j18643; Mon, 11 Feb 2002 14:01:07 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <5.1.0.14.2.20020211135229.00a52ec0@localhost> X-Sender: post@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 11 Feb 2002 13:54:50 -0500 To: Paul Vixie , "DNSEXT WG Mailing list" From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: expired SIGs in an active zone In-Reply-To: <20020208173528.AACC328EB3@as.vix.com> References: <003201c1b0b9$c08d2b40$b9370681@antd.nist.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 12:35 PM 2/8/2002, Paul Vixie wrote: >i've got to say that last time i participated in a secret-handshake meeting >in a smoke filled back room that had the result of making a recommendation >to the namedroppers committee, we did a better job explaining our motives >in public than you've done here. what are the motives? 2535 requires the >clients and servers to have securely synchronized clocks. that means a >client, of either direct authoritative data or recursively cached data, >will know whether the signature is expired or not. why are you protecting >the client from something it HAS to be able to deal with ANYWAY? The whole point of this question was to get discussion started on what is acceptable behavior, proposing a particular behavior jump started the discussion. Olafur to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 11 14:14:23 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14390 for ; Mon, 11 Feb 2002 14:14:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16aLm9-0006ML-00 for namedroppers-data@psg.com; Mon, 11 Feb 2002 11:06:05 -0800 Received: from 208-59-114-172.c3-0.129-ubr1.lnh-129.md.cable.rcn.com ([208.59.114.172] helo=ogud.com) by psg.com with esmtp (Exim 3.33 #1) id 16aLm8-0006ME-00 for namedroppers@ops.ietf.org; Mon, 11 Feb 2002 11:06:04 -0800 Received: from oemcomputer.ogud.com (ns.dc.ogud.com [10.20.30.6]) by ogud.com (8.11.6/8.11.6) with ESMTP id g1BJ5oj18651 for ; Mon, 11 Feb 2002 14:05:50 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <5.1.0.14.2.20020211133821.03129210@localhost> X-Sender: post@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 11 Feb 2002 14:03:51 -0500 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Summary: What to do with expired signatures Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA14390 After reading all the messages posted, it is clear that the answer to the original question is applicable to nameserver behavior in general. Is it accurate to summarize the working group consensus as follows: Authorative servers: MUST accurately reflect the zone information supplied. No changes to the contents of the zone file contents are allowed, even if the server can detect errors in some records. Authorative servers SHOULD log any errors they detect in zone files. Caching servers: SHOULD keep all information supplied by authoritative servers unless provably not correct or irrelevant to the original query. Resolvers should ONLY use data that is relevant and temporarily correct, in addition the answer used MUST meet the local security requirements. Ólafur to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 11 14:54:21 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15447 for ; Mon, 11 Feb 2002 14:54:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16aMKP-0007k6-00 for namedroppers-data@psg.com; Mon, 11 Feb 2002 11:41:29 -0800 Received: from gemma.techfak.uni-bielefeld.de ([129.70.136.103]) by psg.com with esmtp (Exim 3.33 #1) id 16aMKO-0007k0-00 for namedroppers@ops.ietf.org; Mon, 11 Feb 2002 11:41:28 -0800 Received: from grimsvotn.TechFak.Uni-Bielefeld.DE (grimsvotn.TechFak.Uni-Bielefeld.DE [129.70.137.40]) by gemma.TechFak.Uni-Bielefeld.DE (8.9.1/8.9.1/TechFak/pk+ro20010720) with SMTP id UAA12670; Mon, 11 Feb 2002 20:41:25 +0100 (MET) Received: from localhost by grimsvotn.TechFak.Uni-Bielefeld.DE (SMI-8.6/pk19971205) id UAA26433; Mon, 11 Feb 2002 20:41:25 +0100 Message-Id: <200202111941.UAA26433@grimsvotn.TechFak.Uni-Bielefeld.DE> To: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Cc: namedroppers@ops.ietf.org Subject: Re: Summary: What to do with expired signatures In-reply-to: Your message of "Mon, 11 Feb 2002 14:03:51 EST." <5.1.0.14.2.20020211133821.03129210@localhost> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 Date: Mon, 11 Feb 2002 20:41:25 +0100 From: Peter Koch Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Authorative servers: MUST accurately reflect the zone information > supplied. No changes to the contents of the zone file contents are > allowed, even if the server can detect errors in some records. > Authorative servers SHOULD log any errors they detect in zone files. + "Servers MAY refuse to serve zones with errors entirely"? > Caching servers: SHOULD keep all information supplied by s/servers/resolvers/; > authoritative servers unless provably not correct or > irrelevant to the original query. This leaves undefined the bahavior w.r.t. non-auth answers received from other caching resolvers. Both should be treated equal. "provably incorrect" should be restricted to proof by DNSSEC or first hand DNS knowledge (like a copy of the zone in a mixed server/resolver environment). It's important to keep RRSets intact. -Peter to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 11 15:01:36 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15615 for ; Mon, 11 Feb 2002 15:01:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16aMSA-00083E-00 for namedroppers-data@psg.com; Mon, 11 Feb 2002 11:49:30 -0800 Received: from sentry.gw.tislabs.com ([192.94.214.100]) by psg.com with esmtp (Exim 3.33 #1) id 16aMS8-000837-00 for namedroppers@ops.ietf.org; Mon, 11 Feb 2002 11:49:29 -0800 Received: by sentry.gw.tislabs.com; id OAA17661; Mon, 11 Feb 2002 14:54:54 -0500 (EST) Received: from test.netsec.tislabs.com(199.171.39.2) by sentry.gw.tislabs.com via smap (V5.5) id xma017634; Mon, 11 Feb 02 14:54:16 -0500 X-Sender: lewis@192.35.165.115 Message-Id: In-Reply-To: <5.1.0.14.2.20020211133821.03129210@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 11 Feb 2002 14:48:02 -0500 To: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_?= =?iso-8859-1?Q?Gu=F0mundsson?= From: Edward Lewis Subject: Re: Summary: What to do with expired signatures Cc: namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA15615 Some comments. At 2:03 PM -0500 2/11/02, Ólafur Guðmundsson wrote: >After reading all the messages posted, it is clear that the answer >to the original question is applicable to nameserver behavior in >general. > >Is it accurate to summarize the working group consensus as follows: Do you mean: "Is it ... ?" or "It is ... :" >Authorative servers: MUST accurately reflect the zone information >supplied. No changes to the contents of the zone file contents are >allowed, even if the server can detect errors in some records. >Authorative servers SHOULD log any errors they detect in zone files. > >Caching servers: SHOULD keep all information supplied by >authoritative servers unless provably not correct or >irrelevant to the original query. "Not correct" for the time being or ever again? And as far as "unless provably not correct or irrelevant to the original query," this should be removed. Caching servers should not try to interpret the data they are "transiting"/as in caching. (Irrelevant - too loose because it could be twisted to mean that A records for unreachable addresses to the user would be culled from the set. This isn't what is desired.) >Resolvers should ONLY use data that is relevant and temporarily >correct, in addition the answer used MUST meet the local security >requirements. s/should/SHOULD/ s/use/return/ s/relevant/relevant to the query/ s/temporarily/temporally/ s/correct/valid/ Why "MUST meet the local security requirements?" Isn't that up to the application? (Remember that resolvers are the general users of the data, applications are.) Whose/which policy? What about the observation that caching servers use resolvers to admit data to the cache? Do these servers follow the rule for caching servers or resolvers? This is an instantiation of the check-on-receive vs. check-on-send issue. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Do you have the time to listen to me whine About nothing and everything all at once? -- Green Day ("Basket Case") Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 11 16:04:31 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17102 for ; Mon, 11 Feb 2002 16:04:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16aNTx-000AQX-00 for namedroppers-data@psg.com; Mon, 11 Feb 2002 12:55:25 -0800 Received: from dsl092-066-067.bos1.dsl.speakeasy.net ([66.92.66.67] helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.33 #1) id 16aNTx-000AQR-00 for namedroppers@ops.ietf.org; Mon, 11 Feb 2002 12:55:25 -0800 Received: from thrintun.hactrn.net (localhost [127.0.0.1]) by thrintun.hactrn.net (Postfix) with ESMTP id ECE2F1B91 for ; Mon, 11 Feb 2002 15:55:23 -0500 (EST) Date: Mon, 11 Feb 2002 15:55:23 -0500 Message-ID: <86eljragck.wl@thrintun.hactrn.net> From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: Summary: What to do with expired signatures In-Reply-To: References: <5.1.0.14.2.20020211133821.03129210@localhost> User-Agent: Wanderlust/2.4.1 (Stand By Me) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Mon, 11 Feb 2002 14:48:02 -0500, Edward Lewis wrote: > > What about the observation that caching servers use resolvers to admit data > to the cache? Do these servers follow the rule for caching servers or > resolvers? This is an instantiation of the check-on-receive vs. > check-on-send issue. "caching server" == an entity that supports both the "resolver role" (including the optional cache) and the "name server role". An entity acting in the resolver role isn't -required- to cache anything. There are some rules it has to follow if it does cache stuff, eg, it must not cache partial RRsets or merge RRsets. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 11 16:06:24 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17133 for ; Mon, 11 Feb 2002 16:06:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16aNTn-000APE-00 for namedroppers-data@psg.com; Mon, 11 Feb 2002 12:55:15 -0800 Received: from is1-50.antd.nist.gov ([129.6.50.251]) by psg.com with esmtp (Exim 3.33 #1) id 16aNTm-000AOr-00 for namedroppers@ops.ietf.org; Mon, 11 Feb 2002 12:55:14 -0800 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by is1-50.antd.nist.gov (8.9.3/8.9.3) with SMTP id PAA18013 for ; Mon, 11 Feb 2002 15:55:12 -0500 (EST) Message-ID: <014001c1b33d$bf4dabc0$b9370681@antd.nist.gov> From: "Scott Rose" To: References: Subject: Re: Summary: What to do with expired signatures Date: Mon, 11 Feb 2002 15:50:32 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit ----- Original Message ----- From: "Edward Lewis" To: "Ólafur Guðmundsson" Cc: Sent: Monday, February 11, 2002 2:48 PM Subject: Re: Summary: What to do with expired signatures > Some comments. > > At 2:03 PM -0500 2/11/02, Ólafur Guðmundsson wrote: > >After reading all the messages posted, it is clear that the answer > >to the original question is applicable to nameserver behavior in > >general. > > > >Is it accurate to summarize the working group consensus as follows: > > Do you mean: "Is it ... ?" or "It is ... :" > I take this as "It is..." > >Authorative servers: MUST accurately reflect the zone information > >supplied. No changes to the contents of the zone file contents are > >allowed, even if the server can detect errors in some records. > >Authorative servers SHOULD log any errors they detect in zone files. > > > >Caching servers: SHOULD keep all information supplied by > >authoritative servers unless provably not correct or > >irrelevant to the original query. > > "Not correct" for the time being or ever again? > I think it should be "ever again" - however, there is the problem of SIGs with inception times in the future. What if a SIG has an inception time 1 day in the future, but the TTL for the SIG and RRSet it covers is only 1 hour? it would be purged from the cache before the signature could be considered valid. Scott to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 11 16:22:31 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17543 for ; Mon, 11 Feb 2002 16:22:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16aNnf-000BFw-00 for namedroppers-data@psg.com; Mon, 11 Feb 2002 13:15:47 -0800 Received: from sentry.gw.tislabs.com ([192.94.214.100]) by psg.com with esmtp (Exim 3.33 #1) id 16aNne-000BFp-00 for namedroppers@ops.ietf.org; Mon, 11 Feb 2002 13:15:46 -0800 Received: by sentry.gw.tislabs.com; id QAA22772; Mon, 11 Feb 2002 16:21:12 -0500 (EST) Received: from test.netsec.tislabs.com(199.171.39.2) by sentry.gw.tislabs.com via smap (V5.5) id xma022686; Mon, 11 Feb 02 16:20:13 -0500 X-Sender: lewis@192.35.165.115 Message-Id: In-Reply-To: <86eljragck.wl@thrintun.hactrn.net> References: <5.1.0.14.2.20020211133821.03129210@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 11 Feb 2002 16:13:54 -0500 To: Rob Austein From: Edward Lewis Subject: Re: Summary: What to do with expired signatures Cc: namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 3:55 PM -0500 2/11/02, Rob Austein wrote: >"caching server" == an entity that supports both the "resolver role" >(including the optional cache) and the "name server role". Granted, my comment was meant to be more rhetorical, Olafur's message talked about the caching server as separate from the resolver. >An entity acting in the resolver role isn't -required- to cache >anything. There are some rules it has to follow if it does cache >stuff, eg, it must not cache partial RRsets or merge RRsets. Since the earlier comment about middlebox, I was beginning to wonder about the rules in 2181. This helps put 2181 in perspective, it makes the the servers "in the middle" do the right thing as opposed to applying judgements. The point that I was troubled over was whether "credibility" was a judgement. It is, but the judgement is based on objective protocol data (section, whether the answer is reported to be authoritative) and not a policy (as most DNSSEC decisions are). -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Do you have the time to listen to me whine About nothing and everything all at once? -- Green Day ("Basket Case") Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 11 18:35:52 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20343 for ; Mon, 11 Feb 2002 18:35:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16aPie-000GOb-00 for namedroppers-data@psg.com; Mon, 11 Feb 2002 15:18:44 -0800 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.33 #1) id 16aPic-000GOU-00 for namedroppers@ops.ietf.org; Mon, 11 Feb 2002 15:18:43 -0800 Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id SAA18866; Mon, 11 Feb 2002 18:18:41 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id SAA10031; Mon, 11 Feb 2002 18:18:33 -0500 (EST) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id SAA12680; Mon, 11 Feb 2002 18:18:24 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id SAA22500; Mon, 11 Feb 2002 18:18:23 -0500 (EST) To: "Scott Rose" Cc: Subject: Re: Summary: What to do with expired signatures References: <014001c1b33d$bf4dabc0$b9370681@antd.nist.gov> From: Derek Atkins Date: 11 Feb 2002 18:18:23 -0500 In-Reply-To: <014001c1b33d$bf4dabc0$b9370681@antd.nist.gov> Message-ID: Lines: 19 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk "Scott Rose" writes: > I think it should be "ever again" - however, there is the problem of SIGs > with inception times in the future. What if a SIG has an inception time 1 > day in the future, but the TTL for the SIG and RRSet it covers is only 1 > hour? it would be purged from the cache before the signature could be > considered valid. Yea? So? What's the problem with that? > Scott -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 11 23:37:52 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25614 for ; Mon, 11 Feb 2002 23:37:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16aUSn-0002iq-00 for namedroppers-data@psg.com; Mon, 11 Feb 2002 20:22:41 -0800 Received: from alb216-fre2.pangeatech.com ([65.192.23.216] helo=spratly.nominum.com) by psg.com with esmtp (Exim 3.33 #1) id 16aUSm-0002ik-00 for namedroppers@ops.ietf.org; Mon, 11 Feb 2002 20:22:40 -0800 Received: from localhost (bwelling@localhost) by spratly.nominum.com (8.11.6/8.11.6) with ESMTP id g1C4MV332330; Mon, 11 Feb 2002 20:22:31 -0800 X-Authentication-Warning: spratly.nominum.com: bwelling owned process doing -bs Date: Mon, 11 Feb 2002 20:22:31 -0800 (PST) From: Brian Wellington X-X-Sender: To: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= cc: Subject: Re: Summary: What to do with expired signatures In-Reply-To: <5.1.0.14.2.20020211133821.03129210@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8BIT On Mon, 11 Feb 2002, Ólafur Guðmundsson wrote: > Authorative servers: MUST accurately reflect the zone information > supplied. No changes to the contents of the zone file contents are > allowed, even if the server can detect errors in some records. > Authorative servers SHOULD log any errors they detect in zone files. Is it the feeling of the working group that expired signatures are considered an error? Brian to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 12 00:02:04 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25940 for ; Tue, 12 Feb 2002 00:02:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16aUs7-0003x4-00 for namedroppers-data@psg.com; Mon, 11 Feb 2002 20:48:51 -0800 Received: from alb216-fre2.pangeatech.com ([65.192.23.216] helo=spratly.nominum.com) by psg.com with esmtp (Exim 3.33 #1) id 16aUs6-0003wy-00 for namedroppers@ops.ietf.org; Mon, 11 Feb 2002 20:48:50 -0800 Received: from localhost (bwelling@localhost) by spratly.nominum.com (8.11.6/8.11.6) with ESMTP id g1C4m5h32726; Mon, 11 Feb 2002 20:48:05 -0800 X-Authentication-Warning: spratly.nominum.com: bwelling owned process doing -bs Date: Mon, 11 Feb 2002 20:48:05 -0800 (PST) From: Brian Wellington X-X-Sender: To: Derek Atkins cc: =?iso-8859-1?q?=D3lafur_Gu=F0mundsson?= , Subject: Re: Summary: What to do with expired signatures In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8BIT On 11 Feb 2002, Derek Atkins wrote: > Brian Wellington writes: > > > On Mon, 11 Feb 2002, Ólafur Guðmundsson wrote: > > > > > Authorative servers SHOULD log any errors they detect in zone files. > > > > Is it the feeling of the working group that expired signatures are > > considered an error? > > I believe that, in terms of server _LOGGING_, expired signatures > should be considered errors. I do NOT believe that a single expired > signature should cause the zone-load to fail. Sounds pretty reasonable to me. Brian to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 12 00:09:43 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26044 for ; Tue, 12 Feb 2002 00:09:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16aV1d-0004QQ-00 for namedroppers-data@psg.com; Mon, 11 Feb 2002 20:58:41 -0800 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.33 #1) id 16aV1b-0004QC-00 for namedroppers@ops.ietf.org; Mon, 11 Feb 2002 20:58:39 -0800 Received: from isc.org (localhost.dv.isc.org [127.0.0.1]) by drugs.dv.isc.org (8.11.6/8.11.2) with ESMTP id g1C4ses78307 for ; Tue, 12 Feb 2002 15:54:41 +1100 (EST) (envelope-from marka@isc.org) Message-Id: <200202120454.g1C4ses78307@drugs.dv.isc.org> To: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: Summary: What to do with expired signatures In-reply-to: Your message of "Mon, 11 Feb 2002 20:22:31 -0800." Date: Tue, 12 Feb 2002 15:54:40 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > On Mon, 11 Feb 2002, Ólafur Guðmundsson wrote: > > > Authorative servers: MUST accurately reflect the zone information > > supplied. No changes to the contents of the zone file contents are > > allowed, even if the server can detect errors in some records. > > Authorative servers SHOULD log any errors they detect in zone files. > > Is it the feeling of the working group that expired signatures are > considered an error? > > Brian They are not errors. Just interesting data. If it was a error the zone should not be served at all. Mark > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 12 03:58:33 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06360 for ; Tue, 12 Feb 2002 03:58:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16aYbM-000Eu2-00 for namedroppers-data@psg.com; Tue, 12 Feb 2002 00:47:48 -0800 Received: from 96-1.nat.psu.ac.th ([202.28.96.1] helo=brandenburg.cs.mu.OZ.AU) by psg.com with esmtp (Exim 3.33 #1) id 16aYbB-000ElO-00 for namedroppers@ops.ietf.org; Tue, 12 Feb 2002 00:47:38 -0800 Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g1C8kVa02886; Tue, 12 Feb 2002 15:46:37 +0700 (ICT) From: Robert Elz To: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= cc: namedroppers@ops.ietf.org Subject: Re: Summary: What to do with expired signatures In-Reply-To: <5.1.0.14.2.20020211133821.03129210@localhost> References: <5.1.0.14.2.20020211133821.03129210@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Date: Tue, 12 Feb 2002 15:46:31 +0700 Message-ID: <2884.1013503591@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA06360 Date: Mon, 11 Feb 2002 14:03:51 -0500 From: Ólafur Guðmundsson Message-ID: <5.1.0.14.2.20020211133821.03129210@localhost> | Authorative servers: MUST accurately reflect the zone information | supplied. No changes to the contents of the zone file contents are | allowed, even if the server can detect errors in some records. | Authorative servers SHOULD log any errors they detect in zone files. Looks OK to me. | Caching servers: SHOULD keep all information supplied by | authoritative servers unless provably not correct or | irrelevant to the original query. Caches (to side step the question of whether a cache is a server or a resolver...) keep whatever they like, for as long as they like, within the TTL bounds. They don't have to cache anything. So SHOULD is too strong. Of course a cache that caches nothing wouldn't be a very useful product, but it still compiles... What is relevant to the question here is that caches should not be making value judgements on the data (based upon what they see as worth keeping, and what is not). The 2181 rules that someone mentioned relate to what happens when the cache (or a resolver even, though without a cache it is very unlikely) has conflicting data, wants to keep some, and has to decide which to retain. | Resolvers should ONLY use data that is relevant and temporarily | correct, in addition the answer used MUST meet the local security | requirements. Resolvers just fetch data from the servers and return it to the application. It is beyond our scope to decide what data the application uses, or why. It is also beyond our scope to lay down boundaries between what is implemented as part of a set of functions an implementor calls "the resolver" and the rest of the application - if "the resolver" wants to do SIG verification in some implementation, that's fine, if another wants to simply pass SIGs back to he application for it to verify, that is also fine. kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 12 08:36:20 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10799 for ; Tue, 12 Feb 2002 08:36:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16acsR-0001o8-00 for namedroppers-data@psg.com; Tue, 12 Feb 2002 05:21:43 -0800 Received: from is1-50.antd.nist.gov ([129.6.50.251]) by psg.com with esmtp (Exim 3.33 #1) id 16acsQ-0001o1-00 for namedroppers@ops.ietf.org; Tue, 12 Feb 2002 05:21:42 -0800 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by is1-50.antd.nist.gov (8.9.3/8.9.3) with SMTP id IAA00641 for ; Tue, 12 Feb 2002 08:21:38 -0500 (EST) Message-ID: <008701c1b3c7$8e7cec60$b9370681@antd.nist.gov> From: "Scott Rose" To: References: <014001c1b33d$bf4dabc0$b9370681@antd.nist.gov> Subject: Re: Summary: What to do with expired signatures Date: Tue, 12 Feb 2002 08:16:58 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Not a "major" problem, but not a wise thing to do if an admin wants their DNS data to be accepted by other servers. If there is at least one SIG in a set that is valid (cryptographically and temoraly) then no problem. SIGs that are not valid can easily be dropped, since it makes no sense storing them. It's an implementation detail. Still fighting the urge to save clueless admins from themselves I guess. :) Scott ----- Original Message ----- From: "Derek Atkins" To: "Scott Rose" Cc: Sent: Monday, February 11, 2002 6:18 PM Subject: Re: Summary: What to do with expired signatures > "Scott Rose" writes: > > > I think it should be "ever again" - however, there is the problem of SIGs > > with inception times in the future. What if a SIG has an inception time 1 > > day in the future, but the TTL for the SIG and RRSet it covers is only 1 > > hour? it would be purged from the cache before the signature could be > > considered valid. > > Yea? So? What's the problem with that? > > > Scott > > -derek > > -- > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > Member, MIT Student Information Processing Board (SIPB) > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > warlord@MIT.EDU PGP key available to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 12 09:34:13 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13231 for ; Tue, 12 Feb 2002 09:34:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16ado7-0004p0-00 for namedroppers-data@psg.com; Tue, 12 Feb 2002 06:21:19 -0800 Received: from sentry.gw.tislabs.com ([192.94.214.100]) by psg.com with esmtp (Exim 3.33 #1) id 16ado6-0004oq-00 for namedroppers@ops.ietf.org; Tue, 12 Feb 2002 06:21:18 -0800 Received: by sentry.gw.tislabs.com; id JAA15373; Tue, 12 Feb 2002 09:26:44 -0500 (EST) Received: from test.netsec.tislabs.com(199.171.39.2) by sentry.gw.tislabs.com via smap (V5.5) id xma015288; Tue, 12 Feb 02 09:25:47 -0500 X-Sender: lewis@192.35.165.115 Message-Id: In-Reply-To: <008701c1b3c7$8e7cec60$b9370681@antd.nist.gov> References: <014001c1b33d$bf4dabc0$b9370681@an td.nist.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 12 Feb 2002 09:19:33 -0500 To: "Scott Rose" From: Edward Lewis Subject: Re: Summary: What to do with expired signatures Cc: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 8:16 AM -0500 2/12/02, Scott Rose wrote: >SIGs that are not valid can easily be dropped, since it makes no sense >storing them. It's an implementation detail. I think the issue is a bit more significant than an implementation detail. Personally, this thread has convinced me that the servers should not edit zones in any way. Putting in "shortcuts" for "efficiency" is how complexity creeps into the design and becomes threatens scaleability (depending on how scaleability is defined). By scaleability I mean: a growth in the number of servers, a growth in the interaction of servers. I'm excluding growth in the size of messages - an obvious consequence of servers editing (downward in size) the responses. Dynamic delete is an exception. It is an acceptable exception in that dynamic update is sufficiently independent of the action of publishing/distributing data. It is a complication of the zone loading process, not the zone serving process. Is a signature that has passed its expiration date a protocol error? No, its a data error, like a bad A record. Is a missing SOA record a protocol error. Yes. My point is that servers should (according to specifications) stick to reporting protocol errors and not data errors. An implementation is free to add other reporting, the freedom is determined by the implementation's users, but this should not enter the specification process. I understand the desire to make things easier for the administrators. I don't think this desire belongs in the protocol specifications but perhaps in implementation guidance, perhaps BCP's. OTOH - to an administrator, multiple tools means complexity, a single tool is simpler (even if the guts of it are complex). There is a tradeoff of simplicity to the protocol and simplicity to the user. Hmmmm. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Do you have the time to listen to me whine About nothing and everything all at once? -- Green Day ("Basket Case") Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 12 09:50:11 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13720 for ; Tue, 12 Feb 2002 09:50:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16ae6h-0005fW-00 for namedroppers-data@psg.com; Tue, 12 Feb 2002 06:40:31 -0800 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.33 #1) id 16ae6g-0005fQ-00 for namedroppers@ops.ietf.org; Tue, 12 Feb 2002 06:40:30 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id AC25F28EB3 for ; Tue, 12 Feb 2002 06:40:29 -0800 (PST) (envelope-from vixie@as.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Summary: What to do with expired signatures In-Reply-To: Message from Edward Lewis of "Tue, 12 Feb 2002 09:19:33 EST." X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.1 Date: Tue, 12 Feb 2002 06:40:29 -0800 Message-Id: <20020212144029.AC25F28EB3@as.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > I think the issue is a bit more significant than an implementation detail. > Personally, this thread has convinced me that the servers should not edit > zones in any way. I was astounded that anyone here even thought that that was debatable. > Dynamic delete is an exception. It is an acceptable exception in that > dynamic update is sufficiently independent of the action of > publishing/distributing data. It is a complication of the zone loading > process, not the zone serving process. The zone whatting process? I have here a server with persistent zone storate. All zone changes are made by RFC2136 "UPDATE" requests. There is no "load" and there is no "zone file" and there is no way to map your "implied delete" to any process that it has. Yet this server is entirely protocol compliant. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 12 10:21:24 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14928 for ; Tue, 12 Feb 2002 10:21:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16aeX3-0006fB-00 for namedroppers-data@psg.com; Tue, 12 Feb 2002 07:07:45 -0800 Received: from sentry.gw.tislabs.com ([192.94.214.100]) by psg.com with esmtp (Exim 3.33 #1) id 16aeX2-0006f5-00 for namedroppers@ops.ietf.org; Tue, 12 Feb 2002 07:07:44 -0800 Received: by sentry.gw.tislabs.com; id KAA19646; Tue, 12 Feb 2002 10:13:11 -0500 (EST) Received: from test.netsec.tislabs.com(199.171.39.2) by sentry.gw.tislabs.com via smap (V5.5) id xma019623; Tue, 12 Feb 02 10:12:38 -0500 X-Sender: lewis@192.35.165.115 Message-Id: In-Reply-To: <20020212144029.AC25F28EB3@as.vix.com> References: Message from Edward Lewis of "Tue, 12 Feb 2002 09:19:33 EST." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 12 Feb 2002 10:06:22 -0500 To: Paul Vixie From: Edward Lewis Subject: Re: Summary: What to do with expired signatures Cc: namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 9:40 AM -0500 2/12/02, Paul Vixie wrote: >> I think the issue is a bit more significant than an implementation detail. >> Personally, this thread has convinced me that the servers should not edit >> zones in any way. > >I was astounded that anyone here even thought that that was debatable. I'm confused by this response. Are you saying that this issue "is" just an implementation detail? Or are you saying that "servers should not edit zones" is undebateable? >> Dynamic delete is an exception. It is an acceptable exception in that >> dynamic update is sufficiently independent of the action of >> publishing/distributing data. It is a complication of the zone loading >> process, not the zone serving process. > >The zone whatting process? I have here a server with persistent zone storate. >All zone changes are made by RFC2136 "UPDATE" requests. There is no "load" >and there is no "zone file" and there is no way to map your "implied delete" >to any process that it has. Yet this server is entirely protocol compliant. This is entirely philosophical: Dynamic update accomplishes the same thing as sending a change request to the appropriate person, editing the zone file and reloading the zone. The serial number is updated, and the if the zone is signed, new signatures are produced as needed. Dynamic update does this much more quickly than the "old" way. That's why I said that dynamic update is related to zone loading. As far as being a "complication," dynamic update is a new process - meaning that there are now more ways to get data into a zone. The fact that this is protocol compliant isn't a debate. I was just trying to decide if dynamic update was a symptom of middleboxness or not. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Do you have the time to listen to me whine About nothing and everything all at once? -- Green Day ("Basket Case") Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 12 10:51:36 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15921 for ; Tue, 12 Feb 2002 10:51:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16af3E-0007Uv-00 for namedroppers-data@psg.com; Tue, 12 Feb 2002 07:41:00 -0800 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.33 #1) id 16af3E-0007Up-00 for namedroppers@ops.ietf.org; Tue, 12 Feb 2002 07:41:00 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id A559D28EB3 for ; Tue, 12 Feb 2002 07:40:59 -0800 (PST) (envelope-from vixie@as.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Summary: What to do with expired signatures In-Reply-To: Message from Edward Lewis of "Tue, 12 Feb 2002 10:06:22 EST." X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.1 Date: Tue, 12 Feb 2002 07:40:59 -0800 Message-Id: <20020212154059.A559D28EB3@as.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > ... Or are you saying that "servers should not edit zones" is undebateable? Yes. > ... That's why I said that dynamic update is related to zone loading. > As far as being a "complication," dynamic update is a new process - > meaning that there are now more ways to get data into a zone. Some folks here have suggested, both in this thread and in threads past, that a zone server ought to be free to elide some nodes or RRs during its "loading" process, and still serve the resulting (implicitly) edited data. I'm now coming to the conclusion that "zone loading" should be deposited in the same dustbin as "zone file format." I was shocked to see $TTL codified since there were, even at that time, totally compliant (on the wire) DNS implementations which had no concept of a "zone file" or "loading." The standard ought to talk about what's on the wire and what to do with stuff you got off the wire and what to put on the wire (and when and why), not implementation details like "zone file format" or "zone loading." If we re-turn RFC 1034/5 I will strongly recommend that all descriptions of "zone file format" be given BCP status. A correct and complete DNS implementation ought not have to deal with these historical card images unless its implementor wants to offer a backward-compatibility crutch. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 12 11:13:37 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16745 for ; Tue, 12 Feb 2002 11:13:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16afOC-00085J-00 for namedroppers-data@psg.com; Tue, 12 Feb 2002 08:02:40 -0800 Received: from dsl092-066-067.bos1.dsl.speakeasy.net ([66.92.66.67] helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.33 #1) id 16afOB-00085D-00 for namedroppers@ops.ietf.org; Tue, 12 Feb 2002 08:02:39 -0800 Received: from thrintun.hactrn.net (localhost [127.0.0.1]) by thrintun.hactrn.net (Postfix) with ESMTP id D50501BC8 for ; Tue, 12 Feb 2002 11:02:38 -0500 (EST) Date: Tue, 12 Feb 2002 11:02:38 -0500 Message-ID: <86sn86eli9.wl@thrintun.hactrn.net> From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: Summary: What to do with expired signatures In-Reply-To: References: <20020212144029.AC25F28EB3@as.vix.com> User-Agent: Wanderlust/2.4.1 (Stand By Me) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I don't see dynamic update as a middlebox thing. As Ed suggests, conceptually it's equivalent to updating a zone file followed by loading that zone file; the fact that a clever implementation might be able to optimize this so completely that the zone file per se doesn't exist anymore doesn't really change the model. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 12 11:15:08 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16817 for ; Tue, 12 Feb 2002 11:15:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16afSZ-0008CV-00 for namedroppers-data@psg.com; Tue, 12 Feb 2002 08:07:11 -0800 Received: from sentry.gw.tislabs.com ([192.94.214.100]) by psg.com with esmtp (Exim 3.33 #1) id 16afSY-0008CO-00 for namedroppers@ops.ietf.org; Tue, 12 Feb 2002 08:07:10 -0800 Received: by sentry.gw.tislabs.com; id LAA24356; Tue, 12 Feb 2002 11:12:36 -0500 (EST) Received: from test.netsec.tislabs.com(199.171.39.2) by sentry.gw.tislabs.com via smap (V5.5) id xma024337; Tue, 12 Feb 02 11:12:33 -0500 X-Sender: lewis@192.35.165.115 Message-Id: In-Reply-To: <20020212154059.A559D28EB3@as.vix.com> References: Message from Edward Lewis of "Tue, 12 Feb 2002 10:06:22 EST." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 12 Feb 2002 11:06:17 -0500 To: Paul Vixie From: Edward Lewis Subject: Re: Summary: What to do with expired signatures Cc: namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 10:40 AM -0500 2/12/02, Paul Vixie wrote: >I'm now coming to the conclusion that "zone loading" should be deposited in >the same dustbin as "zone file format." ... >... The >standard ought to talk about what's on the wire and what to do with stuff >you got off the wire and what to put on the wire (and when and why), not >implementation details like "zone file format" or "zone loading." You are right. I perceive that there has been a tendency for discussions and documents to stray from the mission of specifying protocols and from the goal of interoperability. Given that there is but one testbable implementation of RFC 2535, it has become easy to confuse that implementation with the protocol. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Do you have the time to listen to me whine About nothing and everything all at once? -- Green Day ("Basket Case") Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 12 11:28:51 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17188 for ; Tue, 12 Feb 2002 11:28:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16affA-0008Zm-00 for namedroppers-data@psg.com; Tue, 12 Feb 2002 08:20:12 -0800 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.33 #1) id 16aff9-0008Zg-00 for namedroppers@ops.ietf.org; Tue, 12 Feb 2002 08:20:11 -0800 Received: from shell.nominum.com (localhost [127.0.0.1]) by shell.nominum.com (Postfix) with ESMTP id A65A83190C; Tue, 12 Feb 2002 08:20:10 -0800 (PST) To: Edward Lewis Cc: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: Summary: What to do with expired signatures In-Reply-To: Message from Edward Lewis of "Tue, 12 Feb 2002 11:06:17 EST." Date: Tue, 12 Feb 2002 08:20:10 -0800 Message-ID: <41600.1013530810@shell.nominum.com> From: Jim Reid Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Edward" == Edward Lewis writes: Edward> Given that there is but one testbable Edward> implementation of RFC 2535, it has become easy to confuse Edward> that implementation with the protocol. Doesn't Olaf's Perl version of 2535 qualify as a second implementation? IIRC it found a bug in the BIND footprint calculation. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 12 11:42:21 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17811 for ; Tue, 12 Feb 2002 11:42:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16afoy-0008oa-00 for namedroppers-data@psg.com; Tue, 12 Feb 2002 08:30:20 -0800 Received: from sentry.gw.tislabs.com ([192.94.214.100]) by psg.com with esmtp (Exim 3.33 #1) id 16afox-0008oO-00 for namedroppers@ops.ietf.org; Tue, 12 Feb 2002 08:30:19 -0800 Received: by sentry.gw.tislabs.com; id LAA26803; Tue, 12 Feb 2002 11:35:45 -0500 (EST) Received: from test.netsec.tislabs.com(199.171.39.2) by sentry.gw.tislabs.com via smap (V5.5) id xma026705; Tue, 12 Feb 02 11:34:58 -0500 X-Sender: lewis@192.35.165.115 Message-Id: In-Reply-To: <41600.1013530810@shell.nominum.com> References: Message from Edward Lewis of "Tue, 12 Feb 2002 11:06:17 EST." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 12 Feb 2002 11:28:41 -0500 To: Jim Reid From: Edward Lewis Subject: Re: Summary: What to do with expired signatures Cc: namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I'd have to ask Olaf. If it is, I should put it into use. At 11:20 AM -0500 2/12/02, Jim Reid wrote: >>>>>> "Edward" == Edward Lewis writes: > > Edward> Given that there is but one testbable > Edward> implementation of RFC 2535, it has become easy to confuse > Edward> that implementation with the protocol. > >Doesn't Olaf's Perl version of 2535 qualify as a second implementation? >IIRC it found a bug in the BIND footprint calculation. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Do you have the time to listen to me whine About nothing and everything all at once? -- Green Day ("Basket Case") Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 12 16:18:55 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27636 for ; Tue, 12 Feb 2002 16:18:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16ak2y-000FCL-00 for namedroppers-data@psg.com; Tue, 12 Feb 2002 13:01:04 -0800 Received: from roam.psg.com ([147.28.4.2]) by psg.com with esmtp (Exim 3.33 #1) id 16ak2x-000FCE-00 for namedroppers@ops.ietf.org; Tue, 12 Feb 2002 13:01:04 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16ak2z-0006Dd-00; Tue, 12 Feb 2002 16:01:05 -0500 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: Summary: What to do with expired signatures References: <20020212144029.AC25F28EB3@as.vix.com> Message-Id: Date: Tue, 12 Feb 2002 16:01:05 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> I think the issue is a bit more significant than an implementation detail. >> Personally, this thread has convinced me that the servers should not edit >> zones in any way. > I was astounded that anyone here even thought that that was debatable. i believe that http://ops.ietf.org/lists/namedroppers/2001/... has a long and interesting discussion of the subject based on a difference between two prominent implementations. > All zone changes are made by RFC2136 "UPDATE" requests. There is no > "load" and there is no "zone file" and there is no way to map your > "implied delete" to any process that it has. Yet this server is entirely > protocol compliant. as the docs do specify a zone file and format, this is interesting. randy to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 12 21:36:32 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05003 for ; Tue, 12 Feb 2002 21:36:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16ap1o-000M1t-00 for namedroppers-data@psg.com; Tue, 12 Feb 2002 18:20:12 -0800 Received: from mx05.gis.net ([208.218.130.13] helo=gis.net) by psg.com with esmtp (Exim 3.33 #1) id 16ap1n-000M1n-00 for namedroppers@ops.ietf.org; Tue, 12 Feb 2002 18:20:11 -0800 Received: from tecotoo.www.gis.net ([216.41.49.203]) by mx05.gis.net; Tue, 12 Feb 2002 21:20:07 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by tecotoo.www.gis.net (NTMail 3.02.13) with ESMTP id da026237 for ; Tue, 12 Feb 2002 20:56:30 -0500 Message-Id: <4.3.1.2.20020212205456.00db0610@pop.gis.net> X-Sender: mayer@pop.gis.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Tue, 12 Feb 2002 20:56:19 -0500 To: namedroppers@ops.ietf.org From: Danny Mayer Subject: Re: Summary: What to do with expired signatures In-Reply-To: <200202120454.g1C4ses78307@drugs.dv.isc.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-Info: NTMail 3.02 Server on TECOTOO Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA05003 At 11:54 PM 2/11/02, Mark.Andrews@isc.org wrote: > > On Mon, 11 Feb 2002, Ólafur Guðmundsson wrote: > > > > > Authorative servers: MUST accurately reflect the zone information > > > supplied. No changes to the contents of the zone file contents are > > > allowed, even if the server can detect errors in some records. > > > Authorative servers SHOULD log any errors they detect in zone files. > > > > Is it the feeling of the working group that expired signatures are > > considered an error? > > > > Brian > > They are not errors. Just interesting data. If it was a > error the zone should not be served at all. > > Mark Not only that, a signature could expire while it's loaded. It may have been perfectly valid during the load of the zone. Danny to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 13 03:46:31 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23593 for ; Wed, 13 Feb 2002 03:46:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16auqS-0003bH-00 for namedroppers-data@psg.com; Wed, 13 Feb 2002 00:32:52 -0800 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.33 #1) id 16auqR-0003bB-00 for namedroppers@ops.ietf.org; Wed, 13 Feb 2002 00:32:51 -0800 Received: from x50 (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.11.6/8.11.6) with SMTP id g1D8WiN06205; Wed, 13 Feb 2002 09:32:44 +0100 Date: Wed, 13 Feb 2002 09:32:43 +0100 From: "Olaf M. Kolkman" To: Jim Reid Cc: lewis@tislabs.com, paul@vix.com, namedroppers@ops.ietf.org Subject: Re: Summary: What to do with expired signatures Message-Id: <20020213093243.0ca11b52.olaf@ripe.net> In-Reply-To: <41600.1013530810@shell.nominum.com> References: <41600.1013530810@shell.nominum.com> Organization: RIPE NCC X-Mailer: Sylpheed version 0.7.0 (GTK+ 1.2.9; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tue, 12 Feb 2002 08:20:10 -0800 Jim Reid wrote: > >>>>> "Edward" == Edward Lewis writes: > > Edward> Given that there is but one testbable > Edward> implementation of RFC 2535, it has become easy to confuse > Edward> that implementation with the protocol. > > Doesn't Olaf's Perl version of 2535 qualify as a second implementation? > IIRC it found a bug in the BIND footprint calculation. > FYI: I have added the SIG, KEY, NXT and DS classes to Net::DNS that means you can read these records from a zone file and 'translate' them into wireformat and vice verse. Off course wire-wire is also possible :-). The SIG class has methods to create RSA and DSA signatures using keys generated by the bind tools but does not use the openssl libraries. The SIG class also can verify signatures, made by bind signer's and itself. The DS class has a create method that creates a DS RR from a given key. The (original) Net::DNS packet had resolver functionality and there is some server functionality in the 0.19 alpha version. I am working on a Zone object that can be used as to build a server in perl but that is still pre-alpha. (If you are interested in playing with it please contact me). As for the verifying resolver: all the classes to build such a thing are there but it does need to be done. As soon as there is a server that does DS-style serving and/or I have some time I will to make a verifying resolver using the perl tools. --Olaf "Original" Net::DNS on http://www.fuhr.org/~mfuhr/perldns/ DNSSEC extensions are build against the 0.19 development version of Net::DNS and can be found on: http://www.ripe.net/disi/SRC/Net-DNS-0.19-DNSSEC-0.5.tar.gz --------------------------------------------| Olaf M. Kolkman | www.ripe.net/disi to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 13 15:41:20 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20168 for ; Wed, 13 Feb 2002 15:41:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16b5vD-000ENI-00 for namedroppers-data@psg.com; Wed, 13 Feb 2002 12:22:31 -0800 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.33 #1) id 16b5vC-000ENC-00 for namedroppers@ops.ietf.org; Wed, 13 Feb 2002 12:22:30 -0800 Received: by as.vix.com (Postfix, from userid 716) id 3C0F028EB3; Wed, 13 Feb 2002 08:54:21 -0800 (PST) To: namedroppers@ops.ietf.org Subject: Re: Summary: What to do with expired signatures References: <20020212144029.AC25F28EB3@as.vix.com> From: Paul Vixie Date: 13 Feb 2002 08:54:20 -0800 In-Reply-To: Message-ID: Lines: 20 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > All zone changes are made by RFC2136 "UPDATE" requests. There is no > > "load" and there is no "zone file" and there is no way to map your > > "implied delete" to any process that it has. Yet this server is entirely > > protocol compliant. > > as the docs do specify a zone file and format, this is interesting. Yes. Since at no time in any interoperability workshop has it ever happened that one implementor handed the other a *.TXT file and said "read this and serve it so we can test interoperability", I can legitimately claim that a server which does not parse "zone file format" and does not have a concept of "loading" a zone is completely protocol compliant. On the wire, you just can't tell how the other guy deals with backend storage of zone data. And if an implementation can pass every possible on-the-wire compliance and interoperability test you can devise, then they are fully compliant with the protocol. This supports my earlier statement that zone file format should be a BCP rather than a PS. You can't have a PS that is by its nature untestable, according to my reading of the IETF charter documents. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 13 17:52:35 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23462 for ; Wed, 13 Feb 2002 17:52:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16b81d-000IPA-00 for namedroppers-data@psg.com; Wed, 13 Feb 2002 14:37:17 -0800 Received: from funnel.cisco.com ([161.44.168.79]) by psg.com with esmtp (Exim 3.33 #1) id 16b81c-000IOf-00 for namedroppers@ops.ietf.org; Wed, 13 Feb 2002 14:37:16 -0800 Received: from cisco.com (dhcp-161-44-149-120.cisco.com [161.44.149.120]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA28817; Wed, 13 Feb 2002 17:37:13 -0500 (EST) Message-ID: <3C6AEAA1.21AD5A5E@cisco.com> Date: Wed, 13 Feb 2002 17:37:21 -0500 From: Josh Littlefield Organization: Cisco Systems X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Vixie CC: namedroppers@ops.ietf.org Subject: Re: Summary: What to do with expired signatures References: <20020212144029.AC25F28EB3@as.vix.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul Vixie wrote: > > > > All zone changes are made by RFC2136 "UPDATE" requests. There is no > > > "load" and there is no "zone file" and there is no way to map your > > > "implied delete" to any process that it has. Yet this server is entirely > > > protocol compliant. > > > > as the docs do specify a zone file and format, this is interesting. > > Yes. Since at no time in any interoperability workshop has it ever happened > that one implementor handed the other a *.TXT file and said "read this and > serve it so we can test interoperability", I can legitimately claim that a > server which does not parse "zone file format" and does not have a concept > of "loading" a zone is completely protocol compliant. Well... This is *exactly* what happened at the 46th IETF (DC) interoperability event, and perhaps at prior events as well. The results are posted here: . Note the reference to the Perl config file generator and the Perl master file generator. Still, I agree completely that a protocol compliant server can exist which does not parse zone files (we make one here at Cisco). However, having a user interface which does parse zone files can make life a lot easier, as it did for me in this particular case. I think BCP status for zone file format might make sense. I certainly don't see it as part of the protocol, but as an aspect of a useful user interface. -- ===================================================================== Josh Littlefield Cisco Systems, Inc. joshl@cisco.com 250 Apollo Drive tel: 978-497-8378 fax: same Chelmsford, MA 01824-3627 to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 13 19:44:23 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25019 for ; Wed, 13 Feb 2002 19:44:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16b9pF-000Le7-00 for namedroppers-data@psg.com; Wed, 13 Feb 2002 16:32:37 -0800 Received: from roam.psg.com ([147.28.4.2]) by psg.com with esmtp (Exim 3.33 #1) id 16b9p8-000Le1-00 for namedroppers@ops.ietf.org; Wed, 13 Feb 2002 16:32:36 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16b9ox-0006iG-00; Wed, 13 Feb 2002 16:32:19 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: Summary: What to do with expired signatures References: <20020212144029.AC25F28EB3@as.vix.com> Message-Id: Date: Wed, 13 Feb 2002 16:32:19 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit you are discussing a small element of what you would like a theoretical revised dns spec to be. i am discussing what the standard is. randy to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 14 18:40:50 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12735 for ; Thu, 14 Feb 2002 18:40:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16bVCw-0001Js-00 for namedroppers-data@psg.com; Thu, 14 Feb 2002 15:22:30 -0800 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.33 #1) id 16bVCu-0001Jm-00 for namedroppers@ops.ietf.org; Thu, 14 Feb 2002 15:22:29 -0800 Received: by as.vix.com (Postfix, from userid 716) id C68BB28EB3; Thu, 14 Feb 2002 15:22:27 -0800 (PST) To: namedroppers@ops.ietf.org Subject: Re: Summary: What to do with expired signatures References: <20020212144029.AC25F28EB3@as.vix.com> From: Paul Vixie Date: 14 Feb 2002 15:22:27 -0800 In-Reply-To: Message-ID: Lines: 18 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > you are discussing a small element of what you would like a theoretical > revised dns spec to be. i am discussing what the standard is. since you're telling me what i'm discussing, i'll do the same. you are not discussing a standard, you are discussing a document. rfc1034/5 were written well before the ietf's current standards process existed. (a good thing, too, or else we'd still be arguing about dns rather than using and extending it.) the documents of this area were just documents. they had no status like PS or DS or FS or BCP or FYI. they were just, as i said, documents. you can go on explaining what the documents of this era say, and i will go on listening to you, but you are not describing a "standard" by today's standards. anything that rfc1034/5 say which do not meet the definition of "interoperable standard" is actually just extra words in the document, which don't make or change any "standard". zone file format is an example of this kind of "extra words". to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 14 19:19:11 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13300 for ; Thu, 14 Feb 2002 19:19:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16bVvp-0002Vo-00 for namedroppers-data@psg.com; Thu, 14 Feb 2002 16:08:53 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16bVvp-0002Vi-00 for namedroppers@ops.ietf.org; Thu, 14 Feb 2002 16:08:53 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16bVvo-000Hwv-00; Thu, 14 Feb 2002 16:08:52 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: Summary: What to do with expired signatures References: <20020212144029.AC25F28EB3@as.vix.com> Message-Id: Date: Thu, 14 Feb 2002 16:08:52 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit 1034 Domain names - concepts and facilities. P.V. Mockapetris. Nov-01-1987. (Format: TXT=129180 bytes) (Obsoletes RFC0973, RFC0882, RFC0883) (Updated by RFC1101, RFC1183, RFC1348, RFC1876, RFC1982, RFC2065, RFC2181, RFC2308, RFC2535) (Also STD0013) (Status: STANDARD) 1035 Domain names - implementation and specification. P.V. Mockapetris. Nov-01-1987. (Format: TXT=125626 bytes) (Obsoletes RFC0973, RFC0882, RFC0883) (Updated by RFC1101, RFC1183, RFC1348, RFC1876, RFC1982, RFC1995, RFC1996, RFC2065, RFC2136, RFC2181, RFC2137, RFC2308, RFC2535, RFC2845) (Also STD0013) (Status: STANDARD) to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 15 22:42:22 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28090 for ; Fri, 15 Feb 2002 22:42:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16bvOE-0000HS-00 for namedroppers-data@psg.com; Fri, 15 Feb 2002 19:19:54 -0800 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.33 #1) id 16bvOD-0000HM-00 for namedroppers@ops.ietf.org; Fri, 15 Feb 2002 19:19:54 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 7E50928EB0 for ; Fri, 15 Feb 2002 19:19:52 -0800 (PST) (envelope-from vixie@as.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Summary: What to do with expired signatures In-Reply-To: Message from "Paul V. Mockapetris" of "Fri, 15 Feb 2002 18:10:09 PST." <4.2.0.58.20020215175638.02707078@127.0.0.1> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.1 Date: Fri, 15 Feb 2002 19:19:52 -0800 Message-Id: <20020216031952.7E50928EB0@as.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Yeah, but servers that can load zone files should get the same result. I'm fine with that. But making the ability to "load" a "zone file" a prerequisite to "standards compliance" is what I couldn't understand. So, logic like... IF (the capability to load zone data from external files exists) THEN (you must be able to parse $TTL in all its glory) ELSE (you can still call yourself standards compliant) ...wouldn't be a problem, even though it would also be completely useless text to put into a standards document. > So a better way to decide this is just to have the argument about whether a > text format for zone data is still useful or not, rather than whether it is > possible. I think it's useful. Among my servers that can load zones, I copy zone files all the time. But once upon a time someone yammered at me about how my slave zones had to be stored in $TTL format and I had to impolitely demure. Slave zones stored in Lisp format, or AXFR format, or SQL format, don't make your DNS implementation less standards-compliant. And by that logic, a master server which could only serve zone data from SQL or from its own internal format that was managed by RPC or DNS UPDATE or what have you, is also completely conformant. The lack of an ability to read a zone file just doesn't seem meaningful from a standards point of view. It's only in the narrow case where an implementation clearly has an "import" facility but $TTL and its friends aren't supported by it that standards conformance would come into play. The narrowness of that case equates to irrelevance in my considered opinion. Making zone file format its own RFC so that implementations can either support it or not without affecting their "support level" of "DNS itself" would seem to be the right way out of this argument. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Feb 16 12:17:36 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14318 for ; Sat, 16 Feb 2002 12:17:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16c8CU-000DEP-00 for namedroppers-data@psg.com; Sat, 16 Feb 2002 09:00:38 -0800 Received: from sh.lh.vix.com ([204.152.188.26]) by psg.com with esmtp (Exim 3.33 #1) id 16c8CT-000DEH-00 for namedroppers@ops.ietf.org; Sat, 16 Feb 2002 09:00:37 -0800 Received: from KEYSER (sh.lh.vix.com [204.152.188.26]) by sh.lh.vix.com (8.11.2/8.9.1) via ESMTP id g1GH0Yr15574; Sat, 16 Feb 2002 09:00:35 -0800 (PST) env-from (pvm@nominum.com) Message-Id: <4.2.0.58.20020216085840.031ca7a0@127.0.0.1> X-Sender: pvm@127.0.0.1 (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Sat, 16 Feb 2002 08:58:49 -0800 To: Paul Vixie , namedroppers@ops.ietf.org From: "Paul V. Mockapetris" Subject: Re: Summary: What to do with expired signatures Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_546285==_.ALT" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --=====================_546285==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 08:54 AM 2/13/2002 -0800, Paul Vixie wrote: > > > All zone changes are made by RFC2136 "UPDATE" requests. There is no > > > "load" and there is no "zone file" and there is no way to map your > > > "implied delete" to any process that it has. Yet this server is entirely > > > protocol compliant. > > > > as the docs do specify a zone file and format, this is interesting. > >Yes. Since at no time in any interoperability workshop has it ever happened >that one implementor handed the other a *.TXT file and said "read this and >serve it so we can test interoperability", I can legitimately claim that a >server which does not parse "zone file format" and does not have a concept >of "loading" a zone is completely protocol compliant. Interoperability and/or interoperability testing happened several times in the past, and among those times, one was to allow some newfangled DNS server call bind to interoperate with another UNIX implementation of DNS from Stanford and the old TOPS20 implementation. > On the wire, you just >can't tell how the other guy deals with backend storage of zone data. And >if an implementation can pass every possible on-the-wire compliance and >interoperability test you can devise, then they are fully compliant with the >protocol. Yeah, but servers that can load zone files should get the same result. If they don't, zone files shouldn't be either a standard or a BCP, so maybe we are in agreement. But it should be testable if the specs are written correctly. So a better way to decide this is just to have the argument about whether a text format for zone data is still useful or not, rather than whether it is possible. >This supports my earlier statement that zone file format should be a BCP >rather than a PS. You can't have a PS that is by its nature untestable, >according to my reading of the IETF charter documents. > >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: --=====================_546285==_.ALT Content-Type: text/html; charset="us-ascii" At 08:54 AM 2/13/2002 -0800, Paul Vixie wrote:
> > All zone changes are made by RFC2136 "UPDATE" requests.  There is no
> > "load" and there is no "zone file" and there is no way to map your
> > "implied delete" to any process that it has.  Yet this server is entirely
> > protocol compliant.
>
> as the docs do specify a zone file and format, this is interesting.

Yes.  Since at no time in any interoperability workshop has it ever happened
that one implementor handed the other a *.TXT file and said "read this and
serve it so we can test interoperability", I can legitimately claim that a
server which does not parse "zone file format" and does not have a concept
of "loading" a zone is completely protocol compliant.

Interoperability and/or interoperability testing happened several times in the past, and among those times, one was to allow some newfangled DNS server call bind to interoperate with another  UNIX implementation of DNS from Stanford and the old TOPS20 implementation.

  On the wire, you just
can't tell how the other guy deals with backend storage of zone data.  And
if an implementation can pass every possible on-the-wire compliance and
interoperability test you can devise, then they are fully compliant with the
protocol.

Yeah, but servers that can load zone files should get the same result.  If they don't, zone files shouldn't be either a standard or a BCP, so maybe we are in agreement.  But it should be testable if the specs are written correctly.

So a better way to decide this is just to have the argument about whether a text format for zone data is still useful or not, rather than whether it is possible.

This supports my earlier statement that zone file format should be a BCP
rather than a PS.  You can't have a PS that is by its nature untestable,
according to my reading of the IETF charter documents.

to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>
--=====================_546285==_.ALT-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Feb 16 14:25:54 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15756 for ; Sat, 16 Feb 2002 14:25:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16cAM5-000FXN-00 for namedroppers-data@psg.com; Sat, 16 Feb 2002 11:18:41 -0800 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.33 #1) id 16cAM4-000FXH-00 for namedroppers@ops.ietf.org; Sat, 16 Feb 2002 11:18:40 -0800 Received: from [68.52.224.13] (HELO ferret) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.2) with SMTP id 56152 for namedroppers@ops.ietf.org; Sat, 16 Feb 2002 13:17:57 -0600 Message-ID: <3C6EA099.9D74D470@ehsco.com> Date: Sat, 16 Feb 2002 12:10:33 -0600 From: "Eric A. Hall" MIME-Version: 1.0 To: "Paul V. Mockapetris" CC: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: Summary: What to do with expired signatures References: <4.2.0.58.20020216085840.031ca7a0@127.0.0.1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit "Paul V. Mockapetris" wrote: > So a better way to decide this is just to have the argument about > whether a text format for zone data is still useful or not, rather than > whether it is possible. From my PoV, the two compelling features are portability and directives. The latter is probably the more important of the two in the current environment. I think we need more directives, such as a directive that applies to all entries in a zone (a $DEFAULT or something) so we can set an MX for all defined and undefined entries. My IDNS draft also called for a $UTF-8 directive to indicate the charset in use with the zone file. So at the least, before the zone file format can be deprecated, we would have to come up with a way to define directives outside of a zone file (a "directive" RR that was bound to the top of the zone could do this, I suppose, in a weird sort of way). I think more work needs to be done on the zone file if it is kept, and I'm in favor of keeping it. There should be a definition of line formats, end-of-line markers, etc. So having it in a separate document makes some sense from this perspective. There is plenty of precedent for having a data-format specification supplementing a protocol specification (see [2]822, HTML, etc) so this wouldn't be unheard of. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Feb 16 18:20:07 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17759 for ; Sat, 16 Feb 2002 18:20:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16cDne-000J9l-00 for namedroppers-data@psg.com; Sat, 16 Feb 2002 14:59:22 -0800 Received: from keyser.soze.com ([194.165.93.196]) by psg.com with esmtp (Exim 3.33 #1) id 16cDnd-000J9f-00 for namedroppers@ops.ietf.org; Sat, 16 Feb 2002 14:59:21 -0800 Received: (from stefan@localhost) by keyser.soze.com (8.9.1/8.9.1) id UAA00586 for namedroppers@ops.ietf.org; Sat, 16 Feb 2002 20:32:04 +0100 (CET) Date: Sat, 16 Feb 2002 20:32:04 +0100 From: Stefan Arentz To: namedroppers@ops.ietf.org Subject: Compliance tests (Was: Re: Summary: What to do with expired signatures) Message-ID: <20020216203203.A439@keyser.soze.com> References: <4.2.0.58.20020216085840.031ca7a0@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.2.0.58.20020216085840.031ca7a0@127.0.0.1>; from pvm@nominum.com on Sat, Feb 16, 2002 at 08:58:49AM -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Sat, Feb 16, 2002 at 08:58:49AM -0800, Paul V. Mockapetris wrote: ... > Interoperability and/or interoperability testing happened several times in > the past, and among those times, one was to allow some newfangled DNS > server call bind to interoperate with another UNIX implementation of DNS > from Stanford and the old TOPS20 implementation. This is a bit off topic so I'm putting it in another thread. Are there any tools or test suites available to test for RFC compliance? We have created several tests in which we compare query results with the output of Bind, but it's far from complete. I think the whole DNS developer community would benefit from such a test suite. Anyone interested? Stefan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Feb 16 22:29:21 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21338 for ; Sat, 16 Feb 2002 22:29:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16cHqj-000NIf-00 for namedroppers-data@psg.com; Sat, 16 Feb 2002 19:18:49 -0800 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.33 #1) id 16cHqi-000NIZ-00 for namedroppers@ops.ietf.org; Sat, 16 Feb 2002 19:18:48 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id D718528EB0 for ; Sat, 16 Feb 2002 19:18:47 -0800 (PST) (envelope-from vixie@as.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Compliance tests (Was: Re: Summary: What to do with expired signatures) In-Reply-To: Message from Stefan Arentz of "Sat, 16 Feb 2002 20:32:04 +0100." <20020216203203.A439@keyser.soze.com> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.1 Date: Sat, 16 Feb 2002 19:18:47 -0800 Message-Id: <20020217031847.D718528EB0@as.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > I think the whole DNS developer community would benefit from such a > test suite. > > Anyone interested? yes. but, funding it has been a problem. isc's new BIND Forum ought, if successful, provide the continuous background funding needed for this kind of task. we'll certainly let y'all know. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 18 02:16:12 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27701 for ; Mon, 18 Feb 2002 02:16:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16chkO-0002J6-00 for namedroppers-data@psg.com; Sun, 17 Feb 2002 22:58:00 -0800 Received: from 96-1.nat.psu.ac.th ([202.28.96.1] helo=brandenburg.cs.mu.OZ.AU) by psg.com with esmtp (Exim 3.33 #1) id 16chkB-0002Iy-00 for namedroppers@ops.ietf.org; Sun, 17 Feb 2002 22:57:47 -0800 Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g1I6sLT02040; Mon, 18 Feb 2002 13:54:24 +0700 (ICT) From: Robert Elz To: "Eric A. Hall" , "Paul V. Mockapetris" cc: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: Summary: What to do with expired signatures In-Reply-To: <3C6EA099.9D74D470@ehsco.com> References: <3C6EA099.9D74D470@ehsco.com> <4.2.0.58.20020216085840.031ca7a0@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 18 Feb 2002 13:54:21 +0700 Message-ID: <2038.1014015261@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Sat, 16 Feb 2002 12:10:33 -0600 From: "Eric A. Hall" Message-ID: <3C6EA099.9D74D470@ehsco.com> | "Paul V. Mockapetris" wrote: | | > So a better way to decide this is just to have the argument about | > whether a text format for zone data is still useful or not, rather than | > whether it is possible. It isn't whether the text format is useful, it is whether standardising it is the right thing to do which is the issue. I don't think I'd survive with anything that didn't keep data in text file format, I like to be able to use all the standard tools (grep, ...) on the data (and that includes secondary data). But I don't care in the slightest if my files look much like your files, or anyone else's. Nor do I mind that there are others for whom text file format is an ancient anachronism from the dinosaur era, and who have no need for anything like that. I do appreciate that in the early days having the implementations use a common format was useful - it allowed exchange of data when AXFR wasn't all that reliable. These days, it makes no sense. [Aside: if interop testing was done with (early) BIND's text file format, and others, then it must have been pretty pathetic testing, BIND's parser for the text file was only occasionally related to what the RFC specifies, the variations were almost as common as the compliances]. | There is plenty of precedent for having a | data-format specification supplementing a protocol specification (see | [2]822, HTML, etc) so this wouldn't be unheard of. Bad analogy. Those specify the format of data that is interchanged between two systems. So does the DNS, but it isn't the text file format. The equivalent analogy for e-mail would be mailbox format, and that's something that certainly isn't standardised (though there are some common formats). The arguments for standardising it are exactly the same as those in favour of standardising the DNS text file format (once we accept that AXFR now works) but they're not nearly good enough to win. kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 18 07:21:49 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01034 for ; Mon, 18 Feb 2002 07:21:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16cmYh-0008wy-00 for namedroppers-data@psg.com; Mon, 18 Feb 2002 04:06:15 -0800 Received: from pc-127-097.adm.ku.dk ([130.225.127.97] helo=slimsixten.pilsnet.sunet.se) by psg.com with esmtp (Exim 3.33 #1) id 16cmYg-0008wG-00 for namedroppers@ops.ietf.org; Mon, 18 Feb 2002 04:06:14 -0800 Received: from slimsixten (localhost.pilsnet.sunet.se [127.0.0.1]) by slimsixten.pilsnet.sunet.se (8.12.1/8.12.1) with ESMTP id g1IC4nMa016271 for ; Mon, 18 Feb 2002 13:05:37 +0100 (MET) Date: Mon, 18 Feb 2002 12:51:26 +0100 From: =?ISO-8859-1?Q?M=E5ns_Nilsson?= To: namedroppers@ops.ietf.org Subject: Re: Summary: What to do with expired signatures Message-ID: <81230000.1014033086@localhost> In-Reply-To: <2038.1014015261@brandenburg.cs.mu.OZ.AU> References: =?ISO-8859-1?Q?<3C6EA099.9D74D470@ehsco.com>__<4.2.0.58.200202160?= =?ISO-8859-1?Q?85840.031ca7a0@127.0.0.1>_(8.9.3/8.9.3)_with_ESMTP_id_IAA3658?= =?ISO-8859-1?Q?9=88_<2038.1014015261@brandenburg.cs.mu.OZ.AU>?= X-Mailer: Mulberry/2.1.2 (OpenBSD/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA01034 --On Monday, February 18, 2002 13:54:21 +0700 Robert Elz wrote: > I do appreciate that in the early days having the implementations use a > common format was useful - it allowed exchange of data when AXFR wasn't > all that reliable. These days, it makes no sense. I'd refrain from saying that AXFR is "all that reliable" -- for some of us AXFR'en have stopped working for certain zones. But we are a very small minority, perhaps 4 or so large TLDs and their slaves. ;-) Toungue firmly in cheek, ftp'ing his slave zone every day. -- Måns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 18 10:41:33 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05202 for ; Mon, 18 Feb 2002 10:41:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16cpbg-000Euw-00 for namedroppers-data@psg.com; Mon, 18 Feb 2002 07:21:32 -0800 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.33 #1) id 16cpbf-000Euq-00 for namedroppers@ops.ietf.org; Mon, 18 Feb 2002 07:21:31 -0800 Received: from [207.65.3.26] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.2) with ESMTP-TLS id 56217; Mon, 18 Feb 2002 09:20:56 -0600 Message-ID: <3C711BF8.4426888B@ehsco.com> Date: Mon, 18 Feb 2002 09:21:28 -0600 From: "Eric A. Hall" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en-US,en MIME-Version: 1.0 To: Robert Elz CC: namedroppers@ops.ietf.org Subject: Re: Summary: What to do with expired signatures References: <3C6EA099.9D74D470@ehsco.com> <4.2.0.58.20020216085840.031ca7a0@127.0.0.1> <2038.1014015261@brandenburg.cs.mu.OZ.AU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Robert Elz wrote: > It isn't whether the text format is useful, it is whether > standardising it is the right thing to do which is the issue. There are valid reasons why people want it. What are your valid reasons for preventing other people from having it? I mean, as weak as the arguments for a standardized out-of-band replication system may be, there are no valid arguments against it that I can think of. So the question really is, why should we not clarify it? What is the cost? > The equivalent analogy for e-mail would be mailbox format, and that's > something that certainly isn't standardised (though there are some > common formats). Except that mbox has never been defined in a STD, while this one has. Another example of this would be LDIF (albeit not an STD), and to lesser degrees, things like bootptab which have been described as examples. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 18 11:19:07 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06894 for ; Mon, 18 Feb 2002 11:19:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16cqMp-000Ghg-00 for namedroppers-data@psg.com; Mon, 18 Feb 2002 08:10:15 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.33 #1) id 16cqMn-000Gha-00 for namedroppers@ops.ietf.org; Mon, 18 Feb 2002 08:10:13 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06219; Mon, 18 Feb 2002 11:10:07 -0500 (EST) Message-Id: <200202181610.LAA06219@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-ad-is-secure-04.txt Date: Mon, 18 Feb 2002 11:10:06 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart 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 : Redefinition of DNS AD bit Author(s) : B. Wellington, O. Gudmundsson Filename : draft-ietf-dnsext-ad-is-secure-04.txt Pages : 5 Date : 15-Feb-02 Based on implementation experience, the current definition of the AD bit in the DNS header is not useful. This draft changes the specification so that the AD bit is only set on answers where signatures have been cryptographically verified or the server is authoritative for the data and is allowed to set the bit by policy. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ad-is-secure-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-ad-is-secure-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-ad-is-secure-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020215100549.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-ad-is-secure-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-ad-is-secure-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020215100549.I-D@ietf.org> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 18 11:40:55 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08054 for ; Mon, 18 Feb 2002 11:40:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16cqhB-000HWP-00 for namedroppers-data@psg.com; Mon, 18 Feb 2002 08:31:17 -0800 Received: from dt0b4n7d.maine.rr.com ([24.95.12.125] helo=nic-naa.net) by psg.com with esmtp (Exim 3.33 #1) id 16cqhA-000HWJ-00 for namedroppers@ops.ietf.org; Mon, 18 Feb 2002 08:31:16 -0800 Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.6/8.11.1) with ESMTP id g1IJTo160792; Mon, 18 Feb 2002 11:29:50 -0800 (PST) (envelope-from brunner@nic-naa.net) Message-Id: <200202181929.g1IJTo160792@nic-naa.net> To: "Eric A. Hall" cc: Robert Elz , namedroppers@ops.ietf.org, brunner@nic-naa.net Subject: Re: Summary: What to do with expired signatures In-Reply-To: Your message of "Mon, 18 Feb 2002 09:21:28 CST." <3C711BF8.4426888B@ehsco.com> Date: Mon, 18 Feb 2002 11:29:50 -0800 From: Eric Brunner-Williams in Portland Maine Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Eric, An unintended consequence of moving the foci of XPG / POSIX standardization from sections 2, 3, 4 (kernel, library and driver APIs, respectively) and section 5 (file formats), to sections 1 and 8 (usr and root cmds), was that the white spaces in the output of the long format (-l) of the ls.1 got specified. Naturally, the standards conformance test suite eventually included a test for the -l option of ls. Mercifully, I've forgotten which way was "wrong", N spaces or N/8 tabs, but the fix (to obtain conformance) broke more tools that harbored secret knowledge about white space ... Now there really was a good reason to specify this, it is handy when the l10n guys and gals are putting in inobvious date formats with surprising display character length properties, but we hadn't thought of that at the time we took that sip of the standards koolaid. Uh, I was a primary co-author of Spec 1170, so the egg is on my, err, napkin. I've no problem with the whois-fix proto-wg attempting to find-and-fix (or search-and-destroy) the odd whois (or isn't) formats. More fun with lex and yacc. However, the utility of standardizing the text format here escapes me. Eric to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 18 12:17:05 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09564 for ; Mon, 18 Feb 2002 12:17:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16crCW-000In6-00 for namedroppers-data@psg.com; Mon, 18 Feb 2002 09:03:40 -0800 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.33 #1) id 16crCU-000Imh-00 for namedroppers@ops.ietf.org; Mon, 18 Feb 2002 09:03:39 -0800 Received: from [207.65.3.26] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.2) with ESMTP-TLS id 56226; Mon, 18 Feb 2002 11:02:43 -0600 Message-ID: <3C7133D2.EC81BE86@ehsco.com> Date: Mon, 18 Feb 2002 11:03:15 -0600 From: "Eric A. Hall" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en-US,en MIME-Version: 1.0 To: Eric Brunner-Williams in Portland Maine CC: namedroppers@ops.ietf.org Subject: Re: Summary: What to do with expired signatures References: <200202181929.g1IJTo160792@nic-naa.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Eric Brunner-Williams in Portland Maine wrote: > the utility of standardizing the text format here escapes me. Two reasons: out-of-band zone replication which contributes towards overall stability of the Internet's namespace, and zone directives. The latter will have to be replaced with something else before the file can be deprecated, but moreover, I can't think of a good reason to deprecate it in the first place. Clearly it is useful. I would like to hear arguments that it is unuseful and an interoperability hazard of such magnitude that the loss of stability afforded by a common import/export format (at least) is worthwhile. Anybody? Okay then, well, if we aren't going to deprecate it, would a clarification of the spec that redefined the purpose (import/export, not the backend DB) and the structural format of the file be such a resource drain that the effort should not be undertaken? What is the limiting resource here? Wouldn't such an effort strengthen the benefits? I'm certainly comfortable with a MAY clause so that implementors don't have to mess with it if they don't have the resources. But otherwise it offers some pretty important features. Best for the Internet community to spend a few cycles cleaning it up, I would think. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 18 12:28:34 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08055 for ; Mon, 18 Feb 2002 11:40:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16cqjL-000HYF-00 for namedroppers-data@psg.com; Mon, 18 Feb 2002 08:33:31 -0800 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.33 #1) id 16cqjK-000HY8-00 for namedroppers@ops.ietf.org; Mon, 18 Feb 2002 08:33:31 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 0E60328EB0 for ; Mon, 18 Feb 2002 08:33:30 -0800 (PST) (envelope-from vixie@as.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Summary: What to do with expired signatures In-Reply-To: Message from "Eric A. Hall" of "Mon, 18 Feb 2002 09:21:28 CST." <3C711BF8.4426888B@ehsco.com> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.1 Date: Mon, 18 Feb 2002 08:33:30 -0800 Message-Id: <20020218163330.0E60328EB0@as.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk eric just said, in comments directed at robert: > There are valid reasons why people want it. What are your valid reasons > for preventing other people from having it? I mean, as weak as the > arguments for a standardized out-of-band replication system may be, there > are no valid arguments against it that I can think of. So the question > really is, why should we not clarify it? What is the cost? as long as it is clarified that the whole thing is optional, that's fine. because a number of interoperable-on-the-wire dns implementations don't have a concept of "loading" or even "importing" their authoritative data except via AXFR or DYNUPD or out-of-band methods such as SQL, and it would be factually wrong of this WG to call these "nonstandard". the ability to "load" a "zone file" is often QUITE useful, and so many implementations (including BIND) have implemented and will continue to implement it. and it makes _great_ sense, at the system design level, for there to be a standard "zone file" format to make OOB zone transport easier. this discussion isn't about whether it's useful, or whether the format we use is a good one, or whether it can be or should be extended. the topic at hand is: can a DNS implementation which doesn't "load" zones at all but is still interoperable-on-the-wire for udp/53 and tcp/53 be thought incomplete from a standards point of view? i say "no, that's fine, such an implementation is still complete from the DNS standards point of view." to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 18 12:30:20 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10117 for ; Mon, 18 Feb 2002 12:30:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16crT1-000JPE-00 for namedroppers-data@psg.com; Mon, 18 Feb 2002 09:20:43 -0800 Received: from dt0b4n7d.maine.rr.com ([24.95.12.125] helo=nic-naa.net) by psg.com with esmtp (Exim 3.33 #1) id 16crT0-000JP7-00 for namedroppers@ops.ietf.org; Mon, 18 Feb 2002 09:20:42 -0800 Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.6/8.11.1) with ESMTP id g1IKK7162704; Mon, 18 Feb 2002 12:20:07 -0800 (PST) (envelope-from brunner@nic-naa.net) Message-Id: <200202182020.g1IKK7162704@nic-naa.net> To: "Eric A. Hall" cc: Eric Brunner-Williams in Portland Maine , namedroppers@ops.ietf.org, brunner@nic-naa.net Subject: Re: Summary: What to do with expired signatures In-Reply-To: Your message of "Mon, 18 Feb 2002 11:03:15 CST." <3C7133D2.EC81BE86@ehsco.com> Date: Mon, 18 Feb 2002 12:20:07 -0800 From: Eric Brunner-Williams in Portland Maine Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Two reasons: out-of-band zone replication which contributes towards > overall stability of the Internet's namespace, and zone directives I'm at a loss to understand the first assertion offered. Oh well. ENOCLUE. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 18 16:31:18 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19260 for ; Mon, 18 Feb 2002 16:31:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16cvAn-0005S0-00 for namedroppers-data@psg.com; Mon, 18 Feb 2002 13:18:09 -0800 Received: from 208-59-114-172.c3-0.129-ubr1.lnh-129.md.cable.rcn.com ([208.59.114.172] helo=ogud.com) by psg.com with esmtp (Exim 3.33 #1) id 16cvAl-0005Rr-00 for namedroppers@ops.ietf.org; Mon, 18 Feb 2002 13:18:07 -0800 Received: from oemcomputer.ogud.com (gatt.dc.ogud.com [10.20.30.6]) by ogud.com (8.11.6/8.11.6) with ESMTP id g1ILHWB17209; Mon, 18 Feb 2002 16:17:32 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <5.1.0.14.2.20020218135548.00ac12d0@localhost> X-Sender: post@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 18 Feb 2002 16:15:05 -0500 To: Paul Vixie , namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: RR Text format (was: Re: Summary: What to do ...) In-Reply-To: <20020218163330.0E60328EB0@as.vix.com> References: <3C711BF8.4426888B@ehsco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 11:33 AM 2/18/2002, Paul Vixie wrote: >eric just said, in comments directed at robert: > > > There are valid reasons why people want it. What are your valid reasons > > for preventing other people from having it? I mean, as weak as the > > arguments for a standardized out-of-band replication system may be, there > > are no valid arguments against it that I can think of. So the question > > really is, why should we not clarify it? What is the cost? > >as long as it is clarified that the whole thing is optional, that's fine. Paul, for the last few years I have called the text format "presentation format" as that is where the main use is. For looking at the results of a lookup and recognizing quickly the content of the answer. Because that dig, DnsExpert, DNSjava, nslookup, NET:DNS, and Qdns, all use similar output, derived from the presentation formats in the RFCs I can use these tools interchangeably. There is no reason why any server should be required to be able to load from that format. And for performance reasons using the text format specified by nameserver is suboptimal due to parsing overhead. Having said that it is nice to be able to cut and paste output from dig into a zone file either directly or via a tool. >because a number of interoperable-on-the-wire dns implementations don't >have a concept of "loading" or even "importing" their authoritative data >except via AXFR or DYNUPD or out-of-band methods such as SQL, and it >would be factually wrong of this WG to call these "nonstandard". > >the ability to "load" a "zone file" is often QUITE useful, and so many >implementations (including BIND) have implemented and will continue to >implement it. and it makes _great_ sense, at the system design level, >for there to be a standard "zone file" format to make OOB zone transport >easier. > >this discussion isn't about whether it's useful, or whether the format we >use is a good one, or whether it can be or should be extended. the topic >at hand is: can a DNS implementation which doesn't "load" zones at all but >is still interoperable-on-the-wire for udp/53 and tcp/53 be thought >incomplete from a standards point of view? i say "no, that's fine, such >an implementation is still complete from the DNS standards point of view." We could not agree more. If/when DNSSEC and/or IDN happens there will be much more need for separating the view that the administrator sees to what is given to the nameserver. DNSSEC signer in this case could read a regular zone file but output a file in wire format, another way is that the signer sends dynamic updates with the new signatures, in this case there is no need for the server to ever understand "text zone file." Olafur to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 18 17:03:20 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20181 for ; Mon, 18 Feb 2002 17:03:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16cvj9-0007dp-00 for namedroppers-data@psg.com; Mon, 18 Feb 2002 13:53:39 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16cvj8-0007dd-00 for namedroppers@ops.ietf.org; Mon, 18 Feb 2002 13:53:38 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16cvj8-000EyD-00 for namedroppers@ops.ietf.org; Mon, 18 Feb 2002 13:53:38 -0800 In-Reply-To: <3C7133D2.EC81BE86@ehsco.com> References: <200202181929.g1IJTo160792@nic-naa.net> <3C7133D2.EC81BE86@ehsco.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1014069044.32732.100.camel@error-messages.mit.edu> Mime-Version: 1.0 Subject: RR Text format (was Re: Summary: What to do with expired signatures) From: Greg Hudson To: "Eric A. Hall" Cc: namedroppers@ops.ietf.org Date: 18 Feb 2002 16:50:44 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Mon, 2002-02-18 at 12:03, Eric A. Hall wrote: > > the utility of standardizing the text format here escapes me. > > Two reasons: out-of-band zone replication which contributes towards > overall stability of the Internet's namespace, and zone directives. (Zone directives? I don't get it.) There is certainly utility in being able to replicate zones out of band between different nameserver implementations, but is the value compelling? Should the IETF try to standardize the format of the aliases file used by MTAs? The format of access permissions files used by FTP and HTTP servers? The format of mailbox files used by an IMAP server? All of these standards would facilitate the distribution of services among heterogeneous server implementations, as well as the gradual migration of a distributed service from one implementation to another. Nonetheless, we don't try to standardize those formats because it would be a waste of time. Implementors don't generally see enough value in this kind of interoperability to prevent them from making little improvements to or wholesale reinventions of those data formats. They write import tools to help people migrate from other implementations to their own, and usually leave it at that. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 18 17:36:57 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21262 for ; Mon, 18 Feb 2002 17:36:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16cwDy-0009bj-00 for namedroppers-data@psg.com; Mon, 18 Feb 2002 14:25:30 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16cwDx-0009bd-00 for namedroppers@ops.ietf.org; Mon, 18 Feb 2002 14:25:29 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16cwDs-000FtJ-00; Mon, 18 Feb 2002 14:25:24 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Greg Hudson Cc: "Eric A. Hall" , namedroppers Subject: Re: RR Text format (was Re: Summary: What to do with expired signatures) References: <200202181929.g1IJTo160792@nic-naa.net> <3C7133D2.EC81BE86@ehsco.com> <1014069044.32732.100.camel@error-messages.mit.edu> Message-Id: Date: Mon, 18 Feb 2002 14:25:24 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit the fact is that, whether we like it or nor, zone file format is a formal ietf standard. the question is whether would-be historical revisionism should be a high priority item for this wg. imiho, it isn't. o we have open questions from the dnssec document team o we should close on restrict-key o we may have cooled off enough to discuss opt-in o the usual collection of 42 ids to discuss o ... randy, with co-chair hat on to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 18 18:49:00 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23675 for ; Mon, 18 Feb 2002 18:49:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16cxNS-000E9z-00 for namedroppers-data@psg.com; Mon, 18 Feb 2002 15:39:22 -0800 Received: from outpost.ds9a.nl ([213.244.168.210] helo=outpost.powerdns.com) by psg.com with esmtp (Exim 3.33 #1) id 16cxNQ-000E9o-00 for namedroppers@ops.ietf.org; Mon, 18 Feb 2002 15:39:20 -0800 Received: by outpost.powerdns.com (Postfix, from userid 1000) id 10D48C60D5; Tue, 19 Feb 2002 00:39:18 +0100 (CET) Date: Tue, 19 Feb 2002 00:39:18 +0100 From: bert hubert To: Greg Hudson Cc: "Eric A. Hall" , namedroppers@ops.ietf.org Subject: Re: RR Text format (was Re: Summary: What to do with expired signatures) Message-ID: <20020219003917.A27497@outpost.ds9a.nl> References: <200202181929.g1IJTo160792@nic-naa.net> <3C7133D2.EC81BE86@ehsco.com> <1014069044.32732.100.camel@error-messages.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1014069044.32732.100.camel@error-messages.mit.edu>; from ghudson@MIT.EDU on Mon, Feb 18, 2002 at 04:50:44PM -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, Feb 18, 2002 at 04:50:44PM -0500, Greg Hudson wrote: > On Mon, 2002-02-18 at 12:03, Eric A. Hall wrote: > > > the utility of standardizing the text format here escapes me. > > > > Two reasons: out-of-band zone replication which contributes towards > > overall stability of the Internet's namespace, and zone directives. > > (Zone directives? I don't get it.) > > There is certainly utility in being able to replicate zones out of band > between different nameserver implementations, but is the value > compelling? The point is pretty moot - even without exact interoperability, zone files are semantically all identical - RFC 1035 is quite explicit about 'records' and how they need to be traversed to generate anwers to DNS queries. So whatever format you think up, it is always possible to convert it to any other format that complies with basic DNS specifications regarding records and zones. Even 'zone directives' can easily be expressed by explicitly supplying TTL per record. Regards, bert -- http://www.PowerDNS.com Versatile DNS Software & Services http://www.tk the dot in .tk Netherlabs BV / Rent-a-Nerd.nl - Nerd Available - Linux Advanced Routing & Traffic Control: http://ds9a.nl/lartc -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 20 22:26:35 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27850 for ; Wed, 20 Feb 2002 22:26:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16djXq-000KKt-00 for namedroppers-data@psg.com; Wed, 20 Feb 2002 19:05:18 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.35 #1) id 16djXp-000KKk-00 for namedroppers@ops.ietf.org; Wed, 20 Feb 2002 19:05:17 -0800 Received: from randy by rip.psg.com with local (Exim 3.35 #1) id 16djXp-0008uD-00 for namedroppers@ops.ietf.org; Wed, 20 Feb 2002 19:05:17 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: namedroppers Subject: draft-ietf-dnsext-delegation-signer-05.txt Message-Id: Date: Wed, 20 Feb 2002 19:05:17 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit draft-ietf-dnsext-delegation-signer-05.txt passed wg last call with some nits. i suggest the editors clean up the nits and olafur and i then pass it to erik for ad and then iesg review. in the next hours, olafur will be issuing wg last call on some drafts so we can get them moving as well. randy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 21 21:46:48 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10529 for ; Thu, 21 Feb 2002 21:46:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16e5QS-00055Q-00 for namedroppers-data@psg.com; Thu, 21 Feb 2002 18:27:08 -0800 Received: from 208-59-114-172.c3-0.129-ubr1.lnh-129.md.cable.rcn.com ([208.59.114.172] helo=ogud.com) by psg.com with esmtp (Exim 3.35 #1) id 16e5QR-00055H-00 for namedroppers@ops.ietf.org; Thu, 21 Feb 2002 18:27:07 -0800 Received: from oemcomputer.ogud.com (mail.dc.ogud.com [10.20.30.6]) by ogud.com (8.11.6/8.11.6) with ESMTP id g1M2Q9B25296 for ; Thu, 21 Feb 2002 21:26:09 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <5.1.0.14.2.20020221211120.02376700@localhost> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 21 Feb 2002 21:17:49 -0500 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: DNSSEC WGLC AD is Secure-04 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is last call for this document that has been last called before and this version is based on the comments from last call. The issue in contention on prior version was the statement that an authoritative server is allowed to set the AD bit with out doing full crypto verification. This version provides reasons why and explains the security implications. This WG last call ends March 10'th 2002. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ad-is-secure-04.txt Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 21 21:46:49 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10537 for ; Thu, 21 Feb 2002 21:46:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16e5Pw-000557-00 for namedroppers-data@psg.com; Thu, 21 Feb 2002 18:26:36 -0800 Received: from 208-59-114-172.c3-0.129-ubr1.lnh-129.md.cable.rcn.com ([208.59.114.172] helo=ogud.com) by psg.com with esmtp (Exim 3.35 #1) id 16e5Pu-00054v-00 for namedroppers@ops.ietf.org; Thu, 21 Feb 2002 18:26:35 -0800 Received: from oemcomputer.ogud.com (mail.dc.ogud.com [10.20.30.6]) by ogud.com (8.11.6/8.11.6) with ESMTP id g1M2PbB25292 for ; Thu, 21 Feb 2002 21:25:37 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <5.1.0.14.2.20020221212355.0237d460@wheresmymailserver.com> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 21 Feb 2002 21:23:59 -0500 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: DNSSEC WGLC AD is Secure-04 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is last call for this document that has been last called before and this version is based on the comments from last call. The issue in contention on prior version was the statement that an authoritative server is allowed to set the AD bit with out doing full crypto verification. This version provides reasons why and explains the security implications. This WG last call ends March 10'th 2002. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ad-is-secure-04.txt Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 21 21:46:51 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10554 for ; Thu, 21 Feb 2002 21:46:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16e5Pf-00054j-00 for namedroppers-data@psg.com; Thu, 21 Feb 2002 18:26:19 -0800 Received: from 208-59-114-172.c3-0.129-ubr1.lnh-129.md.cable.rcn.com ([208.59.114.172] helo=ogud.com) by psg.com with esmtp (Exim 3.35 #1) id 16e5Pe-00054d-00 for namedroppers@ops.ietf.org; Thu, 21 Feb 2002 18:26:18 -0800 Received: from oemcomputer.ogud.com (ns.dc.ogud.com [10.20.30.6]) by ogud.com (8.11.6/8.11.6) with ESMTP id g1M2PKB25287 for ; Thu, 21 Feb 2002 21:25:21 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <5.1.0.14.2.20020221211816.0237e5c0@localhost> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 21 Feb 2002 21:23:39 -0500 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: DNSEXT WGLC Restrict KEY-01 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is the first DNSEXT Working group last call for this document and will conclude on March 10'th 2002. This document updates RFC2535 and restricts the use of the KEY RR to only uses by DNS. This document closes the DNS KEY RR protocol registry. This document obsoletes number of KEY RR flag bits. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ad-is-secure-04.txt This document is on standards track. Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 22 10:11:15 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05100 for ; Fri, 22 Feb 2002 10:11:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16eH2T-0000SB-00 for namedroppers-data@psg.com; Fri, 22 Feb 2002 06:51:09 -0800 Received: from 208-59-114-172.c3-0.129-ubr1.lnh-129.md.cable.rcn.com ([208.59.114.172] helo=ogud.com) by psg.com with esmtp (Exim 3.35 #1) id 16eH2S-0000S4-00 for namedroppers@ops.ietf.org; Fri, 22 Feb 2002 06:51:09 -0800 Received: from oemcomputer.ogud.com (ns.dc.ogud.com [10.20.30.6]) by ogud.com (8.11.6/8.11.6) with ESMTP id g1MEo7B26501 for ; Fri, 22 Feb 2002 09:50:07 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <5.1.0.14.2.20020222094749.0239a960@localhost> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 22 Feb 2002 09:48:30 -0500 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: Re: DNSEXT WGLC Restrict KEY-01 In-Reply-To: <5.1.0.14.2.20020221211816.0237e5c0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA05100 At 09:23 PM 2/21/2002, Ólafur Gudmundsson/DNSEXT co-chair wrote: >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ad-is-secure-04.txt Correction http://www.ietf.org/internet-drafts/draft-ietf-dnsext-restrict-key-for-dnssec-01.txt -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 27 06:00:31 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16114 for ; Wed, 27 Feb 2002 06:00:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16g1Ro-000Oe1-00 for namedroppers-data@psg.com; Wed, 27 Feb 2002 02:36:32 -0800 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.35 #1) id 16g1Rn-000Odu-00 for namedroppers@ops.ietf.org; Wed, 27 Feb 2002 02:36:31 -0800 Received: from localhost (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 8752D3190C for ; Wed, 27 Feb 2002 02:36:29 -0800 (PST) Date: Wed, 27 Feb 2002 11:39:44 +0100 (CET) From: Roy Arends X-X-Sender: To: Subject: Another NEW technical argument for Opt-In. Message-ID: <20020227112239.P37547-100000@node10c4d.a2000.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > if someone has NEW technical arguments to present for or against either > proposal, please do so now. N_E_W arguments. > > randy With Opt-In, wildcards can be unsigned in a secured zone, and the WG can optionally ease the current requirements due to wildcards by means of a new proposal. The current requirements and complexity due to wildcards are: (1) If the response is to be a NXDOMAIN response, the current requirement is to include authenticated denial (NXT) of wildcards for every intermediate label level. (2) If the response is to be an expanded wildcard, the current requirement is to include authenticated denial for a "closer wildcard match" and authenticated denial of QNAME. An example: Suppose we have e. SOA e. A d.e. A c.d.e. A b.c.d.e. A A negative response for QNAME "a.b.c.d.e." MUST include: b.c.d.e. NXT e. ([a|*].b.c.d.e. does not exist) b.c.d.e. SIG NXT e. NXT d.e. (*.e. does not exist) e. SIG NXT d.e. NXT c.d.e. (*.d.e. does not exist) d.e. SIG NXT c.d.e. NXT b.c.d.e. (*.c.d.e. does not exist) c.d.e. SIG NXT With a few (one or two) intermediate label levels these requirements can, with some effort be satisfied, though are expensive, especially at the resolver side. With a higher amount of intermediate levels (bitstring labels come to mind), these requirements are hard to satisfy due to message size limits (even with EDNS0) and time-outs. A second, but weak, motivation to deny wildcards to be used in DNSSEC is that eventhough unexpanded wildcards are signed, the name part of an expanded wildcard is not signed. An unsigned name part does not compromise security though. A motivation to allow wildcards to be used in DNSSEC is the requirement to maintain backwards compatibity with RFC1034/5 and the simple fact that people use wildcards, and thus want wildcards in DNSSEC. Opt-In can be used as a method to satisfy both sides of the wildcard issue. Opt-In allows for unsigned nodes in a secured zone, and in this particular case, wildcards can be left unsigned in a secure zone, and the requirement (1) and (2) can optionally be dropped by means of a new proposal. Roy Arends Nominum -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 27 07:41:03 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19452 for ; Wed, 27 Feb 2002 07:41:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16g36H-0002Uk-00 for namedroppers-data@psg.com; Wed, 27 Feb 2002 04:22:25 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.35 #1) id 16g36G-0002Ue-00 for namedroppers@ops.ietf.org; Wed, 27 Feb 2002 04:22:24 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17596; Wed, 27 Feb 2002 07:22:21 -0500 (EST) Message-Id: <200202271222.HAA17596@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dnssec-records-00.txt Date: Wed, 27 Feb 2002 07:22:20 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart 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 : Resource Records for DNS Security Extensions Author(s) : R. Arends et al. Filename : draft-ietf-dnsext-dnssec-records-00.txt Pages : 24 Date : 26-Feb-02 The DNS Security Extensions (DNSSEC) introduce four resource records: the KEY, DS, SIG, and NXT resource records. This document defines the purpose and the RDATA format for each of these records. This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-records-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-dnssec-records-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dnssec-records-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020226130144.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-records-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-records-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020226130144.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 27 09:52:17 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25296 for ; Wed, 27 Feb 2002 09:52:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16g57A-0007uG-00 for namedroppers-data@psg.com; Wed, 27 Feb 2002 06:31:28 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.35 #1) id 16g579-0007uA-00 for namedroppers@ops.ietf.org; Wed, 27 Feb 2002 06:31:27 -0800 Received: from randy by rip.psg.com with local (Exim 4.00) id 16g579-000Fs2-00; Wed, 27 Feb 2002 06:31:27 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Roy Arends Cc: Subject: Re: Another NEW technical argument for Opt-In. References: <20020227112239.P37547-100000@node10c4d.a2000.nl> Message-Id: Date: Wed, 27 Feb 2002 06:31:27 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > With Opt-In, wildcards can be unsigned in a secured zone, and the WG can > optionally ease the current requirements due to wildcards by means of a > new proposal. first, with opt in, the term "secured zone" may not be appropriate. let's not slip into market-speak or we'll have to send email in ppt :-). and can you reconcile this with the suggestion that we might only allow opting out of ns delegations? or do i remember that idea incorrectly? randy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 27 13:08:20 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07068 for ; Wed, 27 Feb 2002 13:08:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16g8H5-000GJ6-00 for namedroppers-data@psg.com; Wed, 27 Feb 2002 09:53:55 -0800 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.35 #1) id 16g8H4-000GIx-00 for namedroppers@ops.ietf.org; Wed, 27 Feb 2002 09:53:54 -0800 Received: from localhost (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 46CCD3190C; Wed, 27 Feb 2002 09:53:50 -0800 (PST) Date: Wed, 27 Feb 2002 18:57:09 +0100 (CET) From: Roy Arends X-X-Sender: To: Randy Bush Cc: Roy Arends , Subject: Re: Another NEW technical argument for Opt-In. In-Reply-To: Message-ID: <20020227154307.D37547-100000@node10c4d.a2000.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 27 Feb 2002, Randy Bush wrote: > > With Opt-In, wildcards can be unsigned in a secured zone, and the WG can > > optionally ease the current requirements due to wildcards by means of a > > new proposal. > > first, with opt in, the term "secured zone" may not be appropriate. let's > not slip into market-speak or we'll have to send email in ppt :-). No market-speak intended, lets not throw mud. > and can you reconcile this with the suggestion that we might only allow > opting out of ns delegations? or do i remember that idea incorrectly? No. Yes. We (opt-in authors) expressed individually, separately on this list our thoughts about "only allow opting out of ns delegations" which generated no comments from the wg. IMHO only allow opting out of _unsecure_ ns delegations (instead of allowing any RRset to opt out), has still not seen a _technical_ argument _for_ it. The new technical argument (wildcards & opt-in) is a way to reduce the current requirements and complexity in dnssec. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 27 13:58:36 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07069 for ; Wed, 27 Feb 2002 13:08:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16g8Eu-000GDA-00 for namedroppers-data@psg.com; Wed, 27 Feb 2002 09:51:40 -0800 Received: from pigeon.verisign.com ([65.205.251.71]) by psg.com with esmtp (Exim 3.35 #1) id 16g8Eu-000GD4-00; Wed, 27 Feb 2002 09:51:40 -0800 Received: from vhqpostal-gw2.verisign.com (verisign.com [65.205.251.56]) by pigeon.verisign.com (8.9.3/BCH1.7.1) with ESMTP id JAA28666; Wed, 27 Feb 2002 09:41:42 -0800 (PST) Received: by vhqpostal-gw2.verisign.com with Internet Mail Service (5.5.2653.19) id <15YDZ27K>; Wed, 27 Feb 2002 09:52:44 -0800 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F40586999B@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Randy Bush'" , Roy Arends Cc: namedroppers@ops.ietf.org Subject: RE: Another NEW technical argument for Opt-In. Date: Wed, 27 Feb 2002 09:52:27 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1BFB7.8523A270" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1BFB7.8523A270 Content-Type: text/plain; charset="iso-8859-1" > first, with opt in, the term "secured zone" may not be > appropriate. let's > not slip into market-speak or we'll have to send email in ppt :-). According to someone talking at the RSA show (Sam the Eagle?), Vint Cerf is alleged to have said "All power corrupts and Powerpoint corrupts absolutely" Phill ------_=_NextPart_000_01C1BFB7.8523A270 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C1BFB7.8523A270-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 28 12:46:16 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07942 for ; Thu, 28 Feb 2002 12:46:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16gUE4-000IJg-00 for namedroppers-data@psg.com; Thu, 28 Feb 2002 09:20:16 -0800 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.35 #1) id 16gUE3-000IJZ-00 for namedroppers@ops.ietf.org; Thu, 28 Feb 2002 09:20:15 -0800 Received: from localhost (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id F14DC3190D for ; Thu, 28 Feb 2002 09:20:11 -0800 (PST) Date: Thu, 28 Feb 2002 18:23:45 +0100 (CET) From: Roy Arends X-X-Sender: To: Subject: Do reserved label types clash with 1034/5 ? Message-ID: <20020228181426.N45468-100000@node10c4d.a2000.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk There is a potential problem due to a clash between rfc2671 (EDNS0) and 1034/5. This has to do with with section 3.2 of rfc2671 where it reads: 3.2. The "1 1 1 1 1 1" extended label type will be reserved for future expansion of the extended label type code space. and at section 7 (IANA Considerations) of rfc2671 it reads: This document assigns extended label type 0bxx111111 as "Reserved for future extended label types." We request that IANA record this assignment. This last section has logically the following effect: (1) An ASCII label has a maximum size of 62 instead of 63, due to the fact that labeltype/length 0b00111111 matches reserved labeltype 0bxx111111. This is bad, since it is not backw. compatible. (2) An offset in a Compressed label (or pointer label) has a maximum of 16127 due to offset>16127 matches reserved labeltype 0bxx111111. This is less bad, since you'd probably use EDNS when using large offsets. Was my interpretation right ? Or are the IANA Considerations of rfc2671 unclear ? (been reading through archives, no mentionings of this, and no registry at IANA has been opened for EDNS extended label types) Please enlighten me :-) Roy Arends Nominum -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 28 14:08:01 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13463 for ; Thu, 28 Feb 2002 14:07:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16gVkX-000K2A-00 for namedroppers-data@psg.com; Thu, 28 Feb 2002 10:57:53 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.35 #1) id 16gVkW-000K24-00 for namedroppers@ops.ietf.org; Thu, 28 Feb 2002 10:57:52 -0800 Received: from randy by rip.psg.com with local (Exim 4.00) id 16gVkW-000E3Q-00 for namedroppers@ops.ietf.org; Thu, 28 Feb 2002 10:57:52 -0800 References: <20020228181426.N45468-100000@node10c4d.a2000.nl> In-Reply-To: <20020228181426.N45468-100000@node10c4d.a2000.nl> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii To: Roy Arends Cc: Subject: Re: Do reserved label types clash with 1034/5 ? From: Bob Halley Date: 28 Feb 2002 10:45:34 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ post by non-subscriber ] Roy Arends writes: > There is a potential problem due to a clash between rfc2671 (EDNS0) and > 1034/5. I don't think there is any clash, though the RFC 2671 text is a little confusing. > This has to do with with section 3.2 of rfc2671 where it reads: > > 3.2. The "1 1 1 1 1 1" extended label type will be reserved for future > expansion of the extended label type code space. > > and at section 7 (IANA Considerations) of rfc2671 it reads: > > This document assigns extended label type 0bxx111111 as "Reserved > for future extended label types." We request that IANA record this > assignment. > > This last section has logically the following effect: > > (1) An ASCII label has a maximum size of 62 instead of 63, due to the > fact that labeltype/length 0b00111111 matches reserved labeltype > 0bxx111111. No. 3.2 says 'The "1 1 1 1 1 1" *extended label type*' [my emphasis]. To be an 'extended label type', the label type (upper two bits) must be '0 1' as described in 3.1. There is thus no conflict with ordinary labels, which always have '0 0' in the upper two bits. Section 7 requests IANA to create an ENDS Extended Label Types registry. The document is differentiating between the normal DNS label type codes which are used in the upper two bits, and the extended type codes which are used in the lower 6 bits of extended labels. Section 7 could have perhaps been clearer, but it says "assigns *extended* label type 0bxx111111" [my emphasis]. The document presumably has "xx" in the upper bit postions not because they may take on any value, but because they are not part of the "extended type" code registry space. > Was my interpretation right ? Or are the IANA Considerations of rfc2671 > unclear ? I think your interpretation is incorrect, and that there is no conflict between RFC 1035 and RFC 2671. /Bob -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 28 14:55:13 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16125 for ; Thu, 28 Feb 2002 14:55:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16gWTU-000KmD-00 for namedroppers-data@psg.com; Thu, 28 Feb 2002 11:44:20 -0800 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.35 #1) id 16gWTT-000Km3-00 for namedroppers@ops.ietf.org; Thu, 28 Feb 2002 11:44:20 -0800 Received: from localhost (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 8CBDA3190D; Thu, 28 Feb 2002 11:44:17 -0800 (PST) Date: Thu, 28 Feb 2002 20:47:52 +0100 (CET) From: Roy Arends X-X-Sender: To: Bob Halley Cc: Roy Arends , Subject: Re: Do reserved label types clash with 1034/5 ? In-Reply-To: Message-ID: <20020228195936.S45468-100000@node10c4d.a2000.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On 28 Feb 2002, Bob Halley wrote: > Section 7 could have perhaps been clearer, but it says "assigns > *extended* label type 0bxx111111" [my emphasis]. The document > presumably has "xx" in the upper bit postions not because they may > take on any value, but because they are not part of the "extended > type" code registry space. That was my initial interpretation too, but thinking more about this, another interpretation could be that since EDNS0, 0bxx111111 is now known as extended label type, reserved for future extensions. i.e. ASCII labels can have extensions by this (aka have extended label types), pointer labels can have extensions by this...... I know this might be a far fetched hair split, but it was a possibility, and the "xx" part was where the ambiguity came from, plus the fact the doc states "types" instead of "type codes". (Why not simply state 'assigns EDNS extended label type code "0b111111" ') Anyway, I needed to have this clarified for the dnssec revision docs. I'll go with your presumption, until consensus states otherwise ;-) Thanks for the quick response, Regards, Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: