From owner-namedroppers@ops.ietf.org Wed Jan 1 06:09:57 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02660 for ; Wed, 1 Jan 2003 06:09:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18TgbT-000J5J-00 for namedroppers-data@psg.com; Wed, 01 Jan 2003 03:00:03 -0800 Received: from randy by psg.com with local (Exim 3.36 #2) id 18TgbR-000J4t-00 for namedroppers@ops.ietf.org; Wed, 01 Jan 2003 03:00:01 -0800 To: namedroppers@ops.ietf.org Subject: list policy Message-Id: From: Randy Bush Date: Wed, 01 Jan 2003 03:00:01 -0800 X-Spam-Status: No, hits=0.6 required=5.0 tests=SPAM_PHRASE_02_03,SUBJECT_IS_LIST version=2.43 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. 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. posts are only accepted from subscribers. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to namedroppers-owner@ops.ietf.org and ask to have your alternate address added to the list of addresses from which submissions are automatically accepted. 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 Thu Jan 2 12:11:00 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08772 for ; Thu, 2 Jan 2003 12:11:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18U8et-0004lW-00 for namedroppers-data@psg.com; Thu, 02 Jan 2003 08:57:27 -0800 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #2) id 18U8eo-0004lE-00 for namedroppers@ops.ietf.org; Thu, 02 Jan 2003 08:57:22 -0800 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id h02GvKYm007821 for ; Thu, 2 Jan 2003 11:57:20 -0500 (EST) Received: from [192.149.252.226] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id LAA06965; Thu, 2 Jan 2003 11:57:18 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: Date: Thu, 2 Jan 2003 11:52:43 -0500 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: comments on DS-12, section 2.2.1.2 Cc: edlewis@arin.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=0.5 required=5.0 tests=SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk To the group - please scrutinize...In the spirit of "sending text": #2.2.1.2 Special processing when child and an ancestor share server # # When a child zone and a ancestor other than parent share an # authorative server, a DS aware server MUST answer with information # from child zone, as specified in section 2.2.1.1. This is to prevent # the server to be marked as lame for child. Special rules are needed to permit DS RR aware servers to gracefully interact with older caches which otherwise might falsely label a server as lame because of the new placement of the DS RR set. Such a situation might arise when a server is authoritative for both a zone and it's grandparent, but not the parent. This sounds like an obscure example, but it is very real. The root zone is currently served on 13 machines, and "root-servers.net." is served on 4 of the same 13, but "net." is served elsewhere. When a server receives a query for (, DS, IN), the response MUST be determined from reading these rules in order: 1) If the server is authoritative for the zone that holds the DS RR set (i.e., the zone that delegates away, aka the "parent" zone), the response contains the DS RR set as an authoritative answer. 2) If the server is offering recursive service, the server performs the query itself (according to the rules for resolvers described below) and returns it's findings. 3) If the server is authoritative for the zone that holds the 's SOA RR set, the response is an authoritative negative answer as described in 2.2.1.1. 4) If the server is authoritative for a zone above the QNAME, a referral to a more enclosing zone's servers is made. 5) If the server is not authoritative for any part of the QNAME, a response indicating a lame server for QNAME is given. [Editorial comment: notice the lack of RFC 2119 terms below this line. I am not sure what to require, most of what I have written might be considered recommendations for finding the data.] Using these rules will require some special processing on the part of a DS RR aware resolver. To illustrate this, an example is used. Assuming a server is authoritative for roots.example.net. and for the root zone but not the intervening two zones (or the intervening two label deep zone). Assume that QNAME=roots.example.net., QTYPE=DS, and QCLASS=IN. The resolver will issue this request (assuming no cached data) expecting a referral to a net. server. Instead, rule number 3 above applies and a negative answer is returned by the server. The reaction by the resolver is not to accept this answer as final as it can determine from the SOA RR in the negative answer the context within which the server has answered. A solution to this is to instruct the resolver to hunt for the authoritative zone of the data in a brute force manner. This can be accomplished by taking the owner name of the returned SOA RR and strip off enough left-hand labels until a successful NS response is obtained. A successful response here means that the answer has NS records in it. (Entertaining the possibility that a cut point may be two labels down in a zone.) Returning to the example, the response will include a negative answer with either the SOA RR for "roots.example.net." or "example.net." depending on whether roots.example.net is a delegated domain. In either case, removing the least significant label of the SOA owner name will lead to the location of the desired data. # # This answer can cause problem for a DS aware resolver that is # traversing this branch of the DNS tree for the first time. The # resolver is expecting to get back either DS record or a delegation # information. The SOA with same name as QNAME informs the resolver # that the answer orignated from the zone below the one where the DS # resides. At this point the resolver has no information on how to get # from the ancestor to the parent. In this case the resolver SHOULD # attempt to fetch the delegation information by issuing a query with a # QNAME one label shorter and type NS. This will yield the NS set for # the parent, allowing the resolver to query for the DS record. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- 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 Jan 4 00:10:11 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25933 for ; Sat, 4 Jan 2003 00:10:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18UgRD-00024v-00 for namedroppers-data@psg.com; Fri, 03 Jan 2003 21:01:35 -0800 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.36 #2) id 18UgRB-00021V-00 for namedroppers@ops.ietf.org; Fri, 03 Jan 2003 21:01:33 -0800 Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.5/8.11.6) with SMTP id h039nwvP021163 for ; Fri, 3 Jan 2003 10:49:58 +0100 Date: Fri, 3 Jan 2003 10:49:58 +0100 From: "Olaf M. Kolkman" To: namedroppers@ops.ietf.org Subject: Version 5 of keys signing key flag draft Message-Id: <20030103104958.50a495cc.olaf@ripe.net> Organization: RIPE NCC X-Mailer: Sylpheed version 0.8.2 (GTK+ 1.2.9; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.8 required=5.0 tests=DATE_IN_PAST_12_24,NOSPAM_INC,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Available in the ID repository soon, now at: http://www.ripe.net/DISI/Notes/draft-ietf-dnsext-keyrr-key-signing-flag-05.html --------------------------------------------| 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 Sat Jan 4 00:10:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25936 for ; Sat, 4 Jan 2003 00:10:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18UgRF-00025E-00 for namedroppers-data@psg.com; Fri, 03 Jan 2003 21:01:37 -0800 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.36 #2) id 18UgRC-00021V-00 for namedroppers@ops.ietf.org; Fri, 03 Jan 2003 21:01:34 -0800 Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.5/8.11.6) with SMTP id h039pFvP021356 for ; Fri, 3 Jan 2003 10:51:15 +0100 Date: Fri, 3 Jan 2003 10:51:14 +0100 From: "Olaf M. Kolkman" To: namedroppers@ops.ietf.org Subject: Version 2 of wildcard optimization draft Message-Id: <20030103105114.0db5829f.olaf@ripe.net> Organization: RIPE NCC X-Mailer: Sylpheed version 0.8.2 (GTK+ 1.2.9; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.6 required=5.0 tests=NOSPAM_INC,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Available in the ID repository soon, now at: http://www.ripe.net/DISI/Notes/draft-olaf-dnsext-dnssec-wildcard-optimization-02.html --------------------------------------------| 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 Mon Jan 6 09:27:47 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04045 for ; Mon, 6 Jan 2003 09:27:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18VXvV-000Gsb-00 for namedroppers-data@psg.com; Mon, 06 Jan 2003 06:08:25 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #2) id 18VXvT-000GsO-00 for namedroppers@ops.ietf.org; Mon, 06 Jan 2003 06:08:23 -0800 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 18VXvT-000BdX-00 for namedroppers@ops.ietf.org; Mon, 06 Jan 2003 06:08:23 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: namedroppers Subject: non-approval Message-Id: Date: Mon, 06 Jan 2003 06:08:23 -0800 X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_03_05,TO_LOCALPART_EQ_REAL version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit just so you know, as there is zero dns protocol content, i am not approving a spate of non-subscriber flamage and name-calling about anti-spam that you can read on the ietf mailing list if you wish. 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 Jan 7 08:53:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14021 for ; Tue, 7 Jan 2003 08:53:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Vtpv-0003kp-00 for namedroppers-data@psg.com; Tue, 07 Jan 2003 05:32:07 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #2) id 18VtpP-0003kK-00 for namedroppers@ops.ietf.org; Tue, 07 Jan 2003 05:31:35 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11905; Tue, 7 Jan 2003 08:28:17 -0500 (EST) Message-Id: <200301071328.IAA11905@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-dnsext-opcode-discover-01.txt Date: Tue, 07 Jan 2003 08:28:17 -0500 X-Spam-Status: No, hits=4.6 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02,TO_MALFORMED version=2.43 X-Spam-Level: **** 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 : The DISCOVER opcode Author(s) : B. Manning, P. Vixie, E. Guttman Filename : draft-dnsext-opcode-discover-01.txt Pages : 0 Date : 2003-1-6 The QUERY opcode in the DNS is designed for unicast. With the development of multicast capabilities in the DNS, it is desireable to have a more robust opcode for server interactions since a single request may result in replies from multiple responders. So DISCOVER is defined to deal with replies from multiple responders. As such, this document extend the core DNS specifications to allow clients to have a method for coping with replies from multiple responders. Use of this new opcode may facilitate DNS operations in modern networking topologies. A prototype of the DISCOVER opcode was developed as part of the TBDS project, funded under DARPA grant F30602-99-1-0523. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-dnsext-opcode-discover-01.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-dnsext-opcode-discover-01.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-dnsext-opcode-discover-01.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: <2003-1-6145216.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-dnsext-opcode-discover-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-dnsext-opcode-discover-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-6145216.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 Tue Jan 7 09:32:35 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14975 for ; Tue, 7 Jan 2003 09:32:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18VuYF-00050k-00 for namedroppers-data@psg.com; Tue, 07 Jan 2003 06:17:55 -0800 Received: from bouncer.telica.com ([4.19.224.197] helo=mailscan.telica.com) by psg.com with esmtp (Exim 3.36 #2) id 18VuYC-00050Y-00 for namedroppers@ops.ietf.org; Tue, 07 Jan 2003 06:17:52 -0800 Received: (from root@localhost) by mailscan.telica.com (8.11.6/8.11.6) id h07EHpf26647; Tue, 7 Jan 2003 09:17:51 -0500 Received: from ran.ietf.org (ran.ietf.org [132.151.6.60]) by mailscan.telica.com (8.11.6/8.11.6) with SMTP id h07E62t25962 for ; Tue, 7 Jan 2003 09:06:10 -0500 Received: from majordomo by ran.ietf.org with local (Exim 4.10) id 18VtwQ-0004y3-00 for ietf-announce-list@ran.ietf.org; Tue, 07 Jan 2003 08:38:50 -0500 Received: from odin.ietf.org ([10.27.2.28] helo=ietf.org) by ran.ietf.org with esmtp (Exim 4.10) id 18VtuE-0004vP-00 for all-ietf@ran.ietf.org; Tue, 07 Jan 2003 08:36:34 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11905; Tue, 7 Jan 2003 08:28:17 -0500 (EST) Message-Id: <200301071328.IAA11905@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: wkwan@telica.com Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-dnsext-opcode-discover-01.txt Date: Tue, 07 Jan 2003 08:28:17 -0500 X-Spam-Status: No, hits=4.0 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02 version=2.43 X-Spam-Level: **** 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 : The DISCOVER opcode Author(s) : B. Manning, P. Vixie, E. Guttman Filename : draft-dnsext-opcode-discover-01.txt Pages : 0 Date : 2003-1-6 The QUERY opcode in the DNS is designed for unicast. With the development of multicast capabilities in the DNS, it is desireable to have a more robust opcode for server interactions since a single request may result in replies from multiple responders. So DISCOVER is defined to deal with replies from multiple responders. As such, this document extend the core DNS specifications to allow clients to have a method for coping with replies from multiple responders. Use of this new opcode may facilitate DNS operations in modern networking topologies. A prototype of the DISCOVER opcode was developed as part of the TBDS project, funded under DARPA grant F30602-99-1-0523. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-dnsext-opcode-discover-01.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-dnsext-opcode-discover-01.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-dnsext-opcode-discover-01.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: <2003-1-6145216.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-dnsext-opcode-discover-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-dnsext-opcode-discover-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-6145216.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 Tue Jan 7 09:50:48 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15334 for ; Tue, 7 Jan 2003 09:50:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Vuok-0005MR-00 for namedroppers-data@psg.com; Tue, 07 Jan 2003 06:34:58 -0800 Received: from avocet.mail.pas.earthlink.net ([207.217.120.50]) by psg.com with esmtp (Exim 3.36 #2) id 18Vunj-0005KQ-00 for namedroppers@ops.ietf.org; Tue, 07 Jan 2003 06:33:55 -0800 Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18Vung-0002xJ-00; Tue, 07 Jan 2003 06:33:53 -0800 Date: Tue, 7 Jan 2003 09:31:05 -0500 From: Keith Moore To: namedroppers@ops.ietf.org Cc: moore@cs.utk.edu Subject: commens on draft-dnsext-opcode-discover-01.txt Message-Id: <20030107093105.12ade898.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Note: I'm reading this as if it's a draft protocol specification rather than as if it's intended as an informational or experimental document. Even if the latter is intended, some amount of clarification seems in order. 1. use of SRV to implement getservbyname It is not appropriate to use SRV lookups to implement getservbyname(). This would change the behavior of nearly every protocol on the Internet without considering the impact on the protocol or applications that use it. Use of SRV MUST be determined on a per-protocol or per-application basis. Furthermore SRV was intended to delegate services for specific DNS domains, and getservbyname() doesn't provide a way to input the domain for which the SRV query is being made. Trying to use SRV as a generic way to look up "well known ports" independent of domain is overloading the SRV RR type. That,and trying to use the network to look up constants never was a good idea, not in the context of YP/NIS or anything else. I've seen too many programs fail because getservbyname() was implemented using NIS, and the NIS server was down. It's not as if protocol implementors don't know what port numbers to use anyway. If it's reasonable for a protocol implementation to include string constants like "MAIL FROM" or "POST", then it's reasonable for that protocol implementation to include integer constants like htons(25) or htons(80). 2. under section 2, "method", "Example usage for gethostby{name,addr}-style requestors:" it's not at all clear why "the zone name of the enclosing in-addr.arpa, ip6.int, or ip6.arpa domain" is relevant to an A or AAAA query (as in gethostbyname ) or why queries for a particular NAME should only be sent to servers that are authoritative for the enclosing ADDRESS domain. Is this really what is intended or is it just poor wording? It reads as if you're trying to make the results of DNS lookups vary according to location. 3. same section "Once one learns a host's FQDN by the above means, repeat the process for discovering the closest enclosing authoritative server of such local name." the idea that a host has "a" FQDN seems anachronistic at best. hosts have zero or more addresses assigned to them at any particular time; each address may be associated with zero or more FQDNs. the address-to-host bindings may be short- or long-lived. in general there is no way that the network can be expected to know whether a particular FQDN is any kind of "distinguished name" for a host. the host has to be configured to know this on its own. 4. regarding disconnected networks NO server -- whether multicast or not, whether using DISCOVER or not, whether using the DNS port or not, whether using the DNS protocl or not -- should be answering queries as if it were authoritative for any DNS zone for which that server is not authoritative. The result will inevitiably be that such results are leaked into, and mixed with, results from legitimate DNS servers. a network which appears isolated to one host in a network may not be isolated to another host in the same network. if you want "disconnected" servers to respond to queries for FQDNs then those servers need to be authoritative for those FQDNs, and they need to produce results which are consistent with the other servers for those FQDNs. if some of those servers are on isolated networks and others are on the global internet, this is not a problem as long as the rules for serial numbers are followed. DNS can cope with different servers returning different results as long as those servers have different serial numbers and single-copy serializability is maintained. If a host which is authoritative for one or more FQDNs that are assigned to a host migrates from one network to another, or for whatever reason acquires a new address and/or needs to change its RRs, that host can update its RRs on its stub server and increment the serial # for that zone. If and when the host has connectivity to the (other) advertised servers for that zone, it should update those servers. But even if the host finds itself on an isolated network there is no problem with its updating its own zone and incrementing the serial number, perhaps multiple times, as long as it updates the slave servers whenever it is possible to do so. Of course there are operational concerns associated with advertising RRs that point to addresses that are not reachable, but we generally expect protocols to be robust when hosts are not reachable anyway. Appropriate assignment of TTLs is the best solution here, and the host is in the best position to know whether its RRs should have long or short TTLs (e.g. whether it is stable or nomadic). -- 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 Jan 8 09:11:30 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20420 for ; Wed, 8 Jan 2003 09:11:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18WGdL-000FfA-00 for namedroppers-data@psg.com; Wed, 08 Jan 2003 05:52:39 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #2) id 18WGcp-000Fes-00 for namedroppers@ops.ietf.org; Wed, 08 Jan 2003 05:52:07 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19366; Wed, 8 Jan 2003 08:48:47 -0500 (EST) Message-Id: <200301081348.IAA19366@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-ecc-key-03.txt Date: Wed, 08 Jan 2003 08:48:47 -0500 X-Spam-Status: No, hits=4.6 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02,TO_MALFORMED version=2.43 X-Spam-Level: **** 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 : Elliptic Curve KEYs in the DNS Author(s) : R. Schroeppel, D. Eastlake Filename : draft-ietf-dnsext-ecc-key-03.txt Pages : 14 Date : 2003-1-7 A standard method for storing elliptic curve cryptographic keys in the Domain Name System is described which utilizes DNS KEY resource record. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ecc-key-03.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-ecc-key-03.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-ecc-key-03.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: <2003-1-7160648.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-ecc-key-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-ecc-key-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-7160648.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 Thu Jan 9 09:32:27 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11391 for ; Thu, 9 Jan 2003 09:32:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18WdVB-000HhL-00 for namedroppers-data@psg.com; Thu, 09 Jan 2003 06:17:45 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #2) id 18WdV6-000Hgs-00 for namedroppers@ops.ietf.org; Thu, 09 Jan 2003 06:17:40 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10267; Thu, 9 Jan 2003 09:14:21 -0500 (EST) Message-Id: <200301091414.JAA10267@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-keyrr-key-signing-flag-05.txt Date: Thu, 09 Jan 2003 09:14:21 -0500 X-Spam-Status: No, hits=4.6 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02,TO_MALFORMED version=2.43 X-Spam-Level: **** 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 : KEY RR Key-Signing Key (KSK) Flag Author(s) : O. Kolkman, J. Schlyter, E. Lewis Filename : draft-ietf-dnsext-keyrr-key-signing-flag-05.txt Pages : 9 Date : 2003-1-8 With the DS resource record the concept of key-signing and zone- signing keys has been introduced. During key-exchanges with the parent there is a need to differentiate between these zone- and key- signing keys. We propose a flag to indicate which key is used as key-signing key. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-keyrr-key-signing-flag-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-keyrr-key-signing-flag-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-keyrr-key-signing-flag-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: <2003-1-9091940.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-keyrr-key-signing-flag-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-keyrr-key-signing-flag-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-9091940.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 Jan 10 11:44:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03306 for ; Fri, 10 Jan 2003 11:44:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18X1zH-000PGf-00 for namedroppers-data@psg.com; Fri, 10 Jan 2003 08:26:27 -0800 Received: from e35.co.us.ibm.com ([32.97.110.133]) by psg.com with esmtp (Exim 3.36 #2) id 18X1zB-000PFl-00 for namedroppers@ops.ietf.org; Fri, 10 Jan 2003 08:26:21 -0800 Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e35.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id h0AGPDeP026194; Fri, 10 Jan 2003 11:25:13 -0500 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.12.14]) by westrelay03.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id h0AGPCFU047658; Fri, 10 Jan 2003 09:25:12 -0700 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id h0AGOqL09468; Fri, 10 Jan 2003 11:24:52 -0500 Message-Id: <200301101624.h0AGOqL09468@rotala.raleigh.ibm.com> To: "D. J. Bernstein" cc: ietf@ietf.org, iesg@ietf.org, namedroppers Subject: Dan Bernstein's issues about namedroppers list operation Date: Fri, 10 Jan 2003 11:24:52 -0500 From: Thomas Narten X-Spam-Status: No, hits=-1.5 required=5.0 tests=EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,SPAM_PHRASE_03_05, SUBJECT_IS_LIST version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Dan Bernstein has been making repeated claims that Randy is censoring his postings to namedroppers. I took a look at the claims he has made and here is how I see things. Executive summary: I see no evidence that Randy is censoring postings from Dan. It is the case that some of his messages do not appear to have made it out on namedroppers, but it is unclear why this is. Furthermore, given that most of these missing messages were cc'ed to other lists (i.e., the ietf and iesg lists), there is no evidence of censorship. Namedroppers is a posters-only mailing list that is run in conformance with the policies outlined in http://www.ietf.cnri.reston.va.us/IESG/STATEMENTS/mail-submit-policy.txt. Specifically, all mail sent to namedroppers is: 1) first run through spamassassin. Mail that is rejected here is not archived, as the number of such messages is large. All mail sent to mailing lists on the server hosting namedroppers is run though spamassassin, so this is not a namedroppers-specific procedure. 2) if sent by a subscriber to the mailing list (or by someone in the known posters list), the message is sent immediately. 3) Otherwise, it is queued waiting for approval (or rejection) by the maling list operators. Both Randy and Mark Kosters see these rejected postings. Mark has indicated that he has seen no rejected postings that were not forwarded to the namedroppers mailing list that should have been. It does appear that *some* of the message that Dan has sent to namedroppers have not appeared on the namedroppers mailing list. But it is unclear why that happened. At the time of these postings, some of his other messages have gone through. Also, most of the messages that didn't appear did appear on other mailing lists that were cc'ed. It is unclear why those messages did not make it to namedroppers, but now that Dan's posting address is in the the list of know posters for namedroppers, and his mail seems to be getting through, it seems best to just keep an eye on further problems and investigate them as soon as they happen (e.g, when relevant logs are available). I see no evidence that Randy (or anyone else) is singling out anyone's postings for rejection. Details on specifics follow. "D. J. Bernstein" writes: > Bush imposed his mailing-list control methods without IESG approval, in > violation of RFC 2418, section 3.2. He has been caught engaging in > content-based censorship several times: > http://cr.yp.to/djbdns/namedroppers.html > Background > > The DNS protocol is covered by various IETF specifications. > Unfortunately, obeying those specifications is not sufficient to ensure > interoperability with BIND, in part because the specifications are > ambiguous or otherwise flawed, and in part because BIND violates the > specifications in many ways. > > These facts have hurt competition, and contributed to BIND's market > share, at the expense of the users. For example, one site using lbnamed, > a special-purpose DNS implementation, has had interoperability problems > with BIND, and has been planning to abandon lbnamed in favor of BIND, > even though this means giving up some useful features. > > In late 1999, after yet another BIND security hole was announced, I > wrote a free BIND replacement. Interoperability among DNS > implementations is, of course, essential. I found the IETF > specifications horribly inadequate. > > > The namedroppers mailing list > > IETF carries out its DNS protocol standardization activities within the > DNSEXT working group. The DNSEXT mailing list is > namedroppers@internic.net, also known as comp.protocols.dns.std. This is old and incorrect, for quite some time. The mailing list is namedroppers@ops.ietf.org. Mail from the mailing list may be gatewayed one-way to usenet, but the reverse is not true. [Actually, I've been told that usenet mail is selectively being forwarded back to the list by someone, but it seems "very selectively", as this has happened to only a handful of messages in several months.] > ``Within the scope of this WG are protocol issues, including message > formats, message handling, and data formats,'' the DNSEXT charter says. > Several specific issues have been identified as work items, but other > DNS protocol issues remain clearly within the charter. In particular, > namedroppers is obviously the right forum for implementors to discuss > current and future DNS interoperability problems. > > Unfortunately, namedroppers is being run in a way that slows down, and > sometimes prevents, public communication among DNS implementors. > > Messages to namedroppers are not forwarded directly to subscribers. They > are first sent to Randy Bush. They wait for Bush's review. Bush > discards, edits, or misdirects messages that he doesn't like, and passes > along what's left. > > Here are some specific examples. Many of these incidents involved > opsmail.internic.net, which used some painfully slow, creaky, obsolete > software to distribute messages to subscribers. > > * 1998-12: Bush discarded a message from Richard Sexton commenting > on a proposed extension to MX records, a DNS protocol element. > * 1998-12: Bush edited a message of mine, unilaterally removing a > paragraph at the top that asked why opsmail was so slow. How is > someone supposed to find out what the namedroppers subscribers > think of how the mailing list is run, if complaints to the list > are censored? > * 1999-01: Bush discarded a message from Richard Sexton about client > interpretation of the AA bit, a DNS protocol element, by NSI, the > operators of some well-known DNS TLDs. > * 1999-12: Bush discarded a message of mine > concerning yet > another DNS protocol violation by BIND. ``This belongs in > bind-users@isc.org, not namedroppers,'' Bush told me > , incorrectly. > * 1999-12-31: opsmail finally sent a message that it had received on > 1999-11-04, nearly two months earlier, to a namedroppers > subscription address that had been removed from the list on > 1999-11-25. > * 1999-12-31: I sent an urgent message > to namedroppers > attempting to confirm rumors of a DNS server bug that, if true, > would have been triggered on occasion by my new DNS cache. Someone > else sent a message to namedroppers 14 hours later, and then > another message 4 hours after that; 12 minutes later, Bush sent > those two messages to opsmail; several hours later, opsmail > finally forwarded the messages to me. A day later, I asked Bush > why my message hadn't appeared yet. He finally sent my message to > opsmail three days after I had sent it. I saw a copy from opsmail > several hours after that. > * 2000-01-12: I sent another message > to namedroppers > pointing out a security problem that I had described on bugtraq, > and asking DNSEXT to fix the relevant RFC, which had been > co-written by Bush. My message never appeared on namedroppers. > Bush didn't send me an explanation. I learned much later that Bush > had deliberately misdirected > my message, > sending it to the dnsop mailing list. > * 2000-01-28: I sent a message > to namedroppers > pointing out how Bush's censorship activities had biased DNSEXT > discussions, and a message > to namedroppers > criticizing Bush's unilateral statement of the namedroppers scope. > These messages were direct responses to recent namedroppers > messages, the first by Thomas Narten, the second by Bush. Bush > sent both messages back to me, without saying explicitly what he > had done with them. > * 2000-02-20: I pointed out > on namedroppers > that thousands of system administrators were using dotted-decimal > domain names in MX records. There was some discussion on > namedroppers. Rob Austein and Bill Manning asked for evidence; > Bush claimed that he couldn't find even a single example ``in > almost twenty thousand zones secondaried here from all over the > world.'' A few days later, I sent survey results > to namedroppers > showing that there were approximately fifteen /thousand/ > second-level .com domains with dotted-decimal domain names in > their MX records, usually with no other MX records. My message > never appeared on namedroppers. ``Please report bugs in peoples > zone files to the people with the bugs, not namedroppers,'' Bush > told me. > * 2000-02-21: Bush discarded a message from Dean Anderson > > supporting expansion of the MX protocol definition to allow > dotted-decimal domain names. > * 2000-02-23: I sent another message > to namedroppers > objecting to Bush's censorship. Bush discarded my message. > * 2000-03-12: I sent a message > to namedroppers > asking about DNS query transmission strategy. Bush wrote back: > ``if your question is about the protocol, then fine. if it is > about how the dns operates and how folk's implementations effect > that, then post it to the mailing list for that implementation or > to the dnsop list. i.e. keep your bind bashing off this list.'' I > responded: ``My message asks about an efficiency problem in the > DNS protocol, and gives some illustrative examples. Are you going > to pass my message along to the list, or not?'' Bush discarded my > messages without further comment. > * 2001-03-17: I sent a message > to namedroppers > objecting to a BIND company proposal to modify the DNS protocol. > Bush discarded my message without comment. All of the above is so old there is no point in discussing again. See, for example, http://www.iab.org/Documents/BernsteinAppealResponse.txt > * 2002.11.17: I sent a message > to namedroppers > objecting to Bush and Gudmundsson sending the axfr-clarify > document to the IESG, and summarizing ten > problems with that document. Bush silently discarded my > message. This message was sent to the iesg, ietf and namedroppers mailing list. The message did make it out on at least the iesg mailing list (where I saw a copy), but I do not see it in the namedroppers archive. > * 2002.11.20: I sent a message > to namedroppers > discussing the lack of consensus behind axfr-clarify and > complaining about Bush's censorship. Bush silently discarded my > message. Again, this message was posted to the ietf, iesg and namedroppers list. I see this message did get posted to the iesg list; I do not see it in the namedroppers archive. > * 2002.11.20, continued: I sent a message > to namedroppers > discussing the interoperability problems in axfr-clarify. Bush > silently discarded my message. After Bush wrote (on another list) > ``it is easy to miss and therefore delete mis-posts,'' I sent a > message to > namedroppers saying ``Funny how this happens so often for people > you disagree with'' and reminding Bush that he was causing > problems for newsgroup readers, sublist readers, and ``readers > with private subscription addresses''; Bush allowed that message > through. Again, this message was posted to the ietf, iesg and namedroppers list. I see this message made it do the iesg list; I do not see it in the namedroppers archive. > * 2002.11.20, continued: I sent a message > to namedroppers > discussing the use of separate TCP/UDP ports. Bush silently > discarded my message. This note was allegedely sent to namedroppers (and no where else). It is not in the namedroppers archive. It is noted, however, that other messages from Dan did appear on namedroppers that day. > My subscription address stopped receiving messages from the > namedroppers mailing list. About 40 hours later, I asked Bush what > was going on: > > Is that address still on the list? If not, why not? Does your > software reveal subscription addresses? Does it allow > unconfirmed unsubscription requests? Does it use > non-cryptographic cookies in confirmation notices? If the > address is still on the list, why aren't the outgoing messages > being delivered? Is there some general problem with all > addresses? > > Suddenly the messages all came through. Can't say what this was all about. Temporary mail problems? > * 2002.11.23: I sent a message > and another > message to > namedroppers. Bush promptly forwarded both messages. However, in > the second message, he manually inserted my subscription address, > despite my previous comments about private subscription addresses > and forged unsubscription requests. (Was this malicious, or was it > just mind-bogglingly stupid?) Or perhaps, it was to make it clear to the poster which address the posting was coming from, since there seems to be confusion at times about whether someone is posting from the same address to which they are subscribed. "D. J. Bernstein" writes: > * 2002.11.25: I sent a message > From: "D. J. Bernstein" > To: namedroppers@ops.ietf.org > Cc: sob@harvard.edu > Date: 15 Dec 2002 03:18:14 -0000 > Subject: Re: repeating records > Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. > I've noticed that Randy Bush discarded Len Budney's note on this topic: > http://groups.google.com/groups?selm=asnul4%24640g%241%40isrv4.isc.org Not so. Len's note was posted to usenet, not to the namedroppers mailing list. Mail from usenet cannot be assumed to get gatewayed back to the mailing list. Thomas -- 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 Jan 10 12:54:35 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06642 for ; Fri, 10 Jan 2003 12:54:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18X3EK-0001PO-00 for namedroppers-data@psg.com; Fri, 10 Jan 2003 09:46:04 -0800 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #2) id 18X3EI-0001PB-00 for namedroppers@ops.ietf.org; Fri, 10 Jan 2003 09:46:02 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 4A501379FBB; Fri, 10 Jan 2003 17:46:01 +0000 (GMT) From: Paul Vixie To: Thomas Narten Cc: "D. J. Bernstein" , ietf@ietf.org, iesg@ietf.org, namedroppers Subject: Re: Dan Bernstein's issues about namedroppers list operation In-Reply-To: Message from Thomas Narten of "Fri, 10 Jan 2003 11:24:52 EST." <200301101624.h0AGOqL09468@rotala.raleigh.ibm.com> X-Mailer: MH-E 7.0; nmh 1.0.4; Emacs 21.2 Date: Fri, 10 Jan 2003 17:46:01 +0000 Message-Id: <20030110174601.4A501379FBB@as.vix.com> X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02, SUBJECT_IS_LIST version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk thomas, et al, i have a bone to pick. while dr. bernstein would most likely say that i am no friend to him nor to his chosen issues, the fact is that his complaint has some validity if you look at it edge-on rather than face-on. > Namedroppers is a posters-only mailing list that is run in conformance > with the policies outlined in > http://www.ietf.cnri.reston.va.us/IESG/STATEMENTS/mail-submit-policy.txt. > > Specifically, all mail sent to namedroppers is: > > 1) first run through spamassassin. Mail that is rejected here is not > archived, as the number of such messages is large. All mail sent to > mailing lists on the server hosting namedroppers is run though > spamassassin, so this is not a namedroppers-specific procedure. this is just wrong. spamassassin operates at the MUA level, and as such, the originating MTA receives a "final OK" and drops the connection before spamassassin begins its job. the MUA's only choices when dropping mail due to spamassassin's filtering are: issue a new message back to the sender to inform them of the bounce, or silently drop. because most of the mail spamassassin will drop has an invalid sender address, choice #2 is common. for an IETF list, if submitted mail is being dropped, there must be notice back to the sender. because the sender address will generally not be usable, the only possible choice is to issue the rejection at the MTA level. this will require tighter integration of spamassassin into the MTA level than is currently done on randy's system, or indeed, currently done anywhere at all. silent drops are fatal to the IETF's policy of open discourse, and dr. bernstein is right to complain about that aspect of the namedroppers problems he is experiencing. every time one of dr. bernstein's messages is dropped, dr. bernstein's originating MTA should experience an SMTP delivery error and therefore have the option of informing dr. bernstein that such rejection has occurred. one other very minor point: > > I've noticed that Randy Bush discarded Len Budney's note on this topic: > > http://groups.google.com/groups?selm=asnul4%24640g%241%40isrv4.isc.org > > Not so. Len's note was posted to usenet, not to the namedroppers > mailing list. Mail from usenet cannot be assumed to get gatewayed back > to the mailing list. as the usenet moderator of comp.protocols.dns.std, i set up a bidirectional gateway which isc operates. this gateway is far from perfect, and many posts have been dropped (silently, of course) over the years, and anyone who wants to really ensure that their words appear on namedroppers should avoid the use of the usenet->namedroppers gateway, and mail their words directly to the namedroppers list. paul -- 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 Jan 10 13:34:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10075 for ; Fri, 10 Jan 2003 13:34:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18X3uU-0002kj-00 for namedroppers-data@psg.com; Fri, 10 Jan 2003 10:29:38 -0800 Received: from [63.149.73.20] (helo=vorpal.notabug.com ident=qmailr) by psg.com with smtp (Exim 3.36 #2) id 18X3uR-0002kN-00 for namedroppers@ops.ietf.org; Fri, 10 Jan 2003 10:29:35 -0800 Received: (qmail 30500 invoked from network); 10 Jan 2003 18:29:32 -0000 Received: from 12-249-96-16.client.attbi.com (HELO aaronsw.com) (12.249.96.16) by 0 with SMTP; 10 Jan 2003 18:29:32 -0000 Date: Fri, 10 Jan 2003 12:29:32 -0600 Subject: Re: Dan Bernstein's issues about namedroppers list operation Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: namedroppers , iesg@ietf.org, ietf@ietf.org, "D. J. Bernstein" To: Thomas Narten From: Aaron Swartz In-Reply-To: <200301101624.h0AGOqL09468@rotala.raleigh.ibm.com> Message-Id: <7661B517-24C9-11D7-9721-0003936780B2@aaronsw.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_01_02,SUBJECT_IS_LIST,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Thomas Narten wrote: > Namedroppers is a posters-only mailing list that is run in conformance > with the policies outlined in > http://www.ietf.cnri.reston.va.us/IESG/STATEMENTS/mail-submit- > policy.txt. This states: """ 4) Any held message that is later approved for distribution on the mailing list should appear on the list as a normal posting (e.g., with the proper sender in the From address, etc.). """ Later, however, you write: >> [...] However, in >> the second message, he manually inserted my subscription >> address, >> despite my previous comments about private subscription >> addresses >> and forged unsubscription requests. (Was this malicious, or was >> it >> just mind-bogglingly stupid?) > > Or perhaps, it was to make it clear to the poster which address the > posting was coming from, since there seems to be confusion at times > about whether someone is posting from the same address to which they > are subscribed. Including someone's private subscription address is not done for a normal posting. Doing it for a held message is a violation of the rule above, no? -- Aaron Swartz [http://www.aaronsw.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 Jan 10 13:39:52 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10582 for ; Fri, 10 Jan 2003 13:39:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18X40P-0002w2-00 for namedroppers-data@psg.com; Fri, 10 Jan 2003 10:35:45 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #2) id 18X40N-0002vp-00 for namedroppers@ops.ietf.org; Fri, 10 Jan 2003 10:35:43 -0800 Received: from localhost ([127.0.0.1] helo=rip.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 18X40N-0005uK-00 for namedroppers@ops.ietf.org; Fri, 10 Jan 2003 10:35:43 -0800 In-Reply-To: <200301101624.h0AGOqL09468@rotala.raleigh.ibm.com> Message-ID: References: <200301101624.h0AGOqL09468@rotala.raleigh.ibm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Fri, 10 Jan 2003 17:30:37 +0000 (GMT) From: Lloyd Wood To: Thomas Narten cc: "D. J. Bernstein" , "" , "" , namedroppers Subject: Re: Dan Bernstein's issues about namedroppers list operation X-Spam-Status: No, hits=-3.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, RESENT_TO,SPAM_PHRASE_02_03,SUBJECT_IS_LIST,USER_AGENT_PINE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] On Fri, 10 Jan 2003, Thomas Narten wrote: > Dan Bernstein has been making repeated claims that Randy is censoring > his postings to namedroppers. I took a look at the claims he has made > and here is how I see things. > > Executive summary: I see no evidence that Randy is censoring postings > from Dan. It is the case that some of his messages do not appear to > have made it out on namedroppers, but it is unclear why this is. [..] > It does appear that *some* of the message that Dan has sent to > namedroppers have not appeared on the namedroppers mailing list. But > it is unclear why that happened. In other words, you see no evidence that Bush _isn't_ censoring postings from Bernstein. [Much justifying-the-status-quo snipped] > All of the above is so old there is no point in discussing again. A jolly refreshing attitude. Wish it was brought up more whenever that 'American Constituion' thing comes up. L. -- 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 Jan 10 13:54:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11142 for ; Fri, 10 Jan 2003 13:54:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18X4BT-0003L7-00 for namedroppers-data@psg.com; Fri, 10 Jan 2003 10:47:11 -0800 Received: from relay2.av8.net ([130.105.12.4] helo=citation.av8.net) by psg.com with esmtp (Exim 3.36 #2) id 18X4BO-0003Ki-00 for namedroppers@ops.ietf.org; Fri, 10 Jan 2003 10:47:06 -0800 Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id NAA10067; Fri, 10 Jan 2003 13:40:43 -0500 Date: Fri, 10 Jan 2003 13:41:06 -0500 (EST) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: Thomas Narten cc: "D. J. Bernstein" , , , namedroppers Subject: Re: Dan Bernstein's issues about namedroppers list operation In-Reply-To: <200301101624.h0AGOqL09468@rotala.raleigh.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,SPAM_PHRASE_02_03,SUBJECT_IS_LIST, TO_BE_REMOVED_REPLY,USER_AGENT_PINE,X_OSIRU_SPAM_SRC version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This isn't true. We have been examining the issue, and have found clear evidence that Bernstein's email has been censored and handled differently from other email to namedroppers in recent months, and in the past, prior to changes in the adminstration of namedroppers. We are not yet ready to summarize this evidence. However, it cannot be concluded that there is no such evidence. Dean Anderson On Fri, 10 Jan 2003, Thomas Narten wrote: > Dan Bernstein has been making repeated claims that Randy is censoring > his postings to namedroppers. I took a look at the claims he has made > and here is how I see things. > > Executive summary: I see no evidence that Randy is censoring postings > from Dan. It is the case that some of his messages do not appear to > have made it out on namedroppers, but it is unclear why this is. > Furthermore, given that most of these missing messages were cc'ed to > other lists (i.e., the ietf and iesg lists), there is no evidence of > censorship. > > Namedroppers is a posters-only mailing list that is run in conformance > with the policies outlined in > http://www.ietf.cnri.reston.va.us/IESG/STATEMENTS/mail-submit-policy.txt. > > Specifically, all mail sent to namedroppers is: > > 1) first run through spamassassin. Mail that is rejected here is not > archived, as the number of such messages is large. All mail sent to > mailing lists on the server hosting namedroppers is run though > spamassassin, so this is not a namedroppers-specific procedure. > > 2) if sent by a subscriber to the mailing list (or by someone in the > known posters list), the message is sent immediately. > > 3) Otherwise, it is queued waiting for approval (or rejection) by the > maling list operators. Both Randy and Mark Kosters see these > rejected postings. Mark has indicated that he has seen no rejected > postings that were not forwarded to the namedroppers mailing list > that should have been. > > It does appear that *some* of the message that Dan has sent to > namedroppers have not appeared on the namedroppers mailing list. But > it is unclear why that happened. At the time of these postings, some > of his other messages have gone through. Also, most of the messages > that didn't appear did appear on other mailing lists that were > cc'ed. It is unclear why those messages did not make it to > namedroppers, but now that Dan's posting address is in the the list of > know posters for namedroppers, and his mail seems to be getting > through, it seems best to just keep an eye on further problems and > investigate them as soon as they happen (e.g, when relevant logs are > available). I see no evidence that Randy (or anyone else) is singling > out anyone's postings for rejection. > > Details on specifics follow. > > "D. J. Bernstein" writes: > > > Bush imposed his mailing-list control methods without IESG approval, in > > violation of RFC 2418, section 3.2. He has been caught engaging in > > content-based censorship several times: > > > http://cr.yp.to/djbdns/namedroppers.html > > > Background > > > > The DNS protocol is covered by various IETF specifications. > > Unfortunately, obeying those specifications is not sufficient to ensure > > interoperability with BIND, in part because the specifications are > > ambiguous or otherwise flawed, and in part because BIND violates the > > specifications in many ways. > > > > These facts have hurt competition, and contributed to BIND's market > > share, at the expense of the users. For example, one site using lbnamed, > > a special-purpose DNS implementation, has had interoperability problems > > with BIND, and has been planning to abandon lbnamed in favor of BIND, > > even though this means giving up some useful features. > > > > In late 1999, after yet another BIND security hole was announced, I > > wrote a free BIND replacement. Interoperability among DNS > > implementations is, of course, essential. I found the IETF > > specifications horribly inadequate. > > > > > > The namedroppers mailing list > > > > IETF carries out its DNS protocol standardization activities within the > > DNSEXT working group. The DNSEXT mailing list is > > namedroppers@internic.net, also known as comp.protocols.dns.std. > > This is old and incorrect, for quite some time. The mailing list is > namedroppers@ops.ietf.org. Mail from the mailing list may be gatewayed > one-way to usenet, but the reverse is not true. [Actually, I've been > told that usenet mail is selectively being forwarded back to the list > by someone, but it seems "very selectively", as this has happened to > only a handful of messages in several months.] > > > ``Within the scope of this WG are protocol issues, including message > > formats, message handling, and data formats,'' the DNSEXT charter says. > > Several specific issues have been identified as work items, but other > > DNS protocol issues remain clearly within the charter. In particular, > > namedroppers is obviously the right forum for implementors to discuss > > current and future DNS interoperability problems. > > > > Unfortunately, namedroppers is being run in a way that slows down, and > > sometimes prevents, public communication among DNS implementors. > > > > Messages to namedroppers are not forwarded directly to subscribers. They > > are first sent to Randy Bush. They wait for Bush's review. Bush > > discards, edits, or misdirects messages that he doesn't like, and passes > > along what's left. > > > > Here are some specific examples. Many of these incidents involved > > opsmail.internic.net, which used some painfully slow, creaky, obsolete > > software to distribute messages to subscribers. > > > > * 1998-12: Bush discarded a message from Richard Sexton commenting > > on a proposed extension to MX records, a DNS protocol element. > > * 1998-12: Bush edited a message of mine, unilaterally removing a > > paragraph at the top that asked why opsmail was so slow. How is > > someone supposed to find out what the namedroppers subscribers > > think of how the mailing list is run, if complaints to the list > > are censored? > > * 1999-01: Bush discarded a message from Richard Sexton about client > > interpretation of the AA bit, a DNS protocol element, by NSI, the > > operators of some well-known DNS TLDs. > > * 1999-12: Bush discarded a message of mine > > concerning yet > > another DNS protocol violation by BIND. ``This belongs in > > bind-users@isc.org, not namedroppers,'' Bush told me > > , incorrectly. > > * 1999-12-31: opsmail finally sent a message that it had received on > > 1999-11-04, nearly two months earlier, to a namedroppers > > subscription address that had been removed from the list on > > 1999-11-25. > > * 1999-12-31: I sent an urgent message > > to namedroppers > > attempting to confirm rumors of a DNS server bug that, if true, > > would have been triggered on occasion by my new DNS cache. Someone > > else sent a message to namedroppers 14 hours later, and then > > another message 4 hours after that; 12 minutes later, Bush sent > > those two messages to opsmail; several hours later, opsmail > > finally forwarded the messages to me. A day later, I asked Bush > > why my message hadn't appeared yet. He finally sent my message to > > opsmail three days after I had sent it. I saw a copy from opsmail > > several hours after that. > > * 2000-01-12: I sent another message > > to namedroppers > > pointing out a security problem that I had described on bugtraq, > > and asking DNSEXT to fix the relevant RFC, which had been > > co-written by Bush. My message never appeared on namedroppers. > > Bush didn't send me an explanation. I learned much later that Bush > > had deliberately misdirected > > my message, > > sending it to the dnsop mailing list. > > * 2000-01-28: I sent a message > > to namedroppers > > pointing out how Bush's censorship activities had biased DNSEXT > > discussions, and a message > > to namedroppers > > criticizing Bush's unilateral statement of the namedroppers scope. > > These messages were direct responses to recent namedroppers > > messages, the first by Thomas Narten, the second by Bush. Bush > > sent both messages back to me, without saying explicitly what he > > had done with them. > > * 2000-02-20: I pointed out > > on namedroppers > > that thousands of system administrators were using dotted-decimal > > domain names in MX records. There was some discussion on > > namedroppers. Rob Austein and Bill Manning asked for evidence; > > Bush claimed that he couldn't find even a single example ``in > > almost twenty thousand zones secondaried here from all over the > > world.'' A few days later, I sent survey results > > to namedroppers > > showing that there were approximately fifteen /thousand/ > > second-level .com domains with dotted-decimal domain names in > > their MX records, usually with no other MX records. My message > > never appeared on namedroppers. ``Please report bugs in peoples > > zone files to the people with the bugs, not namedroppers,'' Bush > > told me. > > * 2000-02-21: Bush discarded a message from Dean Anderson > > > > supporting expansion of the MX protocol definition to allow > > dotted-decimal domain names. > > * 2000-02-23: I sent another message > > to namedroppers > > objecting to Bush's censorship. Bush discarded my message. > > * 2000-03-12: I sent a message > > to namedroppers > > asking about DNS query transmission strategy. Bush wrote back: > > ``if your question is about the protocol, then fine. if it is > > about how the dns operates and how folk's implementations effect > > that, then post it to the mailing list for that implementation or > > to the dnsop list. i.e. keep your bind bashing off this list.'' I > > responded: ``My message asks about an efficiency problem in the > > DNS protocol, and gives some illustrative examples. Are you going > > to pass my message along to the list, or not?'' Bush discarded my > > messages without further comment. > > * 2001-03-17: I sent a message > > to namedroppers > > objecting to a BIND company proposal to modify the DNS protocol. > > Bush discarded my message without comment. > > All of the above is so old there is no point in discussing again. See, > for example, http://www.iab.org/Documents/BernsteinAppealResponse.txt > > > * 2002.11.17: I sent a message > > to namedroppers > > objecting to Bush and Gudmundsson sending the axfr-clarify > > document to the IESG, and summarizing ten > > problems with that document. Bush silently discarded my > > message. > > This message was sent to the iesg, ietf and namedroppers mailing > list. The message did make it out on at least the iesg mailing list > (where I saw a copy), but I do not see it in the namedroppers archive. > > > * 2002.11.20: I sent a message > > to namedroppers > > discussing the lack of consensus behind axfr-clarify and > > complaining about Bush's censorship. Bush silently discarded my > > message. > > Again, this message was posted to the ietf, iesg and namedroppers > list. I see this message did get posted to the iesg list; I do not see > it in the namedroppers archive. > > > * 2002.11.20, continued: I sent a message > > to namedroppers > > discussing the interoperability problems in axfr-clarify. Bush > > silently discarded my message. After Bush wrote (on another list) > > ``it is easy to miss and therefore delete mis-posts,'' I sent a > > message to > > namedroppers saying ``Funny how this happens so often for people > > you disagree with'' and reminding Bush that he was causing > > problems for newsgroup readers, sublist readers, and ``readers > > with private subscription addresses''; Bush allowed that message > > through. > > Again, this message was posted to the ietf, iesg and namedroppers > list. I see this message made it do the iesg list; I do not see it in > the namedroppers archive. > > > * 2002.11.20, continued: I sent a message > > to namedroppers > > discussing the use of separate TCP/UDP ports. Bush silently > > discarded my message. > > This note was allegedely sent to namedroppers (and no where else). It > is not in the namedroppers archive. It is noted, however, that other > messages from Dan did appear on namedroppers that day. > > > My subscription address stopped receiving messages from the > > namedroppers mailing list. About 40 hours later, I asked Bush what > > was going on: > > > > Is that address still on the list? If not, why not? Does your > > software reveal subscription addresses? Does it allow > > unconfirmed unsubscription requests? Does it use > > non-cryptographic cookies in confirmation notices? If the > > address is still on the list, why aren't the outgoing messages > > being delivered? Is there some general problem with all > > addresses? > > > > Suddenly the messages all came through. > > Can't say what this was all about. Temporary mail problems? > > > * 2002.11.23: I sent a message > > and another > > message to > > namedroppers. Bush promptly forwarded both messages. However, in > > the second message, he manually inserted my subscription address, > > despite my previous comments about private subscription addresses > > and forged unsubscription requests. (Was this malicious, or was it > > just mind-bogglingly stupid?) > > Or perhaps, it was to make it clear to the poster which address the > posting was coming from, since there seems to be confusion at times > about whether someone is posting from the same address to which they > are subscribed. > > "D. J. Bernstein" writes: > > > * 2002.11.25: I sent a message > > From: "D. J. Bernstein" > > To: namedroppers@ops.ietf.org > > Cc: sob@harvard.edu > > Date: 15 Dec 2002 03:18:14 -0000 > > Subject: Re: repeating records > > Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. > > > I've noticed that Randy Bush discarded Len Budney's note on this topic: > > http://groups.google.com/groups?selm=asnul4%24640g%241%40isrv4.isc.org > > Not so. Len's note was posted to usenet, not to the namedroppers > mailing list. Mail from usenet cannot be assumed to get gatewayed back > to the mailing list. > > Thomas > > -- > 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 Jan 10 15:34:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15290 for ; Fri, 10 Jan 2003 15:34:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18X5mg-0006it-00 for namedroppers-data@psg.com; Fri, 10 Jan 2003 12:29:42 -0800 Received: from abq-web-1.webrack.biz ([64.46.32.10]) by psg.com with esmtp (Exim 3.36 #2) id 18X5mc-0006iW-00 for namedroppers@ops.ietf.org; Fri, 10 Jan 2003 12:29:38 -0800 Received: from thebindcompany.net (localhost.localdomain [127.0.0.1]) (authenticated (0 bits)) by abq-web-1.webrack.biz (8.11.6/8.11.6) with ESMTP id h0AKUoB21614; Fri, 10 Jan 2003 13:30:50 -0700 Received: from 216.223.236.249 (SquirrelMail authenticated user q@thebindcompany.net) by www.thebindcompany.net with HTTP; Fri, 10 Jan 2003 13:30:51 -0700 (MST) Message-ID: <3084.216.223.236.249.1042230651.squirrel@www.thebindcompany.net> Date: Fri, 10 Jan 2003 13:30:51 -0700 (MST) Subject: Re: Dan Bernstein's issues about namedroppers list operation From: To: In-Reply-To: <20030110174601.4A501379FBB@as.vix.com> References: <20030110174601.4A501379FBB@as.vix.com> X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal Cc: , , X-Mailer: SquirrelMail (version 1.2.5) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=1.5 required=5.0 tests=IN_REP_TO,MISSING_MIMEOLE,MISSING_OUTLOOK_NAME, NO_REAL_NAME,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_01_02,SUBJECT_IS_LIST,TO_BE_REMOVED_REPLY version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Interesting since others in this thread also seem to sensor or refuse valid requests made to them... its amazing we all can't just get along and "do the right thing (tm)" which is to help build a robust global system.. much sadness because of these childish activities and lack of acceptance of human traits..... Q The gadget geek > thomas, et al, > > i have a bone to pick. while dr. bernstein would most likely say that > i am no friend to him nor to his chosen issues, the fact is that his > complaint has some validity if you look at it edge-on rather than > face-on. > >> Namedroppers is a posters-only mailing list that is run in conformance >> with the policies outlined in >> http://www.ietf.cnri.reston.va.us/IESG/STATEMENTS/mail-submit-policy.txt. >> >> Specifically, all mail sent to namedroppers is: >> >> 1) first run through spamassassin. Mail that is rejected here is not >> archived, as the number of such messages is large. All mail sent to >> mailing lists on the server hosting namedroppers is run though >> spamassassin, so this is not a namedroppers-specific procedure. > > this is just wrong. spamassassin operates at the MUA level, and as > such, the originating MTA receives a "final OK" and drops the > connection before spamassassin begins its job. the MUA's only choices > when dropping mail due to spamassassin's filtering are: issue a new > message back to the sender to inform them of the bounce, or silently > drop. because most of the mail spamassassin will drop has an invalid > sender address, choice #2 is common. > > for an IETF list, if submitted mail is being dropped, there must be > notice back to the sender. because the sender address will generally > not be usable, the only possible choice is to issue the rejection at > the MTA level. this will require tighter integration of spamassassin > into the MTA level than is currently done on randy's system, or indeed, > currently done anywhere at all. > > silent drops are fatal to the IETF's policy of open discourse, and dr. > bernstein is right to complain about that aspect of the namedroppers > problems he is experiencing. every time one of dr. bernstein's > messages is dropped, dr. bernstein's originating MTA should experience > an SMTP delivery error and therefore have the option of informing dr. > bernstein that such rejection has occurred. > > one other very minor point: > >> > I've noticed that Randy Bush discarded Len Budney's note on this >> > topic: >> > http://groups.google.com/groups?selm=asnul4%24640g%241%40isrv4.isc.org >> >> Not so. Len's note was posted to usenet, not to the namedroppers >> mailing list. Mail from usenet cannot be assumed to get gatewayed back >> to the mailing list. > > as the usenet moderator of comp.protocols.dns.std, i set up a > bidirectional gateway which isc operates. this gateway is far from > perfect, and many posts have been dropped (silently, of course) over > the years, and anyone who wants to really ensure that their words > appear on namedroppers should avoid the use of the usenet->namedroppers > gateway, and mail their words directly to the namedroppers list. > > paul > > -- > 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 Jan 10 19:46:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21218 for ; Fri, 10 Jan 2003 19:46:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18X9d4-000DXx-00 for namedroppers-data@psg.com; Fri, 10 Jan 2003 16:36:02 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #2) id 18X9d1-000DXc-00 for namedroppers@ops.ietf.org; Fri, 10 Jan 2003 16:35:59 -0800 Received: from localhost ([127.0.0.1] helo=rip.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 18X9d1-0007SG-00 for namedroppers@ops.ietf.org; Fri, 10 Jan 2003 16:35:59 -0800 Message-ID: <3E1F59DA.8040201@cisco.com> MIME-Version: 1.0 References: <20030110174601.4A501379FBB@as.vix.com> In-Reply-To: <20030110174601.4A501379FBB@as.vix.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 10 Jan 2003 15:40:10 -0800 From: Eliot Lear To: Paul Vixie CC: Thomas Narten , ietf@ietf.org, iesg@ietf.org, namedroppers Subject: Re: Dan Bernstein's issues about namedroppers list operation X-Spam-Status: No, hits=-1.4 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,RESENT_TO, SPAM_PHRASE_03_05,SUBJECT_IS_LIST version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] Paul, I would settle for the message being logged as dropped on some web site. Or, if disk space is really an issue, I would also find it acceptable to have a global IETF whitelist and bounce mail from people who are not on it. That having been said, I have no problem with the message returning as a bounce above the MTA level, so long a sa bounce is returned. That means that you have to have a valid return address. I don't believe the process has to be so open such that we should respond to invalid return addresses. Eliot Paul Vixie wrote: > thomas, et al, > > i have a bone to pick. while dr. bernstein would most likely say that > i am no friend to him nor to his chosen issues, the fact is that his > complaint has some validity if you look at it edge-on rather than face-on. > > >>Namedroppers is a posters-only mailing list that is run in conformance >>with the policies outlined in >>http://www.ietf.cnri.reston.va.us/IESG/STATEMENTS/mail-submit-policy.txt. >> >>Specifically, all mail sent to namedroppers is: >> >>1) first run through spamassassin. Mail that is rejected here is not >> archived, as the number of such messages is large. All mail sent to >> mailing lists on the server hosting namedroppers is run though >> spamassassin, so this is not a namedroppers-specific procedure. > > > this is just wrong. spamassassin operates at the MUA level, and as such, > the originating MTA receives a "final OK" and drops the connection before > spamassassin begins its job. the MUA's only choices when dropping mail > due to spamassassin's filtering are: issue a new message back to the sender > to inform them of the bounce, or silently drop. because most of the mail > spamassassin will drop has an invalid sender address, choice #2 is common. > > for an IETF list, if submitted mail is being dropped, there must be notice > back to the sender. because the sender address will generally not be usable, > the only possible choice is to issue the rejection at the MTA level. this > will require tighter integration of spamassassin into the MTA level than is > currently done on randy's system, or indeed, currently done anywhere at all. > > silent drops are fatal to the IETF's policy of open discourse, and dr. > bernstein is right to complain about that aspect of the namedroppers problems > he is experiencing. every time one of dr. bernstein's messages is dropped, > dr. bernstein's originating MTA should experience an SMTP delivery error and > therefore have the option of informing dr. bernstein that such rejection has > occurred. > > one other very minor point: > > >>>I've noticed that Randy Bush discarded Len Budney's note on this topic: >>>http://groups.google.com/groups?selm=asnul4%24640g%241%40isrv4.isc.org >> >>Not so. Len's note was posted to usenet, not to the namedroppers >>mailing list. Mail from usenet cannot be assumed to get gatewayed back >>to the mailing list. > > > as the usenet moderator of comp.protocols.dns.std, i set up a bidirectional > gateway which isc operates. this gateway is far from perfect, and many posts > have been dropped (silently, of course) over the years, and anyone who wants > to really ensure that their words appear on namedroppers should avoid the use > of the usenet->namedroppers gateway, and mail their words directly to the > namedroppers list. > > paul > > > -- 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 Jan 10 20:07:45 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21619 for ; Fri, 10 Jan 2003 20:07:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18XA3E-000EJ9-00 for namedroppers-data@psg.com; Fri, 10 Jan 2003 17:03:04 -0800 Received: from swan.mail.pas.earthlink.net ([207.217.120.123]) by psg.com with esmtp (Exim 3.36 #2) id 18XA3B-000EIx-00 for namedroppers@ops.ietf.org; Fri, 10 Jan 2003 17:03:01 -0800 Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by swan.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18XA36-0006u5-00; Fri, 10 Jan 2003 17:02:56 -0800 Date: Fri, 10 Jan 2003 19:59:58 -0500 From: Keith Moore To: Thomas Narten Cc: moore@cs.utk.edu, djb@cr.yp.to, ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org Subject: Re: Dan Bernstein's issues about namedroppers list operation Message-Id: <20030110195958.3d84e0c4.moore@cs.utk.edu> In-Reply-To: <200301101624.h0AGOqL09468@rotala.raleigh.ibm.com> References: <200301101624.h0AGOqL09468@rotala.raleigh.ibm.com> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02, SUBJECT_IS_LIST version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Specifically, all mail sent to namedroppers is: > > 1) first run through spamassassin. Mail that is rejected here is not > archived, as the number of such messages is large. All mail sent to > mailing lists on the server hosting namedroppers is run though > spamassassin, so this is not a namedroppers-specific procedure. SpamAssissin needs to be shot. Most of its criteria are really poorly chosen. Even if its criteria are good at identifying spam on a large scale (with few false positives) that doesn't mean they will work well for a narrowly-focused discussion. In my experience SpamAssassin has too high a false positive rate to be trusted without human review as a backup. Keith p.s. regarding messages that did not make it to the namedroppers archive - are the IETF archives still using to/cc message headers to decide which archive a message should be stored in? if so, is it possible that a message which was sent to multiple lists might be archived in only one of those lists? -- 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 Jan 11 07:29:16 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10710 for ; Sat, 11 Jan 2003 07:29:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18XKYE-0009It-00 for namedroppers-data@psg.com; Sat, 11 Jan 2003 04:15:46 -0800 Received: from outpost.ds9a.nl ([213.244.168.210] ident=postfix) by psg.com with esmtp (Exim 3.36 #2) id 18XKYB-0009Ih-00 for namedroppers@ops.ietf.org; Sat, 11 Jan 2003 04:15:43 -0800 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 443F04510; Sat, 11 Jan 2003 13:15:40 +0100 (CET) Date: Sat, 11 Jan 2003 13:15:40 +0100 From: bert hubert To: namedroppers@ops.ietf.org Subject: does anybody use additional/authority records on RD/RA replies Message-ID: <20030111121540.GA22025@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-1.2 required=5.0 tests=SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MUTT version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk In a refreshing change, here is a question about DNS. I'm wondering if anybody knows of any client library actually using additional/authority records in answers to recursion desired/recursion available questions, with the exception of the SOA negative presence indication. Thanks. Regards, bert hubert -- http://www.PowerDNS.com Open source, database driven DNS Software http://lartc.org Linux Advanced Routing & Traffic Control HOWTO http://netherlabs.nl Consulting -- 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 Jan 11 11:51:49 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14337 for ; Sat, 11 Jan 2003 11:51:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18XOgO-000Hd6-00 for namedroppers-data@psg.com; Sat, 11 Jan 2003 08:40:28 -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.36 #2) id 18XOgM-000Hcn-00 for namedroppers@ops.ietf.org; Sat, 11 Jan 2003 08:40:26 -0800 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id BFC7618E8 for ; Sat, 11 Jan 2003 11:40:19 -0500 (EST) Date: Sat, 11 Jan 2003 11:40:19 -0500 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: does anybody use additional/authority records on RD/RA replies In-Reply-To: <20030111121540.GA22025@outpost.ds9a.nl> References: <20030111121540.GA22025@outpost.ds9a.nl> User-Agent: Wanderlust/2.8.1 (Something) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20030111164019.BFC7618E8@thrintun.hactrn.net> X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Sat, 11 Jan 2003 13:15:40 +0100, bert hubert wrote: > > In a refreshing change, here is a question about DNS. Thank you! > I'm wondering if anybody knows of any client library actually using > additional/authority records in answers to recursion desired/recursion > available questions, with the exception of the SOA negative presence > indication. Additional for sure: think about QTYPE=MX. Dunno about authority: offhand I can't remember any use for it, but that doesn't prove that somebody else hasn't got one. --Rob -- 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 Jan 11 13:45:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15986 for ; Sat, 11 Jan 2003 13:45:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18XQSA-000KDU-00 for namedroppers-data@psg.com; Sat, 11 Jan 2003 10:33:54 -0800 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #2) id 18XQS6-000KDH-00 for namedroppers@ops.ietf.org; Sat, 11 Jan 2003 10:33:50 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 553C0379FBB for ; Sat, 11 Jan 2003 18:33:49 +0000 (GMT) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: does anybody use additional/authority records on RD/RA replies In-Reply-To: Message from bert hubert of "Sat, 11 Jan 2003 13:15:40 +0100." <20030111121540.GA22025@outpost.ds9a.nl> X-Mailer: MH-E 7.0; nmh 1.0.4; Emacs 21.2 Date: Sat, 11 Jan 2003 18:33:49 +0000 Message-Id: <20030111183349.553C0379FBB@as.vix.com> X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > In a refreshing change, here is a question about DNS. > > I'm wondering if anybody knows of any client library actually using > additional/authority records in answers to recursion desired/recursion > available questions, with the exception of the SOA negative presence > indication. sure. sendmail's internal getmxrr does this, to try to get the MX and A from a single dns transaction. as far as i know, so does kerberos's internal getsrvbyname. -- 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 Jan 11 14:15:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16403 for ; Sat, 11 Jan 2003 14:15:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18XR3V-000L3W-00 for namedroppers-data@psg.com; Sat, 11 Jan 2003 11:12:29 -0800 Received: from outpost.ds9a.nl ([213.244.168.210] ident=postfix) by psg.com with esmtp (Exim 3.36 #2) id 18XR3T-000L3J-00 for namedroppers@ops.ietf.org; Sat, 11 Jan 2003 11:12:27 -0800 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 21C6940F5; Sat, 11 Jan 2003 20:12:25 +0100 (CET) Date: Sat, 11 Jan 2003 20:12:24 +0100 From: bert hubert To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: does anybody use additional/authority records on RD/RA replies Message-ID: <20030111191224.GA30869@outpost.ds9a.nl> References: <20030111121540.GA22025@outpost.ds9a.nl> <20030111183349.553C0379FBB@as.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030111183349.553C0379FBB@as.vix.com> User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-4.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MUTT version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Sat, Jan 11, 2003 at 06:33:49PM +0000, Paul Vixie wrote: > sure. sendmail's internal getmxrr does this, to try to get the MX and A > from a single dns transaction. as far as i know, so does kerberos's > internal getsrvbyname. Thanks, also to Rob. Indeed, I only forgot about that one because my own boneheaded mailer did not take advantage from that at one point. But I wonder about the utility of authority in this case - I've already seen the powerdns recursor, a work in progress, spit out the weirdest things. An example is www.bibleinfo.org which defines its own NS records with a 10 second TTL. After those are passed, the 'best' NS records are the ORG ones, which are then attached to the answer, leading to an overly large packet. [btw, I wonder why the ORG NS records are in COM? Seems silly] A simple solution to that is not allowing a child to lower the TTL of existing records, but that does not solve the root issue of the silliness of adding the 'best' NS records known. Was there a non-human rationale to adding those? Regards, bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://lartc.org Linux Advanced Routing & Traffic Control HOWTO http://netherlabs.nl Consulting -- 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 Jan 11 14:49:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17036 for ; Sat, 11 Jan 2003 14:49:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18XRZv-000LvM-00 for namedroppers-data@psg.com; Sat, 11 Jan 2003 11:45:59 -0800 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #2) id 18XRZt-000Lv9-00 for namedroppers@ops.ietf.org; Sat, 11 Jan 2003 11:45:57 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id E94D4379FC7 for ; Sat, 11 Jan 2003 19:45:56 +0000 (GMT) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: does anybody use additional/authority records on RD/RA replies In-Reply-To: Message from bert hubert of "Sat, 11 Jan 2003 20:12:24 +0100." <20030111191224.GA30869@outpost.ds9a.nl> X-Mailer: MH-E 7.0; nmh 1.0.4; Emacs 21.2 Date: Sat, 11 Jan 2003 19:45:56 +0000 Message-Id: <20030111194556.E94D4379FC7@as.vix.com> X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > An example is www.bibleinfo.org which defines its own NS records with a 10 > second TTL. After those are passed, the 'best' NS records are the ORG ones, > which are then attached to the answer, leading to an overly large packet. > > A simple solution to that is not allowing a child to lower the TTL of > existing records, but that does not solve the root issue of the silliness of > adding the 'best' NS records known. Was there a non-human rationale to > adding those? the child zone owns the delegation point. the parent's zone-bottom NS RR's are not authoritative in the parent, they are just hints/glue. the child's data, no matter how icky the TTL's are, is what you have to keep, TTL and all. you could keep an opaqued copy of the parent's hints/glue around, so that when the child's NS RRset expires, you can go back to the glue that got you to the child in the first place. but you have to keep going back to the child. -- 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 Jan 11 15:06:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17367 for ; Sat, 11 Jan 2003 15:06:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18XRrk-000MNE-00 for namedroppers-data@psg.com; Sat, 11 Jan 2003 12:04:24 -0800 Received: from stoneport.math.uic.edu ([131.193.178.160]) by psg.com with smtp (Exim 3.36 #2) id 18XRri-000MN2-00 for namedroppers@ops.ietf.org; Sat, 11 Jan 2003 12:04:22 -0800 Received: (qmail 19177 invoked by uid 1016); 11 Jan 2003 20:04:42 -0000 Date: 11 Jan 2003 20:04:42 -0000 Message-ID: <20030111200442.19176.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: does anybody use additional/authority records on RD/RA replies References: <20030111121540.GA22025@outpost.ds9a.nl> <20030111164019.BFC7618E8@thrintun.hactrn.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=0.3 required=5.0 tests=REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Rob Austein writes: > Additional for sure: think about QTYPE=MX. Clients have to be prepared to ask for A records in a new DNS query. The MX response often doesn't have any additional data. It is, of course, safe for a cache to leave out authority and additional records. dnscache has always done this; BIND 9 can now do it, except for SOA records, with the ``minimal-responses'' option. One client---sendmail---tries to skip the A query by caching A records from the MX response. I'm amused by the ``save network traffic'' excuse for this complication. If you really care about DNS traffic, why aren't you running a real DNS cache on the same machine? ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- 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 Jan 11 16:39:16 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18984 for ; Sat, 11 Jan 2003 16:39:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18XTGZ-000Ov3-00 for namedroppers-data@psg.com; Sat, 11 Jan 2003 13:34:07 -0800 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.36 #2) id 18XTGX-000Oum-00 for namedroppers@ops.ietf.org; Sat, 11 Jan 2003 13:34:05 -0800 Received: from x22.ripe.net (x22.ripe.net [193.0.1.22]) by birch.ripe.net (8.12.5/8.11.6) with ESMTP id h0BLXmvQ002796 for ; Sat, 11 Jan 2003 22:33:48 +0100 Date: Sat, 11 Jan 2003 22:33:48 +0100 (CET) From: Bruce Campbell X-X-Sender: bc@x22.ripe.net To: namedroppers@ops.ietf.org Subject: Re: does anybody use additional/authority records on RD/RA replies In-Reply-To: <20030111200442.19176.qmail@cr.yp.to> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.0 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_02_03,USER_AGENT_PINE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On 11 Jan 2003, D. J. Bernstein wrote: > Rob Austein writes: > > Additional for sure: think about QTYPE=MX. > > One client---sendmail---tries to skip the A query by caching A records > from the MX response. I'm amused by the ``save network traffic'' excuse > for this complication. If you really care about DNS traffic, why aren't > you running a real DNS cache on the same machine? It is possible, especially with the example that you've posted, that the design decision that lead to trying to obtain an 'A' from the additional section of a 'MX' answer was made at a time when Internet links were relatively expensive, and/or at a time when the memory footprint of a DNS cache was not available on every machine. Of course nowadays, the design of a new piece of software doesn't have to take into account costs incurred by the entity running their software as bandwidth/memory/cpu is so cheap, mores the pity. --==-- Bruce. -- 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 Jan 11 18:40:49 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21002 for ; Sat, 11 Jan 2003 18:40:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18XV7X-000348-00 for namedroppers-data@psg.com; Sat, 11 Jan 2003 15:32:55 -0800 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.36 #2) id 18XV7T-00033v-00 for namedroppers@ops.ietf.org; Sat, 11 Jan 2003 15:32:52 -0800 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.6/8.12.6) with ESMTP id h0BNWWt3002085; Sun, 12 Jan 2003 10:32:36 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200301112332.h0BNWWt3002085@drugs.dv.isc.org> To: bert hubert Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: does anybody use additional/authority records on RD/RA replies In-reply-to: Your message of "Sat, 11 Jan 2003 13:15:40 BST." <20030111121540.GA22025@outpost.ds9a.nl> Date: Sun, 12 Jan 2003 10:32:32 +1100 X-Spam-Status: No, hits=0.9 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, TO_BE_REMOVED_REPLY version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > In a refreshing change, here is a question about DNS. > > I'm wondering if anybody knows of any client library actually using > additional/authority records in answers to recursion desired/recursion > available questions, with the exception of the SOA negative presence > indication. > > Thanks. > > Regards, > > bert hubert > > -- > http://www.PowerDNS.com Open source, database driven DNS Software > http://lartc.org Linux Advanced Routing & Traffic Control HOWTO > http://netherlabs.nl Consulting > > -- > 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: The update code in libresolv will take advantage of the NS RRset if it is there along with the address records in the additional section when determining the zone a particular domain name belongs to. Mark -- 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 Sat Jan 11 18:51:00 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21113 for ; Sat, 11 Jan 2003 18:50:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18XVHW-0003TI-00 for namedroppers-data@psg.com; Sat, 11 Jan 2003 15:43:14 -0800 Received: from milligan.cwx.net ([216.17.176.90] helo=mail.acmeps.com) by psg.com with esmtp (Exim 3.36 #2) id 18XVHU-0003T6-00 for namedroppers@ops.ietf.org; Sat, 11 Jan 2003 15:43:12 -0800 Received: by mail.acmeps.com (Postfix, from userid 99) id 43DCEA1468; Sat, 11 Jan 2003 16:43:11 -0700 (MST) Received: from acmeps.com (unknown [172.20.21.31]) by mail.acmeps.com (Postfix) with ESMTP id 0A605A0016; Sat, 11 Jan 2003 16:43:10 -0700 (MST) Message-ID: <3E20AC0E.7050208@acmeps.com> Date: Sat, 11 Jan 2003 16:43:10 -0700 From: Michael Milligan User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021226 Debian/1.2.1-9 MIME-Version: 1.0 To: bert hubert Cc: namedroppers@ops.ietf.org Subject: Re: does anybody use additional/authority records on RD/RA replies References: <20030111121540.GA22025@outpost.ds9a.nl> <20030111183349.553C0379FBB@as.vix.com> <20030111191224.GA30869@outpost.ds9a.nl> In-Reply-To: <20030111191224.GA30869@outpost.ds9a.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-3.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_01_02,USER_AGENT, USER_AGENT_MOZILLA_UA version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit bert hubert wrote: > > [btw, I wonder why the ORG NS records are in COM? Seems silly] They are not "in COM" of course... the gTLD servers, which are authoritative for com, are also still authoritative for org. I'm sure that's the case only for the transition of org to Afilias, but you never know how long QA can take when it comes to the gTLD servers... ;-) Side note: I do find it interesting that a.gtld-servers.net and g.gtld-servers.net have TTLs of 172800 (2 days) for the org NS record set and the rest of the gTLD servers have 518400 (6 days). Regards, Mike -- Michael Milligan -- Free Agent -- milli@acmeps.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 Sun Jan 12 20:21:16 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17552 for ; Sun, 12 Jan 2003 20:21:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Xt6h-000OCX-00 for namedroppers-data@psg.com; Sun, 12 Jan 2003 17:09:39 -0800 Received: from cyphermail.sandelman.ottawa.on.ca ([192.139.46.78] helo=noxmail.sandelman.ottawa.on.ca) by psg.com with esmtp (Exim 3.36 #2) id 18Xt6L-000OC9-00 for namedroppers@ops.ietf.org; Sun, 12 Jan 2003 17:09:17 -0800 Received: from sandelman.ottawa.on.ca (229.toad.com [209.237.225.229]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h0D17dQ18040 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Sun, 12 Jan 2003 20:07:54 -0500 (EST) Received: from sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h0D17ULf002873 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Sun, 12 Jan 2003 17:07:32 -0800 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h0D17Gn4002868 for ; Sun, 12 Jan 2003 17:07:30 -0800 Message-Id: <200301130107.h0D17Gn4002868@sandelman.ottawa.on.ca> To: namedroppers Subject: the DS deployment problem Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Sun, 12 Jan 2003 17:07:16 -0800 From: Michael Richardson X-Spam-Status: No, hits=-0.6 required=5.0 tests=LINES_OF_YELLING,PGP_SIGNATURE,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,TO_LOCALPART_EQ_REAL version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- So, I didn't realize that there was already a document specifying some more details about how to handle DS for the ancestor problem. But that -12 of the DS draft now has: 313a315,333 > 2.2.1.2 Special processing when child and an ancestor share server > > When a child zone and a ancestor other than parent share an > authorative server, a DS aware server MUST answer with information > from child zone, as specified in section 2.2.1.1. This is to prevent > the server to be marked as lame for child. > > This answer can cause problem for a DS aware resolver that is > traversing this branch of the DNS tree for the first time. The > resolver is expecting to get back either DS record or a delegation > information. The SOA with same name as QNAME informs the resolver > that the answer orignated from the zone below the one where the DS > resides. At this point the resolver has no information on how to get > from the ancestor to the parent. In this case the resolver SHOULD > attempt to fetch the delegation information by issuing a query with a > QNAME one label shorter and type NS. This will yield the NS set for > the parent, allowing the resolver to query for the DS record. > I want to make sure that I understand this. It seemed too simple to me! Given two name servers: NS-A NS-B +------------+ +--------------+ | example.| | b.example. | |a.b.example.| | | +------------+ +--------------+ with records: example. NS NS-A b.example. NS NS-B SOA foo SOA bar KEY xxxxx KEY yyyyy b.example. NS NS-B a.b.example. DS hash(zzzzz) DS hash(yyyyy) NS NS-A a.b.example. NS NS-A SOA baz KEY zzzzz So, if I ask NS-A, for a.b.example DS, then I get "a.b.example. SOA baz", and I get no other information, because the DS doesn't reside there. I do not get "b.example. NS NS-B", because I didn't ask for that. So, the instructions say, as for "b.example. NS", and we can make progress. Now, part of the problem was, what if there was a recursive resolving DNS server in front of the querier, that didn't know about DS. And one was forced to use this. (A proxy DNS server in a firewall for instance) So, I think that this doesn't screw anything up as well. I think, that one has to do queries with one shorter label recursively in the situation where maybe a server is authoritative for example. and a.b.c.example. I may be wrong here - I have to think about it some more. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPiIRQIqHRg3pndX9AQHFsgQAqmU8xrXkjxyoWzgNNvtZm49LesalGIVi ydOHG1KmjKYfTAlWea7Ux/Iq3zcpq/XPoVv1WbpTf/Jyw1wZWbeYmNmZaYfojt2P XSO4++CbdY7+iVdp2sUv0zYwp7ZiMBtItpNHuMJD30gxuSHfKAZtHVODDGZujElq 51L/Z0h4rI8= =QFri -----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 Jan 12 21:03:31 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18367 for ; Sun, 12 Jan 2003 21:03:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Xtue-0000OP-00 for namedroppers-data@psg.com; Sun, 12 Jan 2003 18:01:16 -0800 Received: from pcp816081pcs.nrockv01.md.comcast.net ([68.49.60.118] helo=ogud.com) by psg.com with esmtp (Exim 3.36 #2) id 18Xtub-0000OB-00 for namedroppers@ops.ietf.org; Sun, 12 Jan 2003 18:01:13 -0800 Received: from ENGILL.ogud.com (mail.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.3/8.12.3) with ESMTP id h0D1wOW8094351; Sun, 12 Jan 2003 20:58:26 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <5.1.1.6.2.20030112205149.01579c68@localhost> X-Sender: post@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Sun, 12 Jan 2003 21:01:02 -0500 To: Michael Richardson , namedroppers From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: the DS deployment problem In-Reply-To: <200301130107.h0D17Gn4002868@sandelman.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=1.5 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 20:07 2003-01-12, Michael Richardson wrote: >-----BEGIN PGP SIGNED MESSAGE----- > > >So, I didn't realize that there was already a document specifying some more >details about how to handle DS for the ancestor problem. But that -12 of the >DS draft now has: > >313a315,333 > > 2.2.1.2 Special processing when child and an ancestor share server > > > > When a child zone and a ancestor other than parent share an > > authorative server, a DS aware server MUST answer with information > > from child zone, as specified in section 2.2.1.1. This is to prevent > > the server to be marked as lame for child. > > > > This answer can cause problem for a DS aware resolver that is > > traversing this branch of the DNS tree for the first time. The > > resolver is expecting to get back either DS record or a delegation > > information. The SOA with same name as QNAME informs the resolver > > that the answer orignated from the zone below the one where the DS > > resides. At this point the resolver has no information on how to get > > from the ancestor to the parent. In this case the resolver SHOULD > > attempt to fetch the delegation information by issuing a query with a > > QNAME one label shorter and type NS. This will yield the NS set for > > the parent, allowing the resolver to query for the DS record. > > > >I want to make sure that I understand this. It seemed too simple to me! Thank you simple is good. >Given two name servers: > > NS-A NS-B > +------------+ +--------------+ > | example.| | b.example. | > |a.b.example.| | | > +------------+ +--------------+ > >with records: > > example. NS NS-A b.example. NS NS-B > SOA foo SOA bar > KEY xxxxx KEY yyyyy > b.example. NS NS-B a.b.example. DS hash(zzzzz) > DS hash(yyyyy) NS NS-A > a.b.example. NS NS-A > SOA baz > KEY zzzzz > >So, if I ask NS-A, for a.b.example DS, then I get "a.b.example. SOA baz", and >I get no other information, because the DS doesn't reside there. >I do not get "b.example. NS NS-B", because I didn't ask for that. So, the >instructions say, as for "b.example. NS", and we can make progress. > >Now, part of the problem was, what if there was a recursive resolving DNS >server in front of the querier, that didn't know about DS. And one was forced >to use this. (A proxy DNS server in a firewall for instance) > >So, I think that this doesn't screw anything up as well. > >I think, that one has to do queries with one shorter label recursively in the >situation where maybe a server is authoritative for example. and >a.b.c.example. I may be wrong here - I have to think about it some more. This problem has been flagged as a DS problem but it is not, it is a general DNSSEC problem. In your example if you had asked for "a.b.example. KEY" you got back signed answer, but the resolver has to go back and construct the key chain from . to a.b.example. in order to verify the result. If there had not been a ancestor in the path, the key chain is constructed while traversing down the referral chain. 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 Jan 13 14:07:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20181 for ; Mon, 13 Jan 2003 14:07:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Y9eV-0009ml-00 for namedroppers-data@psg.com; Mon, 13 Jan 2003 10:49:39 -0800 Received: from boreas.isi.edu ([128.9.160.161]) by psg.com with esmtp (Exim 3.36 #2) id 18Y9eT-0009mW-00 for namedroppers@ops.ietf.org; Mon, 13 Jan 2003 10:49:37 -0800 Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6/8.11.2) id h0DInZI29936; Mon, 13 Jan 2003 10:49:35 -0800 (PST) From: Bill Manning Message-Id: <200301131849.h0DInZI29936@boreas.isi.edu> Subject: Re: commens on draft-dnsext-opcode-discover-01.txt In-Reply-To: <20030107093105.12ade898.moore@cs.utk.edu> from Keith Moore at "Jan 7, 3 09:31:05 am" To: moore@cs.utk.edu (Keith Moore) Date: Mon, 13 Jan 2003 10:49:35 -0800 (PST) Cc: namedroppers@ops.ietf.org, moore@cs.utk.edu X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-2.0 required=5.0 tests=IN_REP_TO,SIGNATURE_SHORT_SPARSE,SPAM_PHRASE_01_02, TO_BE_REMOVED_REPLY version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit % Note: I'm reading this as if it's a draft protocol specification % rather than as if it's intended as an informational or experimental % document. Even if the latter is intended, some amount of clarification % seems in order. Thanks for your comments. Note that it is clearly -NOT- expected to be a draft protocol specification. This is the documentation of a set of experiments that were run in 1998/1999 and some of the lessons learned. % 1. use of SRV to implement getservbyname % % It is not appropriate to use SRV lookups to implement getservbyname(). Why? Its not forbidden and it can be made to work. % This would change the behavior of nearly every protocol on the Internet % without considering the impact on the protocol or applications that use % it. Use of SRV MUST be determined on a per-protocol or per-application % basis. Where your references to "it" is the call getservbyname() correct? % Furthermore SRV was intended to delegate services for specific DNS domains, % and getservbyname() doesn't provide a way to input the domain for which % the SRV query is being made. Trying to use SRV as a generic way to look % up "well known ports" independent of domain is overloading the SRV RR type. Not really. % That,and trying to use the network to look up constants never was a good % idea, not in the context of YP/NIS or anything else. I've seen too many % programs fail because getservbyname() was implemented using NIS, and the % NIS server was down. It's not as if protocol implementors don't know what % port numbers to use anyway. If it's reasonable for a protocol implementation % to include string constants like "MAIL FROM" or "POST", then it's reasonable % for that protocol implementation to include integer constants like htons(25) % or htons(80). The experiment made the presumption that the constants being lookedup were available from the system being queried. Extrapolation to over network lookups was done as proof of concept and to explore the ramifications thereof. % 2. under section 2, "method", "Example usage for gethostby{name,addr}-style % requestors:" % % it's not at all clear why "the zone name of the enclosing in-addr.arpa, % ip6.int, or ip6.arpa domain" is relevant to an A or AAAA query (as in % gethostbyname ) or why queries for a particular NAME should only be sent % to servers that are authoritative for the enclosing ADDRESS domain. % % Is this really what is intended or is it just poor wording? It reads % as if you're trying to make the results of DNS lookups vary according % to location. Correct. the results were to vary based on location/topology. % 3. same section % % "Once one learns a host's FQDN by the above means, repeat the process % for discovering the closest enclosing authoritative server of such % local name." % % the idea that a host has "a" FQDN seems anachronistic at best. hosts have % zero or more addresses assigned to them at any particular time; each % address may be associated with zero or more FQDNs. the address-to-host % bindings may be short- or long-lived. in general there is no way that the % network can be expected to know whether a particular FQDN is any kind of % "distinguished name" for a host. the host has to be configured to know % this on its own. the host (knowing its FQDN) responds to requests by sending its FQDN. One of the preconditions of the experiment is that each participating node is "imprinted" with an FQDN and some key material that is tied to that FQDN. % 4. regarding disconnected networks % % NO server -- whether multicast or not, whether using DISCOVER or not, % whether using the DNS port or not, whether using the DNS protocl or not -- % should be answering queries as if it were authoritative for any DNS zone % for which that server is not authoritative. The result will inevitiably % be that such results are leaked into, and mixed with, results from % legitimate DNS servers. a network which appears isolated to one host % in a network may not be isolated to another host in the same network. Perhaps we should include the TBDS final report in the references. The experiment presumes that each node is authoritative for its point in the DNS heirarchy. This draft does not presume to answer authoritativly for any part of the DNS. It presumes that the caching servers will cache information they receive, just as happens now. % if you want "disconnected" servers to respond to queries for FQDNs then % those servers need to be authoritative for those FQDNs, and they need % to produce results which are consistent with the other servers for those % FQDNs. if some of those servers are on isolated networks and others are % on the global internet, this is not a problem as long as the rules for % serial numbers are followed. DNS can cope with different servers % returning different results as long as those servers have different % serial numbers and single-copy serializability is maintained. Yes. % If a host which is authoritative for one or more FQDNs that are assigned % to a host migrates from one network to another, or for whatever reason % acquires a new address and/or needs to change its RRs, that host can update % its RRs on its stub server and increment the serial # for that zone. If % and when the host has connectivity to the (other) advertised servers for % that zone, it should update those servers. But even if the host finds itself % on an isolated network there is no problem with its updating its own zone % and incrementing the serial number, perhaps multiple times, as long as it % updates the slave servers whenever it is possible to do so. Of course there % are operational concerns associated with advertising RRs that point to % addresses that are not reachable, but we generally expect protocols to be % robust when hosts are not reachable anyway. Appropriate assignment of TTLs % is the best solution here, and the host is in the best position to know % whether its RRs should have long or short TTLs (e.g. whether it is stable % or nomadic). The model here is that the FQDN does not change based on location in the topology. The dynamic update features existant in todays protocols are largely intact from the old work. It is true that dynamic dns work has evolved since this experiment was run. % -- % 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: % -- --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). -- 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 Jan 13 14:15:37 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20515 for ; Mon, 13 Jan 2003 14:15:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Y9r2-000A7c-00 for namedroppers-data@psg.com; Mon, 13 Jan 2003 11:02:36 -0800 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #2) id 18Y9qy-000A7H-00 for namedroppers@ops.ietf.org; Mon, 13 Jan 2003 11:02:33 -0800 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id h0DJ2VYm098317; Mon, 13 Jan 2003 14:02:31 -0500 (EST) Received: from [204.152.187.219] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id OAA12577; Mon, 13 Jan 2003 14:02:29 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <200301130107.h0D17Gn4002868@sandelman.ottawa.on.ca> References: <200301130107.h0D17Gn4002868@sandelman.ottawa.on.ca> Date: Mon, 13 Jan 2003 11:02:28 -0800 To: Michael Richardson From: Edward Lewis Subject: Re: the DS deployment problem Cc: namedroppers Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,REFERENCES,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 17:07 -0800 1/12/03, Michael Richardson wrote: >So, I didn't realize that there was already a document specifying some more >details about how to handle DS for the ancestor problem. But that -12 of the >DS draft now has: I sent some suggested text for the section in a message: http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg02256.html But there's been no discussion of it. (The text was prompted by some confusion a few of us had regarding great-great-*-great-grandparents and the 'strip a label' instruction.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- 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 Jan 13 14:27:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20936 for ; Mon, 13 Jan 2003 14:27:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Y9z6-000ANC-00 for namedroppers-data@psg.com; Mon, 13 Jan 2003 11:10:56 -0800 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.36 #2) id 18Y9z3-000AMp-00 for namedroppers@ops.ietf.org; Mon, 13 Jan 2003 11:10:53 -0800 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id h0DJ9YA09218; Mon, 13 Jan 2003 14:09:35 -0500 (EST) Message-Id: <200301131909.h0DJ9YA09218@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ X-PGP-Key: 2F07A741 ; 78 15 8E 8B C0 06 5D D1 BC 08 05 7F 42 81 7E 90 To: Bill Manning Subject: Re: commens on draft-dnsext-opcode-discover-01.txt cc: moore@cs.utk.edu, namedroppers@ops.ietf.org From: Keith Moore Date: Mon, 13 Jan 2003 14:09:34 -0500 X-Spam-Status: No, hits=-1.9 required=5.0 tests=EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, 13 Jan 2003 10:49:35 -0800 (PST) Bill Manning wrote: > % Note: I'm reading this as if it's a draft protocol specification > % rather than as if it's intended as an informational or experimental > % document. Even if the latter is intended, some amount of clarification > % seems in order. > > > Thanks for your comments. Note that it is clearly -NOT- > expected to be a draft protocol specification. This is > the documentation of a set of experiments that were run in > 1998/1999 and some of the lessons learned. > > % 1. use of SRV to implement getservbyname > % > % It is not appropriate to use SRV lookups to implement getservbyname(). > > Why? Its not forbidden and it can be made to work. a) it's changing the behavior of existing applications that expect well-known port numbers. b) it's violating the SRV RFC, which states that each application needs to define how SRV is used. > % This would change the behavior of nearly every protocol on the Internet > % without considering the impact on the protocol or applications that use > % it. Use of SRV MUST be determined on a per-protocol or per-application > % basis. > > Where your references to "it" is the call getservbyname() correct yes, but it's also true for SRV in general. > % Furthermore SRV was intended to delegate services for specific DNS domains, > % and getservbyname() doesn't provide a way to input the domain for which > % the SRV query is being made. Trying to use SRV as a generic way to look > % up "well known ports" independent of domain is overloading the SRV RR type. > > Not really. I strongly and emphatically disagree. > % That,and trying to use the network to look up constants never was a good > % idea, not in the context of YP/NIS or anything else. I've seen too many > % programs fail because getservbyname() was implemented using NIS, and the > % NIS server was down. It's not as if protocol implementors don't know what > % port numbers to use anyway. If it's reasonable for a protocol implementation > % to include string constants like "MAIL FROM" or "POST", then it's reasonable > % for that protocol implementation to include integer constants like htons(25) > % or htons(80). > > The experiment made the presumption that the constants being lookedup > were available from the system being queried. Extrapolation to over > network lookups was done as proof of concept and to explore the > ramifications thereof. I doubt your experiments were of sufficient scale to show the problems. > > % 2. under section 2, "method", "Example usage for gethostby{name,addr}-style > % requestors:" > % > % it's not at all clear why "the zone name of the enclosing in-addr.arpa, > % ip6.int, or ip6.arpa domain" is relevant to an A or AAAA query (as in > % gethostbyname ) or why queries for a particular NAME should only be sent > % to servers that are authoritative for the enclosing ADDRESS domain. > % > % Is this really what is intended or is it just poor wording? It reads > % as if you're trying to make the results of DNS lookups vary according > % to location. > > Correct. the results were to vary based on location/topology. well, that's another lousy idea. many applications depend on DNS names producing consistent results from multiple locations in the Internet. > % 3. same section > % > % "Once one learns a host's FQDN by the above means, repeat the process > % for discovering the closest enclosing authoritative server of such > % local name." > % > % the idea that a host has "a" FQDN seems anachronistic at best. hosts have > % zero or more addresses assigned to them at any particular time; each > % address may be associated with zero or more FQDNs. the address-to-host > % bindings may be short- or long-lived. in general there is no way that the > % network can be expected to know whether a particular FQDN is any kind of > % "distinguished name" for a host. the host has to be configured to know > % this on its own. > > > the host (knowing its FQDN) responds to requests by sending > its FQDN. One of the preconditions of the experiment is that > each participating node is "imprinted" with an FQDN and some > key material that is tied to that FQDN. again the idea that a host has "a" FQDN seems anachronistic. if you can generalize this to something like "a server on a host may be made authoritative for zero or more FQDNs" then it might be more useful. > > % 4. regarding disconnected networks > % > % NO server -- whether multicast or not, whether using DISCOVER or not, > % whether using the DNS port or not, whether using the DNS protocl or not -- > % should be answering queries as if it were authoritative for any DNS zone > % for which that server is not authoritative. The result will inevitiably > % be that such results are leaked into, and mixed with, results from > % legitimate DNS servers. a network which appears isolated to one host > % in a network may not be isolated to another host in the same network. > > > Perhaps we should include the TBDS final report in the references. > The experiment presumes that each node is authoritative for its > point in the DNS heirarchy. This draft does not presume to answer > authoritativly for any part of the DNS. It presumes that the caching > servers will cache information they receive, just as happens now. some of additional context would help the draft immensely. stating your goals, assumptions, the constraints you imposed, the limitations of your work, all seem appropriate for a description of an experiment. Keith -- 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 Jan 13 14:47:58 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21501 for ; Mon, 13 Jan 2003 14:47:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18YAP9-000BFW-00 for namedroppers-data@psg.com; Mon, 13 Jan 2003 11:37:51 -0800 Received: from boreas.isi.edu ([128.9.160.161]) by psg.com with esmtp (Exim 3.36 #2) id 18YAP7-000BFK-00 for namedroppers@ops.ietf.org; Mon, 13 Jan 2003 11:37:49 -0800 Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6/8.11.2) id h0DJbhE13612; Mon, 13 Jan 2003 11:37:43 -0800 (PST) From: Bill Manning Message-Id: <200301131937.h0DJbhE13612@boreas.isi.edu> Subject: Re: commens on draft-dnsext-opcode-discover-01.txt In-Reply-To: <200301131909.h0DJ9YA09218@astro.cs.utk.edu> from Keith Moore at "Jan 13, 3 02:09:34 pm" To: moore@cs.utk.edu (Keith Moore) Date: Mon, 13 Jan 2003 11:37:43 -0800 (PST) Cc: bmanning@ISI.EDU, moore@cs.utk.edu, namedroppers@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-2.4 required=5.0 tests=IN_REP_TO,SIGNATURE_SHORT_SPARSE,SPAM_PHRASE_01_02 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit % > Thanks for your comments. Note that it is clearly -NOT- % > expected to be a draft protocol specification. This is % > the documentation of a set of experiments that were run in % > 1998/1999 and some of the lessons learned. % > % > % 1. use of SRV to implement getservbyname % > % % > % It is not appropriate to use SRV lookups to implement getservbyname(). % > % > Why? Its not forbidden and it can be made to work. % % a) it's changing the behavior of existing applications that expect % well-known port numbers. % % b) it's violating the SRV RFC, which states that each application needs % to define how SRV is used. it was an experiment. changing behaviour is one thing that experiments do. and wrt SRV, we defined how SRV is used for DNS. % > % the SRV query is being made. Trying to use SRV as a generic way to look % > % up "well known ports" independent of domain is overloading the SRV RR type. % > % > Not really. % % I strongly and emphatically disagree. thats allowed. % > The experiment made the presumption that the constants being lookedup % > were available from the system being queried. Extrapolation to over % > network lookups was done as proof of concept and to explore the % > ramifications thereof. % % I doubt your experiments were of sufficient scale to show the problems. that kind of presumes a single suite of problems to be shown. we found several and identified ways to overcome some of them. % > Correct. the results were to vary based on location/topology. % % well, that's another lousy idea. many applications depend on DNS names % producing consistent results from multiple locations in the Internet. your concept of "lousy" ideas may even be relevent. % > the host (knowing its FQDN) responds to requests by sending % > its FQDN. One of the preconditions of the experiment is that % > each participating node is "imprinted" with an FQDN and some % > key material that is tied to that FQDN. % % again the idea that a host has "a" FQDN seems anachronistic. % if you can generalize this to something like "a server on a host may be % made authoritative for zero or more FQDNs" % then it might be more useful. so set the wayback machine for 1998 and we'll be happy to redo the work. % > Perhaps we should include the TBDS final report in the references. % > The experiment presumes that each node is authoritative for its % > point in the DNS heirarchy. This draft does not presume to answer % > authoritativly for any part of the DNS. It presumes that the caching % > servers will cache information they receive, just as happens now. % % some of additional context would help the draft immensely. % stating your goals, assumptions, the constraints you imposed, the % limitations of your work, all seem appropriate for a description of an % experiment. -- --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). -- 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 Jan 13 14:55:28 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21675 for ; Mon, 13 Jan 2003 14:55:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18YAdF-000Bjl-00 for namedroppers-data@psg.com; Mon, 13 Jan 2003 11:52:25 -0800 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.36 #2) id 18YAdC-000BjY-00 for namedroppers@ops.ietf.org; Mon, 13 Jan 2003 11:52:22 -0800 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id h0DJp5A09369; Mon, 13 Jan 2003 14:51:05 -0500 (EST) Message-Id: <200301131951.h0DJp5A09369@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ X-PGP-Key: 2F07A741 ; 78 15 8E 8B C0 06 5D D1 BC 08 05 7F 42 81 7E 90 To: Bill Manning Subject: Re: commens on draft-dnsext-opcode-discover-01.txt cc: moore@cs.utk.edu, namedroppers@ops.ietf.org From: Keith Moore Date: Mon, 13 Jan 2003 14:51:05 -0500 X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > % > % It is not appropriate to use SRV lookups to implement getservbyname(). > % > > % > Why? Its not forbidden and it can be made to work. > % > % a) it's changing the behavior of existing applications that expect > % well-known port numbers. > % > % b) it's violating the SRV RFC, which states that each application needs > % to define how SRV is used. > > it was an experiment. changing behaviour is one thing that experiments > do. and wrt SRV, we defined how SRV is used for DNS. silly me. I thought RFC 2782 defined how SRV was used for DNS, and that the RFCs for applications defined which port numbers they use. From RFC 2782: Applicability Statement In general, it is expected that SRV records will be used by clients for applications where the relevant protocol specification indicates that clients should use the SRV record. Such specification MUST define the symbolic name to be used in the Service field of the SRV record as described below. It also MUST include security considerations. Service SRV records SHOULD NOT be used in the absence of such specification. -- Keith Moore http://www.cs.utk.edu/~moore/ 27 February 1933 11 September 2001 -- 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 Jan 13 15:41:16 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23449 for ; Mon, 13 Jan 2003 15:41:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18YBJK-000DQm-00 for namedroppers-data@psg.com; Mon, 13 Jan 2003 12:35:54 -0800 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #2) id 18YBJE-000DQ7-00 for namedroppers@ops.ietf.org; Mon, 13 Jan 2003 12:35:48 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id C539C37A194 for ; Mon, 13 Jan 2003 20:35:17 +0000 (GMT) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: commens on draft-dnsext-opcode-discover-01.txt In-Reply-To: Message from Keith Moore of "Mon, 13 Jan 2003 14:51:05 EST." <200301131951.h0DJp5A09369@astro.cs.utk.edu> X-Mailer: MH-E 7.0; nmh 1.0.4; Emacs 21.2 Date: Mon, 13 Jan 2003 20:35:17 +0000 Message-Id: <20030113203517.C539C37A194@as.vix.com> X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk i thought i'd let everybody know that after some deep talks with stuart cheshire over at apple, i am withdrawing my support and co-authorship of the DISCOVER draft. -- 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 Jan 13 17:37:46 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26660 for ; Mon, 13 Jan 2003 17:37:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18YD9Z-000Hdw-00 for namedroppers-data@psg.com; Mon, 13 Jan 2003 14:33:57 -0800 Received: from cyphermail.sandelman.ottawa.on.ca ([192.139.46.78] helo=noxmail.sandelman.ottawa.on.ca) by psg.com with esmtp (Exim 3.36 #2) id 18YD9W-000Hdi-00 for namedroppers@ops.ietf.org; Mon, 13 Jan 2003 14:33:54 -0800 Received: from sandelman.ottawa.on.ca (ip42-219.syzygy.com [216.240.42.219]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h0DMWSQ23029 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Mon, 13 Jan 2003 17:32:37 -0500 (EST) Received: from sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h0DMWKOt005362 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Mon, 13 Jan 2003 14:32:22 -0800 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h0DMWHqS005358 for ; Mon, 13 Jan 2003 14:32:20 -0800 Message-Id: <200301132232.h0DMWHqS005358@sandelman.ottawa.on.ca> To: namedroppers Subject: Re: the DS deployment problem In-reply-to: Your message of "Mon, 13 Jan 2003 11:02:28 PST." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Mon, 13 Jan 2003 14:32:17 -0800 From: Michael Richardson X-Spam-Status: No, hits=-0.9 required=5.0 tests=IN_REP_TO,LINES_OF_YELLING,PGP_SIGNATURE,SPAM_PHRASE_01_02, TO_LOCALPART_EQ_REAL version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Edward" == Edward Lewis writes: Edward> At 17:07 -0800 1/12/03, Michael Richardson wrote: >> So, I didn't realize that there was already a document specifying some more >> details about how to handle DS for the ancestor problem. But that -12 of the >> DS draft now has: Edward> I sent some suggested text for the section in a message: Edward> http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg02256.html Edward> But there's been no discussion of it. (The text was prompted by some Edward> confusion a few of us had regarding great-great-*-great-grandparents Edward> and the 'strip a label' instruction.) Here are your comments, again: Edward> 1) If the server is authoritative for the zone that holds the DS RR Edward> set (i.e., the zone that delegates away, aka the "parent" Edward> zone), the response contains the DS RR set as an authoritative answer. Edward> 2) If the server is offering recursive service, the server performs Edward> the query itself (according to the rules for resolvers described Edward> below) and returns it's findings. Edward> 3) If the server is authoritative for the zone that holds the Edward> 's SOA RR set, the response is an authoritative negative answer Edward> as described in 2.2.1.1. Edward> 4) If the server is authoritative for a zone above the QNAME, a Edward> referral to a more enclosing zone's servers is made. Edward> 5) If the server is not authoritative for any part of the QNAME, a Edward> response indicating a lame server for QNAME is given. I can not argue with any of these. Maybe I'm just too dead for too many late nights recently, to think these through. Can you tell me what problems each one of these points addresses? Olafur's rather simple suggestion, which I think was originally proposed for the DNSSEC work way back when (I spent yesterday in long meetings with John Gilmore, and we discussed this), gets rid of any issues with dealing with caches, since you do not depend upon them fetching the right stuff, you just keep asking on the way up the chain. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPiM+b4qHRg3pndX9AQGADgQA6pdtMXX4sh/qk5lFb9BT6S9/Eg3bczdr VOL+mrzZeUT8duzYq5E5pRU2Xth5wI3uI+8uznJhgNWXU68S08gP31l7mePYRJzk Lwlwzb4QWbGr0mvE/zD4pE77zLMTU1jgWMNmkYpzbHiENLXTx9Gd3XBAc/sT6U9v pyxRpu/8o5k= =3Pm+ -----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 Mon Jan 13 19:27:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29340 for ; Mon, 13 Jan 2003 19:27:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18YEli-000Lbv-00 for namedroppers-data@psg.com; Mon, 13 Jan 2003 16:17:26 -0800 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #2) id 18YEla-000LbZ-00 for namedroppers@ops.ietf.org; Mon, 13 Jan 2003 16:17:19 -0800 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id h0E0HFYm008305; Mon, 13 Jan 2003 19:17:15 -0500 (EST) Received: from [204.152.187.219] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id TAA11640; Mon, 13 Jan 2003 19:17:14 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <200301132232.h0DMWHqS005358@sandelman.ottawa.on.ca> References: <200301132232.h0DMWHqS005358@sandelman.ottawa.on.ca> Date: Mon, 13 Jan 2003 16:17:19 -0800 To: Michael Richardson From: Edward Lewis Subject: Re: the DS deployment problem Cc: namedroppers Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-1.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_02_03 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I jumbled your words to present a better response At 14:32 -0800 1/13/03, Michael Richardson wrote: >Olafur's rather simple suggestion, which I think was originally proposed for >the DNSSEC work way back when (I spent yesterday in long meetings with John >Gilmore, and we discussed this), gets rid of any issues with dealing with >caches, since you do not depend upon them fetching the right stuff, you just >keep asking on the way up the chain. What I suggested should be the same as Olafur's suggestion, just more tersely and concretely written. (The motivation of the suggestion was to clear up the text in -12, not conflict/change the strategy.) >I can not argue with any of these. Maybe I'm just too dead for too many late >nights recently, to think these through. Can you tell me what problems each >one of these points addresses? Sure, I'll hit them line by line. >Here are your comments, again: > > Ed> 1) If the server is authoritative for the zone that holds the DS RR > Ed> set (i.e., the zone that delegates away, aka the "parent" > Ed> zone), the response contains the DS RR set as an authoritative answer. The best of all possible situations is that the query has hit the (or a) "right" server. If a server holds the answer, there's no reason to withhold it. > Ed> 2) If the server is offering recursive service, the server performs > Ed> the query itself (according to the rules for resolvers described > Ed> below) and returns it's findings. I think this is the next step - regardless of any other configuration. (I can be argued over this.) I notice that I missed a doing a cache lookup, but that should probably be done here as well (cache then recurse) under the theory - if you have the answer, send it. > Ed> 3) If the server is authoritative for the zone that holds the > Ed> 's SOA RR set, the response is an authoritative negative answer > Ed> as described in 2.2.1.1. If the server serves the zone for which you want the DS, answer negatively. > Ed> 4) If the server is authoritative for a zone above the QNAME, a > Ed> referral to a more enclosing zone's servers is made. If the server is a grand*parent of the zone, refer down. > Ed> 5) If the server is not authoritative for any part of the QNAME, a > Ed> response indicating a lame server for QNAME is given. Otherwise, indicate lameness as traditional. The reason the above works is that there are instructions that the DS-seeker must follow. These include: If getting a negative answer for the DS, look at the SOA in the negative answer. This will give you the name of the zone where the query is returning from (the context of the answer). (This isn't a complete answer.) Strip one label, ask for the NS - ask there for DS. if there's no NS (and the answer has the next up SOA), ask for the the NS there etc. I'm losing focus in answering this...it's obvious. The "fear" is that zones may have multilabel deep delegations...that's where the confusion comes in. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- 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 Jan 13 21:00:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01480 for ; Mon, 13 Jan 2003 21:00:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18YGHH-000NZK-00 for namedroppers-data@psg.com; Mon, 13 Jan 2003 17:54:07 -0800 Received: from pcp816081pcs.nrockv01.md.comcast.net ([68.49.60.118] helo=ogud.com) by psg.com with esmtp (Exim 3.36 #2) id 18YGHE-000NZ6-00 for namedroppers@ops.ietf.org; Mon, 13 Jan 2003 17:54:04 -0800 Received: from ENGILL.ogud.com (mail.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.3/8.12.3) with ESMTP id h0E1p2W8097673; Mon, 13 Jan 2003 20:51:03 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <5.1.1.6.2.20030113204546.023c1100@localhost> X-Sender: post@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Mon, 13 Jan 2003 20:53:45 -0500 To: Edward Lewis , =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?__Gu=F0mundsson?= , namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: Delegation signer-12 Cc: Erik Nordmark In-Reply-To: References: <5.1.1.6.2.20021218133820.02a95870@localhost> <5.1.1.6.2.20021218133820.02a95870@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=1.8 required=5.0 tests=IN_REP_TO,RCVD_IN_RFCI,REFERENCES,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 21:07 2002-12-20, Edward Lewis wrote: >I was staring at the new words on the handling of the DS RR in section >2.2.1.2 when I noticed this problem with the text: > ># 2.2.2 Signer's Name (replaces RFC3008 section 2.7) ># ># The signer's name field of a SIG RR MUST contain the name of the zone ># to which the data and signature belong. The combination of signer's > >This is a very bad idea. > >The signer's name had better remain as it is defined. So much for my rule >of thumb reaction. Here are a laundry list of reasons why I have a >problem with this section and idea: > >1) The section has nothing to do with the DS RR definition. > >2) There is no rationale presented for changing the syntactic definition >of the SIG RR. > >3) Reading between the lines, the author of the document seems to be either: > >3a) trying to clean up something in 3008 The title of the section says it is updating 3008, I thought that updating 3008 to reflect the DS was needed. If 3008 is not updated then the DS must be signed by the child KEY. >or >3b) is trying to usurp the signer name to mean the authority name > >If it is 3a - this is the wrong document. >If it is 3b - why do folks try to usurp fields for new purposes >needlessly. It's easy enough to discover the authority via SOA records in >responses. Some document must do this clarification, if not DS a small update to 3008. The sections that I'm less sure about if they belong are the 2.2.3 subsections that update RFC3090 comments. 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 Jan 13 21:08:05 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01567 for ; Mon, 13 Jan 2003 21:08:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18YGPG-000Nmy-00 for namedroppers-data@psg.com; Mon, 13 Jan 2003 18:02:22 -0800 Received: from pcp816081pcs.nrockv01.md.comcast.net ([68.49.60.118] helo=ogud.com) by psg.com with esmtp (Exim 3.36 #2) id 18YGPD-000Nmh-00 for namedroppers@ops.ietf.org; Mon, 13 Jan 2003 18:02:19 -0800 Received: from ENGILL.ogud.com (mail.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.3/8.12.3) with ESMTP id h0E1xNW8097693; Mon, 13 Jan 2003 20:59:24 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <5.1.1.6.2.20030113193541.02102b40@localhost> X-Sender: post@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Mon, 13 Jan 2003 21:02:05 -0500 To: Edward Lewis , namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: comments on DS-12, section 2.2.1.2 Cc: edlewis@arin.net In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=2.0 required=5.0 tests=IN_REP_TO,RCVD_IN_RFCI,SPAM_PHRASE_01_02 version=2.43 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 11:52 2003-01-02, Edward Lewis wrote: >To the group - please scrutinize...In the spirit of "sending text": thank you, thank you >#2.2.1.2 Special processing when child and an ancestor share server ># ># When a child zone and a ancestor other than parent share an ># authorative server, a DS aware server MUST answer with information ># from child zone, as specified in section 2.2.1.1. This is to prevent ># the server to be marked as lame for child. > >Special rules are needed to permit DS RR aware servers to gracefully >interact with older caches which otherwise might falsely label a server as >lame because of the new placement of the DS RR set. > >Such a situation might arise when a server is authoritative for both a >zone and it's grandparent, but not the parent. This sounds like an >obscure example, but it is very real. The root zone is currently served >on 13 machines, and "root-servers.net." is served on 4 of the same 13, but >"net." is served elsewhere. Much better than my text, will include in the document. >When a server receives a query for (, DS, IN), the response MUST be >determined from reading these rules in order: > >1) If the server is authoritative for the zone that holds the DS RR set >(i.e., the zone that delegates away, aka the "parent" zone), the >response contains the DS RR set as an authoritative answer. > >2) If the server is offering recursive service, the server performs the >query itself (according to the rules for resolvers described below) and >returns it's findings. > >3) If the server is authoritative for the zone that holds the 's >SOA RR set, the response is an authoritative negative answer as described >in 2.2.1.1. I do not think this is correct philosophically: A server than performs authoritative service as well as recursive service, should not switch back and forth between the two on a single query. It should complete the rule set for authoritative service first and then switch to the recursive service. Thus I would move rule 2 out of this list, and the rule is missing the condition that the query MUST have the RD bit set. >4) If the server is authoritative for a zone above the QNAME, a referral >to a more enclosing zone's servers is made. > >5) If the server is not authoritative for any part of the QNAME, a >response indicating a lame server for QNAME is given. > >[Editorial comment: notice the lack of RFC 2119 terms below this line. I >am not sure what to require, most of what I have written might be >considered recommendations for finding the data.] Most of the rules above are in the MUST category. Rules 1 and 3 are needed in the DS document. Rules 4 and 5 are standard DNS authoritative server rules and IMHO there is no need to restate them. >Using these rules will require some special processing on the part of a DS >RR aware resolver. To illustrate this, an example is used. > >Assuming a server is authoritative for roots.example.net. and for the root >zone but not the intervening two zones (or the intervening two label deep >zone). Assume that QNAME=roots.example.net., QTYPE=DS, and QCLASS=IN. > >The resolver will issue this request (assuming no cached data) expecting a >referral to a net. server. Instead, rule number 3 above applies and a >negative answer is returned by the server. The reaction by the resolver >is not to accept this answer as final as it can determine from the SOA RR >in the negative answer the context within which the server has answered. > >A solution to this is to instruct the resolver to hunt for the >authoritative zone of the data in a brute force manner. > >This can be accomplished by taking the owner name of the returned SOA RR >and strip off enough left-hand labels until a successful NS response is >obtained. A successful response here means that the answer has NS records >in it. (Entertaining the possibility that a cut point may be two labels >down in a zone.) > >Returning to the example, the response will include a negative answer with >either the SOA RR for "roots.example.net." or "example.net." depending on >whether roots.example.net is a delegated domain. In either case, removing >the least significant label of the SOA owner name will lead to the >location of the desired data. One minor nit, the only reason SOA is needed in a negative answers along with NXT is not confuse old resolvers, RFC3225 (DO bit) should have eliminated the need to include the SOA. If only NXT is sent in the SOA section then the singer name on the NXT reflects the zone where the DS belongs in. I will include this text or suggested successor in version 13 that will be submitted late Thursday (unless there is still debate going on about the text). 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 Tue Jan 14 13:11:39 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05345 for ; Tue, 14 Jan 2003 13:11:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18YVIs-000Mx6-00 for namedroppers-data@psg.com; Tue, 14 Jan 2003 09:56:46 -0800 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #2) id 18YVIp-000Mwo-00 for namedroppers@ops.ietf.org; Tue, 14 Jan 2003 09:56:44 -0800 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id h0EHuYYm024666; Tue, 14 Jan 2003 12:56:34 -0500 (EST) Received: from [204.152.189.20] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id MAA06545; Tue, 14 Jan 2003 12:56:32 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <5.1.1.6.2.20030113204546.023c1100@localhost> References: <5.1.1.6.2.20021218133820.02a95870@localhost> <5.1.1.6.2.20021218133820.02a95870@localhost> <5.1.1.6.2.20030113204546.023c1100@localhost> Date: Tue, 14 Jan 2003 09:50:02 -0800 To: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_?= =?iso-8859-1?Q?Gu=F0mundsson?= From: Edward Lewis Subject: Re: Delegation signer-12 Cc: Edward Lewis , =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?___?= =?iso-8859-1?Q?Gu=F0mundsson?= , namedroppers@ops.ietf.org, Erik Nordmark Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,REFERENCES,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Well, you're right that 3008 does already redefine the SIG RR's signer name field and thus the change here is appropriate. Regardless, the change in section 2.7 of RFC 3008 was a mistake. But that's not to be argued here. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- 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 Jan 14 16:15:05 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12121 for ; Tue, 14 Jan 2003 16:15:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18YYFt-0004xn-00 for namedroppers-data@psg.com; Tue, 14 Jan 2003 13:05:53 -0800 Received: from e35.co.us.ibm.com ([32.97.110.133]) by psg.com with esmtp (Exim 3.36 #2) id 18YYFq-0004vO-00 for namedroppers@ops.ietf.org; Tue, 14 Jan 2003 13:05:50 -0800 Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e35.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id h0EL4keP106190; Tue, 14 Jan 2003 16:04:46 -0500 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.12.14]) by westrelay03.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id h0EL3TsK111014; Tue, 14 Jan 2003 14:03:29 -0700 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id h0EL2oV30388; Tue, 14 Jan 2003 16:02:50 -0500 Message-Id: <200301142102.h0EL2oV30388@rotala.raleigh.ibm.com> To: "D. J. Bernstein" , ietf@ietf.org, iesg@ietf.org, namedroppers Subject: Re: Dan Bernstein's issues about namedroppers list operation In-Reply-To: Message from narten@us.ibm.com of "Fri, 10 Jan 2003 11:24:52 EST." <200301101624.h0AGOqL09468@rotala.raleigh.ibm.com> Date: Tue, 14 Jan 2003 16:02:50 -0500 From: Thomas Narten X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02, SUBJECT_IS_LIST version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk To clarify a bit, based on followup mail. AD hat was on in previous message, same here. I am not speaking for the full IESG, however. It was not my intent to imply that if messages did not get forwarded to one list, but did on another, that this somehow was OK and couldn't be censorship. It is not OK. The messages at issue should have made it out onto namedroppers. Regarding namedroppers mail processing: > 1) first run through spamassassin. Mail that is rejected here is not > archived, as the number of such messages is large. All mail sent to > mailing lists on the server hosting namedroppers is run though > spamassassin, so this is not a namedroppers-specific > procedure. Strictly speaking, the above is not permitted by the published spam filtering guidelines. The issue isn't the use of spamassassin in front of the list, but post-processing of rejected messages. The current guidelines call for a human to manually approve the improperly flagged rejections. I have started a process to see what can be done to address the problem of rejections from spamassassin not being reviewed by a human when sent to namedroppers. In the case at issue, however, I do not believe that the use of spamassassin is the problem with the messages at issue. The explanation I find most likely is that the messages were deleted in haste rather than forwarded as they should have been after having been flagged as possible spam since they came from a non-subscriber. Of course, it is also not possible to prove intention in this case. Given that I have seen no compelling evidence that suggests a desire or intent to censor anyone on the list, I chose not to read such an intent in the cases at issue here. But of course, there is no way to prove one way or the other. Thomas -- 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 Jan 14 16:51:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13011 for ; Tue, 14 Jan 2003 16:51:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18YYri-0006mW-00 for namedroppers-data@psg.com; Tue, 14 Jan 2003 13:44:58 -0800 Received: from e34.co.us.ibm.com ([32.97.110.132]) by psg.com with esmtp (Exim 3.36 #2) id 18YYrg-0006mK-00 for namedroppers@ops.ietf.org; Tue, 14 Jan 2003 13:44:56 -0800 Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e34.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id h0ELih99025302; Tue, 14 Jan 2003 16:44:43 -0500 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.12.14]) by westrelay03.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id h0ELigsK103400; Tue, 14 Jan 2003 14:44:42 -0700 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id h0ELi3O30583; Tue, 14 Jan 2003 16:44:03 -0500 Message-Id: <200301142144.h0ELi3O30583@rotala.raleigh.ibm.com> To: Aaron Swartz cc: namedroppers , iesg@ietf.org, ietf@ietf.org, "D. J. Bernstein" Subject: Re: Dan Bernstein's issues about namedroppers list operation In-Reply-To: Message from me@aaronsw.com of "Fri, 10 Jan 2003 12:29:32 CST." <7661B517-24C9-11D7-9721-0003936780B2@aaronsw.com> Date: Tue, 14 Jan 2003 16:44:03 -0500 From: Thomas Narten X-Spam-Status: No, hits=-2.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_02_03,SUBJECT_IS_LIST version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Aaron Swartz writes: > 4) Any held message that is later approved for distribution on the > mailing list should appear on the list as a normal posting (e.g., > with the proper sender in the From address, etc.). > """ > Later, however, you write: > >> [...] However, in > >> the second message, he manually inserted my subscription > >> address, > >> despite my previous comments about private subscription > >> addresses > >> and forged unsubscription requests. (Was this malicious, or was > >> it > >> just mind-bogglingly stupid?) > > > > Or perhaps, it was to make it clear to the poster which address the > > posting was coming from, since there seems to be confusion at times > > about whether someone is posting from the same address to which they > > are subscribed. > Including someone's private subscription address is not done for a > normal posting. Doing it for a held message is a violation of the rule > above, no? My recollection of the intent of the spam guidelines cited is two things: 1) it wasn't good enough to just resend the message to the list such that the message now appeared to have come from the person who forwarded it. This makes it hard to quote authors appropriately in followups, find specific messages (e.g., to search for the message by the original poster). That sort of thing. 2) It wasn't appropriate to edit the message in a way that might lead someone to claim that the message had been edited to alter its intent. Namedropper's mail that is manually forwarded has (for as long as I can remember) included a line indicating it has been forwarded. The current message (which was improved as a result of the recent attention) is: [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] This seems like a reasonable thing to add to such messages. I would not want the guidelines cited to mean this is not permissable or that no other modification was permissible (e.g., adding a header line). One can debate whether including the specific information cited above was the right thing to do, but I don't see it as breach of the guidelines. Thomas -- 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 Jan 14 18:02:46 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15169 for ; Tue, 14 Jan 2003 18:02:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18YZlw-000A1J-00 for namedroppers-data@psg.com; Tue, 14 Jan 2003 14:43:04 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #2) id 18YZlt-000A0z-00 for namedroppers@ops.ietf.org; Tue, 14 Jan 2003 14:43:01 -0800 Received: from localhost ([127.0.0.1] helo=rip.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 18YZlt-000N9T-00 for namedroppers@ops.ietf.org; Tue, 14 Jan 2003 14:43:01 -0800 In-Reply-To: <200301142102.h0EL2oV30388@rotala.raleigh.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Tue, 14 Jan 2003 17:09:16 -0500 (EST) From: Dean Anderson To: Thomas Narten cc: "D. J. Bernstein" , , , namedroppers Subject: Re: Dan Bernstein's issues about namedroppers list operation X-Spam-Status: No, hits=-3.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,RESENT_TO, SPAM_PHRASE_01_02,SUBJECT_IS_LIST,TO_BE_REMOVED_REPLY, USER_AGENT_PINE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] Perhaps it would be helpful to consider that other lists have multiple persons who can handle such processing, and that all of those persons get the flagged message. Anyone in the administrative group can approve the message. An audit trail might be helpful, in this case. Such an audit trail would have to be read-only to the persons doing the administration, as well as readable to the public, who might wish to see that the administrators are properly handling messages. --Dean On Tue, 14 Jan 2003, Thomas Narten wrote: > To clarify a bit, based on followup mail. > > AD hat was on in previous message, same here. I am not speaking for > the full IESG, however. > > It was not my intent to imply that if messages did not get forwarded > to one list, but did on another, that this somehow was OK and couldn't > be censorship. It is not OK. The messages at issue should have made it > out onto namedroppers. > > Regarding namedroppers mail processing: > > > 1) first run through spamassassin. Mail that is rejected here is not > > archived, as the number of such messages is large. All mail sent to > > mailing lists on the server hosting namedroppers is run though > > spamassassin, so this is not a namedroppers-specific > > procedure. > > Strictly speaking, the above is not permitted by the published spam > filtering guidelines. The issue isn't the use of spamassassin in front > of the list, but post-processing of rejected messages. The current > guidelines call for a human to manually approve the improperly flagged > rejections. I have started a process to see what can be done to > address the problem of rejections from spamassassin not being reviewed > by a human when sent to namedroppers. > > In the case at issue, however, I do not believe that the use of > spamassassin is the problem with the messages at issue. The > explanation I find most likely is that the messages were deleted in > haste rather than forwarded as they should have been after having been > flagged as possible spam since they came from a non-subscriber. > > Of course, it is also not possible to prove intention in this case. > Given that I have seen no compelling evidence that suggests a desire > or intent to censor anyone on the list, I chose not to read such an > intent in the cases at issue here. But of course, there is no way to > prove one way or the other. > > Thomas > > -- > 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 Wed Jan 15 20:15:59 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17090 for ; Wed, 15 Jan 2003 20:15:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18YyN3-000KG9-00 for namedroppers-data@psg.com; Wed, 15 Jan 2003 16:59:01 -0800 Received: from stoneport.math.uic.edu ([131.193.178.160]) by psg.com with smtp (Exim 3.36 #2) id 18YyN1-000KFx-00 for namedroppers@ops.ietf.org; Wed, 15 Jan 2003 16:58:59 -0800 Received: (qmail 5504 invoked by uid 1016); 16 Jan 2003 00:59:20 -0000 Date: 16 Jan 2003 00:59:20 -0000 Message-ID: <20030116005920.5503.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org, iesg@ietf.org, ietf@ietf.org Subject: Re: Dan Bernstein's issues about namedroppers list operation References: <7661B517-24C9-11D7-9721-0003936780B2@aaronsw.com> <200301142144.h0ELi3O30583@rotala.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=-0.7 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, SUBJECT_IS_LIST version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Thomas Narten writes: > One can debate whether including the specific information cited above > was the right thing to do That's the paragraph Bush added to other people's messages. Bush added a different paragraph to my messages. (The ones he didn't throw away, that is.) In that paragraph, he specifically included my private subscription address, which hadn't appeared anywhere in the messages I actually sent. Unintentional, eh? ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- 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 Jan 15 20:20:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17151 for ; Wed, 15 Jan 2003 20:20:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18YyZW-000Kj5-00 for namedroppers-data@psg.com; Wed, 15 Jan 2003 17:11:54 -0800 Received: from stoneport.math.uic.edu ([131.193.178.160]) by psg.com with smtp (Exim 3.36 #2) id 18YyZU-000Kio-00 for namedroppers@ops.ietf.org; Wed, 15 Jan 2003 17:11:52 -0800 Received: (qmail 8745 invoked by uid 1016); 16 Jan 2003 01:12:13 -0000 Date: 16 Jan 2003 01:12:13 -0000 Message-ID: <20030116011213.8744.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: does anybody use additional/authority records on RD/RA replies References: <20030111200442.19176.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=0.3 required=5.0 tests=REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Bruce Campbell writes: > the memory footprint of a DNS cache You think that it's better use of memory to have separate caches---plus separate caching code---in every application? Bad design decisions like this are responsible for most of the bloat in programs like sendmail and named. It's particularly sad when one bloated program uses the size of another bloated program as an excuse to add even more bloat to the first instead of reusing the second. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- 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 Jan 16 01:37:34 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22920 for ; Thu, 16 Jan 2003 01:37:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Z3U7-00063s-00 for namedroppers-data@psg.com; Wed, 15 Jan 2003 22:26:39 -0800 Received: from rwcrmhc51.attbi.com ([204.127.198.38]) by psg.com with esmtp (Exim 3.36 #2) id 18Z3U2-00063L-00 for namedroppers@ops.ietf.org; Wed, 15 Jan 2003 22:26:34 -0800 Received: from billsbox (12-211-30-155.client.attbi.com[12.211.30.155]) by rwcrmhc51.attbi.com (rwcrmhc51) with SMTP id <2003011606260305100pllg0e>; Thu, 16 Jan 2003 06:26:03 +0000 Reply-To: From: "Bill Strahm" To: "'D. J. Bernstein'" , , , Subject: RE: Dan Bernstein's issues about namedroppers list operation Date: Wed, 15 Jan 2003 22:25:56 -0800 Message-ID: <000001c2bd28$20c5ca50$6501a8c0@billsbox> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: <20030116005920.5503.qmail@cr.yp.to> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=-1.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, SUBJECT_IS_LIST version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----Original Message----- From: owner-ietf@ietf.org [mailto:owner-ietf@ietf.org] On Behalf Of D. J. Bernstein Sent: Wednesday, January 15, 2003 4:59 PM To: namedroppers@ops.ietf.org; iesg@ietf.org; ietf@ietf.org Subject: Re: Dan Bernstein's issues about namedroppers list operation Thomas Narten writes: > One can debate whether including the specific information cited above > was the right thing to do That's the paragraph Bush added to other people's messages. Bush added a different paragraph to my messages. (The ones he didn't throw away, that is.) In that paragraph, he specifically included my private subscription address, which hadn't appeared anywhere in the messages I actually sent. Unintentional, eh? ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- 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 Jan 16 17:36:47 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25764 for ; Thu, 16 Jan 2003 17:36:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18ZIPb-0005ZK-00 for namedroppers-data@psg.com; Thu, 16 Jan 2003 14:22:59 -0800 Received: from peacock.verisign.com ([65.205.251.73]) by psg.com with esmtp (Exim 3.36 #2) id 18ZIPX-0005Z5-00 for namedroppers@ops.ietf.org; Thu, 16 Jan 2003 14:22:55 -0800 Received: from vhqpostal-gw2.verisign.com (verisign.com [65.205.251.56]) by peacock.verisign.com (8.12.1/) with ESMTP id h0GMMAq4025060; Thu, 16 Jan 2003 14:22:10 -0800 (PST) Received: by vhqpostal-gw2.verisign.com with Internet Mail Service (5.5.2653.19) id ; Thu, 16 Jan 2003 14:22:42 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: Keith Moore , Thomas Narten Cc: djb@cr.yp.to, ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org Subject: RE: Dan Bernstein's issues about namedroppers list operation Date: Thu, 16 Jan 2003 14:22:40 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0091_01C2BD83.CEB7E980" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=0.9 required=5.0 tests=EXCHANGE_SERVER,MISSING_OUTLOOK_NAME,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02,SUBJECT_IS_LIST,TO_BE_REMOVED_REPLY version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0091_01C2BD83.CEB7E980 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit There is a proposal to start an IRTF research group on the topic of SPAM. Perhaps one of the things that could be looked at is how mailing lists could apply spam defenses and still maintain open-ness. Many of the problems with spam are now the second order effects of dropped messages that should have been forwarded. By default SpamAssasin is configured to consult a blacklist that is currently blocking all UUNET addresses because the maintainer does not like something that a UUNET subscriber is publishing on their site. I conclude that blacklists of that type will not last long as the Internet starts to re-route arround the censorship damage. That said, there is an old proverb in politics about what you should do when you become the story. I think the issues that concern the group members here are more than just the alleged filtering of Bernstein's posts. Phill > -----Original Message----- > From: Keith Moore [mailto:moore@cs.utk.edu] > Sent: Friday, January 10, 2003 8:00 PM > To: Thomas Narten > Cc: moore@cs.utk.edu; djb@cr.yp.to; ietf@ietf.org; iesg@ietf.org; > namedroppers@ops.ietf.org > Subject: Re: Dan Bernstein's issues about namedroppers list operation > > > > > Specifically, all mail sent to namedroppers is: > > > > 1) first run through spamassassin. Mail that is rejected here is not > > archived, as the number of such messages is large. All > mail sent to > > mailing lists on the server hosting namedroppers is run though > > spamassassin, so this is not a namedroppers-specific procedure. > > SpamAssissin needs to be shot. Most of its criteria are > really poorly chosen. > Even if its criteria are good at identifying spam on a large > scale (with few > false positives) that doesn't mean they will work well for a > narrowly-focused > discussion. In my experience SpamAssassin has too high a > false positive rate > to be trusted without human review as a backup. > > Keith > > p.s. regarding messages that did not make it to the > namedroppers archive - > are the IETF archives still using to/cc message headers to > decide which > archive a message should be stored in? if so, is it > possible that a message > which was sent to multiple lists might be archived in only > one of those lists? > > -- > 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: > ------=_NextPart_000_0091_01C2BD83.CEB7E980 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINbTCCAj0w ggGmAhEAulrJTAU7ktantt9O0FOSDTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMDQwMTA3MjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBALZai6MNaiODgGvPOYf0IRMzBkwlou1VEpfFp4C5+oPBIKD6LxUNfKFga355LPoGDzqu 9htvsdL/LyhSX4N9S8R6t/hmH4BU/LfCjllKFFdG0ZqTvkGRA7sVgJNc6+fMCGw/PrNK/P9LbCPV UIImRBmOI8Nx6hkkRwSedb/IpgAfAgMBAAEwDQYJKoZIhvcNAQECBQADgYEAtgAfk1ekB6dAzmVA P1Ve7e/6VEmlMNYhfGGH7oOTC7+0M/KYrJ8Gv06ozhSBTMsETljDz1/ufNeab8tBird/gbj/hGHG J0NlHQzssQAK3Ruku8d4ICiyot02lS7hVE+/YLl3aBGZI+jqUuiqAE5nTruQtUWbRuuOFu/EM1sz PdUwggNDMIICrKADAgECAhAffl/nA9Hgv5kg3GuJDUsEMA0GCSqGSIb3DQEBBAUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMiBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDUy MzU5NTlaMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEmMCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQ ZXJzb25uZWwgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKcEbA+icrdKBi741yksNJ2C vEiRSses+en8uVl4sVXAU1ixz28WO8FJ1cv0bszhzMu1xy5OiKo06bbQW3w+FVc04Ri8/931r2dZ IArlPeqIikDSmokTKam21dunfuHnNyST/ZR0TXrkMm1M6FwWl6/dktlmihRm5OpaA6g9X/sLAgMB AAGjgbAwga0wMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEF BQcCARYfaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rcjAPBgNVHRMECDAGAQH/AgEBMAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQB59xXN6GhRWWv8qaa94B77vPQ/kN/n+u3kVPdh PVSLBrqXMloeqyzur3Orx13TP4/0zstOSGCiqGC2ON6gpvePKegRrMw5dlA83TlsC/Fa/QhUdt0W bPcxcLi/CPfJJgaO37svGbG2uLToPEjoJ7GXKSBXA5ybZ/p9QMQ4fxiqmjCCA8QwggMtoAMCAQIC EQCEzvIOADm1dVXaGYePUu2JMA0GCSqGSIb3DQEBBAUAMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1 YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEm MCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQZXJzb25uZWwgQ0EwHhcNOTkwMjI1MDAwMDAwWhcN MDQwMTA0MjM1OTU5WjCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAjBgNVBAMTHFZlcmlTaWduIENs YXNzIDIgRW1wbG95ZWUgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMCK0YdhouowA1Vr CDbwl/oaVDUkH+h9ncjDc9PYRvWRLdk47ZTXsCZzKt6XUE3/Ihy9cACYDFgqsaRyj6W59y18YOO1 3+l9TiEhYdX8O1TJpAmcuyL5orpwYU+GRqL9BWTsCj+mWHZXuxZzRHzwpQ2XwGym8WMIJbEEF5Wg jf5/AgMBAAGjgeIwgd8wKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMTE4 MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNy bDARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUF BwIBFh9odHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQAwCwYD VR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBABlGztRrcI5YXIhCNa0WfaUJLKhTkPH2PYbX8M5y FD0ivPLDM+3U/AWa4GMgdaMb71UZDwZzIQJhrqaeUSt43FvIhIvV17bP1fg+l5ixRIujmI6gS/aY MZOz8AzdUXbKl+RWRMb7lKFIfSJDzKDGXHlV9WeBG2iYNCREsZjBOiheMIIEGTCCA4KgAwIBAgIQ da9pAn9XoMlLtvoUDq8LyTANBgkqhkiG9w0BAQQFADCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJq ZWN0IHRvIHRlcm1zIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAj BgNVBAMTHFZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EwHhcNMDIwMjI3MDAwMDAwWhcNMDMw MjI3MjM1OTU5WjBtMREwDwYDVQQKEwhWRVJJU0lHTjELMAkGA1UECxMCSFExEzARBgNVBAMTClJl Y2lwaWVudHMxNjA0BgNVBAMTLXBiYWtlciAoSGFsbGFtLUJha2VyIFBoaWxsaXAsIFZlcmlTaWdu LCBJbmMuKTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtcA/okLsFi9brjmDsXQ6+g+R95B1 81Lq1EXkdzhY7XHxQ2QDq0sS2U4j9N1Ic6nHIiMq5dticztWpKdn6CrDx3Ovd5k+PACq/jSQo7NL tlMJi7fsUrP7pM4izKu4JjSak6wRJUA4x85TSC1PLfd1u8oq16iqNJRhpEJ8VJUMRyECAwEAAaOC AXgwggF0MAkGA1UdEwQCMAAwWQYDVR0fBFIwUDBOoEygSoZIaHR0cDovL29uc2l0ZWNybC52ZXJp c2lnbi5jb20vVmVyaVNpZ25JbmNFeGNoYW5nZUVtcGxveWVlcy9MYXRlc3RDUkwuY3JsMAsGA1Ud DwQEAwIFoDAeBgNVHREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4G C2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BT MGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEE BAMCB4AwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBACCK +gbdTcJB2wmWF5q8hbnP6slvVFehmjSX1Se+4Ff6a3Uiw8aOQLyNwnYUSOtHe12rTwAtWOhEgXHK D4XY3tF7cofo5hM8dk8xsj9vV3z3fYARDr4nR2bZblPJ3MGmAFAYKW4pgX4Y6NU4VhAG2Hiuj18/ H4Cc5g5oqJp5dArUMYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQOrwvJMAkGBSsOAwIa BQCgggGMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDExNjIy MjIxMlowIwYJKoZIhvcNAQkEMRYEFJ3lZDYkUs/sRzfC+KhfGRj6LUnQMFgGCSqGSIb3DQEJDzFL MEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcG BSsOAwIaMAoGCCqGSIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2Ug aXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChj KTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQO rwvJMA0GCSqGSIb3DQEBAQUABIGAUqTMmJwOP7FOpgLAYwy2GiJ0OoxiBPzDPqt2mDT5XAdxfBtQ LRuMr0T5j1LqvVMA7l6S3gKUPN1feplc58vUnf35NnK6mu7z8xdqZV98oieFQR6CcJJd2+OiL0/P bZrfpv+k3jSJaiiywyuruBx09dYCRDy273iTNJsz9O5Wv0UAAAAAAAA= ------=_NextPart_000_0091_01C2BD83.CEB7E980-- -- 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 Jan 17 02:15:50 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14319 for ; Fri, 17 Jan 2003 02:15:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18ZQYY-000LJl-00 for namedroppers-data@psg.com; Thu, 16 Jan 2003 23:04:46 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #2) id 18ZQYW-000LJY-00 for namedroppers@ops.ietf.org; Thu, 16 Jan 2003 23:04:44 -0800 Received: from localhost ([127.0.0.1] helo=rip.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 18ZQYW-000BLR-00 for namedroppers@ops.ietf.org; Thu, 16 Jan 2003 23:04:44 -0800 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Thu, 16 Jan 2003 19:21:01 -0500 (EST) From: Dean Anderson To: "Hallam-Baker, Phillip" cc: Keith Moore , Thomas Narten , , , , Subject: RE: Dan Bernstein's issues about namedroppers list operation X-Spam-Status: No, hits=-3.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,RESENT_TO, SPAM_PHRASE_01_02,SUBJECT_IS_LIST,TO_BE_REMOVED_REPLY, USER_AGENT_PINE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] The current issues with namedroppers administration have nothing to do with SPAM, but rather have to do with draconian and un-audited controls given to one person _on_behalf_of_SPAM_. This was a unwise decision. SPAM problems did not require that supreme, un-audited authority be given one person. A large part of "SPAM" is not a matter of marketing. It is a matter of terrorism, where instead of violence, they conduct annoyance. The persons creating the vast bulk of the abuse are people trying to terrorize or annoy people into banning spam. Vixie said from the start that it was his goal to make things worse. He has succeeded: More annoying it is. These people have no real commercial motivation--at least, not with respect to the services described in the emails they send. They aren't trying to sell anything by email. They are trying to sabotage the system of email, and annoy people. One might wonder who would only want to annoy people, and for what purpose, since they are not trying to sell something. No matter what kind of system you build, if there is any openness for people, whatsoever, it will be vulnerable to abuse by people inclined to conduct such abuse. There is no way to prevent that abuse. You can try to delete the abuse, after it has occurred. You can implement moderation with the incumbent delays, and other problems, which are necessary or unnecessary consequences of moderation. You can complain to the ISP's who sold accounts to the abusers. Etc. These things are all activities performed after the fact. Even the moderation staff still has to deal with the abuse, if the entire list doesn't. When someone is trying to annoy you, the correct response is not to be annoyed, but to remain calm. Like terrorism, there is no solution to spam. Whatever you do, beyond punishing those directly responsible, will only make the matter worse. --Dean On Thu, 16 Jan 2003, Hallam-Baker, Phillip wrote: > There is a proposal to start an IRTF research group on the topic of > SPAM. Perhaps one of the things that could be looked at is how mailing > lists could apply spam defenses and still maintain open-ness. > > Many of the problems with spam are now the second order effects of > dropped messages that should have been forwarded. > > By default SpamAssasin is configured to consult a blacklist that is > currently blocking all UUNET addresses because the maintainer does not > like something that a UUNET subscriber is publishing on their site. I > conclude that blacklists of that type will not last long as the Internet > starts to re-route arround the censorship damage. > > > That said, there is an old proverb in politics about what you should do > when you become the story. I think the issues that concern the group > members here are more than just the alleged filtering of Bernstein's > posts. > > > Phill > > > -----Original Message----- > > From: Keith Moore [mailto:moore@cs.utk.edu] > > Sent: Friday, January 10, 2003 8:00 PM > > To: Thomas Narten > > Cc: moore@cs.utk.edu; djb@cr.yp.to; ietf@ietf.org; iesg@ietf.org; > > namedroppers@ops.ietf.org > > Subject: Re: Dan Bernstein's issues about namedroppers list operation > > > > > > > > > Specifically, all mail sent to namedroppers is: > > > > > > 1) first run through spamassassin. Mail that is rejected here is not > > > archived, as the number of such messages is large. All > > mail sent to > > > mailing lists on the server hosting namedroppers is run though > > > spamassassin, so this is not a namedroppers-specific procedure. > > > > SpamAssissin needs to be shot. Most of its criteria are > > really poorly chosen. > > Even if its criteria are good at identifying spam on a large > > scale (with few > > false positives) that doesn't mean they will work well for a > > narrowly-focused > > discussion. In my experience SpamAssassin has too high a > > false positive rate > > to be trusted without human review as a backup. > > > > Keith > > > > p.s. regarding messages that did not make it to the > > namedroppers archive - > > are the IETF archives still using to/cc message headers to > > decide which > > archive a message should be stored in? if so, is it > > possible that a message > > which was sent to multiple lists might be archived in only > > one of those lists? > > > > -- > > 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 Sat Jan 18 06:13:57 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25581 for ; Sat, 18 Jan 2003 06:13:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Zqg0-000DEi-00 for namedroppers-data@psg.com; Sat, 18 Jan 2003 02:58:12 -0800 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.36 #2) id 18Zqfw-000DEB-00 for namedroppers@ops.ietf.org; Sat, 18 Jan 2003 02:58:09 -0800 Received: from x22.ripe.net (x22.ripe.net [193.0.1.22]) by birch.ripe.net (8.12.5/8.11.6) with ESMTP id h0IAvbAr018985 for ; Sat, 18 Jan 2003 11:57:37 +0100 Date: Sat, 18 Jan 2003 11:57:37 +0100 (CET) From: Bruce Campbell X-X-Sender: bc@x22.ripe.net To: namedroppers@ops.ietf.org Subject: Re: does anybody use additional/authority records on RD/RA replies In-Reply-To: <20030116011213.8744.qmail@cr.yp.to> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.4 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, USER_AGENT_PINE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On 16 Jan 2003, D. J. Bernstein wrote, removing the original context: > Bruce Campbell writes: > > the memory footprint of a DNS cache > > You think that it's better use of memory to have separate caches---plus > separate caching code---in every application? In the original context that I provided, it _was_ a better usage of _resources_, not necessarily memory, to re-use information previously received due to the greater expense of asking for the same information, _at that point in time_ (ie, more expensive internet links, more expensive cpu, more expensive memory). --==-- Bruce. -- 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 Jan 18 07:32:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26192 for ; Sat, 18 Jan 2003 07:32:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Zryz-000FIv-00 for namedroppers-data@psg.com; Sat, 18 Jan 2003 04:21:53 -0800 Received: from stoneport.math.uic.edu ([131.193.178.160]) by psg.com with smtp (Exim 3.36 #2) id 18Zryv-000FIe-00 for namedroppers@ops.ietf.org; Sat, 18 Jan 2003 04:21:49 -0800 Received: (qmail 4910 invoked by uid 1016); 18 Jan 2003 12:22:11 -0000 Date: 18 Jan 2003 12:22:11 -0000 Message-ID: <20030118122211.4909.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: does anybody use additional/authority records on RD/RA replies References: <20030116011213.8744.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=-0.5 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Bruce Campbell writes: > more expensive internet links, more expensive cpu, more expensive memory I'm not saying that bandwidth, CPU time, and memory are free. I'm saying that the costs of the strategy you're advocating outweigh the benefits. A machine-wide cache is better than an ad-hoc cache in every program. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- 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 Jan 20 06:07:18 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16068 for ; Mon, 20 Jan 2003 06:07:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18aZbN-0002YU-00 for namedroppers-data@psg.com; Mon, 20 Jan 2003 02:56:25 -0800 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.36 #2) id 18aZbJ-0002YH-00 for namedroppers@ops.ietf.org; Mon, 20 Jan 2003 02:56:21 -0800 Received: from x22.ripe.net (x22.ripe.net [193.0.1.22]) by birch.ripe.net (8.12.5/8.11.6) with ESMTP id h0KAu7Ar022024 for ; Mon, 20 Jan 2003 11:56:07 +0100 Date: Mon, 20 Jan 2003 11:56:07 +0100 (CET) From: Bruce Campbell X-X-Sender: bc@x22.ripe.net To: namedroppers@ops.ietf.org Subject: Re: does anybody use additional/authority records on RD/RA replies In-Reply-To: <20030118122211.4909.qmail@cr.yp.to> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.0 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_02_03,USER_AGENT_PINE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On 18 Jan 2003, D. J. Bernstein wrote: [ danny boy, you may wish to re-read this thread to understand why I keep putting in the original context. I dislike having my words quoted out of context in order to uphold statements outside said context. ] > Bruce Campbell writes: : > On 16 Jan 2003, D. J. Bernstein wrote, removing the original context: : > > You think that it's better use of memory to have separate caches---plus : > > separate caching code---in every application? : > In the original context that I provided, it _was_ a better usage of : > _resources_, not necessarily memory, to re-use information previously : > received due to the greater expense of asking for the same information, : >_at that point in time_ (ie, > > more expensive internet links, more expensive cpu, more expensive memory). > > I'm not saying that bandwidth, CPU time, and memory are free. Neither am I. You may wish to re-read this thread to understand the difference between the inverse of 'more expensive', ie 'cheaper' and 'free'. > I'm saying > that the costs of the strategy you're advocating outweigh the benefits. Given that I haven't been advocating any particular design strategy for writing programs today, I suspect that you meant to write: | I'm saying that the costs of using such an old strategy today outweigh | the benefits. You may wish to re-read this thread to understand the difference between the two statements. > A machine-wide cache is better than an ad-hoc cache in every program. Not quite correct. You probably mean: A machine-wide cache is better than an ad-hoc cache in most programs written today. There are programs written today which implement their own (DNS) caching simply because their design goal is pure speed, and the local machine-wide (DNS) cache, irrespective of the author of such, is too slow for their particular needs. You may wish to re-read the thread to understand why I put forward my thoughts on such a design strategy for times past in the first place. --==-- Bruce. -- 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 Jan 20 06:59:10 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17298 for ; Mon, 20 Jan 2003 06:59:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18aaYb-0005Ai-00 for namedroppers-data@psg.com; Mon, 20 Jan 2003 03:57:37 -0800 Received: from stoneport.math.uic.edu ([131.193.178.160]) by psg.com with smtp (Exim 3.36 #2) id 18aaYX-0005AP-00 for namedroppers@ops.ietf.org; Mon, 20 Jan 2003 03:57:33 -0800 Received: (qmail 39974 invoked by uid 1016); 20 Jan 2003 11:57:53 -0000 Date: 20 Jan 2003 11:57:53 -0000 Message-ID: <20030120115753.39972.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: does anybody use additional/authority records on RD/RA replies References: <20030118122211.4909.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=0.3 required=5.0 tests=REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I'm not just saying that ad-hoc per-program DNS caches are bad design today. I'm also saying that they were bad design twenty years ago. The traffic argument is, and has always been, silly: a machine-wide cache saves more traffic. The memory argument is, and has always been, silly: a machine-wide cache uses less memory. The CPU-time argument is not silly, but if you measure carefully then you'll see that it's wrong. More importantly, all three arguments reflect a serious failure to put costs in perspective. As Knuth wrote thirty years ago: There is no doubt that the ``grail'' of efficiency leads to abuse. Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We _should_ forget about small efficiencies, say about 97% of the time; premature optimization is the root of all evil. No rational estimate for the benefits of sendmail's ad-hoc DNS cache could ever have justified the lines of code spent on that cache. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- 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 Jan 20 07:27:56 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17578 for ; Mon, 20 Jan 2003 07:27:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18aazj-0006QU-00 for namedroppers-data@psg.com; Mon, 20 Jan 2003 04:25:39 -0800 Received: from open.nlnetlabs.nl ([213.53.69.1]) by psg.com with esmtp (Exim 3.36 #2) id 18aazh-0006QI-00 for namedroppers@ops.ietf.org; Mon, 20 Jan 2003 04:25:37 -0800 Received: from open.nlnetlabs.nl (localhost.nlnetlabs.nl [127.0.0.1]) by open.nlnetlabs.nl (8.12.6/8.12.6) with ESMTP id h0KCPXpG043381; Mon, 20 Jan 2003 13:25:33 +0100 (CET) (envelope-from alexis@open.nlnetlabs.nl) Received: (from alexis@localhost) by open.nlnetlabs.nl (8.12.6/8.12.6/Submit) id h0KCPXic043380; Mon, 20 Jan 2003 13:25:33 +0100 (CET) Message-Id: <200301201225.h0KCPXic043380@open.nlnetlabs.nl> Subject: Re: does anybody use additional/authority records on RD/RA replies In-Reply-To: <20030120115753.39972.qmail@cr.yp.to> To: "D. J. Bernstein" Date: Mon, 20 Jan 2003 13:25:33 +0100 (CET) From: Alexis Yushin CC: namedroppers@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Once D. J. Bernstein wrote: >I'm not just saying that ad-hoc per-program DNS caches are bad design >today. I'm also saying that they were bad design twenty years ago. > >The traffic argument is, and has always been, silly: a machine-wide >cache saves more traffic. The memory argument is, and has always been, >silly: a machine-wide cache uses less memory. The CPU-time argument is >not silly, but if you measure carefully then you'll see that it's wrong. I think the real arguement here is that resolving process, quite often lengthy, potentionaly blocking operation, can dramatically impact the performance of the application unless optimized. Having dns cache built in ensures that the application does not rely on external software and will function reasonably even when no machine-wide dns cache software is in use, which is quite often the case. Now if machine-level dns caching was a standard feature of the resolver library or the operating system, I'm sure nobody would be implementing custom built in program-level dns caches. Until them I'm afraid it does make sense to avoid complicating dependancies. Alexis -- 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 Jan 21 13:45:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08302 for ; Tue, 21 Jan 2003 13:45:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18b3AK-000B4W-00 for namedroppers-data@psg.com; Tue, 21 Jan 2003 10:30:28 -0800 Received: from pigeon.verisign.com ([65.205.251.71]) by psg.com with esmtp (Exim 3.36 #2) id 18b3AH-000B4E-00 for namedroppers@ops.ietf.org; Tue, 21 Jan 2003 10:30:25 -0800 Received: from vhqpostal-gw1.verisign.com (verisign.com [65.205.251.55]) by pigeon.verisign.com (8.12.1/) with ESMTP id h0LISgVG028353; Tue, 21 Jan 2003 10:28:42 -0800 (PST) Received: by vhqpostal-gw1.verisign.com with Internet Mail Service (5.5.2656.59) id ; Tue, 21 Jan 2003 10:30:21 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org Subject: Dan Berrnstein deserves what he gets. FW: qsecretary notice Date: Tue, 21 Jan 2003 10:30:18 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0119_01C2C14E.374DCA50" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=2.5 required=5.0 tests=EXCHANGE_SERVER,MISSING_OUTLOOK_NAME,OUTLOOK_FW_MSG, SPAM_PHRASE_05_08 version=2.43 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0119_01C2C14E.374DCA50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Bernstein is a whiner who deserves no sympathy from anyone. In order to avoid cluttering up his inbox with SPAM he has one of those annoying callback systems. Only thing is that the self-centered clod can't be bothered to put people who reply into a whitelist. What this means is that as a result of Mr* Bernsteins attempt to minimize the amount of spam HE receives, he is generating spam for EVERYONE ELSE. I have answered the call back twice, Bernstein continues to SPAM me. What is worse, the main purpose of the callback message appears to be to remind the recipient of the size of Bernstein's ego. If bernstein is having difficulty posting to the list I suspect that it is not at all unlikely that the cause will turn out to be some interaction between his eccentric mailing code and the mailing list software that he has not bothered to consider or investigate. Phill [*] Its only an assistant professorship that by European lights only ranks him as a mere lecturer. The fact that he has to refer to himself by title TEN times in his pompous note suggests that his sense of self importance is dangerously exagerated. -----Original Message----- From: The qsecretary program [mailto:djb-notbulkmail-eeac5f7ce0588c3ec6303c66f5f2ef59@cr.yp.to] Sent: Thursday, January 16, 2003 5:23 PM To: pbaker@verisign.com Subject: qsecretary notice Hi. This is D. J. Bernstein's automated mail-handling program. I've received a message from you. The top of your message is shown below. Professor Bernstein receives many interesting messages. Unfortunately, he also receives a torrent of unsolicited commercial mail, unsolicited job applications, unsolicited mailing-list subscriptions, forged mailing-list subscriptions, etc. Professor Bernstein has asked me to reject all bulk mail messages. But I'm a rather primitive computer program, and I'm not sure whether your message is bulk mail. If you reply to this notice, you are (1) acknowledging that Professor Bernstein does not want to receive bulk mail; (2) confirming that your message is not part of a bulk mailing; and (3) agreeing to pay Professor Bernstein $250 if your message is part of a bulk mailing. I won't look at the contents of your reply. A simple OK is fine, as long as it's sent to the address shown above. You don't have to include a second copy of your message. If you do not reply to this notice, your message will eventually be returned to you, and Professor Bernstein will not see it. I realize that this confirmation process is inconvenient. I'm sorry for the hassle. I hope that IM2000, Professor Bernstein's new Internet mail architecture, succeeds in eliminating these problems. In the meantime, we're all suffering because of a few inconsiderate people. Sincerely, The qsecretary program P.S. Professor Bernstein has asked me to convey his own apologies to you if you're someone he knows. I'm sure he'll tell me to accept subsequent messages from you without confirmation. If you're replying to a message that Professor Bernstein sent you, the problem is probably that the return address in your message isn't the same as the address that Professor Bernstein has on file. I'll let Professor Bernstein know that he should add your new address. P.P.S. If you're a legitimate mailing-list manager, and you've received what appears to be a subscription request from djb@cr.yp.to: That request is a forgery. Professor Bernstein uses different addresses for his mailing-list subscriptions. Please remove djb@cr.yp.to from your mailing list. Do not reply to this message. Note that high-quality mailing-list software confirms each subscription request with a secure cryptographic authenticator; supports tracing by returning a complete copy of each request, including Received fields; and supports filtering by adding a Mailing-List field to every outgoing message, including confirmation notices. If your software does not have these features, upgrade! ------=_NextPart_000_0119_01C2C14E.374DCA50 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINbTCCAj0w ggGmAhEAulrJTAU7ktantt9O0FOSDTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMDQwMTA3MjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBALZai6MNaiODgGvPOYf0IRMzBkwlou1VEpfFp4C5+oPBIKD6LxUNfKFga355LPoGDzqu 9htvsdL/LyhSX4N9S8R6t/hmH4BU/LfCjllKFFdG0ZqTvkGRA7sVgJNc6+fMCGw/PrNK/P9LbCPV UIImRBmOI8Nx6hkkRwSedb/IpgAfAgMBAAEwDQYJKoZIhvcNAQECBQADgYEAtgAfk1ekB6dAzmVA P1Ve7e/6VEmlMNYhfGGH7oOTC7+0M/KYrJ8Gv06ozhSBTMsETljDz1/ufNeab8tBird/gbj/hGHG J0NlHQzssQAK3Ruku8d4ICiyot02lS7hVE+/YLl3aBGZI+jqUuiqAE5nTruQtUWbRuuOFu/EM1sz PdUwggNDMIICrKADAgECAhAffl/nA9Hgv5kg3GuJDUsEMA0GCSqGSIb3DQEBBAUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMiBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDUy MzU5NTlaMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEmMCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQ ZXJzb25uZWwgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKcEbA+icrdKBi741yksNJ2C vEiRSses+en8uVl4sVXAU1ixz28WO8FJ1cv0bszhzMu1xy5OiKo06bbQW3w+FVc04Ri8/931r2dZ IArlPeqIikDSmokTKam21dunfuHnNyST/ZR0TXrkMm1M6FwWl6/dktlmihRm5OpaA6g9X/sLAgMB AAGjgbAwga0wMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEF BQcCARYfaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rcjAPBgNVHRMECDAGAQH/AgEBMAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQB59xXN6GhRWWv8qaa94B77vPQ/kN/n+u3kVPdh PVSLBrqXMloeqyzur3Orx13TP4/0zstOSGCiqGC2ON6gpvePKegRrMw5dlA83TlsC/Fa/QhUdt0W bPcxcLi/CPfJJgaO37svGbG2uLToPEjoJ7GXKSBXA5ybZ/p9QMQ4fxiqmjCCA8QwggMtoAMCAQIC EQCEzvIOADm1dVXaGYePUu2JMA0GCSqGSIb3DQEBBAUAMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1 YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEm MCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQZXJzb25uZWwgQ0EwHhcNOTkwMjI1MDAwMDAwWhcN MDQwMTA0MjM1OTU5WjCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAjBgNVBAMTHFZlcmlTaWduIENs YXNzIDIgRW1wbG95ZWUgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMCK0YdhouowA1Vr CDbwl/oaVDUkH+h9ncjDc9PYRvWRLdk47ZTXsCZzKt6XUE3/Ihy9cACYDFgqsaRyj6W59y18YOO1 3+l9TiEhYdX8O1TJpAmcuyL5orpwYU+GRqL9BWTsCj+mWHZXuxZzRHzwpQ2XwGym8WMIJbEEF5Wg jf5/AgMBAAGjgeIwgd8wKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMTE4 MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNy bDARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUF BwIBFh9odHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQAwCwYD VR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBABlGztRrcI5YXIhCNa0WfaUJLKhTkPH2PYbX8M5y FD0ivPLDM+3U/AWa4GMgdaMb71UZDwZzIQJhrqaeUSt43FvIhIvV17bP1fg+l5ixRIujmI6gS/aY MZOz8AzdUXbKl+RWRMb7lKFIfSJDzKDGXHlV9WeBG2iYNCREsZjBOiheMIIEGTCCA4KgAwIBAgIQ da9pAn9XoMlLtvoUDq8LyTANBgkqhkiG9w0BAQQFADCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJq ZWN0IHRvIHRlcm1zIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAj BgNVBAMTHFZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EwHhcNMDIwMjI3MDAwMDAwWhcNMDMw MjI3MjM1OTU5WjBtMREwDwYDVQQKEwhWRVJJU0lHTjELMAkGA1UECxMCSFExEzARBgNVBAMTClJl Y2lwaWVudHMxNjA0BgNVBAMTLXBiYWtlciAoSGFsbGFtLUJha2VyIFBoaWxsaXAsIFZlcmlTaWdu LCBJbmMuKTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtcA/okLsFi9brjmDsXQ6+g+R95B1 81Lq1EXkdzhY7XHxQ2QDq0sS2U4j9N1Ic6nHIiMq5dticztWpKdn6CrDx3Ovd5k+PACq/jSQo7NL tlMJi7fsUrP7pM4izKu4JjSak6wRJUA4x85TSC1PLfd1u8oq16iqNJRhpEJ8VJUMRyECAwEAAaOC AXgwggF0MAkGA1UdEwQCMAAwWQYDVR0fBFIwUDBOoEygSoZIaHR0cDovL29uc2l0ZWNybC52ZXJp c2lnbi5jb20vVmVyaVNpZ25JbmNFeGNoYW5nZUVtcGxveWVlcy9MYXRlc3RDUkwuY3JsMAsGA1Ud DwQEAwIFoDAeBgNVHREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4G C2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BT MGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEE BAMCB4AwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBACCK +gbdTcJB2wmWF5q8hbnP6slvVFehmjSX1Se+4Ff6a3Uiw8aOQLyNwnYUSOtHe12rTwAtWOhEgXHK D4XY3tF7cofo5hM8dk8xsj9vV3z3fYARDr4nR2bZblPJ3MGmAFAYKW4pgX4Y6NU4VhAG2Hiuj18/ H4Cc5g5oqJp5dArUMYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQOrwvJMAkGBSsOAwIa BQCgggGMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDEyMTE4 MDgzOVowIwYJKoZIhvcNAQkEMRYEFDAzImeCwWkumcnGeM8UON13A59qMFgGCSqGSIb3DQEJDzFL MEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcG BSsOAwIaMAoGCCqGSIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2Ug aXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChj KTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQO rwvJMA0GCSqGSIb3DQEBAQUABIGAUygU16m8TPmOAxnQOIhrB6foHy1W3Rl8YrIy7QddvlJpl33y YuHdWjjrnB/ORffb7la+x1HIXiJXM/HNV6Ysg0H0ACy7lgx0kYZIg6ZYHuklRvk7kEiBaIxjxVUt CvCu16Utaw/2nap0yZlFfiaW/u9cOY4DbaBkokSdCVMEwSAAAAAAAAA= ------=_NextPart_000_0119_01C2C14E.374DCA50-- -- 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 Jan 23 18:29:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24245 for ; Thu, 23 Jan 2003 18:29:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18bqYS-000I2D-00 for namedroppers-data@psg.com; Thu, 23 Jan 2003 15:14:40 -0800 Received: from d215-134.uoregon.edu ([128.223.215.134] helo=roam.psg.com ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18bqYO-000I1s-00 for namedroppers@ops.ietf.org; Thu, 23 Jan 2003 15:14:36 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18bqYN-0000EE-00 for namedroppers@ops.ietf.org; Thu, 23 Jan 2003 15:14:35 -0800 Message-Id: <200301221813.h0MIDCQY007903@turing-police.cc.vt.edu> In-Reply-To: Your message of "Tue, 21 Jan 2003 10:30:18 PST." References: Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-227804608P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit To: "Hallam-Baker, Phillip" Cc: ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org Subject: Re: Dan Berrnstein deserves what he gets. FW: qsecretary notice From: Valdis.Kletnieks@vt.edu Date: Wed, 22 Jan 2003 13:13:12 -0500 X-Spam-Status: No, hits=-0.6 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,OUTLOOK_FW_MSG,QUOTED_EMAIL_TEXT, REFERENCES,RESENT_TO,SPAM_PHRASE_01_02 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --==_Exmh_-227804608P Content-Type: text/plain; charset=us-ascii [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] On Tue, 21 Jan 2003 10:30:18 PST, "Hallam-Baker, Phillip" said: > [*] Its only an assistant professorship that by European lights > only ranks him as a mere lecturer. The fact that he has to refer And by common US practice, he has a PhD and is accorded the title Doctor. At the place he has a professorship, the customary usage is to use the title. Also, in the US, there is usually a distinction made between an assistant professor and an adjunct professor and a lecturer/instructor. --==_Exmh_-227804608P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Exmh version 2.5 07/13/2001 iD8DBQE+Lt84cC3lWbTT17ARAvx0AKDmHPYtgLsjUfRzefhR1MaPSFcjrgCg/JHB WTwMFAJhvMD11YOGUac8Y1M= =MvPu -----END PGP SIGNATURE----- --==_Exmh_-227804608P-- -- 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 Jan 24 04:43:10 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14306 for ; Fri, 24 Jan 2003 04:43:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18c0EQ-000OsT-00 for namedroppers-data@psg.com; Fri, 24 Jan 2003 01:34:38 -0800 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #2) id 18c0EO-000Ori-00 for namedroppers@ops.ietf.org; Fri, 24 Jan 2003 01:34:36 -0800 Received: from shell.nominum.com (localhost [127.0.0.1]) by shell.nominum.com (Postfix) with ESMTP id C6BE3137F02; Fri, 24 Jan 2003 01:34:22 -0800 (PST) To: Valdis.Kletnieks@vt.edu Cc: "Hallam-Baker, Phillip" , ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org Subject: Re: Dan Berrnstein deserves what he gets. FW: qsecretary notice In-Reply-To: Message from Valdis.Kletnieks@vt.edu of "Wed, 22 Jan 2003 13:13:12 EST." <200301221813.h0MIDCQY007903@turing-police.cc.vt.edu> Date: Fri, 24 Jan 2003 01:34:22 -0800 Message-ID: <50041.1043400862@shell.nominum.com> From: Jim Reid X-Spam-Status: No, hits=-0.1 required=5.0 tests=IN_REP_TO,OUTLOOK_FW_MSG,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Please take this debate about academic titles somewhere else. It's not relevant to any of the lists above. -- 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 Jan 24 11:19:52 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23902 for ; Fri, 24 Jan 2003 11:19:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18c6Ni-000A2K-00 for namedroppers-data@psg.com; Fri, 24 Jan 2003 08:08:38 -0800 Received: from pigeon.verisign.com ([65.205.251.71]) by psg.com with esmtp (Exim 3.36 #2) id 18c6Ne-000A1z-00 for namedroppers@ops.ietf.org; Fri, 24 Jan 2003 08:08:34 -0800 Received: from vhqpostal-gw1.verisign.com (verisign.com [65.205.251.55]) by pigeon.verisign.com (8.12.1/) with ESMTP id h0OG6l3k001220; Fri, 24 Jan 2003 08:06:47 -0800 (PST) Received: by vhqpostal-gw1.verisign.com with Internet Mail Service (5.5.2656.59) id ; Fri, 24 Jan 2003 08:08:29 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: Jim Reid , Valdis.Kletnieks@vt.edu Cc: "Hallam-Baker, Phillip" , ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org Subject: RE: Dan Berrnstein deserves what he gets. FW: qsecretary notice Date: Fri, 24 Jan 2003 08:08:26 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_009C_01C2C398.CCFBE220"; micalg=SHA1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=0.9 required=5.0 tests=EXCHANGE_SERVER,MISSING_OUTLOOK_NAME,OUTLOOK_FW_MSG, QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_009C_01C2C398.CCFBE220 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit My objective was to try to put an end to the Bernstein thread, not to start yet another. I appologise for paying insufficient respect to the decorations and titles of the New World. I did not realise that it was the custom in these parts for the holders of academic titles to address themselves in the third person. Phill Dr. Phillip M. Hallam-Baker, B.Sc(Soton), D.Phil(Oxon), C.Eng, FBCS > -----Original Message----- > From: Jim Reid [mailto:Jim.Reid@nominum.com] > Sent: Friday, January 24, 2003 4:34 AM > To: Valdis.Kletnieks@vt.edu > Cc: Hallam-Baker, Phillip; ietf@ietf.org; iesg@ietf.org; > namedroppers@ops.ietf.org > Subject: Re: Dan Berrnstein deserves what he gets. FW: > qsecretary notice > > > > Please take this debate about academic titles somewhere else. It's not > relevant to any of the lists above. > ------=_NextPart_000_009C_01C2C398.CCFBE220 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINbTCCAj0w ggGmAhEAulrJTAU7ktantt9O0FOSDTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMDQwMTA3MjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBALZai6MNaiODgGvPOYf0IRMzBkwlou1VEpfFp4C5+oPBIKD6LxUNfKFga355LPoGDzqu 9htvsdL/LyhSX4N9S8R6t/hmH4BU/LfCjllKFFdG0ZqTvkGRA7sVgJNc6+fMCGw/PrNK/P9LbCPV UIImRBmOI8Nx6hkkRwSedb/IpgAfAgMBAAEwDQYJKoZIhvcNAQECBQADgYEAtgAfk1ekB6dAzmVA P1Ve7e/6VEmlMNYhfGGH7oOTC7+0M/KYrJ8Gv06ozhSBTMsETljDz1/ufNeab8tBird/gbj/hGHG J0NlHQzssQAK3Ruku8d4ICiyot02lS7hVE+/YLl3aBGZI+jqUuiqAE5nTruQtUWbRuuOFu/EM1sz PdUwggNDMIICrKADAgECAhAffl/nA9Hgv5kg3GuJDUsEMA0GCSqGSIb3DQEBBAUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMiBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDUy MzU5NTlaMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEmMCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQ ZXJzb25uZWwgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKcEbA+icrdKBi741yksNJ2C vEiRSses+en8uVl4sVXAU1ixz28WO8FJ1cv0bszhzMu1xy5OiKo06bbQW3w+FVc04Ri8/931r2dZ IArlPeqIikDSmokTKam21dunfuHnNyST/ZR0TXrkMm1M6FwWl6/dktlmihRm5OpaA6g9X/sLAgMB AAGjgbAwga0wMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEF BQcCARYfaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rcjAPBgNVHRMECDAGAQH/AgEBMAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQB59xXN6GhRWWv8qaa94B77vPQ/kN/n+u3kVPdh PVSLBrqXMloeqyzur3Orx13TP4/0zstOSGCiqGC2ON6gpvePKegRrMw5dlA83TlsC/Fa/QhUdt0W bPcxcLi/CPfJJgaO37svGbG2uLToPEjoJ7GXKSBXA5ybZ/p9QMQ4fxiqmjCCA8QwggMtoAMCAQIC EQCEzvIOADm1dVXaGYePUu2JMA0GCSqGSIb3DQEBBAUAMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1 YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEm MCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQZXJzb25uZWwgQ0EwHhcNOTkwMjI1MDAwMDAwWhcN MDQwMTA0MjM1OTU5WjCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAjBgNVBAMTHFZlcmlTaWduIENs YXNzIDIgRW1wbG95ZWUgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMCK0YdhouowA1Vr CDbwl/oaVDUkH+h9ncjDc9PYRvWRLdk47ZTXsCZzKt6XUE3/Ihy9cACYDFgqsaRyj6W59y18YOO1 3+l9TiEhYdX8O1TJpAmcuyL5orpwYU+GRqL9BWTsCj+mWHZXuxZzRHzwpQ2XwGym8WMIJbEEF5Wg jf5/AgMBAAGjgeIwgd8wKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMTE4 MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNy bDARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUF BwIBFh9odHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQAwCwYD VR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBABlGztRrcI5YXIhCNa0WfaUJLKhTkPH2PYbX8M5y FD0ivPLDM+3U/AWa4GMgdaMb71UZDwZzIQJhrqaeUSt43FvIhIvV17bP1fg+l5ixRIujmI6gS/aY MZOz8AzdUXbKl+RWRMb7lKFIfSJDzKDGXHlV9WeBG2iYNCREsZjBOiheMIIEGTCCA4KgAwIBAgIQ da9pAn9XoMlLtvoUDq8LyTANBgkqhkiG9w0BAQQFADCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJq ZWN0IHRvIHRlcm1zIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAj BgNVBAMTHFZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EwHhcNMDIwMjI3MDAwMDAwWhcNMDMw MjI3MjM1OTU5WjBtMREwDwYDVQQKEwhWRVJJU0lHTjELMAkGA1UECxMCSFExEzARBgNVBAMTClJl Y2lwaWVudHMxNjA0BgNVBAMTLXBiYWtlciAoSGFsbGFtLUJha2VyIFBoaWxsaXAsIFZlcmlTaWdu LCBJbmMuKTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtcA/okLsFi9brjmDsXQ6+g+R95B1 81Lq1EXkdzhY7XHxQ2QDq0sS2U4j9N1Ic6nHIiMq5dticztWpKdn6CrDx3Ovd5k+PACq/jSQo7NL tlMJi7fsUrP7pM4izKu4JjSak6wRJUA4x85TSC1PLfd1u8oq16iqNJRhpEJ8VJUMRyECAwEAAaOC AXgwggF0MAkGA1UdEwQCMAAwWQYDVR0fBFIwUDBOoEygSoZIaHR0cDovL29uc2l0ZWNybC52ZXJp c2lnbi5jb20vVmVyaVNpZ25JbmNFeGNoYW5nZUVtcGxveWVlcy9MYXRlc3RDUkwuY3JsMAsGA1Ud DwQEAwIFoDAeBgNVHREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4G C2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BT MGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEE BAMCB4AwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBACCK +gbdTcJB2wmWF5q8hbnP6slvVFehmjSX1Se+4Ff6a3Uiw8aOQLyNwnYUSOtHe12rTwAtWOhEgXHK D4XY3tF7cofo5hM8dk8xsj9vV3z3fYARDr4nR2bZblPJ3MGmAFAYKW4pgX4Y6NU4VhAG2Hiuj18/ H4Cc5g5oqJp5dArUMYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQOrwvJMAkGBSsOAwIa BQCgggGMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDEyNDE2 MDczNlowIwYJKoZIhvcNAQkEMRYEFOAzEvkVm4WM893rsuvCV8x+y293MFgGCSqGSIb3DQEJDzFL MEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcG BSsOAwIaMAoGCCqGSIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2Ug aXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChj KTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQO rwvJMA0GCSqGSIb3DQEBAQUABIGAIAaKCkFIJ86z3laggDWtf8o1NGZOMnOgfUJxqQSINADvkmbY o6rEia8FQyrUDESW/RgKD/5FP8+uwnBUU5NJ21yPuj6gSVYKof8VuW7S7h6LnRTliV0GOftr2I5f aWJpRomQGnZlbqs0+8Cqp5ukAUAkiXm+3GoLHAkLpkX0EYkAAAAAAAA= ------=_NextPart_000_009C_01C2C398.CCFBE220-- -- 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 Jan 30 08:13:16 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26670 for ; Thu, 30 Jan 2003 08:13:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18eEFS-0006A0-00 for namedroppers-data@psg.com; Thu, 30 Jan 2003 04:56:54 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 18eEFM-00069o-00 for namedroppers@ops.ietf.org; Thu, 30 Jan 2003 04:56:48 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25720; Thu, 30 Jan 2003 07:53:14 -0500 (EST) Message-Id: <200301301253.HAA25720@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-insensitive-00.txt Date: Thu, 30 Jan 2003 07:53:14 -0500 X-Spam-Status: No, hits=4.6 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02,TO_MALFORMED version=2.43 X-Spam-Level: **** 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 : Domain Name System (DNS) Case Insensitivity Clarification Author(s) : D. Eastlake Filename : draft-ietf-dnsext-insensitive-00.txt Pages : 8 Date : 2003-1-29 Domain Name System (DNS) names are 'case insensitive'. This document explains exactly what that means and provides a clear specification of the rules. This clarification should not have any interoperability consequences. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-insensitive-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-insensitive-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-insensitive-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: <2003-1-29154628.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-insensitive-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-insensitive-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-29154628.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 Thu Jan 30 12:36:11 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05082 for ; Thu, 30 Jan 2003 12:36:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18eISS-000CrQ-00 for namedroppers-data@psg.com; Thu, 30 Jan 2003 09:26:36 -0800 Received: from mail2.dtn.com ([207.252.127.120]) by psg.com with esmtp (Exim 3.36 #1) id 18eISP-000CrE-00 for namedroppers@ops.ietf.org; Thu, 30 Jan 2003 09:26:33 -0800 Received: from omaha.dtn.com (omaha.dtn.com [10.32.1.170]) by mail2.dtn.com (8.9.3/8.9.1) with ESMTP id LAA03506; Thu, 30 Jan 2003 11:26:30 -0600 (CST) Subject: Re: I-D ACTION:draft-ietf-dnsext-insensitive-00.txt To: Internet-Drafts@ietf.org, namedroppers@ops.ietf.org X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: From: dana@dtn.com Date: Thu, 30 Jan 2003 11:27:03 -0600 X-MIMETrack: Serialize by Router on Omaha/ENG(Release 5.0.11 |July 24, 2002) at 01/30/2003 11:26:30 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Spam-Status: No, hits=3.9 required=5.0 tests=NO_REAL_NAME,SEARCH_ENGINE_PROMO,SPAM_PHRASE_01_02 version=2.43 X-Spam-Level: *** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk "There is one additional instance of note, which relfects the general..." (pg 6 para 2 line 1 (last para of section 4)) We should probably relfect on this awhile more lest the world think we have no spell checkers. Dan Internet-Drafts@ietf .org To: IETF-Announce: ; Sent by: cc: namedroppers@ops.ietf.org owner-namedroppers@o Subject: I-D ACTION:draft-ietf-dnsext-insensitive-00.txt ps.ietf.org 01/30/2003 06:53 AM Please respond to Internet-Drafts A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Domain Name System (DNS) Case Insensitivity Clarification Author(s) : D. Eastlake Filename : draft-ietf-dnsext-insensitive-00.txt Pages : 8 Date : 2003-1-29 Domain Name System (DNS) names are 'case insensitive'. This document explains exactly what that means and provides a clear specification of the rules. This clarification should not have any interoperability consequences. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-insensitive-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-insensitive-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-insensitive-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. ftp://anonymous@ftp.ietf.org/internet-drafts/draft-ietf-dnsext-insensitive-00.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 Thu Jan 30 18:13:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12978 for ; Thu, 30 Jan 2003 18:13:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18eNgt-000PZS-00 for namedroppers-data@psg.com; Thu, 30 Jan 2003 15:01:51 -0800 Received: from netbusters.com ([207.8.219.204] helo=www.netbusters.com) by psg.com with esmtp (Exim 3.36 #1) id 18eNgn-000PY0-00 for namedroppers@ops.ietf.org; Thu, 30 Jan 2003 15:01:45 -0800 Received: by www.netbusters.com (Postfix, from userid 513) id 58A411818; Thu, 30 Jan 2003 18:01:43 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by www.netbusters.com (Postfix) with ESMTP id 55925372C; Thu, 30 Jan 2003 18:01:43 -0500 (EST) Date: Thu, 30 Jan 2003 18:01:43 -0500 (EST) From: Donald Eastlake 3rd X-X-Sender: dee3@netbusters.com To: dana@dtn.com Cc: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-insensitive-00.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.8 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SEARCH_ENGINE_PROMO,SPAM_PHRASE_01_02,TO_BE_REMOVED_REPLY, USER_AGENT_PINE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Thanks for pointing this out. I'll do a revision before San Francisco. Thanks, Donald ====================================================================== Donald E. Eastlake 3rd dee3@torque.pothole.com 155 Beaver Street +1-508-634-2066(h) +1-508-851-8280(w) Milford, MA 01757 USA Donald.Eastlake@motorola.com On Thu, 30 Jan 2003 dana@dtn.com wrote: > Date: Thu, 30 Jan 2003 11:27:03 -0600 > From: dana@dtn.com > To: Internet-Drafts@ietf.org, namedroppers@ops.ietf.org > Subject: Re: I-D ACTION:draft-ietf-dnsext-insensitive-00.txt > > "There is one additional instance of note, which relfects the general..." > (pg 6 para 2 line 1 (last para of section 4)) We should probably relfect > on this awhile more lest the world think we have no spell checkers. > > Dan > > > Internet-Drafts@ietf > .org To: IETF-Announce: ; > Sent by: cc: namedroppers@ops.ietf.org > owner-namedroppers@o Subject: I-D ACTION:draft-ietf-dnsext-insensitive-00.txt > ps.ietf.org > > > 01/30/2003 06:53 AM > Please respond to > Internet-Drafts > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the DNS Extensions Working Group of the IETF. > > Title : Domain Name System (DNS) Case > Insensitivity > Clarification > Author(s) : D. Eastlake > Filename : draft-ietf-dnsext-insensitive-00.txt > Pages : 8 > Date : 2003-1-29 > > Domain Name System (DNS) names are 'case insensitive'. This document > explains exactly what that means and provides a clear specification > of the rules. This clarification should not have any interoperability > consequences. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-insensitive-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-insensitive-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-insensitive-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. > ftp://anonymous@ftp.ietf.org/internet-drafts/draft-ietf-dnsext-insensitive-00.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: > -- 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 Jan 30 19:14:13 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14109 for ; Thu, 30 Jan 2003 19:14:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18eOgi-0002ZK-00 for namedroppers-data@psg.com; Thu, 30 Jan 2003 16:05:44 -0800 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by psg.com with esmtp (Exim 3.36 #1) id 18eOgf-0002Z7-00 for namedroppers@ops.ietf.org; Thu, 30 Jan 2003 16:05:41 -0800 Received: from ha2sca-mail1.SFBay.Sun.COM ([129.145.155.61]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA16030 for ; Thu, 30 Jan 2003 16:05:40 -0800 (PST) Received: from spin.SFBay.Sun.COM (spin [129.145.128.98]) by ha2sca-mail1.SFBay.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.1p1) with ESMTP id h0V05dY01021 for ; Thu, 30 Jan 2003 16:05:39 -0800 (PST) Received: from localhost (seligman@localhost) by spin.SFBay.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id QAA28975 for ; Thu, 30 Jan 2003 16:05:39 -0800 (PST) Message-Id: <200301310005.QAA28975@spin.SFBay.Sun.COM> To: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-insensitive-00.txt References: Date: Thu, 30 Jan 2003 16:05:39 -0800 From: Scott Seligman X-Spam-Status: No, hits=0.3 required=5.0 tests=REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >A period can also be protected from >recognition as a separator, so that it will be treated as a normal >label character, by preceeding it with a back-slash. In at least some common contexts, a backslash preceding any non-digit octet -- not just a period -- is interpreted as an escape character. This is most useful for embedding a backslash itself within a label ("ab\\cd" being the 5-octet label with a single backslash in the middle). A superfluous backslash is effectively ignored ("ab\de" represents the same label as "abde"). None of this really needs to be discussed to nail down the rules regarding case-sensitivity. But if it is going to be discussed, this should be taken into account. Scott Seligman Java Software Engineering Sun Microsystems -- 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 Jan 30 21:35:42 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16602 for ; Thu, 30 Jan 2003 21:35:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18eQva-0009Rd-00 for namedroppers-data@psg.com; Thu, 30 Jan 2003 18:29:14 -0800 Received: from netbusters.com ([207.8.219.204] helo=www.netbusters.com) by psg.com with esmtp (Exim 3.36 #1) id 18eQvY-0009RR-00 for namedroppers@ops.ietf.org; Thu, 30 Jan 2003 18:29:12 -0800 Received: by www.netbusters.com (Postfix, from userid 513) id 01CA017EB; Thu, 30 Jan 2003 21:29:11 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by www.netbusters.com (Postfix) with ESMTP id F306C372C; Thu, 30 Jan 2003 21:29:11 -0500 (EST) Date: Thu, 30 Jan 2003 21:29:11 -0500 (EST) From: Donald Eastlake 3rd X-X-Sender: dee3@netbusters.com To: Scott Seligman Cc: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-insensitive-00.txt In-Reply-To: <200301310005.QAA28975@spin.SFBay.Sun.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.0 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The question is what do DNS Master File parsers and user interfaces do? I'm not included to specify a wider applicability of \ without some re-assurance from implementers. Thanks, Donald ====================================================================== Donald E. Eastlake 3rd dee3@torque.pothole.com 155 Beaver Street +1-508-634-2066(h) +1-508-851-8280(w) Milford, MA 01757 USA Donald.Eastlake@motorola.com On Thu, 30 Jan 2003, Scott Seligman wrote: > Date: Thu, 30 Jan 2003 16:05:39 -0800 > From: Scott Seligman > To: namedroppers@ops.ietf.org > Subject: Re: I-D ACTION:draft-ietf-dnsext-insensitive-00.txt > > >A period can also be protected from > >recognition as a separator, so that it will be treated as a normal > >label character, by preceeding it with a back-slash. > > In at least some common contexts, a backslash preceding any non-digit > octet -- not just a period -- is interpreted as an escape character. > This is most useful for embedding a backslash itself within a label > ("ab\\cd" being the 5-octet label with a single backslash in the middle). > A superfluous backslash is effectively ignored ("ab\de" represents the > same label as "abde"). > > None of this really needs to be discussed to nail down the rules > regarding case-sensitivity. But if it is going to be discussed, this > should be taken into account. > > > Scott Seligman Java Software Engineering Sun Microsystems > -- 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 Jan 30 21:35:52 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16617 for ; Thu, 30 Jan 2003 21:35:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18eQzI-0009cW-00 for namedroppers-data@psg.com; Thu, 30 Jan 2003 18:33:04 -0800 Received: from kathmandu.sun.com ([192.18.98.36]) by psg.com with esmtp (Exim 3.36 #1) id 18eQzF-0009c1-00 for namedroppers@ops.ietf.org; Thu, 30 Jan 2003 18:33:01 -0800 Received: from ha2sca-mail1.SFBay.Sun.COM ([129.145.155.61]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA28506; Thu, 30 Jan 2003 19:32:59 -0700 (MST) Received: from spin.SFBay.Sun.COM (spin [129.145.128.98]) by ha2sca-mail1.SFBay.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.1p1) with ESMTP id h0V2WwY27591; Thu, 30 Jan 2003 18:32:58 -0800 (PST) Received: from localhost (seligman@localhost) by spin.SFBay.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id SAA29413; Thu, 30 Jan 2003 18:32:58 -0800 (PST) Message-Id: <200301310232.SAA29413@spin.SFBay.Sun.COM> To: Donald Eastlake 3rd cc: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-insensitive-00.txt In-reply-to: Your message of "Thu, 30 Jan 2003 21:29:11 EST." Date: Thu, 30 Jan 2003 18:32:58 -0800 From: Scott Seligman X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >> In at least some common contexts, a backslash preceding any non-digit >> octet -- not just a period -- is interpreted as an escape character. > >The question is what do DNS Master File parsers and user interfaces do? Right. That's what I'm talking about. BIND 8 for instance. Scott Seligman Java Software Engineering Sun Microsystems -- 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 Jan 30 22:00:45 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16872 for ; Thu, 30 Jan 2003 22:00:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18eRMq-000Avh-00 for namedroppers-data@psg.com; Thu, 30 Jan 2003 18:57:24 -0800 Received: from netbusters.com ([207.8.219.204] helo=www.netbusters.com) by psg.com with esmtp (Exim 3.36 #1) id 18eRMo-000AvU-00 for namedroppers@ops.ietf.org; Thu, 30 Jan 2003 18:57:22 -0800 Received: by www.netbusters.com (Postfix, from userid 513) id 2DD8B182F; Thu, 30 Jan 2003 21:57:22 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by www.netbusters.com (Postfix) with ESMTP id 2A0BC372C; Thu, 30 Jan 2003 21:57:22 -0500 (EST) Date: Thu, 30 Jan 2003 21:57:22 -0500 (EST) From: Donald Eastlake 3rd X-X-Sender: dee3@netbusters.com To: Scott Seligman Cc: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-insensitive-00.txt In-Reply-To: <200301310232.SAA29413@spin.SFBay.Sun.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.0 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk So your assertion is that every version of BIND and all versions of Microsoft DNS code and any other DNS code I'm overlooking all behave as your specify? Your original message says "some common contexts", not "all contexts" or even "all DNS Master File parsers and UIs". Thanks, Donald ====================================================================== Donald E. Eastlake 3rd dee3@torque.pothole.com 155 Beaver Street +1-508-634-2066(h) +1-508-851-8280(w) Milford, MA 01757 USA Donald.Eastlake@motorola.com On Thu, 30 Jan 2003, Scott Seligman wrote: > Date: Thu, 30 Jan 2003 18:32:58 -0800 > From: Scott Seligman > To: Donald Eastlake 3rd > Cc: namedroppers@ops.ietf.org > Subject: Re: I-D ACTION:draft-ietf-dnsext-insensitive-00.txt > > >> In at least some common contexts, a backslash preceding any non-digit > >> octet -- not just a period -- is interpreted as an escape character. > > > >The question is what do DNS Master File parsers and user interfaces do? > > Right. That's what I'm talking about. BIND 8 for instance. > > > Scott Seligman > Java Software Engineering > Sun Microsystems > -- 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 Jan 31 00:39:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19708 for ; Fri, 31 Jan 2003 00:39:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18eTiQ-000JFj-00 for namedroppers-data@psg.com; Thu, 30 Jan 2003 21:27:50 -0800 Received: from [2002:425c:4242:0:250:daff:fe82:1c39] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 18eTiO-000JFV-00 for namedroppers@ops.ietf.org; Thu, 30 Jan 2003 21:27:48 -0800 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 0342818EC for ; Fri, 31 Jan 2003 00:27:16 -0500 (EST) Date: Fri, 31 Jan 2003 00:26:30 -0500 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-insensitive-00.txt In-Reply-To: References: User-Agent: Wanderlust/2.8.1 (Something) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20030131052717.0342818EC@thrintun.hactrn.net> X-Spam-Status: No, hits=-1.0 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The "typographic convention" is decimal, not hexadecimal, and the rules for backslash are spelled out explicitly in RFC 1035: \X where X is any character other than a digit (0-9), is used to quote that character so that its special meaning does not apply. For example, "\." can be used to place a dot character in a label. \DDD where each D is a digit is the octet corresponding to the decimal number described by DDD. The resulting octet is assumed to be text and is not checked for special meaning. NB: this means that a backslash followed by one or two decimal digits is undefined, and that a backslash followed by four decimal digits parses as two encoded octets. s{bytes} {octets}g s{It is just that they are traditionally interpreted as ASCII characters} {Most applications, however, interpret them as ASCII characters} s{Historic Note} {Historical Note} s{elsewhere in the wire encoding} {elsewhere in the wire encoding of a DNS message} -- 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 Jan 31 05:35:10 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02928 for ; Fri, 31 Jan 2003 05:35:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18eYLL-0005De-00 for namedroppers-data@psg.com; Fri, 31 Jan 2003 02:24:19 -0800 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by psg.com with esmtp (Exim 3.36 #1) id 18eYLI-0005DS-00 for namedroppers@ops.ietf.org; Fri, 31 Jan 2003 02:24:16 -0800 Received: from ha2sca-mail1.SFBay.Sun.COM ([129.145.155.61]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA02368; Fri, 31 Jan 2003 02:24:13 -0800 (PST) Received: from spin.SFBay.Sun.COM (spin [129.145.128.98]) by ha2sca-mail1.SFBay.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.1p1) with ESMTP id h0VAODY19507; Fri, 31 Jan 2003 02:24:13 -0800 (PST) Received: from localhost (seligman@localhost) by spin.SFBay.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id CAA29646; Fri, 31 Jan 2003 02:24:13 -0800 (PST) Message-Id: <200301311024.CAA29646@spin.SFBay.Sun.COM> To: Donald Eastlake 3rd cc: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-insensitive-00.txt In-reply-to: Your message of "Thu, 30 Jan 2003 21:57:22 EST." Date: Fri, 31 Jan 2003 02:24:12 -0800 From: Scott Seligman X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >So your assertion is that every version of BIND and all versions of >Microsoft DNS code and any other DNS code I'm overlooking all behave as >your specify? Certainly not. I used the words "some" and "common", not "all". The paragraph purports to describe "_The_ typographic convention" (emphasis added) for labels. What it describes, however, differs from *some* common practice. If the paragraph had instead begun: "One of the possible typographic conventions" or something along those lines, that would be different. It's probably best to avoid this whole can of worms here and not mention such "typographic conventions" at all. The case sensitivity rules can be precisely specified without this. Scott Seligman Java Software Engineering Sun Microsystems -- 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 Jan 31 08:45:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06266 for ; Fri, 31 Jan 2003 08:45:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ebMf-000AVY-00 for namedroppers-data@psg.com; Fri, 31 Jan 2003 05:37:53 -0800 Received: from netbusters.com ([207.8.219.204] helo=www.netbusters.com) by psg.com with esmtp (Exim 3.36 #1) id 18ebMc-000AVM-00 for namedroppers@ops.ietf.org; Fri, 31 Jan 2003 05:37:50 -0800 Received: by www.netbusters.com (Postfix, from userid 513) id 644B717EB; Fri, 31 Jan 2003 08:37:49 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by www.netbusters.com (Postfix) with ESMTP id 62C01372C; Fri, 31 Jan 2003 08:37:49 -0500 (EST) Date: Fri, 31 Jan 2003 08:37:49 -0500 (EST) From: Donald Eastlake 3rd X-X-Sender: dee3@netbusters.com To: Scott Seligman Cc: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-insensitive-00.txt In-Reply-To: <200301311024.CAA29646@spin.SFBay.Sun.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,TO_BE_REMOVED_REPLY,USER_AGENT_PINE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The rule is included because the format of Master Files is part of the DNS standard. I'll try to take your comments into account in updating the draft...n Thanks, Donald ====================================================================== Donald E. Eastlake 3rd dee3@torque.pothole.com 155 Beaver Street +1-508-634-2066(h) +1-508-851-8280(w) Milford, MA 01757 USA Donald.Eastlake@motorola.com On Fri, 31 Jan 2003, Scott Seligman wrote: > Date: Fri, 31 Jan 2003 02:24:12 -0800 > From: Scott Seligman > To: Donald Eastlake 3rd > Cc: namedroppers@ops.ietf.org > Subject: Re: I-D ACTION:draft-ietf-dnsext-insensitive-00.txt > > >So your assertion is that every version of BIND and all versions of > >Microsoft DNS code and any other DNS code I'm overlooking all behave as > >your specify? > > Certainly not. I used the words "some" and "common", not "all". > > The paragraph purports to describe "_The_ typographic convention" > (emphasis added) for labels. What it describes, however, differs > from *some* common practice. If the paragraph had instead begun: > "One of the possible typographic conventions" or something along > those lines, that would be different. > > It's probably best to avoid this whole can of worms here and not > mention such "typographic conventions" at all. The case sensitivity > rules can be precisely specified without this. > > > Scott Seligman > Java Software Engineering > Sun Microsystems > > -- > 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 Jan 31 13:35:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14922 for ; Fri, 31 Jan 2003 13:35:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18efp6-000Md0-00 for namedroppers-data@psg.com; Fri, 31 Jan 2003 10:23:32 -0800 Received: from pheriche.sun.com ([192.18.98.34]) by psg.com with esmtp (Exim 3.36 #1) id 18efp2-000Mcn-00 for namedroppers@ops.ietf.org; Fri, 31 Jan 2003 10:23:28 -0800 Received: from ha2sca-mail1.SFBay.Sun.COM ([129.145.155.61]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA17097; Fri, 31 Jan 2003 11:23:26 -0700 (MST) Received: from spin.SFBay.Sun.COM (spin [129.145.128.98]) by ha2sca-mail1.SFBay.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.1p1) with ESMTP id h0VINQY26221; Fri, 31 Jan 2003 10:23:26 -0800 (PST) Received: from localhost (seligman@localhost) by spin.SFBay.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id KAA29812; Fri, 31 Jan 2003 10:23:26 -0800 (PST) Message-Id: <200301311823.KAA29812@spin.SFBay.Sun.COM> To: Donald Eastlake 3rd cc: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-insensitive-00.txt In-reply-to: Your message of "Fri, 31 Jan 2003 08:37:49 EST." Date: Fri, 31 Jan 2003 10:23:25 -0800 From: Scott Seligman X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >The rule is included because the format of Master Files is part of the >DNS standard. I'll try to take your comments into account in updating >the draft. You may wish to use this wording from RFC 1035 itself: \X where X is any character other than a digit (0-9), is used to quote that character so that its special meaning does not apply. For example, "\." can be used to place a dot character in a label. Scott Seligman Java Software Engineering Sun Microsystems -- 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 Jan 31 14:42:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16806 for ; Fri, 31 Jan 2003 14:42:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18egyD-0000EO-00 for namedroppers-data@psg.com; Fri, 31 Jan 2003 11:37:01 -0800 Received: from one.elistx.com ([209.116.252.130]) by psg.com with esmtp (Exim 3.36 #1) id 18egy9-0000E9-00 for namedroppers@ops.ietf.org; Fri, 31 Jan 2003 11:36:58 -0800 Received: from ogud.com (pcp816081pcs.nrockv01.md.comcast.net [68.49.60.118]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0H9L008MJFTXMD@eListX.com> for namedroppers@ops.ietf.org; Fri, 31 Jan 2003 14:37:09 -0500 (EST) Received: from ENGILL.ogud.com (gatt.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.3/8.12.3) with ESMTP id h0VJaots014371 for ; Fri, 31 Jan 2003 14:36:50 -0500 (EST envelope-from ogud@ogud.com) Date: Fri, 31 Jan 2003 14:36:24 -0500 From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: Q: Conflict between TSIG RFC and GSS-API documents X-Sender: (Unverified) To: namedroppers@ops.ietf.org Message-id: <5.1.1.6.2.20030131124656.0191dd50@localhost> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Content-type: text/plain; format=flowed; charset=us-ascii X-Spam-Status: No, hits=2.3 required=5.0 tests=QUOTED_EMAIL_TEXT,RCVD_IN_RFCI,SPAM_PHRASE_02_03 version=2.43 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk From the minutes in ATLANTA: >GSSAPI and TSIG conflict: > DNSEXT wg generated TSIG RFC > DNSEXT wg processed gssapi TSIG > just before rfc editor started 48hour period we got a report > that there was a conflict between two the documents. > TSIG specifies that TSIG can only be used if original query > contains TSIG > GSSAPI specifies that last message in TKEY exchange has TSIG > last message is empty, and this proves the key negotiated is > working from security point of view this is a good thing > > TSIG needs minor updates before advancing to draft standard: > is this extensions one of them? > >The sense of the room was that this was a reasonable extensions and the >chair is instructed to take this question to the mailing list. Does the mailing list agree with this assessment and give its consensus that the lock on the GSS-API document be lifted ? Silence will be taken as agreement. Please post objections before Feb 12'th. thanks 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 Jan 31 15:53:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18550 for ; Fri, 31 Jan 2003 15:53:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ei5H-0003xt-00 for namedroppers-data@psg.com; Fri, 31 Jan 2003 12:48:23 -0800 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 18ei5D-0003xf-00 for namedroppers@ops.ietf.org; Fri, 31 Jan 2003 12:48:19 -0800 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id h0VKmGYm066253; Fri, 31 Jan 2003 15:48:16 -0500 (EST) Received: from [192.149.252.226] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id PAA14169; Fri, 31 Jan 2003 15:48:01 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <5.1.1.6.2.20030131124656.0191dd50@localhost> References: <5.1.1.6.2.20030131124656.0191dd50@localhost> Date: Fri, 31 Jan 2003 15:47:23 -0500 To: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair From: Edward Lewis Subject: Re: Q: Conflict between TSIG RFC and GSS-API documents Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" X-Spam-Status: No, hits=-1.2 required=5.0 tests=IN_REP_TO,MIME_LONG_LINE_QP,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_01_02,TO_BE_REMOVED_REPLY version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA18550 I'm not sure that I understand the question. The base TSIG PS document proscribes behavior in conflict with the proposed GSS-API. This conflict is allegedly removed either via an improvement to the base TSIG or by restricting the GSS-API proposal. As the former (improving the TSIG base) is more desirable, all things considered, the proposal is that GSS-API is allowed to proceed unmodified and that the TSIG base is improved. If I recall correctly, the above is what I think is being said. Although I agree with that assessment, that doesn't mean that I think it is a good idea to thaw the GSS-API document. I think it should be thawed in tandem with a document that proscribes the needed improvement to the TSIG base. I.e., a document specifying an extension to TSIG's base is needed before allowing an extension that would otherwise be in conflict. Basic principle: Make sure we have a clear base. Only then attempt modifications. Failure to heed this has proven in the past to lead to unpredictable consequences ("corner cases") when composing extensions and bases. At 14:36 -0500 1/31/03, Ólafur Gudmundsson/DNSEXT co-chair wrote: >From the minutes in ATLANTA: > > >>GSSAPI and TSIG conflict: >> DNSEXT wg generated TSIG RFC >> DNSEXT wg processed gssapi TSIG >> just before rfc editor started 48hour period we got a report >> that there was a conflict between two the documents. >> TSIG specifies that TSIG can only be used if original query >> contains TSIG >> GSSAPI specifies that last message in TKEY exchange has TSIG >> last message is empty, and this proves the key negotiated is >> working from security point of view this is a good thing >> >> TSIG needs minor updates before advancing to draft standard: >> is this extensions one of them? >> >>The sense of the room was that this was a reasonable extensions and the >>chair is instructed to take this question to the mailing list. > >Does the mailing list agree with this assessment and give >its consensus that the lock on the GSS-API document be lifted ? > >Silence will be taken as agreement. > >Please post objections before Feb 12'th. > >thanks > 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: -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- 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: