From owner-namedroppers@ops.ietf.org Sun Dec 1 06:07:09 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02726 for ; Sun, 1 Dec 2002 06:07:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18IRpT-000PZ1-00 for namedroppers-data@psg.com; Sun, 01 Dec 2002 03:00:03 -0800 Received: from randy by psg.com with local (Exim 3.36 #2) id 18IRpQ-000PYZ-00 for namedroppers@ops.ietf.org; Sun, 01 Dec 2002 03:00:00 -0800 To: namedroppers@ops.ietf.org Subject: list policy Message-Id: From: Randy Bush Date: Sun, 01 Dec 2002 03:00:00 -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 namedroppersq-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 Sun Dec 1 17:49:33 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17335 for ; Sun, 1 Dec 2002 17:49:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Icio-000JPs-00 for namedroppers-data@psg.com; Sun, 01 Dec 2002 14:37:54 -0800 Received: from mx05.gis.net ([208.218.130.13] helo=gis.net) by psg.com with esmtp (Exim 3.36 #2) id 18Icil-000JPg-00 for namedroppers@ops.ietf.org; Sun, 01 Dec 2002 14:37:51 -0800 Received: from tecotoo.www.gis.net ([67.30.187.230]) by mx05.gis.net; Sun, 01 Dec 2002 17:37:48 -0500 Received: from localhost (localhost [127.0.0.1]) by tecotoo.www.gis.net (NTMail 3.02.13) with ESMTP id ra029423 for ; Sun, 1 Dec 2002 17:40:38 -0500 Message-Id: <4.3.1.2.20021201172338.0391baa0@pop.gis.net> X-Sender: mayer@pop.gis.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Sun, 01 Dec 2002 17:40:08 -0500 To: "D. J. Bernstein" , namedroppers@ops.ietf.org From: Danny Mayer Subject: Re: in support of axfr-clarify In-Reply-To: <20021130042703.23356.qmail@cr.yp.to> References: <3DE54582.1C9704ED@daimlerchrysler.com> <4.3.1.2.20021127224733.0381c580@pop.gis.net> <4.3.1.2.20021129194515.038705b0@pop.gis.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Info: NTMail 3.02 Server on TECOTOO X-Rcpt-To: X-Spam-Status: No, hits=0.5 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM, REFERENCES,SPAM_PHRASE_05_08,X_OSIRU_DUL version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 11:27 PM 11/29/02, D. J. Bernstein wrote: >Mayer claimed ``You can't clarify without breaking something.'' Is there >anyone else here who doesn't understand how ridiculous that claim is? It's not ridiculous. In this case, whatever you do will result in someone being in nonconformance with the proposed spec. >BIND company consultant Danny Mayer writes: > > I am not and never have been an employee of either ISC or Nominum. > >I apologize for the error. The fact remains that you're not disclosing >your financial interests in BIND. I have no financial interests in BIND, though I see no need to discuss my financial interests in anything, least of all to you. If I make use of BIND in the course of my employment or in pursuance of new employment, do you consider that a financial interest? > > Since it's ambiguous, people have made different interpretations of > > the spec resulting in compatibility problems. > >A typical implementation difference---whether or not it is caused by >different interpretations of the spec---does _not_ cause any failures. If you would read that sentence again, I didn't say anything about failures. What you get as a result is that two authorative servers for the same zone which use AXFR to transfer zones from one to the other can give you answers if the zone transfer is done where each server has a different implementation of the protocol based on different interpretation of the spec. >For example, some AXFR servers insert glue records everywhere they're >used, while some AXFR servers insert each glue record exactly once. >AXFR clients can handle either approach. There are no failures here. Noone said anything about failures. The discussion is about consistency. The AXFR clients, as you call them, don't get to pick and choose, it's the server that is making all of the decisions here. >Explaining that servers can repeat records, and requiring clients to >handle repetitions, would be a clarification of the protocol. It would >not cause any failures. It would save time for future implementors, and >reduce the chance of careless implementors screwing up. I'm not even sure why you are arguing about this since your idea of zone transfers use rsync, etc. Why should this even bother you? Why are you so terrified by this proposal? Danny -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Dec 1 20:17:42 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19525 for ; Sun, 1 Dec 2002 20:17:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18If3w-000OhJ-00 for namedroppers-data@psg.com; Sun, 01 Dec 2002 17:07:52 -0800 Received: from relay2.av8.net ([130.105.12.4] helo=citation.av8.net) by psg.com with esmtp (Exim 3.36 #2) id 18If3t-000Oh7-00 for namedroppers@ops.ietf.org; Sun, 01 Dec 2002 17:07:49 -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 TAA23779; Sun, 1 Dec 2002 19:59:30 -0500 Date: Sun, 1 Dec 2002 20:01:15 -0500 (EST) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: Danny Mayer cc: namedroppers@ops.ietf.org Subject: Re: in support of axfr-clarify In-Reply-To: <4.3.1.2.20021130181740.03890910@pop.gis.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.1 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,SPAM_PHRASE_02_03,USER_AGENT_PINE, X_OSIRU_SPAM_SRC version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Sat, 30 Nov 2002, Danny Mayer wrote: > The cheapest thing would be to do nothing. It is, however, not the right > thing to do. Figure out the right thing first and then you can take a > realistic view of the costs. AXFR clearly needs clarification. The cheapest thing to do is clarify AXFR so as to minimize or eliminate changes to existing software, and to minimize the introduction of interoperability problems. The "right" thing is to minimize costs, and not introduce unnecessary changes in AXFR. No one has shown yet that the changes proposed are in fact necessary. That is, they haven't shown that one can't implment IXFR with a more common implemented (but clarified) version of AXFR. > >"Right" might not be the same as "Common". But changes from common aren't > >"clarifications". "Right" depends on your point of view. > > It didn't mention the word common. I said right. Right is very rarely objective > anyway, so what's your point? That is my point: You want to do the "right" thing from your point of view. Others have different points of view. But I think the most common point of view of "right", is to minimize the impact and costs, and avoid unnecessary changes. > >I think that AXFR can be nailed down without severely impacting existing > >implementations, and I expect that IXFR can be made to work with the > >existing (and clarified) AXFR. > > That's what the document is trying to do. So far nothing that you said > discusses the document, just how "unfair" it is to djbdns. The current clarify document requires unnecessary changes, and imposes unnecessary costs, and interoperability problems in the field. I would be willing to work on an alternative clarify document. * I've re-ordered your email to separate some of the less relevant material and put it at the end. > Of course, it is relevant to point out that if BIND were a commercial > product it would cost more, in real money, to have it changed than for > djbdns to be changed. Bind made incompatible and non-standard changes. Its supporters are now trying to impose those changes on the rest of the community under the dishonest description of a "clarification". Further, I think most sites are still running some version of Bind 8. For very little cost, ISC can remove the non-standard changes. The cost expended so far by Bind will have to be considered "research" which didn't produce anything useful. C'est la Vie. > Since djbdns is apparently a non-commercial product and noone is > employed to make changes or fixes to it, it costs nothing to change and > we have therefore chosen the cheapest alternative. Nonsense. Deployment costs imposed on the user community are part of the costs to be considered. And I'm willing to concede for sake of argument (though perhaps DJB does not, and I have no authority to speak for him), that djbdns is also a commercial product, as are other implementations. The users of Bind 8 will also be forced to upgrade. As will users of Microsoft, etc. Many operating system vendors ship Bind 8 variants. They (and their users) will be forced to upgrade. In the meantime, unnecessary interoperability problems will persist. This is a very expensive operation, and it is unnecessarilly expensive. * What follows is of little relevance to namedroppers, except to support the contention that Bind is actually commercial, and the subsequent conclusion that its supporters have a commercially and competively vested interest in getting these AXFR changes through. This will be my last post on this sub-topic. > Assuming that you are in the US, you know nothing about UCC. I suggest > an introductory course in the Uniform Commercial Code before you discuss > this so knowledgably. Please point me to a site that is selling BIND on > behalf of ISC. Sigh. After being President of the LPF since 1993, and having been to the Supreme Court on copyright issues, and having worked on intellectual property issues for a long time, and having been informally educated by prominent lawyers and law professors on certain aspects of intellectual property and anti-trust law, I am still surprised that people still seem to think I know nothing about these issues. However, I'm not a lawyer and of course, I don't know everything. But I know some things. Indeed, I am reasonably familiar with UCC and UCC2. I have a copy of the UCC on my desk. As well as a Blacks law dictionary. And I have a copy of "Intellectual Property. Patents, Trademarks, and Copyright in a Nutshell" by Miller and Davis. (This is a West's Law book for Lawyers, not an O'Reilly book) What you seem not to be able to grasp is that there is a difference between being commercial and being profitable. One doesn't have to charge money in order for something to be commercial. While exchange of money may more clearly make something commercial, it is not a requirement for something to be commercial. From Blacks Law Dictionary: Commercial: "Relates to or is connected with trade and traffic or commerce in general." Commerce: (much longer): "The exchange of goods, productions, or property of any kind" You can see the contents of 37 CFR 2.33 which governs trademark practice by the PTO by going to http://www.law.cornell.edu and clicking on "Constitutions and Codes, then "Code of Federal Regulations, then Chapter 1, Part 2, then 2.33. You can see the underlying law by clicking on US Code, then going to Title 15, Chapter 22, Subchapter 1, Section 1051. Look at 1051(b)(3)(B). Bind is commercial because in the trademarking of Bind, ISC declared its _intent_ to be commercial, in order to have a well defined place in the marketplace with a protected name. These are public statements that cannot be withdrawn. Bind is therefore inextricably involved in trade, even if its trademark fails because of prior use. This could go farther afield and get into contracts but for one thing: I do not need to assert that Bind has actually been involved in commerce. ISC has demonstrated its _intent_ for Bind to be commercial. But since you seem so misinformed on the UCC, I will take up some more space in this last post on this subtopic to explain things to you: 'Actual use' in commerce would certainly be demonstrated by a contract. A contract does not need to be written and signed if it is less than $500, to fullfill the UCC Statute of Frauds requirement. A contract also needs a valid consideration, in order to be binding. That consideration need not be for money, provided it is a bargain, and involves a detriment to the parties. (See Contracts, by Emanuel Law Outlines, chapter 3). The ISC Bind license is a bargain involving the exchange of a detriment between the users of Bind and ISC for the rights to use Bind software produced by ISC. The users get to use the software, and ISC obtains acceptance of liability disclaimers, etc, which would otherwise be a detriment. The User gives up his rights to sue ISC for certain things, and agrees to give credit to ISC, amoung other things. This creates a valid consideration, which then makes the contact binding and subject to the UCC. So you see, one does not have to necessarilly accept money for contracts to be binding, and for something to be commercial. --Dean -- 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 Dec 1 22:24:40 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21550 for ; Sun, 1 Dec 2002 22:24:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Ih29-0000yv-00 for namedroppers-data@psg.com; Sun, 01 Dec 2002 19:14:09 -0800 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.36 #2) id 18Ih23-0000yC-00 for namedroppers@ops.ietf.org; Sun, 01 Dec 2002 19:14:04 -0800 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.5/8.12.5) with ESMTP id gB23D9gU034040; Mon, 2 Dec 2002 14:13:17 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200212020313.gB23D9gU034040@drugs.dv.isc.org> To: Dean Anderson Cc: Danny Mayer , namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: in support of axfr-clarify In-reply-to: Your message of "Sun, 01 Dec 2002 20:01:15 CDT." Date: Mon, 02 Dec 2002 14:13:09 +1100 X-Spam-Status: No, hits=0.5 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > On Sat, 30 Nov 2002, Danny Mayer wrote: > > > The cheapest thing would be to do nothing. It is, however, not the right > > thing to do. Figure out the right thing first and then you can take a > > realistic view of the costs. > > AXFR clearly needs clarification. The cheapest thing to do is clarify > AXFR so as to minimize or eliminate changes to existing software, and to > minimize the introduction of interoperability problems. Clarification should always be, firstly, to get the protocol to do what it is attempting to do. After that if there are multiple ways to do something you look at the implementation costs. > The "right" thing is to minimize costs, and not introduce unnecessary > changes in AXFR. No. The right thing here is to ensure that AXFR transfers the zone to all servers in the AXFR transfer graph. > No one has shown yet that the changes proposed are in > fact necessary. That is, they haven't shown that one can't implment IXFR > with a more common implemented (but clarified) version of AXFR. It's quite easy to demonstrate the need for these changes and it has been done several times. As for IXFR over broken AXFR. What is the correct behaviour of a IXFR client when it receives a delta which says to remove a record that doesn't exist due to merging of zone contents? Does it abort the IXFR and request a AXFR? Does it apply what it can and then transmit the changes to its copy of the zone. These questions don't even come up if the servers don't merge content from different sources. > > >"Right" might not be the same as "Common". But changes from common aren't > > >"clarifications". "Right" depends on your point of view. > > > > It didn't mention the word common. I said right. Right is very rarely objec > tive > > anyway, so what's your point? > > That is my point: You want to do the "right" thing from your point of > view. Others have different points of view. But I think the most common > point of view of "right", is to minimize the impact and costs, and avoid > unnecessary changes. > > > >I think that AXFR can be nailed down without severely impacting existing > > >implementations, and I expect that IXFR can be made to work with the > > >existing (and clarified) AXFR. > > > > That's what the document is trying to do. So far nothing that you said > > discusses the document, just how "unfair" it is to djbdns. > > The current clarify document requires unnecessary changes, and imposes > unnecessary costs, and interoperability problems in the field. > > I would be willing to work on an alternative clarify document. > > * I've re-ordered your email to separate some of the less relevant > material and put it at the end. > > > Of course, it is relevant to point out that if BIND were a commercial > > product it would cost more, in real money, to have it changed than for > > djbdns to be changed. > > Bind made incompatible and non-standard changes. Its supporters are now > trying to impose those changes on the rest of the community under the > dishonest description of a "clarification". Please demonstate which changes are incompatible and non-standard. > Further, I think most sites are still running some version of Bind 8. For > very little cost, ISC can remove the non-standard changes. The cost > expended so far by Bind will have to be considered "research" which > didn't produce anything useful. C'est la Vie. > > > Since djbdns is apparently a non-commercial product and noone is > > employed to make changes or fixes to it, it costs nothing to change and > > we have therefore chosen the cheapest alternative. > > Nonsense. Deployment costs imposed on the user community are part of the > costs to be considered. And I'm willing to concede for sake of argument > (though perhaps DJB does not, and I have no authority to speak for him), > that djbdns is also a commercial product, as are other implementations. > > The users of Bind 8 will also be forced to upgrade. As will users of > Microsoft, etc. Many operating system vendors ship Bind 8 variants. They > (and their users) will be forced to upgrade. In the meantime, unnecessary > interoperability problems will persist. The operating system vendors are already shifting to BIND 9. It's management is backwards compatible with BIND 8. Note there are no *forced* upgrades happening here. The pre-clarify servers will interoperate with the post-clarify servers. However the post-clarify servers can be used in configurations where most of the pre-clarify servers (those that merge data) can't. Mark > This is a very expensive operation, and it is unnecessarilly expensive. > -- 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 Sun Dec 1 22:56:30 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22718 for ; Sun, 1 Dec 2002 22:56:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18IhaX-0001eO-00 for namedroppers-data@psg.com; Sun, 01 Dec 2002 19:49:41 -0800 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.36 #2) id 18IhaT-0001eB-00 for namedroppers@ops.ietf.org; Sun, 01 Dec 2002 19:49:37 -0800 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.5/8.12.5) with ESMTP id gB23nSgU034186; Mon, 2 Dec 2002 14:49:29 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200212020349.gB23nSgU034186@drugs.dv.isc.org> To: "D. J. Bernstein" Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: axfr-clarify supporting unauthorized users In-reply-to: Your message of "30 Nov 2002 18:48:03 -0000." <20021130184803.83758.qmail@cr.yp.to> Date: Mon, 02 Dec 2002 14:49:28 +1100 X-Spam-Status: No, hits=1.3 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Have you stopped beating your wife, Mark? Dan, I demand a apology for this remark. -- 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 Sun Dec 1 23:03:32 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22870 for ; Sun, 1 Dec 2002 23:03:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Ihj2-0001rc-00 for namedroppers-data@psg.com; Sun, 01 Dec 2002 19:58:28 -0800 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.36 #2) id 18Ihiz-0001rG-00 for namedroppers@ops.ietf.org; Sun, 01 Dec 2002 19:58:26 -0800 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.5/8.12.5) with ESMTP id gB23wLgU034230; Mon, 2 Dec 2002 14:58:21 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200212020358.gB23wLgU034230@drugs.dv.isc.org> To: "D. J. Bernstein" Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: axfr-clarify supporting unauthorized users In-reply-to: Your message of "30 Nov 2002 18:48:03 -0000." <20021130184803.83758.qmail@cr.yp.to> Date: Mon, 02 Dec 2002 14:58:21 +1100 X-Spam-Status: No, hits=1.2 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_03_05, TO_BE_REMOVED_REPLY version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Mark.Andrews@isc.org writes: > > "Does your server meet RFC 1034 and return REFUSED under these conditions?" > > It is entirely up to the primary to decide who the secondaries are. RFC > 1034 imposes no constraints on this decision. A non-secondary asking for > AXFR is violating the protocol (specifically, the text that you quoted), > and has no right to a response. Dan I asked you a reasonable question with reasonable pre-conditions. This does not answer that question. > > I suspect that the DNS admistators of most ISP curse your stupid decision > > when trying to setup secondary service for one of their customers who > > is using your servers but forgot to adjust the access controls. > > Funny how nobody has ever complained about that. Whether they have complained to you or not is irrelevent. > Maybe this is because step 3 of my upgrade-from-BIND instructions tells > people to authorize zone transfers from their third-party servers. Or > maybe it's because nobody actually gives a damn whether the AXFR client > prints useless error message #1 or useless error message #2---all the > useful information is on the server side. Well if people didn't give a damn we wouldn't be having this discussion. > Next, I suppose, you're going to demand that everybody have BIND-style > promiscuous defaults, so that users who ``forgot to adjust the access > controls'' don't have to be bothered fixing their configurations. Irrelevent. > ---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: -- 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 Mon Dec 2 00:01:02 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24151 for ; Mon, 2 Dec 2002 00:01:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Iib6-0003AC-00 for namedroppers-data@psg.com; Sun, 01 Dec 2002 20:54:20 -0800 Received: from spitfire.law.miami.edu ([129.171.187.10] ident=postfix) by psg.com with esmtp (Exim 3.36 #2) id 18Iib3-0003A0-00 for namedroppers@ops.ietf.org; Sun, 01 Dec 2002 20:54:17 -0800 Received: from spitfire.law.miami.edu (localhost [127.0.0.1]) by spitfire.law.miami.edu (Postfix) with ESMTP id 77FB05C3AB6; Sun, 1 Dec 2002 23:54:16 -0500 (EST) Received: by spitfire.law.miami.edu (Postfix, from userid 1113) id 1423D5C3AB6; Sun, 1 Dec 2002 23:54:16 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by spitfire.law.miami.edu (Postfix) with ESMTP id 0B0235D3A61; Sun, 1 Dec 2002 23:54:16 -0500 (EST) Date: Sun, 1 Dec 2002 23:54:16 -0500 (EST) From: "Michael Froomkin - U.Miami School of Law" To: Danny Mayer Cc: Dean Anderson , namedroppers@ops.ietf.org Subject: TM/UCC distractions [Was Re: in support of axfr-clarify] In-Reply-To: <4.3.1.2.20021130181740.03890910@pop.gis.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_02_03,USER_AGENT_PINE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Oh dear. Trademarks. UCC. May a law professor step in? Maybe this way we can get back to the things that matter in this thread -- like what to do about a 'clarification' that I gather breaks some substantial quantity of deployed software... On Sat, 30 Nov 2002, Danny Mayer introduced the UCC to this thread as follows: [...] > > > > >An applicant for a trademark must declare that he is using, or intends to > > > >use, the mark in commerce. See 37 C.F.R. 2.33. > > > > > > Your statement does not include the word sell, for profit or otherwise. "in commerce" is different from "commercial" -- it pretty much means any course of conduct of repeated and continuous selling, trading, or shipping. Note well: "Sell" is not required; you can trademark a thing you will give away. See Planetary Motion, Inc. v. Techsplosion, Inc., 261 F.3d 1188 (11th cir. 2001), http://laws.findlaw.com/11th/0010872opn.html, which holds that an owner's distribution of software for end-users over Internet, even absent any sales thereof, was sufficient to establish trademark rights in software's name. > > > There are many non-profits in the US that have trademarks. You also Yes. some even sell things; some don't. > > > seem to be restricting yourself to the US. Are you saying that ISC > > > cannot trademark the name whereever they please? > > > >This says nothing of the sort. > > > >Non-profit is not the same as "non-commercial". The ISC uses names in > >commerce: it seeks donations, owns property, hires employees, and (if I > >recall, either offers either support or directions to Vixies consulting > >operations), and promotes the Bind, Inn, and DCHPD packages. > > > >ISC claims (rightly or wrongly) a trademark on Bind. That indicates that > >it intends to use "Bind" in commerce. Whether it makes a profit or not > >is irrelevant. Bind is a product of ISC. > > > >Whether that trademark claim is invalid (by prior public domain use by > >UCB), is irrelevant. Once ISC makes a declaration of a trademark, it > >can't later say the "product" is not commercial. > > Assuming that you are in the US, you know nothing about UCC. I suggest OK. Listen up: THIS HAS NOTHING TO DO WITH THE UCC. This is a question of Trademark law pure and simple. And under trademark law, having a trademark tells you nothing about whether the product is "commercial" -- it only says it was alleged to be "used in commerce". > an introductory course in the Uniform Commercial Code before you discuss > this so knowledgably. Please point me to a site that is selling BIND on > behalf of ISC. > See above. UCC is simply irrelevant. > Of course, it is relevant to point out that if BIND were a commercial product > it would cost more, in real money, to have it changed than for djbdns to be > changed. Since djbdns is apparently a non-commercial product and noone > is employed to make changes or fixes to it, it costs nothing to change and > we have therefore chosen the cheapest alternative. > This is absurd. The mind boggles. If this were true there would be no commercial software at all since it's always the low cost producer. -- Please visit http://www.icannwatch.org A. Michael Froomkin | Professor of Law | froomkin@law.tm U. Miami School of Law, P.O. Box 248087, Coral Gables, FL 33124 USA +1 (305) 284-4285 | +1 (305) 284-6506 (fax) | http://www.law.tm -->It's warm here.<-- -- 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 Dec 2 11:41:11 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25008 for ; Mon, 2 Dec 2002 11:41:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18ItRU-000LYi-00 for namedroppers-data@psg.com; Mon, 02 Dec 2002 08:29:08 -0800 Received: from peacock.verisign.com ([65.205.251.73]) by psg.com with esmtp (Exim 3.36 #2) id 18ItRN-000LYU-00 for namedroppers@ops.ietf.org; Mon, 02 Dec 2002 08:29:01 -0800 Received: from vhqpostal-gw2.verisign.com (verisign.com [65.205.251.56]) by peacock.verisign.com (8.12.1/) with ESMTP id gB2GSbkw026113; Mon, 2 Dec 2002 08:28:37 -0800 (PST) Received: by vhqpostal-gw2.verisign.com with Internet Mail Service (5.5.2653.19) id ; Mon, 2 Dec 2002 08:28:57 -0800 Message-ID: From: "Hallam-Baker, Phillip" Cc: ietf@ietf.org, namedroppers@ops.ietf.org, iesg@ietf.org Subject: RE: namedroppers, continued Date: Mon, 2 Dec 2002 08:28:57 -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"; boundary="----=_NextPart_000_009D_01C299EF.942BD810"; micalg=SHA1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=2.3 required=5.0 tests=EXCHANGE_SERVER,MISSING_HEADERS,MISSING_OUTLOOK_NAME, QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02,TO_BE_REMOVED_REPLY, TO_EMPTY 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_009D_01C299EF.942BD810 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit This whole discussion should be taken to the YWKTIEDNWWFALNORIBNLTICSADEWSIFOSTFSTNOML working group. (yes we know that internet email does not work well for a large number of reasons, including but not limited to, incorrect code, spam and dare we say it failure of smtp to fully support the needs of mailing lists). The only way to resolve this issue properly would be to require every submission to an IETF mailing list to be cryptographically signed (PGP or S/MIME), to require the subscribers to register their signing key and to then filter the mail sent out on the list so that only signed mail gets through. While this would require a moderate degree of work on the part of the list users it would eliminate the need for moderator action. Problem posters could be dealt with by means of a formal process. Thawte still provides free S/MIME certificates, however for the purposes of this proposal it would suffice to use a self signed certificate. SPAM is becomming a serious problem - as Bersnteins own rather offensive spam protection measures atest. The only way to resolve that problem in the long run is to start authenticating the good signal at source. The strategy of attempting to isolate the bad signal from the good is failling progressively as the spam companies employ counter measures. The relevance of this to DNS is that the ability to authenticate an SRV record provides an imense amount of leverage in automating this process. For example I can have some form of information service set up linked to the DNS that tells people that I sign every one of my emails without exception and that any unsigned mail message can be rejected. SPAM is a security problem. If we don't fix it the signal to noise ratio will fall way below acceptable levels for many users. Phill > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Saturday, November 30, 2002 8:00 AM > To: D. J. Bernstein > Cc: ietf@ietf.org; namedroppers@ops.ietf.org; iesg@ietf.org > Subject: Re: namedroppers, continued > > > [ 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 29 Nov 2002, D. J. Bernstein wrote: > > Keith claims that allowing ``contributions from outsiders'' requires > > delay and manual review. That claim is absurd. Immediately > bounce the > > message to the ``outsider,'' with instructions explaining > how to have > > the message sent to subscribers; end of problem. > > No, it's not 'end of problem'. > > If I cross-post a reply to some message with was cross-posted > to a list > I'm subscribed at and a list I'm not, in the general case I > do *not* want > to subscribe to the other list to be able to send my > cross-post reply to > both. > > Waiting for moderator approval is just fine for me, much better than > requiring to subscribe or do something else. > > It's not black and white. > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > > > > -- > 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_009D_01C299EF.942BD810 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 BQCgggGMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTIwMjE1 NDI1OFowIwYJKoZIhvcNAQkEMRYEFDAk0auL/kA60NS4XLQ/9gJOwZamMFgGCSqGSIb3DQEJDzFL MEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcG BSsOAwIaMAoGCCqGSIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2Ug aXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChj KTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQO rwvJMA0GCSqGSIb3DQEBAQUABIGAJU87Kpa+qPCDMD03dhGlCXMkCFmZqllwRGZXdRRuxvFbxSw1 YK+laYhS5HfbIVBuOIx7hs2n4ZoqhhC9fOs3BbfCRyQO3pdbTdaR5IPOu4vsN26eNE3jRaZcGGNj e9bwP99sBJViUHqOnqF19PAQcR2A2VOqAEaLYr6aOzCkztIAAAAAAAA= ------=_NextPart_000_009D_01C299EF.942BD810-- -- 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 Dec 2 12:55:24 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29070 for ; Mon, 2 Dec 2002 12:55:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Iug1-000P2X-00 for namedroppers-data@psg.com; Mon, 02 Dec 2002 09:48:13 -0800 Received: from fxodpr13.extra.daimlerchrysler.com ([129.9.82.74]) by psg.com with esmtp (Exim 3.36 #2) id 18Iufw-000P0h-00 for namedroppers@ops.ietf.org; Mon, 02 Dec 2002 09:48:08 -0800 Received: (from uucp@localhost) by fxodpr13.extra.daimlerchrysler.com (8.11.4/8.9.0) id gB2HlbU05025 for ; Mon, 2 Dec 2002 12:47:37 -0500 (EST) Received: from unknown(53.231.71.237) by fxodpr13.extra.daimlerchrysler.com via csmap (V6.0) id srcAAAxoaa0j; Mon, 2 Dec 02 12:47:37 -0500 Received: from shmrspr1-pf0.shdc.chrysler.com ([129.9.145.48]) by odconpr2-hme0.oddc.chrysler.com (Mail-Gear 2.0.0 bld 58) with SMTP id M2002120212473628876 for ; Mon, 02 Dec 2002 12:47:36 -0500 Received: from daimlerchrysler.com (wokcdts1.is.chrysler.com [53.230.102.164]) by shmrspr1-pf0.shdc.chrysler.com (8.11.2/8.11.2/daimlerchrysler-relay-1.1-kcd) with ESMTP id gB2HlWb24953 for ; Mon, 2 Dec 2002 12:47:32 -0500 (EST) Message-ID: <3DEB9C7C.BA087EF9@daimlerchrysler.com> Date: Mon, 02 Dec 2002 12:46:36 -0500 From: Kevin Darcy X-Mailer: Mozilla 4.74 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: axfr-clarify supporting unauthorized users References: <20021128222538.28764.qmail@cr.yp.to> <200211290315.gAT3FHgU023121@drugs.dv.isc.org> <20021129180339.70455.qmail@cr.yp.to> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-2.1 required=5.0 tests=EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_03_05,USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit "D. J. Bernstein" wrote: > Mark.Andrews@isc.org writes: > > > > Of course, there's also no support in RFC 1034 for your strange claim > > > that a closed connection is not ``an error.'' > > Closing a connection is not sending back a error message. > > On the contrary. I agree that FIN is, in this context, not a > particularly _informative_ error message, but REFUSED and SERVFAIL > aren't particularly informative either; they carry only marginally more > information than FIN. I'd just like to point out that, even if RCODE=REFUSED is rather non-informative *today*, at least it's more informative than TCP FIN, and also, it has room to grow to be more informative in potential revisions of the DNS protocol. Something could be put in an OPT record, for instance, detailing the error condition further, extended flags could be used, or a whole new RR type could be created dedicated to error reporting. TCP FIN forecloses such possibilities and is basically an evolutionary dead-end for the protocol. - Kevin -- 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 Dec 2 13:50:59 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02975 for ; Mon, 2 Dec 2002 13:50:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18IvWk-0001aL-00 for namedroppers-data@psg.com; Mon, 02 Dec 2002 10:42:42 -0800 Received: from [63.149.73.20] (helo=vorpal.notabug.com) by psg.com with smtp (Exim 3.36 #2) id 18IvWh-0001a9-00 for namedroppers@ops.ietf.org; Mon, 02 Dec 2002 10:42:39 -0800 Received: (qmail 10664 invoked from network); 2 Dec 2002 18:42:38 -0000 Received: from 12-249-96-16.client.attbi.com (HELO aaronsw.com) (12.249.96.16) by 0 with SMTP; 2 Dec 2002 18:42:38 -0000 Date: Mon, 2 Dec 2002 12:42:36 -0600 Subject: Re: namedroppers, continued Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: iesg@ietf.org, namedroppers@ops.ietf.org, ietf@ietf.org To: "Hallam-Baker, Phillip" From: Aaron Swartz In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) X-Spam-Status: No, hits=-3.2 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_01_02,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hallam-Baker, Phillip wrote: > The only way to resolve this issue properly would be to require every > submission to an IETF mailing list to be cryptographically signed > [and] to require the subscribers to register their signing key And how do we prevent spammers from registering their signing key? Are you suggesting that we change the IETF's open enrollment policy? -- 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 Mon Dec 2 14:14:04 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04633 for ; Mon, 2 Dec 2002 14:14:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Ivrp-0002iY-00 for namedroppers-data@psg.com; Mon, 02 Dec 2002 11:04:29 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18Ivrm-0002iI-00 for namedroppers@ops.ietf.org; Mon, 02 Dec 2002 11:04:26 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18Ivrl-000868-00 for namedroppers@ops.ietf.org; Mon, 02 Dec 2002 11:04:25 -0800 Message-ID: <021001c29a28$54b2ab80$8b876540@amer.cisco.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit From: "Stephen Sprunk" To: "Dean Anderson" , "John S. Quarterman" Cc: "D. J. Bernstein" , , , Subject: Re: trying to sweep namedroppers mismanagement under the rug Date: Mon, 2 Dec 2002 11:09:17 -0600 X-Spam-Status: No, hits=-1.0 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,RESENT_TO,SPAM_PHRASE_01_02 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. ] Thus spake "Dean Anderson" > I would agree the problem is solved if Bush adds the proper addresses to > the approved subscribers list, as publicly requested. > > But since it has taken so much discussion to arrive at that solution (and > I'm not sure we have yet), list management is clearly a problem, and has > been a chronic problem. List management is not a problem; there is a policy statement and it is followed. If individuals refuse to follow the documented process because they wish to be a martyr, that is not the IETF's or IESG's problem. If someone has a problem with the process, that needs to be directed at the IESG in a general form, not as a personal attack against a list maintainer as long as said maintainer is following the IESG's policy. S -- 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 Dec 2 14:18:42 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04996 for ; Mon, 2 Dec 2002 14:18:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Ivzv-00037o-00 for namedroppers-data@psg.com; Mon, 02 Dec 2002 11:12:51 -0800 Received: from peacock.verisign.com ([65.205.251.73]) by psg.com with esmtp (Exim 3.36 #2) id 18Ivzp-00037Z-00 for namedroppers@ops.ietf.org; Mon, 02 Dec 2002 11:12:46 -0800 Received: from vhqpostal-gw2.verisign.com (verisign.com [65.205.251.56]) by peacock.verisign.com (8.12.1/) with ESMTP id gB2JCKkw029824; Mon, 2 Dec 2002 11:12:20 -0800 (PST) Received: by vhqpostal-gw2.verisign.com with Internet Mail Service (5.5.2653.19) id ; Mon, 2 Dec 2002 11:12:40 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: Aaron Swartz , "Hallam-Baker, Phillip" Cc: iesg@ietf.org, namedroppers@ops.ietf.org, ietf@ietf.org Subject: RE: namedroppers, continued Date: Mon, 2 Dec 2002 11:12:36 -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"; boundary="----=_NextPart_000_013E_01C29A0C.D6545010"; micalg=SHA1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=1.8 required=5.0 tests=EXCHANGE_SERVER,HERBAL_VIAGRA,MISSING_OUTLOOK_NAME, QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 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_013E_01C29A0C.D6545010 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit First off, the problem of SPAM is one of the perfect being the enemy of the good. If we can cut the spam by 95% then that is a pretty useful achievement. So, no I don't think that the folk selling feather luggage, herbal viagra, p0rn etc are likely to go to that length in great numbers, unless that is the Internet as a whole adopts the same type of measure following our lead. However I have thought ahead to the issues of scale here, let us imagine that a large number of groups use the same scheme, that email agents that filter based on signatures are available and widely used. First, consider the effect of a minor authentication requirement on certificate issue, the ability to read email sent to the address specified in the certificate. Using that technique we could eliminate spams with bogus addresses which itself would be a major advance. The amount of spam that comes through with a valid email address is vanishingly small. Second consider that if the whole internet follows our lead and starts to use cryptography routinely there are a lot of additional steps that then become possible that are not practical until most people have a public key and there is a means of discovering that via a DNS linkage. Third one of the things we could do in an extended enrollment process would be to get participants to agree to the following set of terms: 1) Thou shalt not SPAM. 2) Thou shalt permit your messages to be posted in the archives. 3) Thou shalt provide timely notice of any intellectual property claims. 4) Thou shalt not take the name of the chair in vain unless she deserves it. 5) etc. Then we could sue the b*#*@#&ds if they spammed after that. People have been looking for a test case for digital signatures for ages, so don't worry about the cost. A side benefit of this is that it would cause a lot of people to start using secure email and thus start to create some critical mass for email security. What we need is for someone to take Majordomo or the like and merge in some sort of filter to check S/MIME and PGP signatures. Then find a group that wanted to serve as a guinea pig (S/MIME or PKIX perhaps?). Alternatively we should perhaps form a group 'Deployment of secure email' which could apply this rubric. Phill > -----Original Message----- > From: Aaron Swartz [mailto:me@aaronsw.com] > Sent: Monday, December 02, 2002 1:43 PM > To: Hallam-Baker, Phillip > Cc: iesg@ietf.org; namedroppers@ops.ietf.org; ietf@ietf.org > Subject: Re: namedroppers, continued > > > Hallam-Baker, Phillip wrote: > > The only way to resolve this issue properly would be to > require every > > submission to an IETF mailing list to be cryptographically signed > > [and] to require the subscribers to register their signing key > > And how do we prevent spammers from registering their signing > key? Are > you suggesting that we change the IETF's open enrollment policy? > > -- > Aaron Swartz [http://www.aaronsw.com] > ------=_NextPart_000_013E_01C29A0C.D6545010 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 BQCgggGMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTIwMjE5 MTIyNFowIwYJKoZIhvcNAQkEMRYEFOSC9o5d33M2REpsilDSkB+hBQSbMFgGCSqGSIb3DQEJDzFL MEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcG BSsOAwIaMAoGCCqGSIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2Ug aXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChj KTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQO rwvJMA0GCSqGSIb3DQEBAQUABIGABbziVqZVLx3NCiDHZ1jnmoaotpFpQ5B0HLoR92sVLfG42x4o UKjV+aS1wZwvEL2+0Cq1khkrrajt9rfSV//Hw4HBMrgFYHfEllMOrysb/djqIFE0cuAiDG7zoR+9 tLT0STddy9ZerbOGYeNAQbVYo++KNTcv+J7XZny5tnzZsocAAAAAAAA= ------=_NextPart_000_013E_01C29A0C.D6545010-- -- 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 Dec 2 15:38:57 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08856 for ; Mon, 2 Dec 2002 15:38:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18IxBt-0006uc-00 for namedroppers-data@psg.com; Mon, 02 Dec 2002 12:29:17 -0800 Received: from adsl-63-197-0-204.dsl.snfc21.pacbell.net ([63.197.0.204] helo=guava.araneus.fi) by psg.com with esmtp (Exim 3.36 #2) id 18IxBo-0006t8-00 for namedroppers@ops.ietf.org; Mon, 02 Dec 2002 12:29:13 -0800 Received: (from gson@localhost) by guava.araneus.fi (8.11.6/8.11.6) id gB2KTA620609; Mon, 2 Dec 2002 12:29:10 -0800 (PST) Date: Mon, 2 Dec 2002 12:29:10 -0800 (PST) Message-Id: <200212022029.gB2KTA620609@guava.araneus.fi> To: namedroppers@ops.ietf.org Subject: Re: in support of axfr-clarify In-Reply-To: <20021130042703.23356.qmail@cr.yp.to> References: <3DE54582.1C9704ED@daimlerchrysler.com> <4.3.1.2.20021127224733.0381c580@pop.gis.net> <4.3.1.2.20021129194515.038705b0@pop.gis.net> <20021130042703.23356.qmail@cr.yp.to> X-Mailer: VM 7.04 under Emacs 20.7.1 From: gson@nominum.com (Andreas Gustafsson) X-Spam-Status: No, hits=-1.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk D. J. Bernstein writes: > Mayer claimed ``You can't clarify without breaking something.'' Is there > anyone else here who doesn't understand how ridiculous that claim is? For the record, I also find Mayer's claim ridiculous. The axfr-clarify specification does not "break" anything - it maintains full compatibility with existing implementations. While some existing implementations don't _conform_ to the specification, all known existing implementations do _interoperate_ with conforming implementations. > For example, some AXFR servers insert glue records everywhere they're > used, while some AXFR servers insert each glue record exactly once. > AXFR clients can handle either approach. There are no failures here. > > Explaining that servers can repeat records, and requiring clients to > handle repetitions, would be a clarification of the protocol. That's what the draft says: The transmission order of all other RRs in the zone is undefined. Each of them SHOULD be transmitted only once, and slaves MUST ignore any duplicate RRs received. -- Andreas Gustafsson, gson@nominum.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Dec 2 16:49:54 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13079 for ; Mon, 2 Dec 2002 16:49:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18IyBz-0009zn-00 for namedroppers-data@psg.com; Mon, 02 Dec 2002 13:33:27 -0800 Received: from relay2.av8.net ([130.105.12.4] helo=citation.av8.net) by psg.com with esmtp (Exim 3.36 #2) id 18IyBl-0009zM-00 for namedroppers@ops.ietf.org; Mon, 02 Dec 2002 13:33:13 -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 QAA19980; Mon, 2 Dec 2002 16:25:51 -0500 Date: Mon, 2 Dec 2002 16:27:14 -0500 (EST) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: Stephen Sprunk cc: "John S. Quarterman" , "D. J. Bernstein" , , , Subject: Re: trying to sweep namedroppers mismanagement under the rug In-Reply-To: <021001c29a28$54b2ab80$8b876540@amer.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,SPAM_PHRASE_01_02,USER_AGENT_PINE, X_OSIRU_SPAM_SRC version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk If list management weren't a problem, and the policy were being followed, we wouldn't be having this discussion. I have been engaged with some people in private discussion that has illuminated some fallacies. Apparently, some people think that somehow DJB just hasn't followed instructions. And that Bush has somehow "simply misunderstood". Neither of these are the case. From a private message: > http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg02010.html > > [ In this one, Bernstein states: 'As for my own sender address > djb@cr.yp.to, Bush has already taken manual action---but what he > did was _not_ adding the address to a list of known addresses.' > Bernstein fails to mention whether he explicitly asked Bush to > do this action. Bernstein also fails to acknowledge that his > posts have been clearly marked as being from a non-subscribed > address for some time. ] This seems pretty self explanatory, and supports my point. But you left off a critical piece: "---shortly after I had informed him that I kept _that_ address private to limit the number of people who can forge unsubscription requests." Note the 'after I informed him'. Obviously, Bush and Bernstein have had private conversations on this topic, and Bernstein has asked Bush to put djb@cr.yp.to on the post list. Very clearly, IESG policy is not being followed by the list maintainer. From a private message: > Dean Anderson writes: > > The history of Bush mis-using his administrative tools to gratify his > > animosity towards certain people is well established, and is not > > irrelevant to the present situation. Bush will continue to abuse his > > priveleges, and its my opinion he should therefore be removed as > > namedroppers adminstrator. > > As I've said, I am not expressing an opinion on Bush's past behaviour, > and thus feel it is irrelevant to the current topic. How can it be irrelevant? If someone has a past history of abuse of a particular person, they can't be judged as though they have never met and have no reason to be malicious. Bush's "misunderstanding" is not accidental, but a pattern of willful harrassment. This is not a "personal attack" on Bush. I'm just stating the facts. The facts reflect badly on Bush, but that is through his own doing, or not doing. --Dean On Mon, 2 Dec 2002, Stephen Sprunk wrote: > Thus spake "Dean Anderson" > > I would agree the problem is solved if Bush adds the proper addresses to > > the approved subscribers list, as publicly requested. > > > > But since it has taken so much discussion to arrive at that solution (and > > I'm not sure we have yet), list management is clearly a problem, and has > > been a chronic problem. > > List management is not a problem; there is a policy statement and it is > followed. If individuals refuse to follow the documented process because > they wish to be a martyr, that is not the IETF's or IESG's problem. > > If someone has a problem with the process, that needs to be directed at the > IESG in a general form, not as a personal attack against a list maintainer > as long as said maintainer is following the IESG's policy. > > S > > -- 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 Dec 2 17:19:16 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14911 for ; Mon, 2 Dec 2002 17:19:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Iyii-000Bdl-00 for namedroppers-data@psg.com; Mon, 02 Dec 2002 14:07:16 -0800 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.36 #2) id 18Iyie-000BdY-00 for namedroppers@ops.ietf.org; Mon, 02 Dec 2002 14:07:13 -0800 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.5/8.12.5) with ESMTP id gB2M73gU036923; Tue, 3 Dec 2002 09:07:04 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200212022207.gB2M73gU036923@drugs.dv.isc.org> To: Kevin Darcy Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: axfr-clarify supporting unauthorized users In-reply-to: Your message of "Mon, 02 Dec 2002 12:46:36 CDT." <3DEB9C7C.BA087EF9@daimlerchrysler.com> Date: Tue, 03 Dec 2002 09:07:03 +1100 X-Spam-Status: No, hits=1.2 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_03_05, TO_BE_REMOVED_REPLY version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > "D. J. Bernstein" wrote: > > > Mark.Andrews@isc.org writes: > > > > > > Of course, there's also no support in RFC 1034 for your strange claim > > > > that a closed connection is not ``an error.'' > > > Closing a connection is not sending back a error message. > > > > On the contrary. I agree that FIN is, in this context, not a > > particularly _informative_ error message, but REFUSED and SERVFAIL > > aren't particularly informative either; they carry only marginally more > > information than FIN. > > I'd just like to point out that, even if RCODE=REFUSED is rather non-informat > ive > *today*, at least it's more informative than TCP FIN, and also, it has room t > o > grow to be more informative in potential revisions of the DNS protocol. Somet > hing > could be put in an OPT record, for instance, detailing the error condition > further, extended flags could be used, or a whole new RR type could be create > d > dedicated to error reporting. TCP FIN forecloses such possibilities and is > basically an evolutionary dead-end for the protocol. It's already happened. NOTAUTH is returned when the server is not configured for the zone rather than REFUSED from the RFC 1034 days. > > - Kevin > > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Dec 2 17:31:22 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15626 for ; Mon, 2 Dec 2002 17:31:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18IyqQ-000C70-00 for namedroppers-data@psg.com; Mon, 02 Dec 2002 14:15:14 -0800 Received: from smtp.comcast.net ([24.153.64.2]) by psg.com with esmtp (Exim 3.36 #2) id 18IyqN-000C3c-00 for namedroppers@ops.ietf.org; Mon, 02 Dec 2002 14:15:12 -0800 Received: from daimlerchrysler.com (bgp01019620bgs.sanarb01.mi.comcast.net [68.40.66.101]) by mtaout06.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0H6I005TYIZ0W3@mtaout06.icomcast.net> for namedroppers@ops.ietf.org; Mon, 02 Dec 2002 17:11:25 -0500 (EST) Date: Mon, 02 Dec 2002 17:12:51 -0500 From: Kevin Darcy Subject: Re: axfr-clarify supporting unauthorized users Cc: namedroppers@ops.ietf.org Message-id: <3DEBDAE3.80005@daimlerchrysler.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.1) Gecko/20020826 References: <200212022207.gB2M73gU036923@drugs.dv.isc.org> X-Spam-Status: No, hits=-1.3 required=5.0 tests=EMAIL_ATTRIBUTION,MISSING_HEADERS,REFERENCES, SPAM_PHRASE_03_05,USER_AGENT,USER_AGENT_MOZILLA_UA, X_ACCEPT_LANG version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Mark.Andrews@isc.org wrote: >>"D. J. Bernstein" wrote: >> >> >> >>>Mark.Andrews@isc.org writes: >>> >>> >>> >>>>>Of course, there's also no support in RFC 1034 for your strange claim >>>>>that a closed connection is not ``an error.'' >>>>> >>>>> >>>>Closing a connection is not sending back a error message. >>>> >>>> >>>On the contrary. I agree that FIN is, in this context, not a >>>particularly _informative_ error message, but REFUSED and SERVFAIL >>>aren't particularly informative either; they carry only marginally more >>>information than FIN. >>> >>> >>I'd just like to point out that, even if RCODE=REFUSED is rather non-informat >>ive >>*today*, at least it's more informative than TCP FIN, and also, it has room t >>o >>grow to be more informative in potential revisions of the DNS protocol. Somet >>hing >>could be put in an OPT record, for instance, detailing the error condition >>further, extended flags could be used, or a whole new RR type could be create >>d >>dedicated to error reporting. TCP FIN forecloses such possibilities and is >>basically an evolutionary dead-end for the protocol. >> >> > > It's already happened. NOTAUTH is returned when the server > is not configured for the zone rather than REFUSED from the > RFC 1034 days. > > Indeed. In fact, I think I was one of the ones who urged that provision several discussion rounds ago. I guess memory is the first thing to go... - Kevin -- 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 Dec 2 21:57:40 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23343 for ; Mon, 2 Dec 2002 21:57:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18J32Y-000Pac-00 for namedroppers-data@psg.com; Mon, 02 Dec 2002 18:44:02 -0800 Received: from mx05.gis.net ([208.218.130.13] helo=gis.net) by psg.com with esmtp (Exim 3.36 #2) id 18J32T-000PZz-00 for namedroppers@ops.ietf.org; Mon, 02 Dec 2002 18:43:57 -0800 Received: from tecotoo.www.gis.net ([63.214.83.227]) by mx05.gis.net; Mon, 02 Dec 2002 21:43:53 -0500 Received: from localhost (localhost [127.0.0.1]) by tecotoo.www.gis.net (NTMail 3.02.13) with ESMTP id ja029441 for ; Mon, 2 Dec 2002 21:46:58 -0500 Message-Id: <4.3.1.2.20021202211119.03829890@pop.gis.net> X-Sender: mayer@pop.gis.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 02 Dec 2002 21:46:36 -0500 To: "Michael Froomkin - U.Miami School of Law" From: Danny Mayer Subject: Re: TM/UCC distractions [Was Re: in support of axfr-clarify] Cc: Dean Anderson , namedroppers@ops.ietf.org In-Reply-To: References: <4.3.1.2.20021130181740.03890910@pop.gis.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Info: NTMail 3.02 Server on TECOTOO X-Rcpt-To: X-Spam-Status: No, hits=-0.3 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM, REFERENCES,SPAM_PHRASE_00_01,X_OSIRU_DUL version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 11:54 PM 12/1/02, Michael Froomkin - U.Miami School of Law wrote: [Note: the rest of this has been taken offline - pdm] >Maybe this way we >can get back to the things that matter in this thread -- like what to do >about a 'clarification' that I gather breaks some substantial quantity of >deployed software... No, nothing breaks per se. The disagreement, as I understand it, is which records get transferred to the requestor during an AXFR request that represents the whole zone. The subplot is what response should be given to a requestor who is not authorized to transfer the zone. > > Of course, it is relevant to point out that if BIND were a commercial > product > > it would cost more, in real money, to have it changed than for djbdns to be > > changed. Since djbdns is apparently a non-commercial product and noone > > is employed to make changes or fixes to it, it costs nothing to change and > > we have therefore chosen the cheapest alternative. > > > >This is absurd. The mind boggles. If this were true there would be no >commercial software at all since it's always the low cost producer. I'm not sure how your response relates to my comment. You are, for example, apparently using Pine as your mail client which is a free piece of software. However, most people, especially in companies use Microsoft's Outlook, which in conjunction with Microsoft Exchange, is an enormous cost, relatively speaking, for most companies. Microsoft's Windows O/S which can cost anything from $99 to $199 or more is still the most popular platform even though there are many different free versions of Unix, like FreeBSD and Linux. The cost to Microsoft to fix a bug or close a security hole and then distribute the fix is rather large, but they do it anyway. Bugs or security holes in say Linux also get fixed and distributed by the various Linux supporting organizations like Red Hat, but their visibility is much lower and I suspect, but don't know, that their associated costs are much lower. To sum this up, people buy and use according to their own perceptions, otherwise people would be buying AMD's chips rather than Intel's since their prices are lower. BIND has an enormous installed base and admins are slow to install bug fixes for security holes, never mind upgrades that fix protocol errors or changes. djbdns has a much smaller base and therefore a smaller number of admins to deal with fixes and changes. djb recommends using resync rather than AXFR, so I suspect that use of AXFR by users of djbdns is a very small number relatively speaking. So, once a change is made how many systems are really impacted, especially given that good admins regularly upgrade the software on their systems anyway? Danny -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Dec 2 22:16:27 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23753 for ; Mon, 2 Dec 2002 22:16:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18J3M8-0000hg-00 for namedroppers-data@psg.com; Mon, 02 Dec 2002 19:04:16 -0800 Received: from mx03.gis.net ([208.218.130.11] helo=gis.net) by psg.com with esmtp (Exim 3.36 #2) id 18J3Lw-0000gS-00 for namedroppers@ops.ietf.org; Mon, 02 Dec 2002 19:04:04 -0800 Received: from tecotoo.www.gis.net ([63.214.83.227]) by mx03.gis.net; Mon, 02 Dec 2002 22:04:00 -0500 Received: from localhost (localhost [127.0.0.1]) by tecotoo.www.gis.net (NTMail 3.02.13) with ESMTP id la029443 for ; Mon, 2 Dec 2002 22:07:00 -0500 Message-Id: <4.3.1.2.20021202215152.0384d320@pop.gis.net> X-Sender: mayer@pop.gis.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 02 Dec 2002 22:06:44 -0500 To: gson@nominum.com (Andreas Gustafsson), namedroppers@ops.ietf.org From: Danny Mayer Subject: Re: in support of axfr-clarify In-Reply-To: <200212022029.gB2KTA620609@guava.araneus.fi> References: <20021130042703.23356.qmail@cr.yp.to> <3DE54582.1C9704ED@daimlerchrysler.com> <4.3.1.2.20021127224733.0381c580@pop.gis.net> <4.3.1.2.20021129194515.038705b0@pop.gis.net> <20021130042703.23356.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Info: NTMail 3.02 Server on TECOTOO X-Rcpt-To: X-Spam-Status: No, hits=-0.3 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM, REFERENCES,SPAM_PHRASE_00_01,X_OSIRU_DUL version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 03:29 PM 12/2/02, Andreas Gustafsson wrote: > > Mayer claimed ``You can't clarify without breaking something.'' Is there > > anyone else here who doesn't understand how ridiculous that claim is? > >For the record, I also find Mayer's claim ridiculous. > >The axfr-clarify specification does not "break" anything - it >maintains full compatibility with existing implementations. While >some existing implementations don't _conform_ to the specification, >all known existing implementations do _interoperate_ with conforming >implementations. To clarify myself, I phrased this badly. I should have said that a server that previously conformed to RFC's based on their being multiple possible interpretations of those RFC's may be non-compliant with this draft and would need to be changed in order to be compliant. Breaking was a badly chosen word. The other part of this question is this: If you have two servers, one a master and the other the slave for a specific zone and the slave uses AXFR to transfer the zone from the master, can the slave ever give different answers to queries than what the master would respond as a result of the received zone? If the answer is yes, something is wrong since you should get the same answer no matter which authorative server you ask. That's what I meant by broken. Does that make more sense? Danny -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Dec 3 05:47:20 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14147 for ; Tue, 3 Dec 2002 05:47:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JAPW-000L4g-00 for namedroppers-data@psg.com; Tue, 03 Dec 2002 02:36:14 -0800 Received: from host1.btamail.net.cn ([202.106.196.71] helo=btmail.net.cn) by psg.com with smtp (Exim 3.36 #2) id 18JAPS-000L4U-00 for namedroppers@ops.ietf.org; Tue, 03 Dec 2002 02:36:11 -0800 Received: from btmail.net.cn([202.106.196.73]) by btamail.net.cn(JetMail 2.5.3.0) with SMTP id jmc3decdefe; Tue, 3 Dec 2002 10:36:05 -0000 Received: from loki.ietf.org([132.151.1.177]) by btamail.net.cn(JetMail 2.5.3.0) with SMTP id jm163de7b6bd; Fri, 29 Nov 2002 16:31:03 -0000 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id KAA22576 for ietf-outbound.01@loki.ietf.org; Fri, 29 Nov 2002 10:37:00 -0500 (EST) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id KAA22475 for ; Fri, 29 Nov 2002 10:27:43 -0500 (EST) Received: by ietf.org (8.9.1a/8.9.1a) id KAA01417 for ietf-mainout@loki.ietf.org; Fri, 29 Nov 2002 10:24:57 -0500 (EST) X-Authentication-Warning: ietf.org: majordom set sender to owner-ietf@ietf.org using -f Received: from ogud.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01413; Fri, 29 Nov 2002 10:24:54 -0500 (EST) Received: from localhost (ogud@localhost) by ogud.com (8.11.6/8.11.6) with ESMTP id gATFRPm04360; Fri, 29 Nov 2002 10:27:25 -0500 (EST) (envelope-from ogud@ogud.com) Date: Fri, 29 Nov 2002 10:27:25 -0500 (EST) From: Olafur Gudmundsson X-X-Sender: ogud@hlid.dc.ogud.com To: Dean Anderson cc: "D. J. Bernstein" , , , DNSEXT mailing list Subject: Re: namedroppers mismanagement, continued In-Reply-To: Message-ID: <20021129100605.T4318-100000@hlid.dc.ogud.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Loop: ietf@ietf.org X-Spam-Status: No, hits=-2.8 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_02_03,X_AUTH_WARNING,X_LOOP version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 27 Nov 2002, Dean Anderson wrote: > I am not on the ietf or iesg list. I don't know if this will go through to > those lists. > > While DJB may also have some subscription issue, that is not the > fundamental problem. > > It seems from your comments below, that you think that Randy isn't > manually blocking/forwarding messages from subscribed addresses. However, > that it not true. As of early this year the policy of the list was changed from "moderation" to "subscriber automated posting". Bringing up ancient history is not productive as that issue has been addressed. Randy is currently wasting valuable time in manually scanning 100+ spams a day that are sent to namedroppers and other IETF mailing lists he runs and we all should thank him for the good citizen service he provides! Every meesage that is reposted from the bounced list contains a header explaining that posting address is not a subscribed address. I agree that the feature to get a message back saying that a message is waiting for manual moderation is good, it requires effort for the list operator to set up. In my personal case I get few of these messages each month in response to viral attempts to post messages as me on random mailing lists. > > The real problem is that Randy sometimes don't post messages from people > he doesn't like or on topics he has an interest in, even when they are > posted from subscribed addresses. This has happened to me several times. > One of the occasions where it happened to me is documented on Bernstein's > web page. It has probably happened many more times that haven't made it > on DJB's webpage. Ancient history. > > There seems to be no reason that Randy should set himself up as a > moderator, or any reason whatsoever there should be any manual > intervention on posting from subscribed addresses. Do you agree? Yes, this is the CURRENT list policy. Thus the only messages that are affected are from non subscribers and people posting from different address. In response the some points raised in this thread two changes will happen: - Montly namedroppers list policy message will contain statement on the posting policy. - Moderated messages will contain more informative instructions on how to avoid moderation. Olafur (DNSEXT co-chair) -- 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 Dec 3 08:07:11 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17673 for ; Tue, 3 Dec 2002 08:07:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JCfy-000Pr0-00 for namedroppers-data@psg.com; Tue, 03 Dec 2002 05:01:22 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #2) id 18JCfv-000Pqo-00 for namedroppers@ops.ietf.org; Tue, 03 Dec 2002 05:01:19 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16780; Tue, 3 Dec 2002 07:58:28 -0500 (EST) Message-Id: <200212031258.HAA16780@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-axfr-clarify-05.txt Date: Tue, 03 Dec 2002 07:58:28 -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 : DNS Zone Transfer Protocol Clarifications Author(s) : A. Gustafsson Filename : draft-ietf-dnsext-axfr-clarify-05.txt Pages : 7 Date : 2002-12-2 In the Domain Name System, zone data is replicated among authoritative DNS servers by means of the 'zone transfer' protocol, also known as the 'AXFR' protocol. This memo clarifies, updates, and adds missing detail to the original AXFR protocol specification in RFC1034. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-axfr-clarify-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-axfr-clarify-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-axfr-clarify-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: <2002-12-2135558.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-axfr-clarify-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-axfr-clarify-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-12-2135558.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 Dec 3 09:00:20 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20392 for ; Tue, 3 Dec 2002 09:00:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JDWC-00021x-00 for namedroppers-data@psg.com; Tue, 03 Dec 2002 05:55:20 -0800 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.36 #2) id 18JDW9-0001zK-00 for namedroppers@ops.ietf.org; Tue, 03 Dec 2002 05:55:17 -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 gB3Dsk8V020320; Tue, 3 Dec 2002 14:54:46 +0100 Date: Tue, 3 Dec 2002 14:54:46 +0100 From: "Olaf M. Kolkman" To: namedroppers@ops.ietf.org Cc: Johan Ihren Subject: Dropping denial of existence of wildcard Message-Id: <20021203145446.216891c4.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_02_03 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The wildcard optimization draft was written under the assumption that denial of existence of a match covered by a wildcard is needed. (see 2.7 of the dns-threats draft). As we are editing the wildcard-optimization draft we would like to have feedback on the following. Why not simplify the protocol and implementation by dropping denial of existence of wildcards? We realize we stir the pot with this question so let us elaborate. Having to denial the existence of a (closer) match to a wildcard brings a lot of complications. It is not only computationally expensive but also complex and error prone (The first implementations did not do it correctly. We worry that without proper documentation of the algorithm both servers and verifying resolvers will do things wrong). The threats model does not document why denial of existence of wildcards is needed ("in order to provide the desired services" does not specify 'desired'). What if we threw out a lot of complicated code and possible troubleshooting headache at the cost of loosing the authenticated denial of a (closer) matching wildcard? One would be vulnerable to the following attack vectors: 1. A NXDOMAIN could be spoofed for names for which a wildcard expansion is possible 2. A match to a wildcard can be replaced with a less closer matching wildcard. In our opinion the second attack is the most worrying one; verifiable data but wrong data is returned. On the other hand in most cases where there are multiple wildcards in a zone it is because there is a name in the zone that cancels the generic match and both wildcard point to the same data. e.g example MX generic_mailhost *.example MX generic_mailhost a.example MX specific_mailhost *.a.example MX generic_mailhost Besides if one wants to be secured that mail to a given host is being delivered than one can always configure that hosts MX record. It's more trivial to write a tool for that than having to troubleshoot why one of your clients get a SERVFAIL on one of your signed zones. The first kind of attack is a DOS type of attack. It can also be circumvented by hard configuring the mailhosts for your important services. (We use MX/mailhosts in our example but the arguments apply to general usage) So far the possible attack vectors. We would like to hear the WG's opinion on the idea to drop denial of existence of wildcards. If we do not drop the denial of existence I think it is vital for proper deployment of DNSSEC that somebody publishes the algorithm to deliver and verify proof of non-existence of (closer) matching wildcards. Preferably with a correctness proof of that algorithm. Olaf Kolkman and Johan Ihren. --------------------------------------------| 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 Tue Dec 3 10:45:00 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27540 for ; Tue, 3 Dec 2002 10:45:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JEwF-0006EX-00 for namedroppers-data@psg.com; Tue, 03 Dec 2002 07:26:19 -0800 Received: from portal.hamachi.org ([140.239.227.17]) by psg.com with esmtp (Exim 3.36 #2) id 18JEwA-0006Dn-00 for namedroppers@ops.ietf.org; Tue, 03 Dec 2002 07:26:15 -0800 Received: from syn.hamachi.org (localhost [127.0.0.1]) by portal.hamachi.org (Postfix) with ESMTP id 44D7617926; Tue, 3 Dec 2002 10:22:10 -0500 (EST) Received: from syn.hamachi.org (sommerfeld@localhost) by syn.hamachi.org (8.11.6/8.8.8) with ESMTP id gB3FNwk10977; Tue, 3 Dec 2002 10:23:59 -0500 (EST) Message-Id: <200212031523.gB3FNwk10977@syn.hamachi.org> From: Bill Sommerfeld To: "Olaf M. Kolkman" Cc: namedroppers@ops.ietf.org, Johan Ihren Subject: Re: Dropping denial of existence of wildcard In-Reply-To: Message from "Olaf M. Kolkman" of "Tue, 03 Dec 2002 14:54:46 +0100." <20021203145446.216891c4.olaf@ripe.net> Reply-To: sommerfeld@orchard.arlington.ma.us Date: Tue, 03 Dec 2002 10:23:51 -0500 X-Spam-Status: No, hits=0.1 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_3,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > 1. A NXDOMAIN could be spoofed for names for which a wildcard > expansion is possible One consequence of this case is that if the resolver is walking down a search path, a spoofed NXDOMAIN may result in unexpected behavior (falling back to second-choice names). This particular case seems pretty implausible -- if I knew that *.example.com existed I'd likely not put example.com anywhere but the last spot in the search path. Seems slightly less implausible if the search involves a multi-label name.. for example, looking up "a.b" with a search path including example.com and example.net in that order; if *.b.example.com exists but a NXDOMAIN is spoofed it may unexpectedly fall back to resolving a.b.example.net Also, what about the case where a.b.example.com exists but doesn't have an RR of the appropriate type, but there's a covering wildcard with that RR type? - Bill -- 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 Dec 3 10:58:05 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28807 for ; Tue, 3 Dec 2002 10:58:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JFK1-0007SI-00 for namedroppers-data@psg.com; Tue, 03 Dec 2002 07:50:53 -0800 Received: from fxodpr13.extra.daimlerchrysler.com ([129.9.82.74]) by psg.com with esmtp (Exim 3.36 #2) id 18JFJs-0007Ru-00 for namedroppers@ops.ietf.org; Tue, 03 Dec 2002 07:50:45 -0800 Received: (from uucp@localhost) by fxodpr13.extra.daimlerchrysler.com (8.11.4/8.9.0) id gB3FobF02634 for ; Tue, 3 Dec 2002 10:50:37 -0500 (EST) Received: from unknown(53.231.71.237) by fxodpr13.extra.daimlerchrysler.com via csmap (V6.0) id srcAAAwiaijf; Tue, 3 Dec 02 10:50:37 -0500 Received: from shmrspr1-pf0.shdc.chrysler.com ([129.9.145.48]) by odconpr2-hme0.oddc.chrysler.com (Mail-Gear 2.0.0 bld 58) with SMTP id M2002120310503627591 for ; Tue, 03 Dec 2002 10:50:36 -0500 Received: from daimlerchrysler.com (wokcdts1.is.chrysler.com [53.230.102.164]) by shmrspr1-pf0.shdc.chrysler.com (8.11.2/8.11.2/daimlerchrysler-relay-1.1-kcd) with ESMTP id gB3FoWb16522 for ; Tue, 3 Dec 2002 10:50:32 -0500 (EST) Message-ID: <3DECD28F.5A2B4AA8@daimlerchrysler.com> Date: Tue, 03 Dec 2002 10:49:35 -0500 From: Kevin Darcy X-Mailer: Mozilla 4.74 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: TM/UCC distractions [Was Re: in support of axfr-clarify] References: <4.3.1.2.20021130181740.03890910@pop.gis.net> <4.3.1.2.20021202211119.03829890@pop.gis.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-2.0 required=5.0 tests=EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,TO_BE_REMOVED_REPLY, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Look, people, I'm sure you're all dying to impress us with your respective stores of knowledge about various aspects of the law, but there's no reason for this discussion to disappear down a rathole of legalism. When DJB uses the term "BIND company employee" his plain implication is to assign some sort of ulterior profit motive to the referenced individual. It's basically just a childish _ad_hominem_, and a ludicrous one at that, since even if BIND is in some limited, technical legal context "commercial", "in commerce", "a commercial product" or whatever, the simple fact is that BIND (like djbdns) is given away free, and thus there is no discernible, provable profit motive involved. Or, if DJB has such proof, let him present it. Merely waving legalisms around doesn't prove intent or motive, or detract from anyone's arguments for or against any particular IETF document. - Kevin Danny Mayer wrote: > At 11:54 PM 12/1/02, Michael Froomkin - U.Miami School of Law wrote: > [Note: the rest of this has been taken offline - pdm] > >Maybe this way we > >can get back to the things that matter in this thread -- like what to do > >about a 'clarification' that I gather breaks some substantial quantity of > >deployed software... > > No, nothing breaks per se. The disagreement, as I understand it, is > which records get transferred to the requestor during an AXFR request > that represents the whole zone. The subplot is what response should > be given to a requestor who is not authorized to transfer the zone. > > > > Of course, it is relevant to point out that if BIND were a commercial > > product > > > it would cost more, in real money, to have it changed than for djbdns to be > > > changed. Since djbdns is apparently a non-commercial product and noone > > > is employed to make changes or fixes to it, it costs nothing to change and > > > we have therefore chosen the cheapest alternative. > > > > > > >This is absurd. The mind boggles. If this were true there would be no > >commercial software at all since it's always the low cost producer. > > I'm not sure how your response relates to my comment. You are, for > example, apparently using Pine as your mail client which is a free piece > of software. However, most people, especially in companies use Microsoft's > Outlook, which in conjunction with Microsoft Exchange, is an enormous > cost, relatively speaking, for most companies. Microsoft's Windows O/S > which can cost anything from $99 to $199 or more is still the most popular > platform even though there are many different free versions of Unix, like > FreeBSD and Linux. The cost to Microsoft to fix a bug or close a security > hole and then distribute the fix is rather large, but they do it anyway. Bugs > or security holes in say Linux also get fixed and distributed by the various > Linux supporting organizations like Red Hat, but their visibility is much lower > and I suspect, but don't know, that their associated costs are much lower. > > To sum this up, people buy and use according to their own perceptions, > otherwise people would be buying AMD's chips rather than Intel's since > their prices are lower. BIND has an enormous installed base and admins > are slow to install bug fixes for security holes, never mind upgrades that > fix protocol errors or changes. djbdns has a much smaller base and therefore > a smaller number of admins to deal with fixes and changes. djb recommends > using resync rather than AXFR, so I suspect that use of AXFR by users > of djbdns is a very small number relatively speaking. So, once a change > is made how many systems are really impacted, especially given that > good admins regularly upgrade the software on their systems anyway? > > Danny > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- 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 Dec 3 12:09:15 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03433 for ; Tue, 3 Dec 2002 12:09:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JG7A-000A7x-00 for namedroppers-data@psg.com; Tue, 03 Dec 2002 08:41:40 -0800 Received: from fxshpr08.extra.daimlerchrysler.com ([129.9.80.165] helo=fxshpr06.extra.daimlerchrysler.com) by psg.com with esmtp (Exim 3.36 #2) id 18JG73-000A7k-00 for namedroppers@ops.ietf.org; Tue, 03 Dec 2002 08:41:33 -0800 Received: (from uucp@localhost) by fxshpr06.extra.daimlerchrysler.com (8.11.4/8.9.0) id gB3GenX05169 for ; Tue, 3 Dec 2002 11:40:49 -0500 (EST) Received: from nodnsquery(129.9.147.104) by fxshpr08.extra.daimlerchrysler.com via csmap (V6.0) id srcAAAXGaagk; Tue, 3 Dec 02 11:40:49 -0500 Received: from shmrspr1-pf0.shdc.chrysler.com ([129.9.145.48]) by shconpr2-hme0.shdc.chrysler.com (Mail-Gear 2.0.0 bld 58) with SMTP id M2002120311413122691 for ; Tue, 03 Dec 2002 11:41:31 -0500 Received: from daimlerchrysler.com (wokcdts1.is.chrysler.com [53.230.102.164]) by shmrspr1-pf0.shdc.chrysler.com (8.11.2/8.11.2/daimlerchrysler-relay-1.1-kcd) with ESMTP id gB3GfQb29184 for ; Tue, 3 Dec 2002 11:41:26 -0500 (EST) Message-ID: <3DECDE7E.EB63EDE9@daimlerchrysler.com> Date: Tue, 03 Dec 2002 11:40:30 -0500 From: Kevin Darcy X-Mailer: Mozilla 4.74 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: in support of axfr-clarify References: <20021127174104.41801.qmail@cr.yp.to> <3DE52984.219E825A@daimlerchrysler.com> <20021128002526.68429.qmail@cr.yp.to> <3DE577C4.4FAA2846@daimlerchrysler.com> <20021128114055.87612.qmail@cr.yp.to> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-2.4 required=5.0 tests=EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit "D. J. Bernstein" wrote: > [ post by non-subscriber. with the massive amount of spam, it is easy to > miss and therefore delete mis-posts. your subscription address is > 54830374684695-namedroppers@sublist.cr.yp.to, please post from it or > fix subscription your subscription address! ] > > Kevin Darcy writes: > > You're only reinforcing the need for a Clarify draft. > > I've been saying for years that the DNS specifications are horribly > inadequate. I thought axfr-clarify sounded like a great idea until I > read the document and discovered twelve problems. Two of those problems > have now been fixed; ten more to go. > > > an implicit assumption -- that non-Answer sections of an AXFR response > > would never be used productively -- which turned out to be false > > because of things like EDNS0 and TSIG. > > These issues have been discussed before. First, contrary to your claim, > there is no evidence of an actual problem. Second, and more importantly, > if an optional protocol extension fails to ensure compatibility with the > previous protocol, that is entirely the extension's fault. Well, no, not really. My understanding is that any protocol extension may alter the base protocol as long as the extension itself is on Standards Track. In this case, it's rather a moot point anyway, since AXFR was underspecified originally (we all agreed on that, right?), so it's not clear whether TSIG, EDNS0, etc. actually broke anything vis-a-vis their potential applicability to AXFR transactions. You can't "break" something that wasn't specified in the first place. > As I wrote when we last discussed this in July 2001, after you asked why > I wasn't changing my code: > > The benefits are nonexistent. The harms include encouraging further > disregard for compatibility. What stops incompetent implementors from > demanding another code change every week? Ignore AXFR AR, discard > TKEY, ignore types 128-255, recognize IXFR, ignore MS garbage. This > is not a sane way to handle optional protocol extensions. > > Is compatibility such a difficult concept to grasp? Just because you don't find any use for TSIG, EDNS0, doesn't mean that other people don't. Yes, I find compatibility-as-a-concept easy to grasp, but what I fail to understand is why you think *your* compatibility trumps everyone else's. I want to (and do) use TSIG-signed zone transfers. Do you think this is or should be a "proprietary" mechanism? As your code stands today, would it break your AXFR client to receive one? axfr-clarify confers the blessing of IETF standards on TSIG-signed zone transfers, among other extensions, while at the same time ensuring that implementations which don't understand or don't support these extensions aren't hurt if some day they receive one. And the only cost we (collectively) pay for these benefits is that *one* implementation (yours) has to make a relatively small code change that didn't demonstrably help anyone in the first place. - Kevin -- 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 Dec 3 13:21:29 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07739 for ; Tue, 3 Dec 2002 13:21:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JHF0-000Dmo-00 for namedroppers-data@psg.com; Tue, 03 Dec 2002 09:53:50 -0800 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #2) id 18JHEV-000Dk5-00 for namedroppers@ops.ietf.org; Tue, 03 Dec 2002 09:53: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 gB3HrIYm068829; Tue, 3 Dec 2002 12:53:18 -0500 (EST) Received: from [192.149.252.235] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id MAA18588; Tue, 3 Dec 2002 12:53:15 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <200212031523.gB3FNwk10977@syn.hamachi.org> References: <200212031523.gB3FNwk10977@syn.hamachi.org> Date: Tue, 3 Dec 2002 12:53:42 -0500 To: sommerfeld@orchard.arlington.ma.us From: Edward Lewis Subject: partial answer Re: Dropping denial of existence of wildcard Cc: namedroppers@ops.ietf.org 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 10:23 -0500 12/3/02, Bill Sommerfeld wrote: >Also, what about the case where a.b.example.com exists but doesn't >have an RR of the appropriate type, but there's a covering wildcard >with that RR type? The premise of the algorithm (in RFC 1034) is that first you look for a domain name (match the QNAME). From that either you find a match, you fall back to a wild card, or NXDOMAIN. If you match at the specific name, you forget the others. If the RR set you seek is not at the specific name, you return "no data" and do not look for a wild card entry. Another way to think of this is that the wild card matching is done at domain name granularity, not RR set granularity. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Dec 3 16:20:36 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19240 for ; Tue, 3 Dec 2002 16:20:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JKGU-0001de-00 for namedroppers-data@psg.com; Tue, 03 Dec 2002 13:07:34 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18JKGR-0001dJ-00 for namedroppers@ops.ietf.org; Tue, 03 Dec 2002 13:07:31 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18JKGQ-00094l-00 for namedroppers@ops.ietf.org; Tue, 03 Dec 2002 13:07:31 -0800 Message-ID: <20021203081311.83986.qmail@cr.yp.to> References: <20021130042703.23356.qmail@cr.yp.to> <3DE54582.1C9704ED@daimlerchrysler.com> <4.3.1.2.20021127224733.0381c580@pop.gis.net> <4.3.1.2.20021129194515.038705b0@pop.gis.net> <20021130042703.23356.qmail@cr.yp.to> <4.3.1.2.20021202215152.0384d320@pop.gis.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Date: 3 Dec 2002 08:13:11 -0000 Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: elementary DNS facts X-Spam-Status: No, hits=-1.0 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,RESENT_TO,SPAM_PHRASE_01_02 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. your subscription address is 54830374684695-namedroppers@sublist.cr.yp.to, please post from it or, 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 the alternate address added to the list of addresses from which submissions are automatically accepted. ] Danny Mayer writes: > If you have two servers, one a master and the other the slave for a > specific zone and the slave uses AXFR to transfer the zone from the > master, can the slave ever give different answers to queries than what > the master would respond as a result of the received zone? Yes, of course. Suppose the server is also a slave for a child zone from another master. If there's an inconsistency between the two masters, it's obviously impossible to simultaneously (1) match what the parent zone master says and (2) match what the child zone master says. It's possible to match both for AXFR requests, as axfr-clarify demands, but it's simply impossible to match both for normal queries, because queries don't name zones. Matching is not part of the DNS protocol. (See my message <20021124091420.47876.qmail@cr.yp.to> for an analysis of what the protocol says about these inconsistencies.) > If the answer is yes, something is wrong since you should get the same > answer no matter which authorative server you ask. That's what I meant > by broken. You are fundamentally confused about how DNS works. See above. ---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 Tue Dec 3 16:24:16 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19541 for ; Tue, 3 Dec 2002 16:24:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JKN1-00027f-00 for namedroppers-data@psg.com; Tue, 03 Dec 2002 13:14:19 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18JKMy-00027E-00 for namedroppers@ops.ietf.org; Tue, 03 Dec 2002 13:14:16 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18JKMx-00095s-00 for namedroppers@ops.ietf.org; Tue, 03 Dec 2002 13:14:16 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200212031023.gB3ANGhZ015824@mailserver4.hushmail.com> Date: Tue, 3 Dec 2002 02:23:15 -0800 To: namedroppers@ops.ietf.org Subject: Re: TM/UCC distractions [Was Re: in support of axfr-clarify] From: ahaukin@hushmail.com X-Spam-Status: No, hits=2.9 required=5.0 tests=CASHCASHCASH,LINES_OF_YELLING,NO_REAL_NAME,PGP_SIGNATURE, QUOTED_EMAIL_TEXT,RESENT_TO,SPAM_PHRASE_03_05, SUPERLONG_LINE version=2.43 X-Spam-Level: ** 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. ] -----BEGIN PGP SIGNED MESSAGE----- Danny Mayer wrote:- > So, once a change is made how many systems are really impacted, > especially given that good admins regularly upgrade the software > on their systems anyway? I work for a bank. We have a very high level of risk-aversion, which extends to not upgrading software and operating systems unless mission critical -- upgrades which others might consider routine. We ditched BIND (at least on internet facing systems) because of the difficulties of running a secure version of it in production that had also passed through the painfully slow testing and change control process here. >From our perspective good admins run software that doesn't need upgrading regularly. Ahau K'in -----BEGIN PGP SIGNATURE----- Version: Hush 2.2 (Java) Note: This signature can be verified at https://www.hushtools.com/verify wlwEARECABwFAj3shhAVHGFoYXVraW5AaHVzaG1haWwuY29tAAoJEOxf2AiMt61hM7AA n14afoc/pqA7hEU8yQFM8fmatal/AJ9OLY+71/PS3UiKo6vRUEoAAg50mA== =ZjPC -----END PGP SIGNATURE----- Concerned about your privacy? Follow this link to get FREE encrypted email: https://www.hushmail.com/?l=2 Big $$$ to be made with the HushMail Affiliate Program: https://www.hushmail.com/about.php?subloc=affiliate&l=427 -- 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 Dec 3 16:40:58 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20134 for ; Tue, 3 Dec 2002 16:40:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JKb6-0003Jt-00 for namedroppers-data@psg.com; Tue, 03 Dec 2002 13:28:52 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18JKay-0003JA-00 for namedroppers@ops.ietf.org; Tue, 03 Dec 2002 13:28:44 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18JKax-00098y-00 for namedroppers@ops.ietf.org; Tue, 03 Dec 2002 13:28:43 -0800 Message-ID: <3DECC24E.D9ADF206@quadritek.com> MIME-Version: 1.0 References: <5.1.1.6.2.20021114134710.0158ffa8@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 03 Dec 2002 09:40:14 -0500 From: randyhall@lucent.com (Randy Hall) To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: TKEY Renewal Mode-02 X-Spam-Status: No, hits=-1.0 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,RESENT_TO,SPAM_PHRASE_01_02 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. ] > This is the beginning of a 3 week working group last call. > This last call ends on December 6'th. > > This document updates RFC2930 to allow atomic updating of TKEY > secrets. This document defines a new mode for each algorithm > supported, and how the "key rollover" takes place. > > This document is on standards track and is available via following > URL: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-tkey-renewal-mode-02.txt I have two comments on this draft. I don't feel this protocol should advanced as written. 1) Quoting from section 2.2: > Server which has received queries signed with the partially revoked > key MUST NOT answer them except when they are Renewal requests (See > section 2.3.) or "key adoption" requests (See section 2.4.). Instead, > it returns TSIG error messages whose error codes are "PartialRevoke" > (See section 9.) I feel the server should accept a TKEY delete query (TKEY mode 5) which is signed with a partially revoked key. The wording above (and in section 9), shuts the door on this possibility, at least the way I have read it (perhaps it just needs a clarification, or an explanation for this decision). As an aside, it occurs to me that the protocol seems unnecessarily complex. Based on implementation experience, a cleaner approach may be -- a) server partially revokes key and sends appropriate rcode in response to messages signed with that key b) client sends a tkey delete request signed with that key and server deletes key c) client and server establish brand new secret using tkey Which approach is better is a matter to think about, but unless there is a downside to allowing a tkey delete request to be signed with a partially revoked key (and I can't think of one off the top of my head, since deleting a key can be construed as part of a mechanism of using RFC 2930 to renew the key), then it would be nice if the protocol didn't preclude this possibility -- and allowing it would certainly improve at least on deployed implementation -- which currently has a hokey client side management of "is this key about to expire" logic. 2) Just a minor thing -- I think section 1.3 would be clearer if paragraph 3 mentioned that the messages in the key renewal procedure are (or can be?) signed with the partially revoked key (I realise this is mentioned later, but it was my first question as I was reading it ...) Cheers 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 Dec 3 17:00:41 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21208 for ; Tue, 3 Dec 2002 17:00:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JL0p-0005AD-00 for namedroppers-data@psg.com; Tue, 03 Dec 2002 13:55:27 -0800 Received: from fxodpr13.extra.daimlerchrysler.com ([129.9.82.74]) by psg.com with esmtp (Exim 3.36 #2) id 18JL0n-00057b-00 for namedroppers@ops.ietf.org; Tue, 03 Dec 2002 13:55:25 -0800 Received: (from uucp@localhost) by fxodpr13.extra.daimlerchrysler.com (8.11.4/8.9.0) id gB3LtBc25478 for ; Tue, 3 Dec 2002 16:55:11 -0500 (EST) Received: from unknown(53.231.71.237) by fxodpr13.extra.daimlerchrysler.com via csmap (V6.0) id srcAAANzaOWX; Tue, 3 Dec 02 16:55:11 -0500 Received: from shmrspr1-pf0.shdc.chrysler.com ([129.9.145.48]) by odconpr2-hme0.oddc.chrysler.com (Mail-Gear 2.0.0 bld 58) with SMTP id M2002120316551027903 for ; Tue, 03 Dec 2002 16:55:10 -0500 Received: from daimlerchrysler.com (wokcdts1.is.chrysler.com [53.230.102.164]) by shmrspr1-pf0.shdc.chrysler.com (8.11.2/8.11.2/daimlerchrysler-relay-1.1-kcd) with ESMTP id gB3Lt5b17541 for ; Tue, 3 Dec 2002 16:55:05 -0500 (EST) Message-ID: <3DED2802.A7ACCF5D@daimlerchrysler.com> Date: Tue, 03 Dec 2002 16:54:10 -0500 From: Kevin Darcy X-Mailer: Mozilla 4.74 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: TM/UCC distractions [Was Re: in support of axfr-clarify] References: <200212031023.gB3ANGhZ015824@mailserver4.hushmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.6 required=5.0 tests=EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_05_08,SUPERLONG_LINE,USER_AGENT_MOZILLA_XM, X_ACCEPT_LANG version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ahaukin@hushmail.com wrote: > [ 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. ] > > -----BEGIN PGP SIGNED MESSAGE----- > > Danny Mayer wrote:- > > So, once a change is made how many systems are really impacted, > > especially given that good admins regularly upgrade the software > > on their systems anyway? "All generalizations are false. Except this one" :-) > I work for a bank. We have a very high level of risk-aversion, which extends to not upgrading software and operating systems unless mission critical -- upgrades which others might consider routine. We ditched BIND (at least on internet facing systems) because of the difficulties of running a secure version of it in production that had also passed through the painfully slow testing and change control process here. You always have the option of running a non-standards-compliant version of your DNS software, as long as you're not polluting the Net. Specifically, if the only non-conformant part of djbdns is the AXFR client, and you're not using the AXFR client, or if djbdns'es AXFR client deals gracefully with the scenarios we've been discussing here, then I don't think anyone will really care that much that you're running something that is technically non-standards-compliant. Or are your PHBs overly strict about RFC standards-conformance as well? They can't have their cake and eat it too: standards evolve, and software needs to change to reflect that evolution. They can't be anti-software-change and pro-continuous-standards-conformance at the same time: something has to give. - Kevin -- 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 Dec 3 17:00:50 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21241 for ; Tue, 3 Dec 2002 17:00:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JKx7-0004w3-00 for namedroppers-data@psg.com; Tue, 03 Dec 2002 13:51:37 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18JKx5-0004vn-00 for namedroppers@ops.ietf.org; Tue, 03 Dec 2002 13:51:35 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18JKx4-0009Bo-00 for namedroppers@ops.ietf.org; Tue, 03 Dec 2002 13:51:34 -0800 Message-ID: <20021203193812.52010.qmail@cr.yp.to> References: <3DE54582.1C9704ED@daimlerchrysler.com> <4.3.1.2.20021127224733.0381c580@pop.gis.net> <4.3.1.2.20021129194515.038705b0@pop.gis.net> <4.3.1.2.20021201172338.0391baa0@pop.gis.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Date: 3 Dec 2002 19:38:12 -0000 Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: in support of axfr-clarify X-Spam-Status: No, hits=-0.4 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,RESENT_TO,SPAM_PHRASE_03_05 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. your subscription address is 54830374684695-namedroppers@sublist.cr.yp.to, please post from it or, 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 the alternate address added to the list of addresses from which submissions are automatically accepted. ] Danny ``I am not and never have been an employee of ... Nominum'' Mayer, who in other forums has identified himself as a Senior Software Engineer at Nominum, also known as danny.mayer@nominum.com, writes: > Noone said anything about failures. The discussion is about consistency. So you're demanding that an implementation decision be prohibited simply because it's different from a decision in your implementation---even though you admit that it interoperates just fine. Even if you don't understand how ridiculous this demand is, surely you can understand that it violates section 6 of RFC 2119. > whatever you do will result in someone being in nonconformance with > the proposed spec. That's blatantly incorrect. I already gave you an obvious example of a useful clarification that wouldn't declare current practice to be non-compliant. The only reason for a clarification to make such a declaration is when there's an interoperability problem---a conflict between implementations that has to be fixed by one side or the other. > I have no financial interests in BIND Liar. Is your pretense of independence part of the BIND company's strategy for packing this standards committee, or have other BIND company people been quietly warning you that you should fess up? ---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 Tue Dec 3 17:02:01 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21303 for ; Tue, 3 Dec 2002 17:02:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JL2l-0005L8-00 for namedroppers-data@psg.com; Tue, 03 Dec 2002 13:57:27 -0800 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.36 #2) id 18JL2e-0005Kr-00 for namedroppers@ops.ietf.org; Tue, 03 Dec 2002 13:57:20 -0800 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.5/8.12.5) with ESMTP id gB3Lv6gU063229; Wed, 4 Dec 2002 08:57:08 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200212032157.gB3Lv6gU063229@drugs.dv.isc.org> To: "Olaf M. Kolkman" Cc: namedroppers@ops.ietf.org, Johan Ihren From: Mark.Andrews@isc.org Subject: Re: Dropping denial of existence of wildcard In-reply-to: Your message of "Tue, 03 Dec 2002 14:54:46 BST." <20021203145446.216891c4.olaf@ripe.net> Date: Wed, 04 Dec 2002 08:57:06 +1100 X-Spam-Status: No, hits=1.3 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I think that dropping denial of existance of wildcards is a bad idea. While it may be difficult to implement it is possible to implement the verifier as a library function. 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 Tue Dec 3 17:08:33 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21640 for ; Tue, 3 Dec 2002 17:08:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JL7H-0005cf-00 for namedroppers-data@psg.com; Tue, 03 Dec 2002 14:02:07 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18JL7D-0005cR-00 for namedroppers@ops.ietf.org; Tue, 03 Dec 2002 14:02:04 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18JL7C-0009CR-00 for namedroppers@ops.ietf.org; Tue, 03 Dec 2002 14:02:03 -0800 Message-ID: <20021203201400.61073.qmail@cr.yp.to> References: <3DE54582.1C9704ED@daimlerchrysler.com> <4.3.1.2.20021127224733.0381c580@pop.gis.net> <4.3.1.2.20021129194515.038705b0@pop.gis.net> <20021130042703.23356.qmail@cr.yp.to> <200212022029.gB2KTA620609@guava.araneus.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Date: 3 Dec 2002 20:14:00 -0000 Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: repeating records X-Spam-Status: No, hits=-1.0 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,RESENT_TO,SPAM_PHRASE_01_02 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. your subscription address is 54830374684695-namedroppers@sublist.cr.yp.to, please post from it or, 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 the alternate address added to the list of addresses from which submissions are automatically accepted. ] Andreas Gustafsson writes: > Each of them SHOULD be transmitted only once That blatantly violates RFC 2119, section 6. > > Explaining that servers can repeat records, and requiring clients to > > handle repetitions, would be a clarification of the protocol. > That's what the draft says And I have no objection to the draft saying that. What I object to in this area is the draft saying more---this ludicrous BIND-8-violating ``clarification'' that records ``SHOULD be transmitted only once.'' According to RFC 2119, this means that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course which nobody claims is true in this case. I shouldn't have to say these things even once. The fact that I have to keep saying them---Gustafsson simply waits a few months and tries again; nothing is officially recorded in a usable form; nothing is learned--- reflects a serious deficiency in the IETF procedures. ---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 Tue Dec 3 17:08:54 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21657 for ; Tue, 3 Dec 2002 17:08:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JL9C-0005oH-00 for namedroppers-data@psg.com; Tue, 03 Dec 2002 14:04:06 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18JL9A-0005o4-00 for namedroppers@ops.ietf.org; Tue, 03 Dec 2002 14:04:04 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18JL99-0009CZ-00 for namedroppers@ops.ietf.org; Tue, 03 Dec 2002 14:04:03 -0800 Message-ID: <20021203203443.69852.qmail@cr.yp.to> References: <20021130184803.83758.qmail@cr.yp.to> <200212020358.gB23wLgU034230@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Date: 3 Dec 2002 20:34:43 -0000 Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: axfr-clarify supporting unauthorized users X-Spam-Status: No, hits=-0.7 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,RESENT_TO,SPAM_PHRASE_02_03 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. your subscription address is 54830374684695-namedroppers@sublist.cr.yp.to, please post from it or, 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 the alternate address added to the list of addresses from which submissions are automatically accepted. ] Mark.Andrews@isc.org writes: > Dan I asked you a reasonable question with reasonable pre-conditions. No, you didn't. Your preconditions contradict themselves. You start from the silly assumption that an unauthorized user, a user to whom the primary refuses to give the zone, can nevertheless be a secondary, and then you complain that the primary isn't doing what you think it's supposed to be doing for a secondary. Maybe your implementation has some sort of ``unauthorized users who we call secondaries even though they're not'' list, but there's nothing in the protocol requiring this. ---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 Tue Dec 3 17:15:36 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21909 for ; Tue, 3 Dec 2002 17:15:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JLBx-00061Y-00 for namedroppers-data@psg.com; Tue, 03 Dec 2002 14:06:57 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18JLBu-00061J-00 for namedroppers@ops.ietf.org; Tue, 03 Dec 2002 14:06:54 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18JLBt-0009Cv-00 for namedroppers@ops.ietf.org; Tue, 03 Dec 2002 14:06:53 -0800 Message-ID: <20021203210002.81507.qmail@cr.yp.to> References: <20021128222538.28764.qmail@cr.yp.to> <200211290315.gAT3FHgU023121@drugs.dv.isc.org> <20021129180339.70455.qmail@cr.yp.to> <3DEB9C7C.BA087EF9@daimlerchrysler.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Date: 3 Dec 2002 21:00:02 -0000 Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: axfr-clarify supporting unauthorized users X-Spam-Status: No, hits=-1.0 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,RESENT_TO,SPAM_PHRASE_01_02 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. your subscription address is 54830374684695-namedroppers@sublist.cr.yp.to, please post from it or, 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 the alternate address added to the list of addresses from which submissions are automatically accepted. ] Kevin Darcy writes: > Something could be put in an OPT record, for instance, detailing the > error condition further, extended flags could be used, or a whole new > RR type could be created dedicated to error reporting. And, once these error-message extensions were added to the protocol, would we then have nitwits claiming that all the servers saying REFUSED were suddenly non-compliant because ``making it easier to detect common misconfigurations is an important aspect of interoperability''? ---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 Tue Dec 3 17:17:07 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21979 for ; Tue, 3 Dec 2002 17:17:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JLG9-0006PJ-00 for namedroppers-data@psg.com; Tue, 03 Dec 2002 14:11:17 -0800 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.36 #2) id 18JLG5-0006Mh-00 for namedroppers@ops.ietf.org; Tue, 03 Dec 2002 14:11:13 -0800 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.5/8.12.5) with ESMTP id gB3MB1gU063275; Wed, 4 Dec 2002 09:11:01 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200212032211.gB3MB1gU063275@drugs.dv.isc.org> To: "D. J. Bernstein" Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: elementary DNS facts In-reply-to: Your message of "03 Dec 2002 08:13:11 -0000." <20021203081311.83986.qmail@cr.yp.to> Date: Wed, 04 Dec 2002 09:11:01 +1100 X-Spam-Status: No, hits=0.6 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02, TO_BE_REMOVED_REPLY 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 mis > s > and therefore delete posts by non-subscribers. your subscription address i > s > 54830374684695-namedroppers@sublist.cr.yp.to, please post from it or, if yo > u > 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 the alternate address added to the list of addresses from which > submissions are automatically accepted. ] > > Danny Mayer writes: > > If you have two servers, one a master and the other the slave for a > > specific zone and the slave uses AXFR to transfer the zone from the > > master, can the slave ever give different answers to queries than what > > the master would respond as a result of the received zone? > > Yes, of course. Suppose the server is also a slave for a child zone from > another master. If there's an inconsistency between the two masters, > it's obviously impossible to simultaneously (1) match what the parent > zone master says and (2) match what the child zone master says. > > It's possible to match both for AXFR requests, as axfr-clarify demands, > but it's simply impossible to match both for normal queries, because > queries don't name zones. Matching is not part of the DNS protocol. We are talking about AXFR (IXFR) not queries other than AXFR (IXFR). Queries other than AXFR (IXFR) are already addressed in RFC 2181. > (See my message <20021124091420.47876.qmail@cr.yp.to> for an analysis of > what the protocol says about these inconsistencies.) > > > If the answer is yes, something is wrong since you should get the same > > answer no matter which authorative server you ask. That's what I meant > > by broken. > > You are fundamentally confused about how DNS works. See above. No Don your concept of the DNS is fundementally broken if you believe that you should get different results to AXFR queries to each of the server for the zone when the zone is in steady state. So that there is no confusion about what I mean about the same answer. After removal of duplicate records, down casing all domainnames in the zone and sorting the resulting data should be the same. Mark > > ---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: -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Dec 3 17:45:22 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23201 for ; Tue, 3 Dec 2002 17:45:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JLeY-0008EK-00 for namedroppers-data@psg.com; Tue, 03 Dec 2002 14:36:30 -0800 Received: from fxodpr13.extra.daimlerchrysler.com ([129.9.82.74]) by psg.com with esmtp (Exim 3.36 #2) id 18JLeV-0008B8-00 for namedroppers@ops.ietf.org; Tue, 03 Dec 2002 14:36:27 -0800 Received: (from uucp@localhost) by fxodpr13.extra.daimlerchrysler.com (8.11.4/8.9.0) id gB3MZuQ00238 for ; Tue, 3 Dec 2002 17:35:56 -0500 (EST) Received: from unknown(53.231.71.237) by fxodpr13.extra.daimlerchrysler.com via csmap (V6.0) id srcAAA2taODa; Tue, 3 Dec 02 17:35:56 -0500 Received: from shmrspr1-pf0.shdc.chrysler.com ([129.9.145.48]) by odconpr2-hme0.oddc.chrysler.com (Mail-Gear 2.0.0 bld 58) with SMTP id M2002120317355513880 for ; Tue, 03 Dec 2002 17:35:55 -0500 Received: from daimlerchrysler.com (wokcdts1.is.chrysler.com [53.230.102.164]) by shmrspr1-pf0.shdc.chrysler.com (8.11.2/8.11.2/daimlerchrysler-relay-1.1-kcd) with ESMTP id gB3MZob21848 for ; Tue, 3 Dec 2002 17:35:50 -0500 (EST) Message-ID: <3DED318D.55E44170@daimlerchrysler.com> Date: Tue, 03 Dec 2002 17:34:53 -0500 From: Kevin Darcy X-Mailer: Mozilla 4.74 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: axfr-clarify supporting unauthorized users References: <20021128222538.28764.qmail@cr.yp.to> <200211290315.gAT3FHgU023121@drugs.dv.isc.org> <20021129180339.70455.qmail@cr.yp.to> <3DEB9C7C.BA087EF9@daimlerchrysler.com> <20021203210002.81507.qmail@cr.yp.to> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-2.7 required=5.0 tests=EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_01_02,USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit "D. J. Bernstein" wrote: > [ post by non-subscriber. with the massive amount of spam, it is easy to miss > and therefore delete posts by non-subscribers. your subscription address is > 54830374684695-namedroppers@sublist.cr.yp.to, please post from it or, 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 the alternate address added to the list of addresses from which > submissions are automatically accepted. ] > > Kevin Darcy writes: > > Something could be put in an OPT record, for instance, detailing the > > error condition further, extended flags could be used, or a whole new > > RR type could be created dedicated to error reporting. > > And, once these error-message extensions were added to the protocol, > would we then have nitwits claiming that all the servers saying REFUSED > were suddenly non-compliant because ``making it easier to detect common > misconfigurations is an important aspect of interoperability''? No, RCODE=REFUSED would still be a valid response for the foreseeable future, but these other, richer error-reporting mechanisms would be preferred. RCODE=REFUSED is *already* documented in the relevant DNS specifications; TCP FIN in response to an AXFR request is *not* and does not need to be grandfathered. - Kevin -- 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 Dec 3 17:50:46 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23439 for ; Tue, 3 Dec 2002 17:50:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JLnl-0008p7-00 for namedroppers-data@psg.com; Tue, 03 Dec 2002 14:46:01 -0800 Received: from fxodpr13.extra.daimlerchrysler.com ([129.9.82.74]) by psg.com with esmtp (Exim 3.36 #2) id 18JLnj-0008ou-00 for namedroppers@ops.ietf.org; Tue, 03 Dec 2002 14:45:59 -0800 Received: (from uucp@localhost) by fxodpr13.extra.daimlerchrysler.com (8.11.4/8.9.0) id gB3Mjtc01060 for ; Tue, 3 Dec 2002 17:45:55 -0500 (EST) Received: from unknown(53.231.71.237) by fxodpr13.extra.daimlerchrysler.com via csmap (V6.0) id srcAAAEMayec; Tue, 3 Dec 02 17:45:55 -0500 Received: from shmrspr1-pf0.shdc.chrysler.com ([129.9.145.48]) by odconpr2-hme0.oddc.chrysler.com (Mail-Gear 2.0.0 bld 58) with SMTP id M2002120317455407617 for ; Tue, 03 Dec 2002 17:45:54 -0500 Received: from daimlerchrysler.com (wokcdts1.is.chrysler.com [53.230.102.164]) by shmrspr1-pf0.shdc.chrysler.com (8.11.2/8.11.2/daimlerchrysler-relay-1.1-kcd) with ESMTP id gB3Mjnb29239 for ; Tue, 3 Dec 2002 17:45:49 -0500 (EST) Message-ID: <3DED33E4.C544EDC6@daimlerchrysler.com> Date: Tue, 03 Dec 2002 17:44:52 -0500 From: Kevin Darcy X-Mailer: Mozilla 4.74 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: repeating records References: <3DE54582.1C9704ED@daimlerchrysler.com> <4.3.1.2.20021127224733.0381c580@pop.gis.net> <4.3.1.2.20021129194515.038705b0@pop.gis.net> <20021130042703.23356.qmail@cr.yp.to> <200212022029.gB2KTA620609@guava.araneus.fi> <20021203201400.61073.qmail@cr.yp.to> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-2.7 required=5.0 tests=EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_01_02,USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit "D. J. Bernstein" wrote: > [ post by non-subscriber. with the massive amount of spam, it is easy to miss > and therefore delete posts by non-subscribers. your subscription address is > 54830374684695-namedroppers@sublist.cr.yp.to, please post from it or, 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 the alternate address added to the list of addresses from which > submissions are automatically accepted. ] > > Andreas Gustafsson writes: > > Each of them SHOULD be transmitted only once > > That blatantly violates RFC 2119, section 6. No it doesn't. The "no repeat" provision of the draft merely restates RFC 2181, Section 5.5, which is not limited in applicability to only "ordinary" DNS replies. Feel free to argue that RFC 2181 is incompatible with RFC 2119, Section 6, but I think it's a little late for that... - Kevin -- 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 Dec 3 18:24:32 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24623 for ; Tue, 3 Dec 2002 18:24:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JMJZ-000Avb-00 for namedroppers-data@psg.com; Tue, 03 Dec 2002 15:18:53 -0800 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.36 #2) id 18JMJV-000AvN-00 for namedroppers@ops.ietf.org; Tue, 03 Dec 2002 15:18:49 -0800 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.5/8.12.5) with ESMTP id gB3NIfgU064017; Wed, 4 Dec 2002 10:18:41 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200212032318.gB3NIfgU064017@drugs.dv.isc.org> To: "D. J. Bernstein" Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: axfr-clarify supporting unauthorized users In-reply-to: Your message of "03 Dec 2002 20:34:43 -0000." <20021203203443.69852.qmail@cr.yp.to> Date: Wed, 04 Dec 2002 10:18:41 +1100 X-Spam-Status: No, hits=0.6 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02, TO_BE_REMOVED_REPLY 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 mis > s > and therefore delete posts by non-subscribers. your subscription address i > s > 54830374684695-namedroppers@sublist.cr.yp.to, please post from it or, if yo > u > 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 the alternate address added to the list of addresses from which > submissions are automatically accepted. ] > > Mark.Andrews@isc.org writes: > > Dan I asked you a reasonable question with reasonable pre-conditions. > > No, you didn't. Your preconditions contradict themselves. You start from > the silly assumption that an unauthorized user, a user to whom the > primary refuses to give the zone, can nevertheless be a secondary, and > then you complain that the primary isn't doing what you think it's > supposed to be doing for a secondary. No. You asked that we restrict the discussion to secondaries. I did restrict the discussion to secondaries. Humans, not software, decide who is and is not a secondary. I rephrased the question in terms of the humans deciding that a machine should be secondary and should transfer from the primary and the primary not being updated to reflect that decision. Now does your server return REFUSED under those conditions or not? Mark > Maybe your implementation has some sort of ``unauthorized users who we > call secondaries even though they're not'' list, but there's nothing in > the protocol requiring this. > > ---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: -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Dec 3 18:30:54 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24885 for ; Tue, 3 Dec 2002 18:30:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JMOl-000BHH-00 for namedroppers-data@psg.com; Tue, 03 Dec 2002 15:24:15 -0800 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #2) id 18JMOi-000BG5-00 for namedroppers@ops.ietf.org; Tue, 03 Dec 2002 15:24:12 -0800 Received: from [128.177.195.146] (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 0BDAE137F05; Tue, 3 Dec 2002 15:23:58 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 03 Dec 2002 15:23:55 -0800 Subject: Re: in support of axfr-clarify From: David Conrad To: "D. J. Bernstein" , namedroppers Message-ID: In-Reply-To: <20021203193812.52010.qmail@cr.yp.to> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Status: No, hits=-1.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_08_13,USER_AGENT, USER_AGENT_ENTOURAGE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Bernstein, I've put up with quite a bit of your libel on this thread, but I've had enough. On 12/3/02 11:38 AM, "D. J. Bernstein" wrote: > [ post by non-subscriber. You really should get this fixed. Perhaps you should hire a consultant if you can't figure out how to do it yourself. > Danny ``I am not and never have been an employee of ... Nominum'' Mayer, To be clear, Danny did some contract work for Nominum (porting BINDv9 to Win32) in the past. He was never an employee and we currently don't have a contract with him. Perhaps you could hire him to help you with subscribing to namedroppers? >> I have no financial interests in BIND > Liar. Is your pretense of independence part of the BIND company's > strategy for packing this standards committee, or have other BIND > company people been quietly warning you that you should fess up? Careful of the libelous accusations you throw around Bernstein, particularly as you yourself are so quick to throw threats of lawsuits around. Do you have any proof that "the BIND company" (who is this, exactly?) is "packing this standards committee"? If so, present it. Otherwise admit that you are the liar and send a retraction. Disgusted, -drc -- 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 Dec 3 18:34:44 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25007 for ; Tue, 3 Dec 2002 18:34:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JMUK-000Bec-00 for namedroppers-data@psg.com; Tue, 03 Dec 2002 15:30:00 -0800 Received: from adsl-63-197-0-204.dsl.snfc21.pacbell.net ([63.197.0.204] helo=guava.araneus.fi) by psg.com with esmtp (Exim 3.36 #2) id 18JMUH-000BeN-00 for namedroppers@ops.ietf.org; Tue, 03 Dec 2002 15:29:57 -0800 Received: (from gson@localhost) by guava.araneus.fi (8.11.6/8.11.6) id gB3NTuP07138; Tue, 3 Dec 2002 15:29:56 -0800 (PST) Date: Tue, 3 Dec 2002 15:29:56 -0800 (PST) Message-Id: <200212032329.gB3NTuP07138@guava.araneus.fi> To: namedroppers@ops.ietf.org Subject: Re: repeating records In-Reply-To: <20021203201400.61073.qmail@cr.yp.to> References: <3DE54582.1C9704ED@daimlerchrysler.com> <4.3.1.2.20021127224733.0381c580@pop.gis.net> <4.3.1.2.20021129194515.038705b0@pop.gis.net> <20021130042703.23356.qmail@cr.yp.to> <200212022029.gB2KTA620609@guava.araneus.fi> <20021203201400.61073.qmail@cr.yp.to> X-Mailer: VM 7.04 under Emacs 20.7.1 From: gson@nominum.com (Andreas Gustafsson) X-Spam-Status: No, hits=-1.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk D. J. Bernstein writes: > Andreas Gustafsson writes: > > Each of them SHOULD be transmitted only once > > That blatantly violates RFC 2119, section 6. > > > > Explaining that servers can repeat records, and requiring clients to > > > handle repetitions, would be a clarification of the protocol. > > That's what the draft says > > And I have no objection to the draft saying that. What I object to in > this area is the draft saying more---this ludicrous BIND-8-violating > ``clarification'' that records ``SHOULD be transmitted only once.'' > According to RFC 2119, this means that > > there may exist valid reasons in particular circumstances to ignore a > particular item, but the full implications must be understood and > carefully weighed before choosing a different course > > which nobody claims is true in this case. I would certainly want implementers to understand and carefully weigh the implications of multiple transmission, such as waste of bandwidth and receiver CPU time. Are you suggesting they should not? RFC 2119 section 6 says imperatives (e.g., MUST or SHOULD) "MUST only be used where it is actually required for interoperation or to to limit behavior which has potential for causing harm (e.g., limiting retransmisssions)". This would be the latter case. Incidentally, I found it amusing that the author of RFC2119 specifically chose limiting retransmissions as the example; although he probably had a different kind of retransmission in mind than that of transmitting records multiple times in an AXFR, they both cause similar harm in the form of wasted bandwidth. -- Andreas Gustafsson, gson@nominum.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Dec 3 18:44:58 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25424 for ; Tue, 3 Dec 2002 18:44:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JMdI-000CNK-00 for namedroppers-data@psg.com; Tue, 03 Dec 2002 15:39:16 -0800 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.36 #2) id 18JMdF-000CLm-00 for namedroppers@ops.ietf.org; Tue, 03 Dec 2002 15:39:14 -0800 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.5/8.12.5) with ESMTP id gB3Nd9gU064088; Wed, 4 Dec 2002 10:39:09 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200212032339.gB3Nd9gU064088@drugs.dv.isc.org> To: "D. J. Bernstein" Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: repeating records In-reply-to: Your message of "03 Dec 2002 20:14:00 -0000." <20021203201400.61073.qmail@cr.yp.to> Date: Wed, 04 Dec 2002 10:39:09 +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 > Andreas Gustafsson writes: > > Each of them SHOULD be transmitted only once > > That blatantly violates RFC 2119, section 6. > > > > Explaining that servers can repeat records, and requiring clients to > > > handle repetitions, would be a clarification of the protocol. > > That's what the draft says > > And I have no objection to the draft saying that. What I object to in > this area is the draft saying more---this ludicrous BIND-8-violating > ``clarification'' that records ``SHOULD be transmitted only once.'' > According to RFC 2119, this means that > > there may exist valid reasons in particular circumstances to ignore a > particular item, but the full implications must be understood and > carefully weighed before choosing a different course > > which nobody claims is true in this case. BIND 8 is a legacy implementation and has been for a while now. What I find ludicrous is you ignoring the fact that it is a legacy implementation. There are lots of things BIND 8 does that are against some RFC. We wrote BIND 9 to address those issues. The full implications are that same record will be transmitted multiple times making the transmission process longer. If the zone is stored to disk it without removal of the duplicates it will take up more space. Applications that use the result need to be aware that there may be duplicates. All existing nameservers cope with this. All namesevers that comform to the clarify draft will cope with this. These are NOT NEW implications. They have existed as long as BIND has existed. > I shouldn't have to say these things even once. The fact that I have to > keep saying them---Gustafsson simply waits a few months and tries again; > nothing is officially recorded in a usable form; nothing is learned--- > reflects a serious deficiency in the IETF procedures. > > ---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: -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Dec 3 18:45:18 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25467 for ; Tue, 3 Dec 2002 18:45:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JMb4-000CCI-00 for namedroppers-data@psg.com; Tue, 03 Dec 2002 15:36:58 -0800 Received: from fxshpr08.extra.daimlerchrysler.com ([129.9.80.165] helo=fxshpr06.extra.daimlerchrysler.com) by psg.com with esmtp (Exim 3.36 #2) id 18JMb0-000CBS-00 for namedroppers@ops.ietf.org; Tue, 03 Dec 2002 15:36:54 -0800 Received: (from uucp@localhost) by fxshpr06.extra.daimlerchrysler.com (8.11.4/8.9.0) id gB3NZf912608 for ; Tue, 3 Dec 2002 18:35:41 -0500 (EST) Received: from nodnsquery(129.9.147.104) by fxshpr08.extra.daimlerchrysler.com via csmap (V6.0) id srcAAArVa4Ny; Tue, 3 Dec 02 18:35:41 -0500 Received: from shmrspr1-pf0.shdc.chrysler.com ([129.9.145.48]) by shconpr2-hme0.shdc.chrysler.com (Mail-Gear 2.0.0 bld 58) with SMTP id M2002120318362306295 for ; Tue, 03 Dec 2002 18:36:23 -0500 Received: from daimlerchrysler.com (wokcdts1.is.chrysler.com [53.230.102.164]) by shmrspr1-pf0.shdc.chrysler.com (8.11.2/8.11.2/daimlerchrysler-relay-1.1-kcd) with ESMTP id gB3NaIb06462 for ; Tue, 3 Dec 2002 18:36:18 -0500 (EST) Message-ID: <3DED3FB9.2F6D93EC@daimlerchrysler.com> Date: Tue, 03 Dec 2002 18:35:21 -0500 From: Kevin Darcy X-Mailer: Mozilla 4.74 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: axfr-clarify supporting unauthorized users References: <20021130184803.83758.qmail@cr.yp.to> <200212020358.gB23wLgU034230@drugs.dv.isc.org> <20021203203443.69852.qmail@cr.yp.to> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-2.4 required=5.0 tests=EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_02_03,USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit "D. J. Bernstein" wrote: > [ post by non-subscriber. with the massive amount of spam, it is easy to miss > and therefore delete posts by non-subscribers. your subscription address is > 54830374684695-namedroppers@sublist.cr.yp.to, please post from it or, 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 the alternate address added to the list of addresses from which > submissions are automatically accepted. ] > > Mark.Andrews@isc.org writes: > > Dan I asked you a reasonable question with reasonable pre-conditions. > > No, you didn't. Your preconditions contradict themselves. You start from > the silly assumption that an unauthorized user, a user to whom the > primary refuses to give the zone, can nevertheless be a secondary, and > then you complain that the primary isn't doing what you think it's > supposed to be doing for a secondary. > > Maybe your implementation has some sort of ``unauthorized users who we > call secondaries even though they're not'' list, but there's nothing in > the protocol requiring this. Dan, RFC 1034 only mentions two possible outcomes of an AXFR request: "an error, such as refused" or an answer consisting of "a sequence of response messages", i.e. a zone transfer. Now, we all realize that circumstances beyond the control of the DNS implementation may cause the connection attempt to fail (network congestion, hardware errors, OS crash, whatever), or to be prematurely broken, but RFC 1034, as a *DNS* spec, describes what a DNS implementation should do (or attempt to do), and TCP FIN is not among the options here. Surely you can see this, can't you? Now, you can perform as much semantic acrobatics as you wish over whether that paragraph only applies to "secondary servers" or not, but the fact that "refused" is mentioned as a legitimate response to an AXFR request from "a secondary server", combined with the fact that the companion RFC describes the "refused" RCODE as "the name server refuses to perform the specified operation for policy reasons" means that it is illogical to limit the definition of "secondary server" to "only those entities which, by policy, are allowed to request and/or receive zone transfers from me". To put it another way, the definition of "secondary server" which you are proposing ineluctably leads to the conclusion that "refused" could *never* be a valid, standards-conforming response to an AXFR request. Yet clearly this line of thought is at odds with the RFC 1034 verbiage to which Mark refers. - Kevin -- 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 Dec 3 19:34:05 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27063 for ; Tue, 3 Dec 2002 19:34:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JNNb-000Fn9-00 for namedroppers-data@psg.com; Tue, 03 Dec 2002 16:27:07 -0800 Received: from mx04.gis.net ([208.218.130.12] helo=gis.net) by psg.com with esmtp (Exim 3.36 #2) id 18JNNZ-000Fmx-00 for namedroppers@ops.ietf.org; Tue, 03 Dec 2002 16:27:05 -0800 Received: from tecotoo.www.gis.net ([63.214.73.183]) by mx04.gis.net; Tue, 03 Dec 2002 19:27:01 -0500 Received: from localhost (localhost [127.0.0.1]) by tecotoo.www.gis.net (NTMail 3.02.13) with ESMTP id xa029455 for ; Tue, 3 Dec 2002 19:30:20 -0500 Message-Id: <4.3.1.2.20021203190944.00e2a100@pop.gis.net> X-Sender: mayer@pop.gis.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Tue, 03 Dec 2002 19:29:49 -0500 To: namedroppers@ops.ietf.org From: Danny Mayer Subject: Re: in support of axfr-clarify In-Reply-To: <20021203193812.52010.qmail@cr.yp.to> References: <3DE54582.1C9704ED@daimlerchrysler.com> <4.3.1.2.20021127224733.0381c580@pop.gis.net> <4.3.1.2.20021129194515.038705b0@pop.gis.net> <4.3.1.2.20021201172338.0391baa0@pop.gis.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Info: NTMail 3.02 Server on TECOTOO X-Rcpt-To: X-Spam-Status: No, hits=1.3 required=5.0 tests=IN_REP_TO,RCVD_IN_OSIRUSOFT_COM,REFERENCES, SPAM_PHRASE_05_08,X_OSIRU_DUL version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 02:38 PM 12/3/02, D. J. Bernstein wrote: >Danny ``I am not and never have been an employee of ... Nominum'' Mayer, >who in other forums has identified himself as a Senior Software Engineer >at Nominum, also known as danny.mayer@nominum.com, writes: > > > I have no financial interests in BIND > >Liar. Is your pretense of independence part of the BIND company's >strategy for packing this standards committee, or have other BIND >company people been quietly warning you that you should fess up? Fess up to what? I had enough of your attitude. The statement I made is true. Repeating something ad nauseum doesn't make it true. >---D. J. Bernstein, Associate Professor, Department of Mathematics, >Statistics, and Computer Science, University of Illinois at Chicago For someone who claims to be an assistant professor you are acting very childishly. There are almost no posts that you have made to this forum or others on almost any topic that I've seen that could be described as adult. You've made every opportunity to demean, harass, admonish, and otherwise belittle anyone who disagrees with your point of view. Since your field is supposed to be mathematics, you should know that theorems are supposed to be proven with unassailable logic, not assaulted with abuse. Q.E.D. has a meaning. Stick to it. It's time for you to grow up and become an adult. I have no interest in and will not discuss my employment, financial interests, or other personal information with you in this forum or any other. Danny -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Dec 3 19:49:47 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27721 for ; Tue, 3 Dec 2002 19:49:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JNeT-000H49-00 for namedroppers-data@psg.com; Tue, 03 Dec 2002 16:44:33 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18JNeP-000H3t-00 for namedroppers@ops.ietf.org; Tue, 03 Dec 2002 16:44:29 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18JNeO-0009Km-00 for namedroppers@ops.ietf.org; Tue, 03 Dec 2002 16:44:28 -0800 Message-ID: <20021204003004.53303.qmail@cr.yp.to> References: <3DE54582.1C9704ED@daimlerchrysler.com> <4.3.1.2.20021127224733.0381c580@pop.gis.net> <4.3.1.2.20021129194515.038705b0@pop.gis.net> <20021130042703.23356.qmail@cr.yp.to> <200212022029.gB2KTA620609@guava.araneus.fi> <20021203201400.61073.qmail@cr.yp.to> <3DED33E4.C544EDC6@daimlerchrysler.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Date: 4 Dec 2002 00:30:04 -0000 Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: repeating records X-Spam-Status: No, hits=-0.2 required=5.0 tests=REFERENCES,RESENT_TO,SPAM_PHRASE_01_02 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. your subscription address is 54830374684695-namedroppers@sublist.cr.yp.to, please post from it or, 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 the alternate address added to the list of addresses from which submissions are automatically accepted. ] > > That blatantly violates RFC 2119, section 6. > No it doesn't. [ ... ] > merely restates RFC 2181 I can't imagine why you think that this is relevant to my comment. As I've pointed out before, RFC 2181 blatantly violates RFC 2119 too. As a broader matter: ``We screwed it up before'' does not justify ``Let's screw it up again.'' The solution to problems in RFC 2181 is to fix RFC 2181, not to copy the problems into other documents. Note that BIND 9 clearly fails to comply with RFC 2181 (by, for example, using an A record cached from the additional section of an MX response to answer a subsequent A query---this is normal, desirable behavior that is prohibited by RFC 2181), so please don't spout any religious nonsense about RFC 2181 being an edict from the heavens. ---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 Tue Dec 3 19:56:37 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27927 for ; Tue, 3 Dec 2002 19:56:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JNl9-000Hc0-00 for namedroppers-data@psg.com; Tue, 03 Dec 2002 16:51:27 -0800 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.36 #2) id 18JNl5-000Hbi-00 for namedroppers@ops.ietf.org; Tue, 03 Dec 2002 16:51:23 -0800 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id TAA12965 for ; Tue, 3 Dec 2002 19:51:22 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id TAA22962 for ; Tue, 3 Dec 2002 19:51:22 -0500 (EST) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id TAA13196 for ; Tue, 3 Dec 2002 19:46:34 -0500 (EST) Received: (from ghudson@localhost) by error-messages.mit.edu (8.9.3) id TAA10044; Tue, 3 Dec 2002 19:46:32 -0500 Date: Tue, 3 Dec 2002 19:46:32 -0500 Message-Id: <200212040046.TAA10044@error-messages.mit.edu> From: Greg Hudson To: namedroppers@ops.ietf.org In-reply-to: <20021203210002.81507.qmail@cr.yp.to> Subject: Re: axfr-clarify supporting unauthorized users X-Spam-Status: No, hits=2.9 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM, RCVD_IN_RELAYS_ORDB_ORG,SPAM_PHRASE_00_01, X_OSIRU_OPEN_RELAY version=2.43 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Dan Bernstein wrote: > And, once these error-message extensions were added to the protocol, > would we then have nitwits claiming that all the servers saying > REFUSED were suddenly non-compliant because ``making it easier to > detect common misconfigurations is an important aspect of > interoperability''? You objected to this clause of axfr-clarify on two grounds: (1) It forbids the behavior of djbdns, which you believe to be compliant with the existing (pre-clarification) specifications, and (2) It's not necessary for interoperability, and therefore should not be a MUST. I disagreed with (2) on the grounds that interoperability is about more than just the case where everything is working. That particular argument had no bearing on (1). So no matter how slippery the slope, my argument would never imply that conforming implementations of an old standard would magically become non-conforming when a revision is published. (A conforming C89 compiler remains a conforming C89 compiler even if it is not a conforming C99 compiler.) (As a separate point, I agree with other people that a TCP FIN was not a reasonable implementation choice given the text in RFC 1034 and 1035, and thus djbdns's behavior here should not be considered a data point for a clarification effort. That argument bears on (1) but not (2).) I do not know of an IETF policy on ad hominem remarks, but perhaps it should be discouraged for working group chairs to consider arguments intermixed with personal slurs when gauging consensus. That would allow contributors to ignore abusive behavior such as Dan's without worrying that doing so might affect the standards process. -- 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 Dec 3 20:20:00 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28537 for ; Tue, 3 Dec 2002 20:19:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JO67-000J62-00 for namedroppers-data@psg.com; Tue, 03 Dec 2002 17:13:07 -0800 Received: from fxodpr13.extra.daimlerchrysler.com ([129.9.82.74]) by psg.com with esmtp (Exim 3.36 #2) id 18JO64-000J2R-00 for namedroppers@ops.ietf.org; Tue, 03 Dec 2002 17:13:04 -0800 Received: (from uucp@localhost) by fxodpr13.extra.daimlerchrysler.com (8.11.4/8.9.0) id gB41Cdh08939 for ; Tue, 3 Dec 2002 20:12:39 -0500 (EST) Received: from unknown(53.231.71.237) by fxodpr13.extra.daimlerchrysler.com via csmap (V6.0) id srcAAApeaqDr; Tue, 3 Dec 02 20:12:39 -0500 Received: from shmrspr1-pf0.shdc.chrysler.com ([129.9.145.48]) by odconpr2-hme0.oddc.chrysler.com (Mail-Gear 2.0.0 bld 58) with SMTP id M2002120320123804419 for ; Tue, 03 Dec 2002 20:12:38 -0500 Received: from daimlerchrysler.com (wokcdts1.is.chrysler.com [53.230.102.164]) by shmrspr1-pf0.shdc.chrysler.com (8.11.2/8.11.2/daimlerchrysler-relay-1.1-kcd) with ESMTP id gB41CYb03078 for ; Tue, 3 Dec 2002 20:12:34 -0500 (EST) Message-ID: <3DED5649.375B03F8@daimlerchrysler.com> Date: Tue, 03 Dec 2002 20:11:37 -0500 From: Kevin Darcy X-Mailer: Mozilla 4.74 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: repeating records References: <3DE54582.1C9704ED@daimlerchrysler.com> <4.3.1.2.20021127224733.0381c580@pop.gis.net> <4.3.1.2.20021129194515.038705b0@pop.gis.net> <20021130042703.23356.qmail@cr.yp.to> <200212022029.gB2KTA620609@guava.araneus.fi> <20021203201400.61073.qmail@cr.yp.to> <3DED33E4.C544EDC6@daimlerchrysler.com> <20021204003004.53303.qmail@cr.yp.to> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-2.4 required=5.0 tests=EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_02_03,USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit "D. J. Bernstein" wrote: > [ post by non-subscriber. with the massive amount of spam, it is easy to miss > and therefore delete posts by non-subscribers. your subscription address is > 54830374684695-namedroppers@sublist.cr.yp.to, please post from it or, 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 the alternate address added to the list of addresses from which > submissions are automatically accepted. ] > > > > That blatantly violates RFC 2119, section 6. > > No it doesn't. > [ ... ] > > merely restates RFC 2181 > > I can't imagine why you think that this is relevant to my comment. As > I've pointed out before, RFC 2181 blatantly violates RFC 2119 too. > > As a broader matter: ``We screwed it up before'' does not justify > ``Let's screw it up again.'' The solution to problems in RFC 2181 is to > fix RFC 2181, not to copy the problems into other documents. > > Note that BIND 9 clearly fails to comply with RFC 2181 (by, for example, > using an A record cached from the additional section of an MX response > to answer a subsequent A query---this is normal, desirable behavior that > is prohibited by RFC 2181), so please don't spout any religious nonsense > about RFC 2181 being an edict from the heavens. It's not an edict from the heavens, but it is a prevailing DNS standard. Get over it. The time for gauging "rough concensus" on the "don't repeat records" part of the DNS protocol specification is long past, and the fact that axfr-clarify restates the rule doesn't give you another chance to turn back the hand of progress. - Kevin -- 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 Dec 3 21:12:34 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29704 for ; Tue, 3 Dec 2002 21:12:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JOrR-000MV6-00 for namedroppers-data@psg.com; Tue, 03 Dec 2002 18:02:01 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18JOrN-000MUo-00 for namedroppers@ops.ietf.org; Tue, 03 Dec 2002 18:01:57 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18JOrM-0009OB-00 for namedroppers@ops.ietf.org; Tue, 03 Dec 2002 18:01:56 -0800 Message-ID: <20021204011044.62945.qmail@cr.yp.to> References: <3DE54582.1C9704ED@daimlerchrysler.com> <4.3.1.2.20021127224733.0381c580@pop.gis.net> <4.3.1.2.20021129194515.038705b0@pop.gis.net> <20021130042703.23356.qmail@cr.yp.to> <200212022029.gB2KTA620609@guava.araneus.fi> <20021203201400.61073.qmail@cr.yp.to> <200212032329.gB3NTuP07138@guava.araneus.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Date: 4 Dec 2002 01:10:44 -0000 Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Cc: sob@harvard.edu Subject: Re: repeating records X-Spam-Status: No, hits=0.1 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,RESENT_TO,SPAM_PHRASE_05_08 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. your subscription address is 54830374684695-namedroppers@sublist.cr.yp.to, please post from it or, 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 the alternate address added to the list of addresses from which submissions are automatically accepted. ] Andreas Gustafsson writes: > I would certainly want implementers to understand and carefully weigh > the implications of multiple transmission, such as waste of bandwidth > and receiver CPU time. Are you suggesting they should not? Yes or no: Are you claiming that every DNS implementor, before choosing to use (for example) BIND 8's strategy of sending glue whenever it's referenced, _must_ understand and carefully weigh the implications? That's the definition of ``SHOULD'' in RFC 2119. It's a mechanism to warn implementors about behaviors that are interoperable but dangerous; see RFC 2119, section 6. It isn't an excuse for you to have your BIND 9 implementation decisions masquerading as protocol requirements. Are you next going to claim that people ``SHOULD NOT'' put DNS records into LDAP? Look at all that wasted bandwidth and CPU time! As another example, you're wasting tons of bandwidth by using zone transfers (incremental but not compressed) rather than rsync-over-ssh (incremental _and_ compressed). Have you understood and carefully weighed the implications of your poor choice of protocols? How would you like it if someone said that you ``SHOULD NOT'' use zone transfers? Andreas Gustafsson writes: > Incidentally, I found it amusing that the author of RFC2119 > specifically chose limiting retransmissions as the example; although > he probably had a different kind of retransmission in mind than that > of transmitting records multiple times in an AXFR, they both cause > similar harm in the form of wasted bandwidth. Wow, are you really this ignorant? The retransmission issue has nothing to do with optimizing bandwidth use. The retransmission issue is that momentary network overloads can snowball into nearly complete outages. If people really are misusing ``SHOULD'' for minor efficiency issues (misinterpreting ``harm'' in section 6 of RFC 2119), we're going to need a new word to point out real dangers such as over-eager retransmission. ---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 Tue Dec 3 21:14:57 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29731 for ; Tue, 3 Dec 2002 21:14:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JOs6-000MZR-00 for namedroppers-data@psg.com; Tue, 03 Dec 2002 18:02:42 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18JOs4-000MZF-00 for namedroppers@ops.ietf.org; Tue, 03 Dec 2002 18:02:40 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18JOs3-0009ON-00 for namedroppers@ops.ietf.org; Tue, 03 Dec 2002 18:02:39 -0800 Message-ID: <20021204012405.65728.qmail@cr.yp.to> References: <20021203203443.69852.qmail@cr.yp.to> <200212032318.gB3NIfgU064017@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Date: 4 Dec 2002 01:24:05 -0000 Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: axfr-clarify supporting unauthorized users X-Spam-Status: No, hits=-0.2 required=5.0 tests=REFERENCES,RESENT_TO,SPAM_PHRASE_01_02 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. your subscription address is 54830374684695-namedroppers@sublist.cr.yp.to, please post from it or, 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 the alternate address added to the list of addresses from which submissions are automatically accepted. ] Mark.Andrews@isc.org writes: > Humans, not software, decide who is and is not a secondary. No. The secondaries are defined by software. Humans may decide who they _want_ to have as secondaries, but those servers are _not_ secondaries until the software on both sides is configured appropriately. The paragraph you quoted says ``secondary.'' It does not say ``anyone whom the zone owner wants to have as a secondary.'' ---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 Tue Dec 3 21:15:01 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29745 for ; Tue, 3 Dec 2002 21:15:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JOrq-000MZ9-00 for namedroppers-data@psg.com; Tue, 03 Dec 2002 18:02:26 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18JOrm-000MYi-00 for namedroppers@ops.ietf.org; Tue, 03 Dec 2002 18:02:22 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18JOrl-0009OH-00 for namedroppers@ops.ietf.org; Tue, 03 Dec 2002 18:02:21 -0800 Message-Id: <200212040121.gB41LDA29009@vacation.karoshi.com> In-Reply-To: from "David Conrad" at Dec 03, 2002 03:23:55 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: bmanning@vacation.karoshi.com Subject: Re: in support of axfr-clarify To: david.conrad@nominum.com (David Conrad) Date: Tue, 3 Dec 2002 17:21:13 -0800 (PST) Cc: djb@cr.yp.to (D. J. Bernstein), namedroppers@ops.ietf.org (namedroppers) X-Spam-Status: No, hits=1.1 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,RESENT_TO, SPAM_PHRASE_05_08 version=2.43 X-Spam-Level: * 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. ] > > Is your pretense of independence part of the BIND company's > > strategy for packing this standards committee, > > -- sez djb > > Do you have any proof that "the BIND company" (who is this, exactly?) is > "packing this standards committee"? If so, present it. Otherwise admit > that you are the liar and send a retraction. > > Disgusted, > -drc More humourous, perhaps, is the delusion that a mailing list is a masquerade for a standards committee. Dun & Bradstreet do not appear to have a listing for any company named "BIND" that has DNS software as a product. Perhaps the "DJBDNS company" representative is playing fast and loose with pejoritive statements to attempt to incite non-productive dialog? I expect that a more productive tactic would be for the "DJBDNS company" representative to write an ID to debate/discuss the relative merits of the existing ID under discussion and propose substantive alternatives that are more inclusive and advance the state of art of the Domain Name System. Promotion of better ideas works lots better than castigation of ideas that are distastful, for what ever reason. As for me, I want a strong, robust, evolving system that has "genetic" diversity in the code base. --bill -- 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 Dec 3 21:58:33 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00803 for ; Tue, 3 Dec 2002 21:58:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JPfO-0000Yc-00 for namedroppers-data@psg.com; Tue, 03 Dec 2002 18:53:38 -0800 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.36 #2) id 18JPfL-0000YH-00 for namedroppers@ops.ietf.org; Tue, 03 Dec 2002 18:53:36 -0800 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.5/8.12.5) with ESMTP id gB42rRgU089115; Wed, 4 Dec 2002 13:53:27 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200212040253.gB42rRgU089115@drugs.dv.isc.org> To: "D. J. Bernstein" Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: axfr-clarify supporting unauthorized users In-reply-to: Your message of "04 Dec 2002 01:24:05 -0000." <20021204012405.65728.qmail@cr.yp.to> Date: Wed, 04 Dec 2002 13:53:27 +1100 X-Spam-Status: No, hits=0.5 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Mark.Andrews@isc.org writes: > > Humans, not software, decide who is and is not a secondary. > > No. The secondaries are defined by software. Humans may decide who they > _want_ to have as secondaries, but those servers are _not_ secondaries > until the software on both sides is configured appropriately. > > The paragraph you quoted says ``secondary.'' It does not say ``anyone > whom the zone owner wants to have as a secondary.'' > No is a secondary. It may not be able to get the contents of the zone but it is a secondary. It is performing as many parts of the protocol as it can as a secondary up until it gets a copy of the zone when it can actually start serving data. Those parts of the protocol are to request a AXFR and to keep requesting AXFR's until told otherwise. 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 Wed Dec 4 00:54:25 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04870 for ; Wed, 4 Dec 2002 00:54:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JSOQ-000DxC-00 for namedroppers-data@psg.com; Tue, 03 Dec 2002 21:48:18 -0800 Received: from ms2-gw.noc.ntt.com ([210.163.32.67]) by psg.com with esmtp (Exim 3.36 #2) id 18JSOL-000Dtg-00 for namedroppers@ops.ietf.org; Tue, 03 Dec 2002 21:48:13 -0800 Received: from mr2-gw.noc.ntt.com by ms2-gw.noc.ntt.com (8.9.3/3.7W) id OAA16120; Wed, 4 Dec 2002 14:47:39 +0900 (JST) Received: from mail1.noc.ntt.com by mr2-gw.noc.ntt.com (8.9.3/3.7W) id OAA16006; Wed, 4 Dec 2002 14:47:31 +0900 (JST) Received: from kamite-bsd by mail1.noc.ntt.com (8.9.3/3.7W) id OAA04648; Wed, 4 Dec 2002 14:47:31 +0900 (JST) Date: Wed, 4 Dec 2002 14:48:53 +0900 From: Yuji KAMITE To: namedroppers@ops.ietf.org Cc: y.kamite@ntt.com, nakayama@nc.u-tokyo.ac.jp Subject: Re: DNSEXT WGLC: TKEY Renewal Mode-02 Message-Id: <20021204144853.4d462e2a.y.kamite@ntt.com> In-Reply-To: <3DECC24E.D9ADF206@quadritek.com> References: <5.1.1.6.2.20021114134710.0158ffa8@localhost> <3DECC24E.D9ADF206@quadritek.com> Organization: NTT Communications X-Mailer: Sylpheed version 0.7.5 (GTK+ 1.2.10; i386-portbld-freebsd4.5) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.5 required=5.0 tests=IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Which approach is better is a matter to think about, but unless there > is a downside to allowing a tkey delete request to be signed with > a partially revoked key (and I can't think of one off the top of > my head, since deleting a key can be construed as part of a mechanism > of using RFC 2930 to renew the key), then it would be nice if the > protocol didn't preclude this possibility -- and allowing it would > certainly improve at least on deployed implementation -- which > currently has a hokey client side management of "is this key about > to expire" logic. I understand your point. I've noticed the behavior that client only requests the deletion of it (or deletion of the keys derived from it) signed with the partially revoked key itself, would not occur any serious problems. Obviously, this draft shows the rollover process based on PartialRevoke and following Renewal request, not requiring deletion request; however, as you said, it is also important to consider the friendliness with current deployment. I agree that it must not preclude other possibility without particular reasons. Thanks. > > 2) Just a minor thing -- I think section 1.3 would be clearer > if paragraph 3 mentioned that the messages in the key renewal > procedure are (or can be?) signed with the partially revoked key > (I realise this is mentioned later, but it was my first question > as I was reading it ...) Now I'm going to consider modification. --- Yuji Kamite (E-mail:y.kamite@ntt.com) NTT Communications Corporation TEL: +81-3-6800-3261 FAX: +81-3-5365-2990 -- 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 Dec 4 07:07:37 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07025 for ; Wed, 4 Dec 2002 07:07:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JY8v-00047Z-00 for namedroppers-data@psg.com; Wed, 04 Dec 2002 03:56:41 -0800 Received: from as7-2-2.bn.g.bonet.se ([217.215.21.151] helo=poledra) by psg.com with esmtp (Exim 3.36 #2) id 18JY8s-00047F-00 for namedroppers@ops.ietf.org; Wed, 04 Dec 2002 03:56:38 -0800 Received: from localhost ([127.0.0.1] helo=feline.pp.se ident=www-data) by poledra with smtp (Exim 3.35 #1 (Debian)) id 18JY8o-0007YZ-00 for ; Wed, 04 Dec 2002 12:56:34 +0100 Received: from crawl4.googlebot.com ([136.8.159.11]) (proxying for 136.21.75.41) (SquirrelMail authenticated user feline) by www.feline.pp.se with HTTP; Wed, 4 Dec 2002 12:56:34 +0100 (CET) Message-ID: <13716.136.8.159.11.1039002994.squirrel@www.feline.pp.se> Date: Wed, 4 Dec 2002 12:56:34 +0100 (CET) Subject: Re: repeating records From: "Kandra Nygards" To: In-Reply-To: <20021204011044.62945.qmail@cr.yp.to> References: <3DE54582.1C9704ED@daimlerchrysler.com> <4.3.1.2.20021127224733.0381c580@pop.gis.net> <4.3.1.2.20021129194515.038705b0@pop.gis.net> <20021130042703.23356.qmail@cr.yp.to> <200212022029.gB2KTA620609@guava.araneus.fi> <20021203201400.61073.qmail@cr.yp.to> <200212032329.gB3NTuP07138@guava.araneus.fi> <20021204011044.62945.qmail@cr.yp.to> X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal X-Mailer: SquirrelMail (version 1.2.6) 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, MSG_ID_ADDED_BY_MTA_3,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_03_05 version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit > As another example, you're wasting tons of bandwidth by using zone > transfers (incremental but not compressed) rather than rsync-over-ssh > (incremental _and_ compressed). Have you understood and carefully > weighed the implications of your poor choice of protocols? How would > you like it if someone said that you ``SHOULD NOT'' use zone transfers? Once again... Rsync and ssh has exactly *WHAT* to do with DNS? As for poor choice of protocols, I personally feel that DNS is a rather good choice of protocol for doing things DNS related, but then again, that's just me. Now, could we please focus here? This discussion is about the axfr-clarify draft. It's not about proper mailinglist behaviour, it's not about rsync or ssh, it's not about alternate methods for tranfering zones. It's most definitely not about Mark's wife, and it's not about Danny's employment. In fact, believe it or not, it's about the axfr-clarify draft. Now, Dan, your original objections to the axfr-clarify draft was that it prohibited the behaviour of your software on a number of points, which you claimed was in violation of RFC 2119. Those issues have been discussed. Some people, myself included, feel that they have been resolved. Some people do not. If you have anything further to say regarding those specific issues, please feel free to speak up. If you have any other issues regarding this particular draft that need to be adressed, feel free to bring THEM up. If not, then could we please focus on the work at hand, namely to decide if we have a rough consensus on the draft or not and proceed accordingly. Also, I would appreciate if we could please limit the namecalling, libel, insults and flames to a maximum of one email per person per day. That way it'll be easier for archive readers to find out who's doing what to who's dog. My quota for today would therefore be to ask Dan if his DNS-software is IPv8 compliant yet. Best regards, Kandra Nygards -- 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 Dec 4 07:44:05 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08185 for ; Wed, 4 Dec 2002 07:44:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JYnD-0005Cq-00 for namedroppers-data@psg.com; Wed, 04 Dec 2002 04:38:19 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #2) id 18JYn9-0005CY-00 for namedroppers@ops.ietf.org; Wed, 04 Dec 2002 04:38:16 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07691; Wed, 4 Dec 2002 07:35:24 -0500 (EST) Message-Id: <200212041235.HAA07691@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-mdns-13.txt Date: Wed, 04 Dec 2002 07:35:24 -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 : Linklocal Multicast Name Resolution (LLMNR) Author(s) : L. Esibov, B. Aboba, D. Thaler Filename : draft-ietf-dnsext-mdns-13.txt Pages : 20 Date : 2002-12-3 Today, with the rise of home networking, there are an increasing number of ad-hoc networks operating without a DNS server. In order to allow name resolution in such environments, Link-Local Multicast Name Resolution (LLMNR) is proposed. LLMNR supports all current and future DNS formats, types and classes, while operating on a separate port from DNS, and with a distinct resolver cache. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-13.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-mdns-13.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-mdns-13.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: <2002-12-3142236.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-mdns-13.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-mdns-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-12-3142236.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Dec 4 07:45:04 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08204 for ; Wed, 4 Dec 2002 07:45:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JYn8-0005CW-00 for namedroppers-data@psg.com; Wed, 04 Dec 2002 04:38:14 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #2) id 18JYn4-0005CJ-00 for namedroppers@ops.ietf.org; Wed, 04 Dec 2002 04:38:11 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07671; Wed, 4 Dec 2002 07:35:18 -0500 (EST) Message-Id: <200212041235.HAA07671@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-04.txt Date: Wed, 04 Dec 2002 07:35:18 -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 Filename : draft-ietf-dnsext-keyrr-key-signing-flag-04.txt Pages : 8 Date : 2002-12-3 With the DS record [1] the concept of key-signing and zone-signing keys has been introduced. Key-signing keys are the keys that sign the keyset only. In general, key-signing keys are the keys that are pointed to by DS records and are the first keys to be used when following a chain of trust into the zone. The key-signing keys only sign the KEY RRset at the apex of a zone, zone- signing keys sign all other data in a zone. We propose a flag to distinguish the key- signing key from other keys in the KEY RR set during DNSSEC operations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-keyrr-key-signing-flag-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-keyrr-key-signing-flag-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-keyrr-key-signing-flag-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-12-3142226.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-keyrr-key-signing-flag-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-keyrr-key-signing-flag-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-12-3142226.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Dec 4 11:19:45 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19484 for ; Wed, 4 Dec 2002 11:19:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Jc5N-000AXI-00 for namedroppers-data@psg.com; Wed, 04 Dec 2002 08:09:17 -0800 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.36 #2) id 18Jc5J-000AWj-00 for namedroppers@ops.ietf.org; Wed, 04 Dec 2002 08:09:14 -0800 Received: from x22.ripe.net.ripe.net (x22.ripe.net [193.0.1.22]) by birch.ripe.net (8.12.5/8.11.6) with ESMTP id gB4G998W013320 for ; Wed, 4 Dec 2002 17:09:09 +0100 Date: Wed, 4 Dec 2002 17:09:09 +0100 (CET) From: Bruce Campbell X-X-Sender: bc@x22.ripe.net To: namedroppers@ops.ietf.org Subject: Re: axfr-clarify supporting unauthorized users In-Reply-To: <3DED3FB9.2F6D93EC@daimlerchrysler.com> Message-ID: X-Meta-MD5: c6cca11e9061565d3fabb69ac7492996 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02, USER_AGENT_PINE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 3 Dec 2002, Kevin Darcy wrote in reply to DJBDNS implementor Bernstein: [long lines wordwrapped] > Dan, > RFC 1034 only mentions two possible outcomes of an AXFR request: > "an error, such as refused" or an answer consisting of "a sequence of > response messages", i.e. a zone transfer. Now, we all realize that > circumstances beyond the control of the DNS implementation may cause the > connection attempt to fail (network congestion, hardware errors, OS > crash, whatever), or to be prematurely broken, but RFC 1034, as a *DNS* > spec, describes what a DNS implementation should do (or attempt to do), > and TCP FIN is not among the options here. Surely you can see this, > can't you? I've been trying to work out why any person would consider TCP FIN to be used to terminate a connection due to query type (AXFR); and as near as I can figure, that design choice of djbdns stems from a paragraph in 4.2.2 (TCP usage) of 1035, which states (as part of suggested TCP connection management policies): - If the server needs to close a dormant connection to reclaim resources, it should wait until the connection has been idle for a period on the order of two minutes. In particular, the server should allow the SOA and AXFR request sequence (which begins a refresh operation) to be made on a single connection. Since the server would be unable to answer queries anyway, a unilateral close or reset may be used instead of a graceful close. Unfortunately, the language used in this paragraph is imprecise, and the paragraph can (has) lead to multiple interpretations. It should be clarified (hence a need for a clarification draft). I presume that Bernstein's interpretation of that paragraph in writing djbdns was something like: TCP Connections can be closed by the server after the connection has been idle for a period, eg two minutes. TCP Connections should allow multiple queries, eg SOA and AXFR on the same connection. If the server cannot answer a query (eg, has been configured not to do an AXFR of a zone to that particular client IP address), the connection may be immediately closed instead of gracefully. If my presumption is correct, Bernstein (and any other implementors who have taken the same course of arbitarily closing a connection due to local AXFR policy) have failed to read the rest of the 1034/1035 document set, and the meaning of the response code 'Refused' (1035, 4.1.1): Refused - The name server refuses to perform the specified operation for policy reasons. For example, a name server may not wish to provide the information to the particular requester, or a name server may not wish to perform a particular operation (e.g., zone transfer) for particular data. Another thing that such implementors have ignored is the following paragraph in 1034 4.3.5: When the poll shows that the zone has changed, then the secondary server must request a zone transfer via an AXFR request for the zone. The AXFR may cause an error, such as refused, but normally is answered by a sequence of response messages. The first and last messages must contain the data for the top authoritative node of the zone. My, rather obvious, interpretation of the above paragraph is: ( If you are using AXFR to transfer zones, ) When the poll made by the secondary shows that the zone has changed, then the secondary must request a zone transfer via an AXFR request for the zone. When making the AXFR request to an authoritative master, the response received by the secondary can be _one_ _of_: Error (eg, refused). or A sequence of response messages. ( Note lack of 'Closed Connection' as a possible response ) --==-- Bruce. > Now, you can perform as much semantic acrobatics as you wish over > whether that paragraph only applies to "secondary servers" or not, but > the fact that "refused" is mentioned as a legitimate response to an AXFR > request from "a secondary server", combined with the fact that the > companion RFC describes the "refused" RCODE as "the name server refuses > to perform the specified operation for policy reasons" means that it is > illogical to limit the definition of "secondary server" to "only those > entities which, by policy, are allowed to request and/or receive zone > transfers from me". To put it another way, the definition of "secondary > server" which you are proposing ineluctably leads to the conclusion that > "refused" could *never* be a valid, standards-conforming response to an > AXFR request. Yet clearly this line of thought is at odds with the RFC > 1034 verbiage to which Mark refers. -- 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 Dec 4 11:52:36 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21501 for ; Wed, 4 Dec 2002 11:52:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Jch5-000BiP-00 for namedroppers-data@psg.com; Wed, 04 Dec 2002 08:48:15 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #2) id 18Jch2-000Bi8-00 for namedroppers@ops.ietf.org; Wed, 04 Dec 2002 08:48:12 -0800 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 18Jch2-00013w-00 for namedroppers@ops.ietf.org; Wed, 04 Dec 2002 08:48:12 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: namedroppers Subject: draft-ietf-dnsext-axfr-clarify-05.txt Message-Id: Date: Wed, 04 Dec 2002 08:48:12 -0800 X-Spam-Status: No, hits=0.5 required=5.0 tests=SPAM_PHRASE_00_01,TO_LOCALPART_EQ_REAL version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit confession, other than djb, i have been the other wg member not in consensus on this document. as i said in yokohama, i was the one personally uncomfortable with the axfr document mandating the zone content being maintained exactly as served by the primary. i did not see why it was *necessary* for this to be done, and was hesitant as djb claimed his implementation would be adversely affected. yes dan, i was the one holding up progress of this document. i have recently become convinced that the primary's zone content on axfrs needs to be preserved purely so that subsequent ixfrs may be applied. randy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Dec 4 13:41:53 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27567 for ; Wed, 4 Dec 2002 13:41:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JeI1-000FSU-00 for namedroppers-data@psg.com; Wed, 04 Dec 2002 10:30:29 -0800 Received: from adsl-63-197-0-204.dsl.snfc21.pacbell.net ([63.197.0.204] helo=guava.araneus.fi) by psg.com with esmtp (Exim 3.36 #2) id 18JeHx-000FQk-00 for namedroppers@ops.ietf.org; Wed, 04 Dec 2002 10:30:25 -0800 Received: (from gson@localhost) by guava.araneus.fi (8.11.6/8.11.6) id gB4IUOb24090; Wed, 4 Dec 2002 10:30:24 -0800 (PST) Date: Wed, 4 Dec 2002 10:30:24 -0800 (PST) Message-Id: <200212041830.gB4IUOb24090@guava.araneus.fi> To: namedroppers@ops.ietf.org Subject: Re: repeating records In-Reply-To: <20021204011044.62945.qmail@cr.yp.to> References: <3DE54582.1C9704ED@daimlerchrysler.com> <4.3.1.2.20021127224733.0381c580@pop.gis.net> <4.3.1.2.20021129194515.038705b0@pop.gis.net> <20021130042703.23356.qmail@cr.yp.to> <200212022029.gB2KTA620609@guava.araneus.fi> <20021203201400.61073.qmail@cr.yp.to> <200212032329.gB3NTuP07138@guava.araneus.fi> <20021204011044.62945.qmail@cr.yp.to> X-Mailer: VM 7.04 under Emacs 20.7.1 From: gson@nominum.com (Andreas Gustafsson) X-Spam-Status: No, hits=-1.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk D. J. Bernstein writes: > Yes or no: Are you claiming that every DNS implementor, before choosing > to use (for example) BIND 8's strategy of sending glue whenever it's > referenced, _must_ understand and carefully weigh the implications? Yes. > If people really are misusing ``SHOULD'' for minor efficiency issues > (misinterpreting ``harm'' in section 6 of RFC 2119), we're going to need > a new word to point out real dangers such as over-eager retransmission. We already have one. It's called MUST. -- Andreas Gustafsson, gson@nominum.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Dec 4 17:04:01 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06372 for ; Wed, 4 Dec 2002 17:04:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JhQY-000OgK-00 for namedroppers-data@psg.com; Wed, 04 Dec 2002 13:51:30 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18JhQ4-000Oeq-00 for namedroppers@ops.ietf.org; Wed, 04 Dec 2002 13:51:01 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18JhQ2-000A4c-00 for namedroppers@ops.ietf.org; Wed, 04 Dec 2002 13:50:58 -0800 Message-ID: <20021204204941.81209.qmail@cr.yp.to> References: <3DE54582.1C9704ED@daimlerchrysler.com> <4.3.1.2.20021127224733.0381c580@pop.gis.net> <4.3.1.2.20021129194515.038705b0@pop.gis.net> <20021130042703.23356.qmail@cr.yp.to> <200212022029.gB2KTA620609@guava.araneus.fi> <20021203201400.61073.qmail@cr.yp.to> <200212032329.gB3NTuP07138@guava.araneus.fi> <20021204011044.62945.qmail@cr.yp.to> <200212041830.gB4IUOb24090@guava.araneus.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Date: 4 Dec 2002 20:49:41 -0000 Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Cc: sob@harvard.edu Subject: Re: repeating records X-Spam-Status: No, hits=2.7 required=5.0 tests=NO_MX_FOR_FROM,QUOTED_EMAIL_TEXT,REFERENCES,RESENT_TO, SPAM_PHRASE_03_05 version=2.43 X-Spam-Level: ** 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. your subscription address is 54830374684695-namedroppers@sublist.cr.yp.to, please post from it or, 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 the alternate address added to the list of addresses from which submissions are automatically accepted. ] BIND company employee Andreas Gustafsson writes: > D. J. Bernstein writes: > > Yes or no: Are you claiming that every DNS implementor, before choosing > > to use (for example) BIND 8's strategy of sending glue whenever it's > > referenced, _must_ understand and carefully weigh the implications? > Yes. Let me get this straight. Because the BIND 4/8 strategy (for the sake of server simplicity) generates slightly more traffic (for some zones), you conclude that every DNS implementor _must_ understand and carefully weigh the implications before choosing that strategy? After many years of BIND 4/8 working just fine without anybody worrying about this, why did this suddenly become an issue? Maybe the .com administrators care, but how does that justify demanding that _every_ implementor worry about this? Are you sure that you aren't wildly exaggerating the importance of an absurdly small issue? Do you also conclude that every DNS implementor _must_ understand and carefully weigh the implications before putting DNS records into LDAP? (``DNS servers SHOULD NOT use LDAP.'') And that every DNS implementor _must_ understand and carefully weigh the implications before attempting to use EDNS0? (``DNS servers SHOULD NOT use EDNS0.'') If the last two answers are no: What, precisely, is the relevant difference between these situations and the repeated-glue situation? Don't you agree that these things generate more traffic? A moment ago you said how important it was for all implementors to pay attention to efficiency issues; are you retreating from that principle? How would you like it if other people tried to force you to imitate their implementation decisions by declaring that implementations SHOULD make those decisions---never mind actual costs and benefits? > > If people really are misusing ``SHOULD'' for minor efficiency issues > > (misinterpreting ``harm'' in section 6 of RFC 2119), we're going to need > > a new word to point out real dangers such as over-eager retransmission. > We already have one. It's called MUST. I'm cc'ing this to Bradner. RFC 2119 is obviously meant to stop people from pretending that every implementation decision is a protocol issue; it is not succeeding at this goal. ---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 Dec 4 18:58:11 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11156 for ; Wed, 4 Dec 2002 18:58:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Jj6c-0004cd-00 for namedroppers-data@psg.com; Wed, 04 Dec 2002 15:39:02 -0800 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.36 #2) id 18Jj6U-0004cD-00 for namedroppers@ops.ietf.org; Wed, 04 Dec 2002 15:38:55 -0800 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.5/8.12.5) with ESMTP id gB4NcZtB002203; Thu, 5 Dec 2002 10:38:35 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200212042338.gB4NcZtB002203@drugs.dv.isc.org> To: "D. J. Bernstein" Cc: namedroppers@ops.ietf.org, sob@harvard.edu From: Mark.Andrews@isc.org Subject: Re: repeating records In-reply-to: Your message of "04 Dec 2002 20:49:41 -0000." <20021204204941.81209.qmail@cr.yp.to> Date: Thu, 05 Dec 2002 10:38:35 +1100 X-Spam-Status: No, hits=0.5 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > BIND company employee Andreas Gustafsson writes: > > D. J. Bernstein writes: > > > Yes or no: Are you claiming that every DNS implementor, before choosing > > > to use (for example) BIND 8's strategy of sending glue whenever it's > > > referenced, _must_ understand and carefully weigh the implications? > > Yes. > > Let me get this straight. Because the BIND 4/8 strategy (for the sake of > server simplicity) generates slightly more traffic (for some zones), you > conclude that every DNS implementor _must_ understand and carefully > weigh the implications before choosing that strategy? Yes. The world is changing and zones are getting MUCH bigger. Part of the response to that was to support sending multiple records in one message so that the transfer could take advantage of DNS label compression. The second response was to eliminate the duplicate records. > After many years of BIND 4/8 working just fine without anybody worrying > about this, why did this suddenly become an issue? Maybe the .com > administrators care, but how does that justify demanding that _every_ > implementor worry about this? Are you sure that you aren't wildly > exaggerating the importance of an absurdly small issue? Where do you think the large zone operators get there servers from? They normally don't roll their own. Large zones are just one thing a implementor must think of when designing a nameserver. Transmission times have been a problem in the past. They currently arn't but DNSSEC is just around the corner and with DNSSEC comes a large increase in the volume of data that has to be transmitted. Also as a implementor it is not normally your bandwith (money) that is being wasted. > Do you also conclude that every DNS implementor _must_ understand and > carefully weigh the implications before putting DNS records into LDAP? > (``DNS servers SHOULD NOT use LDAP.'') And that every DNS implementor > _must_ understand and carefully weigh the implications before attempting > to use EDNS0? (``DNS servers SHOULD NOT use EDNS0.'') Yes. The choice of database backend is important. Yes. The choice involved in EDNS are important. > If the last two answers are no: What, precisely, is the relevant > difference between these situations and the repeated-glue situation? > Don't you agree that these things generate more traffic? A moment ago > you said how important it was for all implementors to pay attention to > efficiency issues; are you retreating from that principle? > > How would you like it if other people tried to force you to imitate > their implementation decisions by declaring that implementations SHOULD > make those decisions---never mind actual costs and benefits? No one is forcing you to send each record once. Just to make sure you think about it carefully before you decided to send a record multiple times. > > > If people really are misusing ``SHOULD'' for minor efficiency issues > > > (misinterpreting ``harm'' in section 6 of RFC 2119), we're going to need > > > a new word to point out real dangers such as over-eager retransmission. > > We already have one. It's called MUST. > > I'm cc'ing this to Bradner. RFC 2119 is obviously meant to stop people > from pretending that every implementation decision is a protocol issue; > it is not succeeding at this goal. It's not a minor issue to some zone operators. It has in the past come close to causing the DNS to fail for a large portions of the net. Mark > ---D. J. Bernstein, Associate Professor, Department of Mathematics, > Statistics, and Computer Science, University of Illinois at Chicago -- 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 Wed Dec 4 19:36:19 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12626 for ; Wed, 4 Dec 2002 19:36:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Jjod-0007F6-00 for namedroppers-data@psg.com; Wed, 04 Dec 2002 16:24:31 -0800 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.36 #2) id 18Jjoa-0007EB-00; Wed, 04 Dec 2002 16:24:28 -0800 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.5/8.12.5) with ESMTP id gB50OQtB002433; Thu, 5 Dec 2002 11:24:26 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200212050024.gB50OQtB002433@drugs.dv.isc.org> To: Randy Bush Cc: namedroppers From: Mark.Andrews@isc.org Subject: Re: draft-ietf-dnsext-axfr-clarify-05.txt In-reply-to: Your message of "Wed, 04 Dec 2002 08:48:12 -0800." Date: Thu, 05 Dec 2002 11:24:26 +1100 X-Spam-Status: No, hits=1.2 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_03_05, TO_BE_REMOVED_REPLY version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > > > > confession, other than djb, i have been the other wg member not in > consensus on this document. > > as i said in yokohama, i was the one personally uncomfortable with > the axfr document mandating the zone content being maintained > exactly as served by the primary. i did not see why it was > *necessary* for this to be done, and was hesitant as djb claimed > his implementation would be adversely affected. > > > yes dan, i was the one holding up progress of this document. > > i have recently become convinced that the primary's zone content on > axfrs needs to be preserved purely so that subsequent ixfrs may be > applied. Randy, while I'm glad that you agree that the zone contents need to be preserved, this sounds like you discount the need to fix the operational problems caused as the result replacing data in the zone with that from another source. This is *not* just a IXFR problem. It causes problems with servers that don't support IXFR. I would hate to see a implementor say "I don't need to do this because I don't support IXFR". See <200211280030.gAS0UYgU009457@drugs.dv.isc.org> for a detailed example of a non IXFR related problem that is fixed by preserving the zones contents. Mark > 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: -- 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 Wed Dec 4 21:19:54 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15425 for ; Wed, 4 Dec 2002 21:19:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JlV2-000DSl-00 for namedroppers-data@psg.com; Wed, 04 Dec 2002 18:12:24 -0800 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #2) id 18JlV0-000DSU-00 for namedroppers@ops.ietf.org; Wed, 04 Dec 2002 18:12:22 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 90417379FC6 for ; Thu, 5 Dec 2002 02:12:21 +0000 (GMT) From: Paul Vixie To: namedroppers Subject: Re: draft-ietf-dnsext-axfr-clarify-05.txt In-Reply-To: Message from Mark.Andrews@isc.org of "Thu, 05 Dec 2002 11:24:26 +1100." <200212050024.gB50OQtB002433@drugs.dv.isc.org> X-Mailer: MH-E 7.0; nmh 1.0.4; Emacs 21.2 Date: Thu, 05 Dec 2002 02:12:21 +0000 Message-Id: <20021205021221.90417379FC6@as.vix.com> X-Spam-Status: No, hits=-1.4 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02, TO_LOCALPART_EQ_REAL version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > This is *not* just a IXFR problem. It causes problems with > servers that don't support IXFR. I would hate to see a > implementor say "I don't need to do this because I don't > support IXFR". > > See <200211280030.gAS0UYgU009457@drugs.dv.isc.org> for > a detailed example of a non IXFR related problem that is > fixed by preserving the zones contents. Forgetting for a moment about whether we can find a problem with it, there's a standards track RFC (#2136) with something to say on the matter of zone identity and zone ownership: 7.10. ... Visible (to DNS clients) SOA SERIALs need to differ if the zone differs. ... 7.18. Previously existing names which are occluded by a new zone cut are still considered part of the parent zone, for the purposes of zone transfers, even though queries for such names will be referred to the new subzone's servers. If a zone cut is removed, all parent zone names that were occluded by it will again become visible to queries. (This is a clarification of [RFC1034].) 7.19. If a server is authoritative for both a zone and its child, then queries for names at the zone cut between them will be answered authoritatively using only data from the child zone. (This is a clarification of [RFC1034].) So, whether a server can implicitly edit the data at the zone cut is not a matter of operational necessity or of personal taste. It's a matter of definitional correctness. A zone's identity is what the primary master says it is. Implementations such as BIND4, BIND8, and (apparently) DJBDNS who implicitly edit a zone's apex because they are also authoritative for the parent zone, are wrong. axfr-clarify is not what makes them wrong. They are just plain wrong. The fix to BIND4 or BIND8 is "upgrade to BIND9." -- 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 Dec 5 01:07:51 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21605 for ; Thu, 5 Dec 2002 01:07:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Jp3E-0002jh-00 for namedroppers-data@psg.com; Wed, 04 Dec 2002 21:59:56 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18Jp2m-0002g3-00 for namedroppers@ops.ietf.org; Wed, 04 Dec 2002 21:59:29 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18Jp2l-0000bP-00 for namedroppers@ops.ietf.org; Wed, 04 Dec 2002 21:59:27 -0800 Message-ID: <20021205051152.2321.qmail@cr.yp.to> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Date: 5 Dec 2002 05:11:52 -0000 Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-axfr-clarify-05.txt X-Spam-Status: No, hits=2.1 required=5.0 tests=NO_MX_FOR_FROM,QUOTED_EMAIL_TEXT,REFERENCES,RESENT_TO, SPAM_PHRASE_01_02 version=2.43 X-Spam-Level: ** 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. your subscription address is 54830374684695-namedroppers@sublist.cr.yp.to, please post from it or, 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 the alternate address added to the list of addresses from which submissions are automatically accepted. ] Randy Bush writes: > yes dan, i was the one holding up progress of this document. It's always interesting to see a glimpse into the mind of Bush: * Bush can make these decisions singlehandedly. After all, Bush is more important than anyone else! * Consensus is, by definition, whatever Bush is thinking. Remember, Bush is more important than anyone else! * Bush doesn't need to actually _defend_ his opinions; he can simply state them. Remember, Bush is more important than anyone else! Most importantly, all of this is The Way Things Ought To Be, because there's nothing in the IETF procedures prohibiting it. ---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 Dec 5 02:44:39 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03235 for ; Thu, 5 Dec 2002 02:44:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Jqan-0009DC-00 for namedroppers-data@psg.com; Wed, 04 Dec 2002 23:38:41 -0800 Received: from gw.gbch.net ([203.143.238.93] ident=9hrmm1) by psg.com with smtp (Exim 3.36 #2) id 18Jqa9-000997-00 for namedroppers@ops.ietf.org; Wed, 04 Dec 2002 23:38:01 -0800 Received: (qmail 67867 invoked by uid 1001); 5 Dec 2002 17:37:50 +1000 X-Posted-By: GJB-Post 2.29 08-Nov-2002 X-Operating-System: FreeBSD 4.2-RELEASE i386 X-Uptime: 154 days, 23:35 X-Location: Brisbane, Australia; 27.49841S 152.98439E X-URL: http://www.gbch.net/gjb.html X-Image-URL: http://www.gbch.net/gjb/gjb-auug048.gif X-GPG-Fingerprint: EBB2 2A92 A79D 1533 AC00 3C46 5D83 B6FB 4B04 B7D6 X-PGP-Public-Keys: http://www.gbch.net/keys.html Message-Id: Date: Thu, 05 Dec 2002 17:37:50 +1000 From: Greg Black To: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-axfr-clarify-05.txt References: <20021205051152.2321.qmail@cr.yp.to> In-reply-to: <20021205051152.2321.qmail@cr.yp.to> of 05 Dec 2002 05:11:52 GMT Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-2.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES,SPAM_PHRASE_01_02 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk "D. J. Bernstein" wrote: | [ post by non-subscriber. [...] Perhaps that should be "post by deliberately stupid subscriber". | It's always interesting to see a glimpse into the mind of Bush: Perhaps. But it's certainly become utterly uninteresting to see any more into the mind of Bernstein. For years I have said that one should not make decisions about the software one deploys based on one's perceptions of the personality of its author; and I have said that it's good to have multiple implementations of important infrastructure software. And, as part of putting my metaphorical money where my mouth is, I have used Bernstein's qmail and djbdns utilities. This latest sorry saga of bullying, name-calling, arrogance and bloody-mindedness on the namedroppers list has caused me to have another think about this. I really don't want to get caught up in some backwater with Bernstein's software because he can't get his head around the simple process of co-operative development of standards. I've never liked BIND, and I still don't like it, but I'm going to learn how to set it up (it's changed quite a lot from v4, which is what was current when I last used it); and I will probably learn how to install postfix in place of qmail (although that will also mean that I'll have to move all my mailing lists away from Bernstein's ezmlm, which will take some time and effort). The upside is that I will now be able to filter all Bernstein's messages from my mailbox so that I never again will need to see his ranting. And I'll then be able to stomach this list. So it's not all bad. In fact, what would be really nice would be to see everybody just stop responding to Bernstein, so that those of us who filter him out won't have to see the responses to him either ... Greg -- 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 Dec 5 09:17:59 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12437 for ; Thu, 5 Dec 2002 09:17:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Jwcx-000NC6-00 for namedroppers-data@psg.com; Thu, 05 Dec 2002 06:05:19 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #2) id 18Jwcu-000NBt-00 for namedroppers@ops.ietf.org; Thu, 05 Dec 2002 06:05:16 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11695; Thu, 5 Dec 2002 09:02:24 -0500 (EST) Message-Id: <200212051402.JAA11695@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-delegation-signer-12.txt Date: Thu, 05 Dec 2002 09:02:24 -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 : Delegation Signer Resource Record Author(s) : O. Gudmundsson Filename : draft-ietf-dnsext-delegation-signer-12.txt Pages : 14 Date : 2002-12-4 The delegation signer (DS) resource record is inserted at a zone cut (i.e., a delegation point) to indicate that the delegated zone is digitally signed and that the delegated zone recognizes the indicated key as a valid zone key for the delegated zone. The DS RR is a modification to the DNS Security Extensions definition, motivated by operational considerations. The intent is to use this resource record as an explicit statement about the delegation, rather than relying on inference. This document defines the DS RR, gives examples of how it is used and the implications of this record on resolvers. This change is not backwards compatible with RFC 2535. This document updates RFC1035, RFC2535, RFC3008 and RFC3090. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-delegation-signer-12.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-delegation-signer-12.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-delegation-signer-12.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: <2002-12-4093235.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-delegation-signer-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-delegation-signer-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-12-4093235.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 Dec 5 11:20:31 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18105 for ; Thu, 5 Dec 2002 11:20:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JydY-0002hD-00 for namedroppers-data@psg.com; Thu, 05 Dec 2002 08:14:04 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18Jyd3-0002ec-00 for namedroppers@ops.ietf.org; Thu, 05 Dec 2002 08:13:33 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18Jyd1-0000dv-00 for namedroppers@ops.ietf.org; Thu, 05 Dec 2002 08:13:31 -0800 Message-ID: <20021205074922.32979.qmail@cr.yp.to> References: <20021203193812.52010.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Date: 5 Dec 2002 07:49:22 -0000 Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: in support of axfr-clarify X-Spam-Status: No, hits=2.1 required=5.0 tests=NO_MX_FOR_FROM,QUOTED_EMAIL_TEXT,REFERENCES,RESENT_TO, SPAM_PHRASE_01_02 version=2.43 X-Spam-Level: ** 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. your subscription address is 54830374684695-namedroppers@sublist.cr.yp.to, please post from it or, 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 the alternate address added to the list of addresses from which submissions are automatically accepted. ] BIND company director David Conrad writes: > Do you have any proof that "the BIND company" (who is this, exactly?) See http://cr.yp.to/djbdns/blurb/bindmoney.html. > is "packing this standards committee"? The decisions are being made by Gudmundsson, who has been paid for working on BIND, and Bush, whose biases are obvious from an inspection of the messages that he has censored. Practically all of the promotion of axfr-clarify has come from BIND company people. Even worse, some of those people haven't disclosed their connection to the BIND company. ---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 Dec 5 11:50:59 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19196 for ; Thu, 5 Dec 2002 11:50:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Jz4z-0003zi-00 for namedroppers-data@psg.com; Thu, 05 Dec 2002 08:42:25 -0800 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #2) id 18Jz4T-0003xH-00 for namedroppers@ops.ietf.org; Thu, 05 Dec 2002 08:41:53 -0800 Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id B8E51137F0C; Thu, 5 Dec 2002 08:41:39 -0800 (PST) Date: Thu, 5 Dec 2002 08:41:39 -0800 Subject: Re: in support of axfr-clarify Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: namedroppers@ops.ietf.org To: "D. J. Bernstein" From: David Conrad In-Reply-To: <20021205074922.32979.qmail@cr.yp.to> Message-Id: <6D3A9EB6-0870-11D7-BA10-000393DB42B2@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) X-Spam-Status: No, hits=-4.1 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02,TO_BE_REMOVED_REPLY,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Bernstein, You are a liar. An incompetent one at that. Rgds, -drc On Wednesday, December 4, 2002, at 11:49 PM, liar D. J. Bernstein wrote: > [ post by non-subscriber. with the massive amount of spam, it is easy > to miss > and therefore delete posts by non-subscribers. your subscription > address is > 54830374684695-namedroppers@sublist.cr.yp.to, please post from it > or, 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 the alternate address added to the list of addresses from which > submissions are automatically accepted. ] > > BIND company director David Conrad writes: >> Do you have any proof that "the BIND company" (who is this, exactly?) > > See http://cr.yp.to/djbdns/blurb/bindmoney.html. > >> is "packing this standards committee"? > > The decisions are being made by Gudmundsson, who has been paid for > working on BIND, and Bush, whose biases are obvious from an inspection > of the messages that he has censored. Practically all of the promotion > of axfr-clarify has come from BIND company people. Even worse, some of > those people haven't disclosed their connection to the BIND company. > > ---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: > -- 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 Dec 5 12:06:52 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19946 for ; Thu, 5 Dec 2002 12:06:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JzMC-0004u9-00 for namedroppers-data@psg.com; Thu, 05 Dec 2002 09:00:12 -0800 Received: from portal.hamachi.org ([140.239.227.17]) by psg.com with esmtp (Exim 3.36 #2) id 18JzLg-0004r5-00 for namedroppers@ops.ietf.org; Thu, 05 Dec 2002 08:59:40 -0800 Received: from syn.hamachi.org (localhost [127.0.0.1]) by portal.hamachi.org (Postfix) with ESMTP id 9D76217926 for ; Thu, 5 Dec 2002 11:55:31 -0500 (EST) Received: from syn.hamachi.org (sommerfeld@localhost) by syn.hamachi.org (8.11.6/8.8.8) with ESMTP id gB5GxOg06337 for ; Thu, 5 Dec 2002 11:59:24 -0500 (EST) Message-Id: <200212051659.gB5GxOg06337@syn.hamachi.org> From: Bill Sommerfeld To: namedroppers@ops.ietf.org Subject: in support of axfr-clarify Reply-To: sommerfeld@orchard.arlington.ma.us Date: Thu, 05 Dec 2002 11:59:24 -0500 X-Spam-Status: No, hits=1.7 required=5.0 tests=MSG_ID_ADDED_BY_MTA_3,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I support the current axfr-clarify draft as-is. -- 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 Dec 5 13:01:01 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21562 for ; Thu, 5 Dec 2002 13:01:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18K0Bc-0007YH-00 for namedroppers-data@psg.com; Thu, 05 Dec 2002 09:53:20 -0800 Received: from relay2.av8.net ([130.105.12.4] helo=citation.av8.net) by psg.com with esmtp (Exim 3.36 #2) id 18K0B6-0007VY-00 for namedroppers@ops.ietf.org; Thu, 05 Dec 2002 09:52:48 -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 MAA09821; Thu, 5 Dec 2002 12:49:18 -0500 Date: Thu, 5 Dec 2002 12:51:08 -0500 (EST) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: Bill Sommerfeld cc: namedroppers@ops.ietf.org Subject: Re: in support of axfr-clarify In-Reply-To: <200212051659.gB5GxOg06337@syn.hamachi.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.5 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,SPAM_PHRASE_02_03, TO_BE_REMOVED_REPLY,USER_AGENT_PINE,X_OSIRU_SPAM_SRC version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Where is the axfr-clarify draft? What is it that you support? --Dean On Thu, 5 Dec 2002, Bill Sommerfeld wrote: > I support the current axfr-clarify draft as-is. > > -- > 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 Dec 5 13:47:23 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23240 for ; Thu, 5 Dec 2002 13:47:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18K0vO-0009Yr-00 for namedroppers-data@psg.com; Thu, 05 Dec 2002 10:40:38 -0800 Received: from boreas.isi.edu ([128.9.160.161]) by psg.com with esmtp (Exim 3.36 #2) id 18K0vL-0009YS-00 for namedroppers@ops.ietf.org; Thu, 05 Dec 2002 10:40:35 -0800 Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6/8.11.2) id gB5IeTw21857; Thu, 5 Dec 2002 10:40:29 -0800 (PST) From: Bill Manning Message-Id: <200212051840.gB5IeTw21857@boreas.isi.edu> Subject: Re: in support of axfr-clarify In-Reply-To: from Dean Anderson at "Dec 5, 2 12:51:08 pm" To: dean@av8.com (Dean Anderson) Date: Thu, 5 Dec 2002 10:40:29 -0800 (PST) Cc: sommerfeld@orchard.arlington.ma.us, 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=-1.8 required=5.0 tests=IN_REP_TO,SIGNATURE_SHORT_SPARSE,SPAM_PHRASE_03_05 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit % Where is the axfr-clarify draft? What is it that you support? % % --Dean % % On Thu, 5 Dec 2002, Bill Sommerfeld wrote: % % > I support the current axfr-clarify draft as-is. % > Perhaps you missed this announcement to namedroppers: To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-axfr-clarify-05.txt Date: Tue, 03 Dec 2002 07:58:28 -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 X-AntiVirus: scanned by AMaViS 0.2.1 [Part #1: Type: text/plain, Encoding: 7bit, Size: 2079] A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : DNS Zone Transfer Protocol Clarifications Author(s) : A. Gustafsson Filename : draft-ietf-dnsext-axfr-clarify-05.txt Pages : 7 Date : 2002-12-2 -- --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 Thu Dec 5 14:58:20 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25693 for ; Thu, 5 Dec 2002 14:58:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18K1yv-000CGF-00 for namedroppers-data@psg.com; Thu, 05 Dec 2002 11:48:21 -0800 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #2) id 18K1yP-000CEe-00 for namedroppers@ops.ietf.org; Thu, 05 Dec 2002 11:47:49 -0800 Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 84BA2137F13 for ; Thu, 5 Dec 2002 11:47:35 -0800 (PST) Date: Thu, 5 Dec 2002 11:47:35 -0800 Subject: Re: Bernstein is a liar (was: in support of axfr-clarify) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) From: David Conrad To: namedroppers@ops.ietf.org Content-Transfer-Encoding: 7bit In-Reply-To: <6D3A9EB6-0870-11D7-BA10-000393DB42B2@nominum.com> Message-Id: <66B9C6DD-088A-11D7-BA10-000393DB42B2@nominum.com> X-Mailer: Apple Mail (2.548) X-Spam-Status: No, hits=-3.8 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_02_03,TO_BE_REMOVED_REPLY,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Yowsa. Based on the number of private email I've received, it appears the Danster is nothing if not consistent about lying. To forestall additional requests: I will not expand on namedroppers on the myriad lies, half-truths, misconceptions, irrelevancies, and down right stupidities on Bernstein's web site -- the signal to noise is low enough already. Perhaps a separate mailing list should be set up (maybe 'djblies'?), to which observations of Bernstein's deceits could be sent? Problem is, it'd be a high volume list... Rgds, -drc On Thursday, December 5, 2002, at 08:41 AM, David Conrad wrote: > Bernstein, > > You are a liar. An incompetent one at that. > > Rgds, > -drc > > On Wednesday, December 4, 2002, at 11:49 PM, liar D. J. Bernstein > wrote: > >> [ post by non-subscriber. with the massive amount of spam, it is >> easy to miss >> and therefore delete posts by non-subscribers. your subscription >> address is >> 54830374684695-namedroppers@sublist.cr.yp.to, please post from it >> or, 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 the alternate address added to the list of addresses from which >> submissions are automatically accepted. ] >> >> BIND company director David Conrad writes: >>> Do you have any proof that "the BIND company" (who is this, exactly?) >> >> See http://cr.yp.to/djbdns/blurb/bindmoney.html. >> >>> is "packing this standards committee"? >> >> The decisions are being made by Gudmundsson, who has been paid for >> working on BIND, and Bush, whose biases are obvious from an inspection >> of the messages that he has censored. Practically all of the promotion >> of axfr-clarify has come from BIND company people. Even worse, some of >> those people haven't disclosed their connection to the BIND company. >> >> ---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: >> > > > -- > 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 Dec 5 15:41:06 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27452 for ; Thu, 5 Dec 2002 15:41:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18K2gf-000E0E-00 for namedroppers-data@psg.com; Thu, 05 Dec 2002 12:33:33 -0800 Received: from relay2.av8.net ([130.105.12.4] helo=citation.av8.net) by psg.com with esmtp (Exim 3.36 #2) id 18K2g8-000DzY-00 for namedroppers@ops.ietf.org; Thu, 05 Dec 2002 12:33:00 -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 PAA07205; Thu, 5 Dec 2002 15:26:17 -0500 Date: Thu, 5 Dec 2002 15:27:55 -0500 (EST) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: David Conrad cc: namedroppers@ops.ietf.org Subject: Re: Bernstein is a liar (was: in support of axfr-clarify) In-Reply-To: <66B9C6DD-088A-11D7-BA10-000393DB42B2@nominum.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,SPAM_PHRASE_01_02,USER_AGENT_PINE, X_OSIRU_SPAM_SRC version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I'd like to be on that list. I looked at the page Bernstein posted, and I didn't see anything on it that was false. I'm on some--but not all--of the lists he quotes from and remember some of the messages he quotes. I'm sure they can be found in archives of those lists. Accusations of lying are serious in an acedemic/professional setting. People stake their credentials on such things. I'd like to investigate these claims offline, and report back on findings. I think the name of the should be djb-investigators so as to not appear prejudical. --Dean On Thu, 5 Dec 2002, David Conrad wrote: > Yowsa. > > Based on the number of private email I've received, it appears the > Danster is nothing if not consistent about lying. > > To forestall additional requests: I will not expand on namedroppers on > the myriad lies, half-truths, misconceptions, irrelevancies, and down > right stupidities on Bernstein's web site -- the signal to noise is low > enough already. > > Perhaps a separate mailing list should be set up (maybe 'djblies'?), to > which observations of Bernstein's deceits could be sent? Problem is, > it'd be a high volume list... -- 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 Dec 5 16:30:35 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01086 for ; Thu, 5 Dec 2002 16:30:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18K3Tr-000FxZ-00 for namedroppers-data@psg.com; Thu, 05 Dec 2002 13:24:23 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18K3TM-000Fwi-00 for namedroppers@ops.ietf.org; Thu, 05 Dec 2002 13:23:52 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18K3TL-0000wE-00 for namedroppers@ops.ietf.org; Thu, 05 Dec 2002 13:23:51 -0800 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) In-Reply-To: <66B9C6DD-088A-11D7-BA10-000393DB42B2@nominum.com> Message-Id: <3FE18844-0890-11D7-8F44-003065F376B6@aaronsw.com> Content-Transfer-Encoding: 7bit Date: Thu, 5 Dec 2002 14:29:27 -0600 Subject: djb-discuss list (was: Bernstein is a liar) Cc: namedroppers@ops.ietf.org, djb-discuss@notabug.com To: David Conrad From: Aaron Swartz X-Spam-Status: No, hits=-1.5 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RESENT_TO, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_02_03,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. ] David Conrad wrote: > Perhaps a separate mailing list should be set up (maybe 'djblies'?), > to which observations of Bernstein's deceits could be sent? I've set up djb-discuss@notabug.com for discussion of D. J. Bernstein. To subscribe, send an empty message to djb-discuss-subscribe@notabug.com. -- Aaron Swartz [http://www.aaronsw.com] I'll be in SanFran for the Creative Commons launch the week of Dec15. -- 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 Dec 5 19:06:47 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05612 for ; Thu, 5 Dec 2002 19:06:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18K5g9-000MBw-00 for namedroppers-data@psg.com; Thu, 05 Dec 2002 15:45:13 -0800 Received: from [209.10.143.221] (helo=neonym.net) by psg.com with esmtp (Exim 3.36 #2) id 18K5fd-000M9f-00 for namedroppers@ops.ietf.org; Thu, 05 Dec 2002 15:44:41 -0800 Received: from [207.120.28.115] ([::ffff:207.120.28.115]) (AUTH: PLAIN michael, ) by neonym.net with esmtp; Thu, 05 Dec 2002 05:31:27 -0500 Subject: Re: SRV RR Questions From: Michael Mealling To: Cricket Liu Cc: bind9-users@isc.org, namedroppers@ops.ietf.org In-Reply-To: <005a01c29cb0$8025e720$0200a8c0@nxdomain.com> References: <3DEFAFC7.60002@jpl.nasa.gov> <005a01c29cb0$8025e720$0200a8c0@nxdomain.com> Organization: Harriman Heavy Industries, Inc. Message-Id: <1039131709.4922.21.camel@blackdell.neonym.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.2.0 Date: 05 Dec 2002 18:41:49 -0500 X-Spam-Status: No, hits=-1.5 required=5.0 tests=IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Thu, 2002-12-05 at 17:48, Cricket Liu wrote: > Dave Wilcox wrote: > > Are the underscores really required? or could I use: > > > > service.protocol.target > > The underscores are there by design, to avoid naming collisions with > existing domain names. As the author of RFC 3403 and 3404 and the co-author of the update to RFC 2916 (ENUM), I get asked this quite a bit. Usually of the form: The DDDS documents don't have the underscores that RFC 2782 says have to be there. Does 2782 require me to put them in there or is RFC 3403 right? The issue is/was that one of the iterations of the 2782 draft had language saying that, if SRV was being used in a context where a client was explicitly directed to retrieve a set of SRV records for an exact domainname instead of doing the query-language-encoded-as-a-domainname defined in 2782, then there was no requirement to use the underscores. Due to time and those inevitible miscommunications that text never made it into the final version that became 2782. Thus there is now a confusion between 2872 and 3403 about whether or not '_' is needed in the specific way that the DDDS uses SRVs. Is it possible to get some kind of clarification that this is indeed the case and that I don't need to go update 3403 and 3404 just to stick an underscore into a domain-name that doesn't need it? -MM -- 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 Dec 5 21:30:58 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10277 for ; Thu, 5 Dec 2002 21:30:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18K859-0003Ed-00 for namedroppers-data@psg.com; Thu, 05 Dec 2002 18:19:11 -0800 Received: from mx04.gis.net ([208.218.130.12] helo=gis.net) by psg.com with esmtp (Exim 3.36 #2) id 18K84U-0003AO-00 for namedroppers@ops.ietf.org; Thu, 05 Dec 2002 18:18:30 -0800 Received: from tecotoo.www.gis.net ([67.30.184.52]) by mx04.gis.net; Thu, 05 Dec 2002 21:18:25 -0500 Received: from localhost (localhost [127.0.0.1]) by tecotoo.www.gis.net (NTMail 3.02.13) with ESMTP id ha029465 for ; Thu, 5 Dec 2002 21:22:05 -0500 Message-Id: <4.3.1.2.20021205205923.03865be0@pop.gis.net> X-Sender: mayer@pop.gis.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 05 Dec 2002 21:20:35 -0500 To: namedroppers@ops.ietf.org From: Danny Mayer Subject: Re: in support of axfr-clarify In-Reply-To: <20021205074922.32979.qmail@cr.yp.to> References: <20021203193812.52010.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Info: NTMail 3.02 Server on TECOTOO X-Rcpt-To: X-Spam-Status: No, hits=0.5 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM, REFERENCES,SPAM_PHRASE_05_08,X_OSIRU_DUL version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 02:49 AM 12/5/02, D. J. Bernstein wrote: >[ post by non-subscriber. with the massive amount of spam, it is easy to miss > and therefore delete posts by non-subscribers. your subscription > address is > 54830374684695-namedroppers@sublist.cr.yp.to, please post from it or, > 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 the alternate address added to the list of addresses from which > submissions are automatically accepted. ] > >BIND company director David Conrad writes: > > Do you have any proof that "the BIND company" (who is this, exactly?) > >See http://cr.yp.to/djbdns/blurb/bindmoney.html. > > > is "packing this standards committee"? > >The decisions are being made by Gudmundsson, who has been paid for >working on BIND, and Bush, whose biases are obvious from an inspection >of the messages that he has censored. Practically all of the promotion >of axfr-clarify has come from BIND company people. Even worse, some of >those people haven't disclosed their connection to the BIND company. > >---D. J. Bernstein, Associate Professor, Department of Mathematics, >Statistics, and Computer Science, University of Illinois at Chicago Stop acting like a child! If you can't act like an adult and discuss issues you shouldn't be posting at all. You say that you are a professor of mathematics yet your postings to this list seems to consist of nothing but attempts to harras, intimidate and browbeat the people who do not agree with you. You don't respond to technical questions asked and you don't support any of your technical arguments with anything but abuse. In mathematics you prove theorems with sequential logical coherent steps. That's what Q.E.D. is all about. Maybe you think that as a professor of mathematics you don't think it's necessary to do that any more. Start to act like an adult instead of a child and keep to the subjects for which this forum is designed. Danny -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Dec 5 23:38:35 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13706 for ; Thu, 5 Dec 2002 23:38:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18KA10-0009HI-00 for namedroppers-data@psg.com; Thu, 05 Dec 2002 20:23:02 -0800 Received: from peacock.verisign.com ([65.205.251.73]) by psg.com with esmtp (Exim 3.36 #2) id 18K9zj-0009DO-00 for namedroppers@ops.ietf.org; Thu, 05 Dec 2002 20:21:43 -0800 Received: from vhqpostal-gw2.verisign.com (verisign.com [65.205.251.56]) by peacock.verisign.com (8.12.1/) with ESMTP id gB64LJkw003248; Thu, 5 Dec 2002 20:21:19 -0800 (PST) Received: by vhqpostal-gw2.verisign.com with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Dec 2002 20:21:39 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: Aaron Swartz , David Conrad Cc: namedroppers@ops.ietf.org, djb-discuss@notabug.com Subject: RE: djb-discuss list Date: Thu, 5 Dec 2002 20:21:39 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_0066_01C29C9B.D3B566A0"; protocol="application/x-pkcs7-signature" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=3.9 required=5.0 tests=EXCHANGE_SERVER,MISSING_OUTLOOK_NAME,RCVD_IN_RFCI, SPAM_PHRASE_00_01,SUBJECT_IS_LIST 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_0066_01C29C9B.D3B566A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit This whole conversation has got way way out of control. I would second the proposition that people should refrain from making certain accusations. Regardless of whether you believe an allegation could be proved you might find it very expensive to do so if someone decided to get as Quentin Tarrantino would put it 'litigious on your ass'. Phill ------=_NextPart_000_0066_01C29C9B.D3B566A0 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 BQCgggGMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTIwNjA0 MjEwMFowIwYJKoZIhvcNAQkEMRYEFGpxa6ZDFWiswb0KBvRWFRfrebTxMFgGCSqGSIb3DQEJDzFL MEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcG BSsOAwIaMAoGCCqGSIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2Ug aXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChj KTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQO rwvJMA0GCSqGSIb3DQEBAQUABIGAk3dmfio8aJbWiq7O/eAbniwMpsOcNl7yQg8KmfxDw8HbsG0F aGNYqdWMkEOGxFHBZyY0M749WwTPr8/gOjyaCM6a0omllR/v+B1eFbaB+b5/FZkZUoiFsMunPz8g rfQ5bBETC0vhbslHmKGXoa/G7KrJC0welDEQVOITKqshGfcAAAAAAAA= ------=_NextPart_000_0066_01C29C9B.D3B566A0-- -- 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 Dec 6 01:26:59 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16367 for ; Fri, 6 Dec 2002 01:26:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18KBop-000FRx-00 for namedroppers-data@psg.com; Thu, 05 Dec 2002 22:18:35 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #2) id 18KBoJ-000FRU-00 for namedroppers@ops.ietf.org; Thu, 05 Dec 2002 22:18:03 -0800 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 18KBoJ-000OTx-00 for namedroppers@ops.ietf.org; Thu, 05 Dec 2002 22:18:03 -0800 Message-Id: <200212060449.gB64nFT10809@vacation.karoshi.com> In-Reply-To: from "Hallam-Baker, Phillip" at Dec 05, 2002 08:21:39 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: bmanning@vacation.karoshi.com Subject: Re: djb-discuss list To: pbaker@verisign.com (Hallam-Baker, Phillip) Date: Thu, 5 Dec 2002 20:49:15 -0800 (PST) Cc: me@aaronsw.com (Aaron Swartz), david.conrad@nominum.com (David Conrad), namedroppers@ops.ietf.org, djb-discuss@notabug.com X-Spam-Status: No, hits=-0.2 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,RESENT_TO, SPAM_PHRASE_01_02,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. ] > This whole conversation has got way way out of control. > > I would second the proposition that people should refrain from making > certain accusations. > > Regardless of whether you believe an allegation could be proved you > might find it very expensive to do so if someone decided to get as > Quentin Tarrantino would put it 'litigious on your ass'. > > > Phill actually, I appreciate that there is now a specific list to discuss software products of the DJB company. As adults, we can refrain from personal invective and focus on the merits of and support issues with DJB company software. --bill -- 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 Dec 6 01:30:00 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16405 for ; Fri, 6 Dec 2002 01:29:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18KBrh-000Fb9-00 for namedroppers-data@psg.com; Thu, 05 Dec 2002 22:21:33 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #2) id 18KBrD-000Fak-00 for namedroppers@ops.ietf.org; Thu, 05 Dec 2002 22:21:03 -0800 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 18KBrD-000OUu-00 for namedroppers@ops.ietf.org; Thu, 05 Dec 2002 22:21:03 -0800 Message-ID: <20021206060137.85921.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Date: 6 Dec 2002 06:01:37 -0000 Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: ietf@ietf.org Cc: iesg@ietf.org, namedroppers@ops.ietf.org Subject: namedroppers mismanagement: it never ends X-Spam-Status: No, hits=3.7 required=5.0 tests=NO_MX_FOR_FROM,RESENT_TO,SPAM_PHRASE_02_03 version=2.43 X-Spam-Level: *** 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. your subscription address is 54830374684695-namedroppers@sublist.cr.yp.to, please post from it or, 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 the alternate address added to the list of addresses from which submissions are automatically accepted. ] It has been a week since my latest attempt to get Bush to stop screwing around with my messages. As per his new instructions, I sent a message to namedroppers-owner@ops.ietf.org telling him to put djb@cr.yp.to on the list of addresses from which submissions are automatically accepted. Bush is continuing to delay and modify my messages. Furthermore, he has done nothing to correct the other problems I identified: * He is continuing to manually publish my subscription address, which used to be private. Presumably, if I switch to another subscription address that he knows about, he'll publish that address too. * He is still failing to send ``This message is not being delivered'' bounce notices back to his victims. Non-subscribers never realize that their namedroppers contributions have been destroyed. * He is continuing to delay messages from other people---in the last few days, a message from Bill Manning, a message from Randy Hall, a message from Ahau K'in, and some unknown number of messages that we'll never know about because they were silently discarded. Meanwhile, it has been nearly two days since any namedroppers messages have been delivered to my subscription address, while other subscribers have received quite a few messages. Forged unsubscription requests with no confirmation? ``Accidental'' problems in Bush's MTA? Stay tuned. ---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 Fri Dec 6 03:13:26 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28481 for ; Fri, 6 Dec 2002 03:13:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18KDTL-000Jul-00 for namedroppers-data@psg.com; Fri, 06 Dec 2002 00:04:31 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #2) id 18KDSo-000Jo5-00 for namedroppers@ops.ietf.org; Fri, 06 Dec 2002 00:03:58 -0800 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 18KDSo-000Opv-00 for namedroppers@ops.ietf.org; Fri, 06 Dec 2002 00:03:58 -0800 Message-ID: <20021205230613.A10428@shrubbery.net> References: <20021206060137.85921.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021206060137.85921.qmail@cr.yp.to>; from djb@cr.yp.to on Fri, Dec 06, 2002 at 06:01:37AM -0000 Date: Thu, 5 Dec 2002 23:06:13 -0800 From: john heasley To: "D. J. Bernstein" Cc: ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org Subject: Re: namedroppers mismanagement: it never ends X-Spam-Status: No, hits=-1.5 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,RESENT_TO, SPAM_PHRASE_02_03 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. ] i nominate bush, should he choose to accept, moderator of ietf@ietf.org. Fri, Dec 06, 2002 at 06:01:37AM -0000, D. J. Bernstein: > It has been a week since my latest attempt to get Bush to stop screwing > around with my messages. As per his new instructions, I sent a message > to namedroppers-owner@ops.ietf.org telling him to put djb@cr.yp.to on > the list of addresses from which submissions are automatically accepted. > > Bush is continuing to delay and modify my messages. Furthermore, he has > done nothing to correct the other problems I identified: > > * He is continuing to manually publish my subscription address, which > used to be private. Presumably, if I switch to another subscription > address that he knows about, he'll publish that address too. > > * He is still failing to send ``This message is not being delivered'' > bounce notices back to his victims. Non-subscribers never realize > that their namedroppers contributions have been destroyed. > > * He is continuing to delay messages from other people---in the last > few days, a message from Bill Manning, a message from Randy Hall, a > message from Ahau K'in, and some unknown number of messages that > we'll never know about because they were silently discarded. > > Meanwhile, it has been nearly two days since any namedroppers messages > have been delivered to my subscription address, while other subscribers > have received quite a few messages. Forged unsubscription requests with > no confirmation? ``Accidental'' problems in Bush's MTA? Stay tuned. > > ---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 Fri Dec 6 04:55:35 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00488 for ; Fri, 6 Dec 2002 04:55:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18KF53-000Nb3-00 for namedroppers-data@psg.com; Fri, 06 Dec 2002 01:47:33 -0800 Received: from d150-250-196.home.cgocable.net ([24.150.250.196] helo=dot-god.com) by psg.com with esmtp (Exim 3.36 #2) id 18KF4X-000NaX-00 for namedroppers@ops.ietf.org; Fri, 06 Dec 2002 01:47:01 -0800 Received: from localhost (baptista@localhost) by dot-god.com (8.11.4/8.11.4) with ESMTP id gB69lCR05655; Fri, 6 Dec 2002 04:47:12 -0500 Date: Fri, 6 Dec 2002 04:47:09 -0500 (EST) From: Joe Baptista To: David Conrad cc: Subject: Re: Bernstein is a liar (was: in support of axfr-clarify) In-Reply-To: <66B9C6DD-088A-11D7-BA10-000393DB42B2@nominum.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 On Thu, 5 Dec 2002, David Conrad wrote: > Perhaps a separate mailing list should be set up (maybe 'djblies'?), to > which observations of Bernstein's deceits could be sent? Problem is, > it'd be a high volume list... I've kept my eye on you over the years. Your nasty sometimes. regards joe baptista -- 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 Dec 6 11:28:29 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12694 for ; Fri, 6 Dec 2002 11:28:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18KL5g-000E87-00 for namedroppers-data@psg.com; Fri, 06 Dec 2002 08:12:36 -0800 Received: from [202.99.160.4] (helo=mail1) by psg.com with smtp (Exim 3.36 #2) id 18KL55-000E5Q-00 for namedroppers@ops.ietf.org; Fri, 06 Dec 2002 08:12:00 -0800 Received: from loki.ietf.org([132.151.1.177]) by www.heinfo.net(AIMC 2.9.5.2) with SMTP id jm223dec3886; Tue, 03 Dec 2002 05:25:56 +0800 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id QAA15260 for ietf-outbound.08@loki.ietf.org; Mon, 2 Dec 2002 16:00:01 -0500 (EST) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id PAA15046 for ; Mon, 2 Dec 2002 15:38:28 -0500 (EST) Received: by ietf.org (8.9.1a/8.9.1a) id PAA08710 for ietf-mainout@loki.ietf.org; Mon, 2 Dec 2002 15:35:39 -0500 (EST) X-Authentication-Warning: ietf.org: majordom set sender to owner-ietf@ietf.org using -f Received: from vorpal.notabug.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA01788 for ; Mon, 2 Dec 2002 13:39:49 -0500 (EST) Received: (qmail 10664 invoked from network); 2 Dec 2002 18:42:38 -0000 Received: from 12-249-96-16.client.attbi.com (HELO aaronsw.com) (12.249.96.16) by 0 with SMTP; 2 Dec 2002 18:42:38 -0000 Date: Mon, 2 Dec 2002 12:42:36 -0600 Subject: Re: namedroppers, continued Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: iesg@ietf.org, namedroppers@ops.ietf.org, ietf@ietf.org To: "Hallam-Baker, Phillip" From: Aaron Swartz In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org X-Spam-Status: No, hits=-3.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_01_02,USER_AGENT_APPLEMAIL,X_AUTH_WARNING, X_LOOP version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hallam-Baker, Phillip wrote: > The only way to resolve this issue properly would be to require every > submission to an IETF mailing list to be cryptographically signed > [and] to require the subscribers to register their signing key And how do we prevent spammers from registering their signing key? Are you suggesting that we change the IETF's open enrollment policy? -- 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 Dec 6 11:41:33 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13257 for ; Fri, 6 Dec 2002 11:41:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18KLNA-000F1E-00 for namedroppers-data@psg.com; Fri, 06 Dec 2002 08:30:40 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #2) id 18KLMf-000F0v-00 for namedroppers@ops.ietf.org; Fri, 06 Dec 2002 08:30:09 -0800 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 18KLMe-0000Qh-00 for namedroppers@ops.ietf.org; Fri, 06 Dec 2002 08:30:09 -0800 In-Reply-To: <20021205230613.A10428@shrubbery.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Fri, 6 Dec 2002 14:03:43 +0000 (GMT) From: Lloyd Wood To: john heasley cc: "D. J. Bernstein" , , , Subject: Re: namedroppers mismanagement: it never ends X-Spam-Status: No, hits=-3.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,RESENT_TO, SPAM_PHRASE_02_03,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 Thu, 5 Dec 2002, john heasley wrote: > i nominate bush, should he choose to accept, moderator of ietf@ietf.org. god, no. Bush is uniquely unqualified to run a mailing list - for a start, as an IESG member, he's policy, not admin. we already have ietf_censored, running quite quietly without disrupting the main flow of traffic on the ietf main list. (And recognising the policy/admin distinction is why Harald gave up running _censored on becoming IETF chair. I very much doubt Randy would have thought to have done the same.) Bush and Bernstein are both the kind of people who wish to rearrange the world entirely to their own satisfaction. How unfortunate that they must share that world. L. for us, anyway. -- 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 Dec 6 13:04:13 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16885 for ; Fri, 6 Dec 2002 13:04:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18KMft-000JcN-00 for namedroppers-data@psg.com; Fri, 06 Dec 2002 09:54:05 -0800 Received: from pigeon.verisign.com ([65.205.251.71]) by psg.com with esmtp (Exim 3.36 #2) id 18KMfN-000Jaj-00 for namedroppers@ops.ietf.org; Fri, 06 Dec 2002 09:53:34 -0800 Received: from vhqpostal-gw1.verisign.com (verisign.com [65.205.251.55]) by pigeon.verisign.com (8.12.1/) with ESMTP id gB6HqO47010680; Fri, 6 Dec 2002 09:52:24 -0800 (PST) Received: by vhqpostal-gw1.verisign.com with Internet Mail Service (5.5.2656.59) id ; Fri, 6 Dec 2002 09:53:29 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Aaron Swartz'" , "Hallam-Baker, Phillip" Cc: iesg@ietf.org, namedroppers@ops.ietf.org, ietf@ietf.org Subject: RE: namedroppers, continued Date: Fri, 6 Dec 2002 09:53:28 -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_0017_01C29D0D.53CCC6A0" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=3.0 required=5.0 tests=EXCHANGE_SERVER,MISSING_OUTLOOK_NAME,QUOTED_EMAIL_TEXT, RCVD_IN_RFCI,SPAM_PHRASE_01_02 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_0017_01C29D0D.53CCC6A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit One of the main reasons why anti-spam measures are failing is that the spam-artists are fraudulently hijacking people's email addresses so as to bypass anti-spam filters. My reading of the open enrollement policy is that anyone can contribute. I don't think that a secondary manual filter by which the first post to the list by an individual was only forwarded after moderation would breach that principle - but it would be one heck of a lot less work for the chairs than having to moderate every message. I certainly do not consider it an imposition on those who want to pontificate on Internet protocols to require them to actualy eat the company dog food and sign their messages with either PGP or S/MIME. I am not pushing a corporate interest here, a self signed certificate would be fine. I think that one of the problems for the PKI world is that the perfect has been the enemy of the good. OK you can argue that it would not exactly hurt VRSN if more people started to use security routinely, I don't think that would hurt the IETF either. Phill > -----Original Message----- > From: Aaron Swartz [mailto:me@aaronsw.com] > Sent: Monday, December 02, 2002 10:43 AM > To: Hallam-Baker, Phillip > Cc: iesg@ietf.org; namedroppers@ops.ietf.org; ietf@ietf.org > Subject: Re: namedroppers, continued > > > Hallam-Baker, Phillip wrote: > > The only way to resolve this issue properly would be to > require every > > submission to an IETF mailing list to be cryptographically signed > > [and] to require the subscribers to register their signing key > > And how do we prevent spammers from registering their signing key? Are > you suggesting that we change the IETF's open enrollment policy? > > -- > Aaron Swartz [http://www.aaronsw.com] > ------=_NextPart_000_0017_01C29D0D.53CCC6A0 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 BQCgggGMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTIwNjE3 NTMyOFowIwYJKoZIhvcNAQkEMRYEFC/t35zcYZ4RijuqUJbc9ww5KOUnMFgGCSqGSIb3DQEJDzFL MEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcG BSsOAwIaMAoGCCqGSIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2Ug aXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChj KTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQO rwvJMA0GCSqGSIb3DQEBAQUABIGAJ0DNxX7uWxc1u/F8zXFLjxSgQ8iyVDPBQfkik64KypwOru6u EFcI61o5emZBHLRCODdGoQT0PU7s0ZKLNQp4DIDdnP7cQF6Yj4iLNxAt4qUY2kII/l2lGaVDLmU3 lT+iOKxuAA4q1hgRqsFEOiZzOKzUXZ06lkfHHjbi+Tpsuq8AAAAAAAA= ------=_NextPart_000_0017_01C29D0D.53CCC6A0-- -- 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 Dec 6 14:19:09 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20449 for ; Fri, 6 Dec 2002 14:19:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18KNpc-000Nca-00 for namedroppers-data@psg.com; Fri, 06 Dec 2002 11:08:12 -0800 Received: from relay2.av8.net ([130.105.12.4] helo=citation.av8.net) by psg.com with esmtp (Exim 3.36 #2) id 18KNp6-000NaC-00 for namedroppers@ops.ietf.org; Fri, 06 Dec 2002 11:07:40 -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 NAA24792; Fri, 6 Dec 2002 13:56:37 -0500 Date: Fri, 6 Dec 2002 13:58:27 -0500 (EST) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: Danny Mayer cc: namedroppers@ops.ietf.org Subject: Re: in support of axfr-clarify In-Reply-To: <4.3.1.2.20021205205923.03865be0@pop.gis.net> 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, RCVD_IN_OSIRUSOFT_COM,SPAM_PHRASE_03_05, TO_BE_REMOVED_REPLY,USER_AGENT_PINE,X_OSIRU_SPAM_SRC version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Bernsteins reaction is a natural response to harrassment, and deceptive labeling regarding axfr-clarify. --Dean On Thu, 5 Dec 2002, Danny Mayer wrote: > At 02:49 AM 12/5/02, D. J. Bernstein wrote: > >[ post by non-subscriber. with the massive amount of spam, it is easy to miss > > and therefore delete posts by non-subscribers. your subscription > > address is > > 54830374684695-namedroppers@sublist.cr.yp.to, please post from it or, > > 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 the alternate address added to the list of addresses from which > > submissions are automatically accepted. ] > > > >BIND company director David Conrad writes: > > > Do you have any proof that "the BIND company" (who is this, exactly?) > > > >See http://cr.yp.to/djbdns/blurb/bindmoney.html. > > > > > is "packing this standards committee"? > > > >The decisions are being made by Gudmundsson, who has been paid for > >working on BIND, and Bush, whose biases are obvious from an inspection > >of the messages that he has censored. Practically all of the promotion > >of axfr-clarify has come from BIND company people. Even worse, some of > >those people haven't disclosed their connection to the BIND company. > > > >---D. J. Bernstein, Associate Professor, Department of Mathematics, > >Statistics, and Computer Science, University of Illinois at Chicago > > Stop acting like a child! If you can't act like an adult and discuss issues > you shouldn't be posting at all. You say that you are a professor of > mathematics yet your postings to this list seems to consist of nothing > but attempts to harras, intimidate and browbeat the people who do not > agree with you. You don't respond to technical questions asked and you > don't support any of your technical arguments with anything but abuse. > In mathematics you prove theorems with sequential logical coherent > steps. That's what Q.E.D. is all about. Maybe you think that as a > professor of mathematics you don't think it's necessary to do that any > more. Start to act like an adult instead of a child and keep to the subjects > for which this forum is designed. > > Danny > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- 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 Dec 6 14:23:22 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20615 for ; Fri, 6 Dec 2002 14:23:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18KNud-000Nsz-00 for namedroppers-data@psg.com; Fri, 06 Dec 2002 11:13:23 -0800 Received: from relay2.av8.net ([130.105.12.4] helo=citation.av8.net) by psg.com with esmtp (Exim 3.36 #2) id 18KNu7-000NqX-00 for namedroppers@ops.ietf.org; Fri, 06 Dec 2002 11:12:51 -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 OAA31228; Fri, 6 Dec 2002 14:08:53 -0500 Date: Fri, 6 Dec 2002 14:10:45 -0500 (EST) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: Aaron Swartz cc: David Conrad , , Subject: Re: djb-discuss list (was: Bernstein is a liar) In-Reply-To: <3FE18844-0890-11D7-8F44-003065F376B6@aaronsw.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,SPAM_PHRASE_03_05,SUBJECT_IS_LIST, USER_AGENT_PINE,X_OSIRU_SPAM_SRC version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Has anyone noticed that when DJB posts, the prefix message looks like this: [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. your subscription address is 54830374684695-namedroppers@sublist.cr.yp.to, please post from it or, 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 the alternate address added to the list of addresses from which submissions are automatically accepted. ] While other people's look like this: On Thu, 5 Dec 2002, Aaron Swartz wrote: > [ 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. ] Does anyone else find it strange that these should be different? -- 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 Dec 6 14:26:57 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20748 for ; Fri, 6 Dec 2002 14:26:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18KO01-000O9l-00 for namedroppers-data@psg.com; Fri, 06 Dec 2002 11:18:57 -0800 Received: from relay2.av8.net ([130.105.12.4] helo=citation.av8.net) by psg.com with esmtp (Exim 3.36 #2) id 18KNyj-000O6m-00 for namedroppers@ops.ietf.org; Fri, 06 Dec 2002 11:17:37 -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 OAA05007; Fri, 6 Dec 2002 14:11:16 -0500 Date: Fri, 6 Dec 2002 14:13:06 -0500 (EST) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: "Hallam-Baker, Phillip" cc: "'Aaron Swartz'" , , , Subject: RE: namedroppers, continued In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.1 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,SPAM_PHRASE_00_01,USER_AGENT_PINE, X_OSIRU_SPAM_SRC version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk How much spam is going to namedroppers? I haven't seen any. So, don't you think this has gone a little of the deep end? --Dean On Fri, 6 Dec 2002, Hallam-Baker, Phillip wrote: > One of the main reasons why anti-spam measures are failing is that the > spam-artists are fraudulently hijacking people's email addresses so as > to bypass anti-spam filters. -- 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 Dec 6 14:27:31 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20783 for ; Fri, 6 Dec 2002 14:27:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18KNnx-000NX2-00 for namedroppers-data@psg.com; Fri, 06 Dec 2002 11:06:29 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #2) id 18KNnR-000NUi-00 for namedroppers@ops.ietf.org; Fri, 06 Dec 2002 11:05:57 -0800 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 18KNmx-0001H1-00; Fri, 06 Dec 2002 11:05:27 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "D. J. Bernstein" Cc: namedroppers@ops.ietf.org, iesg@ietf.org, ietf@ietf.org Subject: Re: namedroppers, continued References: <20021129200711.22656.qmail@cr.yp.to> Message-Id: Date: Fri, 06 Dec 2002 11:05:27 -0800 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 Content-Transfer-Encoding: 7bit > From: "D. J. Bernstein" > To: namedroppers-owner@ops.ietf.org > Cc: namedroppers@ops.ietf.org, iesg@ietf.org, ietf@ietf.org > Subject: namedroppers, continued > ... > Okay, Bush: Put djb@cr.yp.to on the list of addresses from which > submissions are automatically accepted. sorry bernstein. as your message also was addressed to lists to which i subscribe, the copy to namedroppers-owner was deleted locally due to dupe message-id: detection. erik and harald pointed it out, and rob just forwarded a copy to me. so i have done the addition. thanks, as approving all your postings was becoming a pain in the butt. 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 Fri Dec 6 14:34:02 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21139 for ; Fri, 6 Dec 2002 14:34:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18KO5v-000OX8-00 for namedroppers-data@psg.com; Fri, 06 Dec 2002 11:25:03 -0800 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #2) id 18KO4L-000ORZ-00 for namedroppers@ops.ietf.org; Fri, 06 Dec 2002 11:23:25 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 61BAA379FC6; Fri, 6 Dec 2002 19:23:24 +0000 (GMT) From: Paul Vixie To: Lloyd Wood Cc: ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org Subject: Re: namedroppers mismanagement: it never ends In-Reply-To: Message from Lloyd Wood of "Fri, 06 Dec 2002 14:03:43 GMT." X-Mailer: MH-E 7.0; nmh 1.0.4; Emacs 21.2 Date: Fri, 06 Dec 2002 19:23:24 +0000 Message-Id: <20021206192324.61BAA379FC6@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 > Bush and Bernstein are both the kind of people who wish to rearrange > the world entirely to their own satisfaction. How unfortunate that > they must share that world. for the record, we must each work to create the world we want to live in (and that we want our children to live in.) i'm not in universal agreement with dbj nor with randy bush, but i won't fault them for their passion about making the world more like whatever they each think "better" means. -- 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 Dec 6 17:13:36 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27228 for ; Fri, 6 Dec 2002 17:13:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18KQUg-0006Hz-00 for namedroppers-data@psg.com; Fri, 06 Dec 2002 13:58:46 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #2) id 18KQUe-0006Hn-00 for namedroppers@ops.ietf.org; Fri, 06 Dec 2002 13:58:44 -0800 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 18KQUe-0002Nf-00 for namedroppers@ops.ietf.org; Fri, 06 Dec 2002 13:58:44 -0800 Message-Id: <5.2.0.9.2.20021206132845.01b56f88@mira-sjcm-4.cisco.com> In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Date: Fri, 06 Dec 2002 13:41:52 -0800 To: "Hallam-Baker, Phillip" From: Fred Baker Subject: RE: namedroppers, continued Cc: ietf@ietf.org, namedroppers@ops.ietf.org, iesg@ietf.org X-Spam-Status: No, hits=-0.5 required=5.0 tests=IN_REP_TO,RESENT_TO,SPAM_PHRASE_01_02 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. ] At 08:28 AM 12/2/2002 -0800, Hallam-Baker, Phillip wrote: >The only way to resolve this issue properly would be to require every >submission to an IETF mailing list to be cryptographically signed (PGP >or S/MIME), to require the subscribers to register their signing key and >to then filter the mail sent out on the list so that only signed mail >gets through. I would be in favor of that, personally, as long as we can ensure that the appropriate signature facility (be it RSA, PGP, or whatever) is freely available to all who need to use it. The issue here is not us corporate types who have a business reason to buy the software, it is the students who often lack the funds. The big issue would be the procedures for posting one's key to the appropriate place - what is to stop a spammer from posting a key and sending the spam anyway? I'm not proposing a mechanism, but someone who is good at such things might well find it of value. It doesn't address the "off topic" issue. As you say, that could be left to a working group chair equiped with formal procedures developed by consensus within the work group or adopted by the working group from a more general place (ie, the IETF could suggest a procedure, and the WG could adopt it if it didn't feel another procedure would be better). I have had a private exchange, over the past few days, with someone who wished that the IETF would please document some good spam-elimination procedure, so that it could be used world-wide to completely eliminate spam. I think that boils down to "provide a global PKI" in this solution, and presumes that spammers are incapable of using one. That might be a great research topic. Too bad nobody has ever thought of it before; we could really use the outcome of that research. (OK, so it's a lame attempt at humor...) I think it was Steve Bellovin that suggested a procedure for reducing the utility of spoofing source addresses in emails; if not, it was me and I happened to suggest something his favorite algorithm fit into, by having a host in each mail domain (mailid.example.com) be able to assert that its domain had or had not sent an email within a given recent time period whose MD5 hash, when divided by resulted in . I could write that up in an internet draft if folks think it makes sense. That would be a more global procedure that didn't require a PKI and only addressed spoofed addresses. -- 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 Dec 6 17:21:18 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27435 for ; Fri, 6 Dec 2002 17:21:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18KQek-0006sC-00 for namedroppers-data@psg.com; Fri, 06 Dec 2002 14:09:10 -0800 Received: from h-135-207-30-102.research.att.com ([135.207.30.102] helo=mail-blue.research.att.com) by psg.com with esmtp (Exim 3.36 #2) id 18KQei-0006qC-00 for namedroppers@ops.ietf.org; Fri, 06 Dec 2002 14:09:08 -0800 Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-blue.research.att.com (Postfix) with ESMTP id A6BA14CE6A; Fri, 6 Dec 2002 17:08:37 -0500 (EST) Received: from berkshire.research.att.com (postal.research.att.com [135.207.23.30]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id RAA13197; Fri, 6 Dec 2002 17:08:36 -0500 (EST) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id 6B0DF7B6B; Fri, 6 Dec 2002 17:08:36 -0500 (EST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: Fred Baker Cc: "Hallam-Baker, Phillip" , ietf@ietf.org, namedroppers@ops.ietf.org, iesg@ietf.org Subject: Re: namedroppers, continued Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 06 Dec 2002 17:08:36 -0500 Message-Id: <20021206220836.6B0DF7B6B@berkshire.research.att.com> 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 In message <5.2.0.9.2.20021206132845.01b56f88@mira-sjcm-4.cisco.com>, Fred Bake r writes: >At 08:28 AM 12/2/2002 -0800, Hallam-Baker, Phillip wrote: >>The only way to resolve this issue properly would be to require every >>submission to an IETF mailing list to be cryptographically signed (PGP >>or S/MIME), to require the subscribers to register their signing key and >>to then filter the mail sent out on the list so that only signed mail >>gets through. > >I would be in favor of that, personally, as long as we can ensure that the >appropriate signature facility (be it RSA, PGP, or whatever) is freely >available to all who need to use it. The issue here is not us corporate >types who have a business reason to buy the software, it is the students >who often lack the funds. The big issue would be the procedures for posting >one's key to the appropriate place - what is to stop a spammer from posting >a key and sending the spam anyway? I'm not proposing a mechanism, but >someone who is good at such things might well find it of value. > Well, it's also the availability of the right signature facility in the myriad email clients people use. > >I think it was Steve Bellovin that suggested a procedure for reducing the >utility of spoofing source addresses in emails; if not, it was me and I >happened to suggest something his favorite algorithm fit into, by having a >host in each mail domain (mailid.example.com) be able to assert that its >domain had or had not sent an email within a given recent time period >whose MD5 hash, when divided by resulted in >. I could write that up in an internet draft if folks >think it makes sense. That would be a more global procedure that didn't >require a PKI and only addressed spoofed addresses. > Wasn't me... --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com ("Firewalls" book) -- 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 Dec 6 17:42:41 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28322 for ; Fri, 6 Dec 2002 17:42:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18KR3C-0008AX-00 for namedroppers-data@psg.com; Fri, 06 Dec 2002 14:34:26 -0800 Received: from peacock.verisign.com ([65.205.251.73]) by psg.com with esmtp (Exim 3.36 #2) id 18KR3A-0008AI-00 for namedroppers@ops.ietf.org; Fri, 06 Dec 2002 14:34:24 -0800 Received: from vhqpostal-gw2.verisign.com (verisign.com [65.205.251.56]) by peacock.verisign.com (8.12.1/) with ESMTP id gB6MXtkw015778; Fri, 6 Dec 2002 14:33:55 -0800 (PST) Received: by vhqpostal-gw2.verisign.com with Internet Mail Service (5.5.2653.19) id ; Fri, 6 Dec 2002 14:34:17 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Dean Anderson'" , "Hallam-Baker, Phillip" Cc: "'Aaron Swartz'" , iesg@ietf.org, namedroppers@ops.ietf.org, ietf@ietf.org Subject: RE: namedroppers, continued Date: Fri, 6 Dec 2002 14:34:14 -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_0063_01C29D34.8C79ADC0" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=4.1 required=5.0 tests=EXCHANGE_SERVER,MISSING_OUTLOOK_NAME,RCVD_IN_RFCI, SPAM_PHRASE_00_01 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_0063_01C29D34.8C79ADC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit > How much spam is going to namedroppers? Well none since Randy Bush and a bunch of others turned on the moderator bit. The problem here is that having Randy Bush moderate is not a scalable solution to the problems of Spam in general. Phill ------=_NextPart_000_0063_01C29D34.8C79ADC0 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 BQCgggGMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTIwNjIy MzQxNFowIwYJKoZIhvcNAQkEMRYEFCXLlk5t23SSok61C70T+Ks9Rz57MFgGCSqGSIb3DQEJDzFL MEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcG BSsOAwIaMAoGCCqGSIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2Ug aXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChj KTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQO rwvJMA0GCSqGSIb3DQEBAQUABIGAisNA2kDoU4o9Kwx8dLrGKLMlZVXBADbdWwg9ht48tmTi58E8 5UDeQE3C0MDC8vuJrrFGCUtrA1ZB9tJdZrqXwhRpTtFSJP06CwVHsxMaI5Jln7beljq3baLRnR4u ZS6v3QCPHxvZFk2P2kWX0dzpCyzj3jT2L17katQbe4JcCVgAAAAAAAA= ------=_NextPart_000_0063_01C29D34.8C79ADC0-- -- 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 Dec 6 17:44:56 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28477 for ; Fri, 6 Dec 2002 17:44:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18KR2q-00089O-00 for namedroppers-data@psg.com; Fri, 06 Dec 2002 14:34:04 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #2) id 18KR2o-00089C-00 for namedroppers@ops.ietf.org; Fri, 06 Dec 2002 14:34:02 -0800 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 18KR2o-0002ZI-00 for namedroppers@ops.ietf.org; Fri, 06 Dec 2002 14:34:02 -0800 In-Reply-To: <5.2.0.9.2.20021206132845.01b56f88@mira-sjcm-4.cisco.com> Message-ID: <20021206231431.X12507-100000@voo.doo.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Fri, 6 Dec 2002 23:23:20 +0100 (CET) From: Marc Schneiders To: Fred Baker cc: "Hallam-Baker, Phillip" , , , Subject: RE: namedroppers, continued X-Spam-Status: No, hits=-2.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,RESENT_TO, SPAM_PHRASE_01_02 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, 6 Dec 2002, at 13:41 [=GMT-0800], Fred Baker wrote: > I think it was Steve Bellovin that suggested a procedure for reducing the > utility of spoofing source addresses in emails; if not, it was me and I > happened to suggest something his favorite algorithm fit into, by having a > host in each mail domain (mailid.example.com) be able to assert that its > domain had or had not sent an email within a given recent time period > whose MD5 hash, when divided by resulted in > . I could write that up in an internet draft if folks > think it makes sense. That would be a more global procedure that didn't > require a PKI and only addressed spoofed addresses. Spammers would be the first to set up your mailid host. They will have had years of experience to find holes in the system before you've convinced everyone to adopt or accept the mailid. It might be easier to write a new protocol to succeed email, instant messaging, mobile phones (something useful in itself) with built-in abuse control from the start. -- 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 Dec 6 17:56:06 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28961 for ; Fri, 6 Dec 2002 17:56:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18KRGL-0008u5-00 for namedroppers-data@psg.com; Fri, 06 Dec 2002 14:48:01 -0800 Received: from relay2.av8.net ([130.105.12.4] helo=citation.av8.net) by psg.com with esmtp (Exim 3.36 #2) id 18KRGH-0008te-00 for namedroppers@ops.ietf.org; Fri, 06 Dec 2002 14:47:58 -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 RAA31960; Fri, 6 Dec 2002 17:44:55 -0500 Date: Fri, 6 Dec 2002 17:46:46 -0500 (EST) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: Fred Baker cc: "Hallam-Baker, Phillip" , , , Subject: RE: namedroppers, continued In-Reply-To: <5.2.0.9.2.20021206132845.01b56f88@mira-sjcm-4.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,SPAM_PHRASE_01_02, TO_BE_REMOVED_REPLY,USER_AGENT_PINE,X_OSIRU_SPAM_SRC version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Every domain would have to have a public key that the public could find. Then every mailserver would have to check every message. And spammers could still send spam, because they are authorized to send email from some ISP, using that ISP's domain, and that ISP mailserver will sign their email. Spam isn't a security problem that can be solved technically. Spam is the exact same problem as when Randy Bush harrasses someone by abusing his privileges as administrator. There isn't a technical solution, other than removing the privileges. Then the new administrator could abuse the privileges, if they were so inclined. There isn't a technical way to give someone privileges that they can't abuse, if so inclined. --Dean On Fri, 6 Dec 2002, Fred Baker wrote: > [ 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. ] > > At 08:28 AM 12/2/2002 -0800, Hallam-Baker, Phillip wrote: > >The only way to resolve this issue properly would be to require every > >submission to an IETF mailing list to be cryptographically signed (PGP > >or S/MIME), to require the subscribers to register their signing key and > >to then filter the mail sent out on the list so that only signed mail > >gets through. > > I would be in favor of that, personally, as long as we can ensure that the > appropriate signature facility (be it RSA, PGP, or whatever) is freely > available to all who need to use it. The issue here is not us corporate > types who have a business reason to buy the software, it is the students > who often lack the funds. The big issue would be the procedures for posting > one's key to the appropriate place - what is to stop a spammer from posting > a key and sending the spam anyway? I'm not proposing a mechanism, but > someone who is good at such things might well find it of value. > > It doesn't address the "off topic" issue. As you say, that could be left to > a working group chair equiped with formal procedures developed by consensus > within the work group or adopted by the working group from a more general > place (ie, the IETF could suggest a procedure, and the WG could adopt it if > it didn't feel another procedure would be better). > > I have had a private exchange, over the past few days, with someone who > wished that the IETF would please document some good spam-elimination > procedure, so that it could be used world-wide to completely eliminate > spam. I think that boils down to "provide a global PKI" in this solution, > and presumes that spammers are incapable of using one. That might be a > great research topic. Too bad nobody has ever thought of it before; we > could really use the outcome of that research. (OK, so it's a lame attempt > at humor...) > > I think it was Steve Bellovin that suggested a procedure for reducing the > utility of spoofing source addresses in emails; if not, it was me and I > happened to suggest something his favorite algorithm fit into, by having a > host in each mail domain (mailid.example.com) be able to assert that its > domain had or had not sent an email within a given recent time period > whose MD5 hash, when divided by resulted in > . I could write that up in an internet draft if folks > think it makes sense. That would be a more global procedure that didn't > require a PKI and only addressed spoofed addresses. > > > > -- > 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 Dec 6 17:57:47 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29050 for ; Fri, 6 Dec 2002 17:57:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18KRLD-0009F6-00 for namedroppers-data@psg.com; Fri, 06 Dec 2002 14:53:03 -0800 Received: from relay2.av8.net ([130.105.12.4] helo=citation.av8.net) by psg.com with esmtp (Exim 3.36 #2) id 18KRL9-0009E2-00 for namedroppers@ops.ietf.org; Fri, 06 Dec 2002 14:52:59 -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 RAA05742; Fri, 6 Dec 2002 17:48:58 -0500 Date: Fri, 6 Dec 2002 17:50:49 -0500 (EST) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: "Hallam-Baker, Phillip" cc: "'Aaron Swartz'" , , , Subject: RE: namedroppers, continued In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,RCVD_IN_OSIRUSOFT_COM, SPAM_PHRASE_00_01,USER_AGENT_PINE,X_OSIRU_SPAM_SRC version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk And how much before Randy was moderator? I'm on other large, subscriber-restricted, public lists, where this isn't a significant problem. --Dean On Fri, 6 Dec 2002, Hallam-Baker, Phillip wrote: > > > How much spam is going to namedroppers? > > Well none since Randy Bush and a bunch of others turned > on the moderator bit. > > The problem here is that having Randy Bush moderate is > not a scalable solution to the problems of Spam in general. > > > Phill > > > -- 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 Dec 6 18:54:16 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01325 for ; Fri, 6 Dec 2002 18:54:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18KS84-000C4M-00 for namedroppers-data@psg.com; Fri, 06 Dec 2002 15:43:32 -0800 Received: from mx03.gis.net ([208.218.130.11] helo=gis.net) by psg.com with esmtp (Exim 3.36 #2) id 18KS81-000C3z-00 for namedroppers@ops.ietf.org; Fri, 06 Dec 2002 15:43:29 -0800 Received: from tecotoo.www.gis.net ([67.30.187.201]) by mx03.gis.net; Fri, 06 Dec 2002 18:43:27 -0500 Received: from localhost (localhost [127.0.0.1]) by tecotoo.www.gis.net (NTMail 3.02.13) with ESMTP id da029487 for ; Fri, 6 Dec 2002 16:10:38 -0500 Message-Id: <4.3.1.2.20021206160829.03856860@pop.gis.net> X-Sender: mayer@pop.gis.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Fri, 06 Dec 2002 16:10:23 -0500 To: Dean Anderson From: Danny Mayer Subject: Re: in support of axfr-clarify Cc: namedroppers@ops.ietf.org In-Reply-To: References: <4.3.1.2.20021205205923.03865be0@pop.gis.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Info: NTMail 3.02 Server on TECOTOO X-Rcpt-To: X-Spam-Status: No, hits=0.5 required=5.0 tests=IN_REP_TO,RCVD_IN_OSIRUSOFT_COM,REFERENCES, SPAM_PHRASE_00_01,X_OSIRU_DUL version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 01:58 PM 12/6/02, Dean Anderson wrote: >Bernsteins reaction is a natural response to harrassment, and deceptive >labeling regarding axfr-clarify. > > --Dean Yes, the natural response of a child who resorts to threads, abuse, harrassment, yells and screams to get their way, rather than a reasoned response. All this from a professor. Danny -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 6 18:55:47 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01393 for ; Fri, 6 Dec 2002 18:55:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18KSAO-000CD3-00 for namedroppers-data@psg.com; Fri, 06 Dec 2002 15:45:56 -0800 Received: from peacock.verisign.com ([65.205.251.73]) by psg.com with esmtp (Exim 3.36 #2) id 18KSAL-000CCl-00 for namedroppers@ops.ietf.org; Fri, 06 Dec 2002 15:45:53 -0800 Received: from vhqpostal-gw2.verisign.com (verisign.com [65.205.251.56]) by peacock.verisign.com (8.12.1/) with ESMTP id gB6NjPkw018244; Fri, 6 Dec 2002 15:45:25 -0800 (PST) Received: by vhqpostal-gw2.verisign.com with Internet Mail Service (5.5.2653.19) id ; Fri, 6 Dec 2002 15:45:47 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Steven M. Bellovin'" , Fred Baker Cc: "Hallam-Baker, Phillip" , ietf@ietf.org, namedroppers@ops.ietf.org, iesg@ietf.org Subject: RE: namedroppers, continued Date: Fri, 6 Dec 2002 15:45:43 -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_0083_01C29D3E.894D6880" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=3.0 required=5.0 tests=EXCHANGE_SERVER,MISSING_OUTLOOK_NAME,QUOTED_EMAIL_TEXT, RCVD_IN_RFCI,SPAM_PHRASE_01_02 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_0083_01C29D3E.894D6880 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit > Well, it's also the availability of the right signature > facility in the > myriad email clients people use. I disagree here, I believe it is a case of supporting the overwhelming majority of the platforms with software that is freely available and free. I don't believe that we should consider support for Open Genera to be a 'must support' issue. Years ago people used to whinge when someone sent a MIME attachment of 10K or so because it took too long to download over a 300 baud modem. I don't think it is a bad thing to consider that high bandwidth connectivity is still a constrained resource absent in many less developed parts of the world. However the complaints about using MIME never come from those quarters. > I could write that up in an internet > draft if folks > >think it makes sense. That would be a more global procedure > that didn't > >require a PKI and only addressed spoofed addresses. > > > Wasn't me... The problem is not the PKI, the problem is the directory. Deployment of PKI is easy. It is the Directory baggage that people foisted onto PKI that is the failure. X.500 has set us back more than the NSA crypto export regulations ever did. LDAP merely compounds the problem, building failure on top of failure. We need a DNS linked PKI, not a directory linked PKI. We need a PKI that only cares about the addresses the applications route on. The idea of using human names for PKI is bogus. The directory PKI model fails for the Internet for many reasons. First taxonomic organization is a broken concept. No real world information is stuctured in that fashion, not even genealogies (cousins marry cousins). The reason that so many enterprise directory projects are fiascos is that they are trying to fit data into a representation that is simply inappropriate. The other main reason that directories are a failure for Internet PKI is that they are exclusively an internal data resource. VeriSign has an employee directory accessible from the inside of the company. There is no way it is ever going to be accessible from the outside. At the Internet level trust relationships are complex, they are certainly not hierarchical. Trying to store that data in a taxanomic sturcture then do path discovery is nonsense on stilts. Linking the PKI to the DNS completes the picture. I want to send Fred Baker an email, well I had better know his email address first. My email client can follow an SRV record from cisco.com to find an XKMS service for cisco.com where I can ask 'what key should I use to send an encrypted S/MIME email to fred@cisco.com'. Allowing organizations to find out that Fred@cisco.com is still working for Cisco is actually a security improvement. It means that Office Max can shut off his personal stationary account ordering privs the minute he leaves Cisco. Don't reject the leverage that public key provides just because you don't like the package people tried to wrap arround it. The protocol you describe requires state and is simply not deployable for large systems like hotmail. It would be nice if the IETF could get ahead of the curve this time instead of being the brake. We still have members of the IESG speaking to security forums disputing the utility of network security measures such as firewalls even after Steve became a security area director. We need to shift towards a comprehensive multi-level security approach which accepts that there are problems that cannot be addressed by the end to end argument. Real users are saying that SPAM is their number one internet related problem today. Classify it how you like but deal with it with a security mentality. The spamers are seriously degrading the utility of email. We need a short term approach to mitigate the problem (filtering) and long term approaches that have the potential to put them out of business. Authenticating the good signal is completely complimentary with rejecting the bad. Phill ------=_NextPart_000_0083_01C29D3E.894D6880 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 BQCgggGMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTIwNjIz NDU0M1owIwYJKoZIhvcNAQkEMRYEFMXcltqlUjJt4qtVlvvTZvguUuniMFgGCSqGSIb3DQEJDzFL MEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcG BSsOAwIaMAoGCCqGSIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2Ug aXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChj KTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQO rwvJMA0GCSqGSIb3DQEBAQUABIGAZ220gKDEkbJ7NHJtD9pXReqOsvGspWZj1VVl+zTMUDaPZEI1 3Lu4wXWKYQ3RCuwctFiJSNRXCWQl4r4VORGYI/0Vu6b/evOB6VPT/BmPm8qw+VoR6+Mc4h07jf2v d/bSrOa5xeRoLDrkFEDW7kHigRTZHNeDqa37UiC1bDhVd7AAAAAAAAA= ------=_NextPart_000_0083_01C29D3E.894D6880-- -- 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 Dec 6 19:14:08 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02440 for ; Fri, 6 Dec 2002 19:14:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18KSTN-000DFg-00 for namedroppers-data@psg.com; Fri, 06 Dec 2002 16:05:33 -0800 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #2) id 18KSTK-000DEk-00 for namedroppers@ops.ietf.org; Fri, 06 Dec 2002 16:05:30 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 72327379FB3; Sat, 7 Dec 2002 00:05:29 +0000 (GMT) From: Paul Vixie To: ietf@ietf.org, namedroppers@ops.ietf.org, iesg@ietf.org Subject: Re: namedroppers, continued In-Reply-To: Message from Fred Baker of "Fri, 06 Dec 2002 13:41:52 PST." <5.2.0.9.2.20021206132845.01b56f88@mira-sjcm-4.cisco.com> X-Mailer: MH-E 7.0; nmh 1.0.4; Emacs 21.2 Date: Sat, 07 Dec 2002 00:05:29 +0000 Message-Id: <20021207000529.72327379FB3@as.vix.com> X-Spam-Status: No, hits=0.9 required=5.0 tests=BULK_EMAIL,IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk it's difficult to imagine a mailing list for which this thread is on-topic. > I think it was Steve Bellovin that suggested a procedure for reducing the > utility of spoofing source addresses in emails; if not, it was me and I > happened to suggest something his favorite algorithm fit into, by having a > host in each mail domain (mailid.example.com) be able to assert that its > domain had or had not sent an email within a given recent time period > whose MD5 hash, when divided by resulted in > . I could write that up in an internet draft if folks > think it makes sense. That would be a more global procedure that didn't > require a PKI and only addressed spoofed addresses. -- here was my attempt at this, which i didn't really know where to go next with: Independent Paul Vixie (Ed.) Request for Comments: XXXX Category: Experimental June 6, 2002 Repudiating MAIL FROM Status of this Memo This memo describes an experimental procedure for handling received e-mail. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract At the time of this writing, more than half of all e-mail received by the author has a forged return address, due to the total absence of address authentication in SMTP (see [RFC2821]). We present a simple and backward compatible method whereby cooperating e-mail senders and receivers can detect forged source/return addresses in e-mail. 1 - Introduction and Overview 1.1. Internet e-mail return addresses are nonrepudiable by design of the relevant transport protocols (see [RFC2821]). Simply put, there is no cause for ANY confidence in the proposition "this e-mail came from where it says it came from." 1.2. Irresponsible actors who wish to transmit unwanted bulk e-mail routinely use this designed-in lack of source/return authenticity to hide their point of origin, which usually involves forging a valid return address belonging to some highly visible and popular ISP (for example, HOTMAIL.COM). 1.3. Recipients who wish to reject unwanted bulk e-mail containing forged source/return addresses are prevented from doing so since the addresses, as presented, are nonrepudiable by design. Simply put, there would be too many false positives, and too much valid e-mail rejected, if one were to program an e-mail relay to "reject all e-mail claiming to be from HOTMAIL.COM" since, statistically, most e-mail claiming to be from HOTMAIL.COM is actually from somewhere else. HOTMAIL.COM, in this example, is a victim of forgery. Vixie Experimental [Page 1] RFC XXXX Repudiating MAIL FROM May 26, 2002 1.4. What's needed is a way to guaranty that each received e-mail message did in fact come from some mail server or relay which can rightfully originate or relay messages from the purported source/return address. 1.5. Approaches of the form "use PGP" and "use SSL" are not scalable in the short term since they depend on end-to-end action and there are just too many endpoints. An effective solution has to be applicable to mail relay, not just final delivery. 1.6. Valid ("wanted") e-mail must not be rejected by side effect or partial adoption of this proposal. Source/return authenticity must be a confidence effector, as in "we can be sure that this did not come from where it claims" and simple uncertainty must remain in effect otherwise. 2 - Behaviour 2.1. Domain owners who wish their mail source/return information to be repudiable will enter stylized MX RR's into their DNS data, whose owner name is "MAIL-FROM", whose priority is zero, and whose servername registers an outbound (border) relay for the domain. For example, to tell the rest of the Internet who they should believe when they receive mail claiming to be from VIXIE@ISC.ORG, the following DNS MX RR's should be entered: $ORIGIN isc.org. MAIL-FROM MX 0 rc MX 0 rc1 In this example, hosts RC.ISC.ORG, and RC1.ISC.ORG are given as appropriate places to originate mail from @ISC.ORG. Note that this differs from the normal inbound MX RRset for this example domain: $ORIGIN isc.org. @ MX 0 rc MX 0 isrv4 So, the inbound mail server set partially overlaps with, but differs from, the example outbound mail server set. This is quite common in the Internet, and is the reason why the normal inbound mail server set described by a domain's apex MX RRset cannot be used for repudiation purposes. Vixie Experimental [Page 2] RFC XXXX Repudiating MAIL FROM May 26, 2002 2.2. Second-stage relays such as ISP mail servers are often used and can be described by adding as many relays as necessary to the MAIL-FROM MX RRset. In our example, if ISC sometimes used UUNET for outbound mail services, the DNS data describing this relationship might be as follows: $ORIGIN isc.org. MAIL-FROM MX 0 rc MX 0 rc1 MX 0 uunet.uu.net. Let it be noted that a domain owner's power to repudiate forged e-mail is only as strong as the security policy of its registered inbound and outbound mail relays, and that if such a relay is (for example) open to third party relay, then no value will be added by registering a domain MAIL-FROM MX containing that relay, and no inbound MAIL-FROM checking will be possible on final delivery relays for a domain @ MX containing that relay. Multistage relays (both inbound and outbound) are a breeding ground for anonymity unless they are very carefully configured. 2.3. SMTP receivers wishing to attempt repudiation on inbound e-mail would check the SMTP (see [RFC2821]) MAIL FROM payload at the time of receipt. The precise method to be used is as follows: Vixie Experimental [Page 3] RFC XXXX Repudiating MAIL FROM May 26, 2002 on (MAIL FROM mailfrom) { switch (repudiated(mailfrom, ipsource)) case tempfail: smtpreply(450, "temporary dns failure, try again later") break case repudiated: smtpreply(550, "surely you're joking") dsn("5.7.1", "delivery not authorized") invalidate() // reject all but QUIT and RSET break } } repudiated(mailfrom, ipsource) = { (lhs, rhs) = parse_addr(mailfrom); // handle "MAIL FROM:<>" somehow mxset = get_mx("MAIL-FROM" "." rhs); if (mxset == NULL) return nonrepudiated; mxset += configured(perimeter_relays); foreach mx (mxset) { aset = get_a(mx.server); if (ipsource IN aset) return nonrepudiated; } return repudiated; } (EDITOR'S NOTE: need to establish a value for 5xx.) The method amounts to "if there's a MAIL-FROM for the purported domain and if the IP source isn't on the resulting list, then reject the mail". Multistage inbound relays are allowed for, by implicitly appending one's own outer perimeter relay names to every extant MAIL-FROM. 3 - Impact 3.1. This specification is optional, and will only affect cooperating parties. Any domain owner who does not enter a MAIL-FROM will be unaffected, and any SMTP receiver who does not look for a MAIL-FROM at time of receipt will be unaffected. However, both parties working together CAN work to repudiate forged e-mail return/source information. 3.2. Transport-level e-mail forwarding must be more explicit under this specification. For example if VIXIE@NETBSD.ORG's account has a Vixie Experimental [Page 4] RFC XXXX Repudiating MAIL FROM May 26, 2002 ".forward" file pointing at VIXIE@ISC.ORG, then e-mail sent to the former will be received by the latter, but with no change in the payload of SMTP MAIL FROM. Thus, ISC's inbound relays would have to be configured to implicitly add NETBSD's outbound mail relays as "multistage inbound relays." This could scale poorly and may add pressure toward transport remailing (with a new envelope) rather than transport forwarding (reusing the old envelope.) 3.3. Roaming hosts such as laptop computers will probably not be able to be listed in the MAIL-FROM MX RR for their return address domain name, and may be forced to use an intermediary for outbound e-mail. STARTTLS or an SSL/SSH tunnel back "home" may become a necessary first hop for mobile e-mail. 3.4. The likely endgame for this behaviour is to force senders of unwanted bulk e-mail to stop lying about who they are, which is illegal in meatspace anyway -- but such laws are unenforceable due to the nature of the Internet's mail system. Under this proposal, any domain owner who is the victim of forgery can respond by adding MAIL-FROM data to their DNS zone, and any relay owner who is the victim of forged unwanted e-mail can respond by checking for MAIL-FROM data upon receipt of all incoming e-mail. 3.5. The DNS TTL for MAIL-FROM MX RRsets ought to be shorter than for the corresponding domain's apex MX RR, since the cost of widely cached wrong information is much higher for outbound repudiation data than for inbound delivery data. Consider that an incomplete apex MX RR can cause mail to be delivered by a suboptimal path, whereas an incomplete MAIL- FROM MX RR can cause valid mail to be rejected by relays who attempt repudiation. 4 - Security Considerations In the continuing absence of widely deployed security for DNS, this proposal effectively places an access control list for forged source/return information in a place where it can be attacked. However, it must be noted that the current senders of forged unwanted bulk e-mail are typically not technologically capable of attacking the DNS to insert forged MAIL-FROM data. 5 - Acknowledgements This idea originated with Jim Miller in 1998. Vixie Experimental [Page 5] RFC XXXX Repudiating MAIL FROM May 26, 2002 5 - Author's Address Paul Vixie 950 Charter Street Redwood City, CA 94063 +1 650 779 7000 paul@vix.com Vixie Experimental [Page 6] -- 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 Dec 6 21:48:51 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06362 for ; Fri, 6 Dec 2002 21:48:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18KUq4-000LAF-00 for namedroppers-data@psg.com; Fri, 06 Dec 2002 18:37:08 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18KUq1-000L9i-00 for namedroppers@ops.ietf.org; Fri, 06 Dec 2002 18:37:06 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18KUq1-0002CH-00 for namedroppers@ops.ietf.org; Fri, 06 Dec 2002 18:37:05 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: Thread-Topic: namedroppers, continued Thread-Index: AcKddpyvmvIUkPCXRnCSp3VlxaBn4wAAPFzQ Subject: RE: namedroppers, continued Date: Fri, 6 Dec 2002 16:48:46 -0600 From: "Ayyasamy, Senthilkumar (UMKC-Student)" To: "Fred Baker" , "Hallam-Baker, Phillip" , Cc: , , X-Spam-Status: No, hits=2.3 required=5.0 tests=FROM_ENDS_IN_NUMS,RESENT_TO,SPAM_PHRASE_05_08 version=2.43 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA06362 [ 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. ] > Too bad nobody has ever thought of it > before; we could really use the outcome > of that research while researchers has not thought about global PKI, their are research which focus on spam elimination. this is the work all about (yesterday's seminar in a MIT group) " If I don't know you, and you want your e-mail to appear in my inbox, then you must attach to your message an easily verified "proof of computational effort", just for me and just for this message. If the proof of effort requires, say, 10 seconds to compute, then the economics of sending spam are radically altered, as a single machine can send only 8,000 messages per day. The recent proliferation of spam has lead to a renewed interest in these ideas. This work is about both the choice of functions that can be used to yield easily verifiable proofs of computational effort, and architectures for implementing the proof of effort approach. Filtering and/or forcing senders to pay in other currencies, such as human attention and money, will be covered as time permits" for more details http://research.microsoft.com/research/sv/PennyBlack -- 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 Dec 7 11:52:38 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01633 for ; Sat, 7 Dec 2002 11:52:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Khxb-000DnV-00 for namedroppers-data@psg.com; Sat, 07 Dec 2002 08:37:47 -0800 Received: from relay2.av8.net ([130.105.12.4] helo=citation.av8.net) by psg.com with esmtp (Exim 3.36 #2) id 18KhxW-000Dll-00 for namedroppers@ops.ietf.org; Sat, 07 Dec 2002 08:37:42 -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 LAA04713; Sat, 7 Dec 2002 11:32:54 -0500 Date: Sat, 7 Dec 2002 11:34:47 -0500 (EST) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: Danny Mayer cc: namedroppers@ops.ietf.org Subject: Re: in support of axfr-clarify In-Reply-To: <4.3.1.2.20021206160829.03856860@pop.gis.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.1 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,SPAM_PHRASE_00_01,USER_AGENT_PINE, X_OSIRU_SPAM_SRC version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk None of this is accurate. He may be yelling, but it is a result of sustained abuse over a long, long period of time. Frankly, I wouldn't be nearly as patient. --Dean On Fri, 6 Dec 2002, Danny Mayer wrote: > At 01:58 PM 12/6/02, Dean Anderson wrote: > >Bernsteins reaction is a natural response to harrassment, and deceptive > >labeling regarding axfr-clarify. > > > > --Dean > > Yes, the natural response of a child who resorts to threads, abuse, > harrassment, > yells and screams to get their way, rather than a reasoned response. All this > from a professor. > > Danny > > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Dec 7 12:25:45 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02528 for ; Sat, 7 Dec 2002 12:25:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18KiVU-000GLg-00 for namedroppers-data@psg.com; Sat, 07 Dec 2002 09:12:48 -0800 Received: from relay2.av8.net ([130.105.12.4] helo=citation.av8.net) by psg.com with esmtp (Exim 3.36 #2) id 18KiVO-000GLN-00 for namedroppers@ops.ietf.org; Sat, 07 Dec 2002 09:12:42 -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 MAA17345; Sat, 7 Dec 2002 12:06:30 -0500 Date: Sat, 7 Dec 2002 12:08:23 -0500 (EST) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: Paul Vixie cc: ietf@ietf.org, , Subject: Re: namedroppers, continued In-Reply-To: <20021207000529.72327379FB3@as.vix.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=2.2 required=5.0 tests=BULK_EMAIL,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,SPAM_PHRASE_00_01, TO_BE_REMOVED_REPLY,USER_AGENT_PINE,X_OSIRU_SPAM_SRC version=2.43 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This doesn't adequately describe backup relays. If uunet is providing an alternate relay service, then all or any of uunet's relays might be providing that service. So it would have to be able to recursively look up uunets mail-from mx's, and the mail-from mx's of any subdomains listed by uunet. This process might contain loops. Additionally, the mail forwarding behavior is highly undesirable. A large mail site does not want to have to manually configure essentially the whole of the internet as possible multi-stage mail relays so that its users can forward mail from other servers to their mailbox. Indeed, even a relatively small site would not want to do that. However, even this approach won't stop spam, since a spammer will still be able to use their ISP's mailservers, with a stolen, or disposable account. There are plenty of KLEZ viruses out there, and plenty of stolen passwords. And it won't have any effect at all on spam from real commercial operators like Exactis who don't forge the from addresses. Essentially, I'm convinced after years of interaction with some radical anti-spammers that most of the non-commercial spam (and quite a lot of the forged-address spam) is sent by anti-spammers trying to essentially terrorize their way to some kind of technical solution that they think exists. However, no such solution exists. If there were such a solution, we could prevent all kinds of evils, like government corruption, embezzlement, misuse of all kinds of property. But there is no substitute for honesty and responsibility. If someone has possession of a privilege, (however that privilege was obtained--it may have been stolen), and they are so inclined to abuse that privilege, the only way to stop them is to remove the privilege. --Dean On Sat, 7 Dec 2002, Paul Vixie wrote: > it's difficult to imagine a mailing list for which this thread is on-topic. > > > I think it was Steve Bellovin that suggested a procedure for reducing the > > utility of spoofing source addresses in emails; if not, it was me and I > > happened to suggest something his favorite algorithm fit into, by having a > > host in each mail domain (mailid.example.com) be able to assert that its > > domain had or had not sent an email within a given recent time period > > whose MD5 hash, when divided by resulted in > > . I could write that up in an internet draft if folks > > think it makes sense. That would be a more global procedure that didn't > > require a PKI and only addressed spoofed addresses. -- > > here was my attempt at this, which i didn't really know where to go next with: > > > > > > > > Independent Paul Vixie (Ed.) > Request for Comments: XXXX Category: Experimental > June 6, 2002 > > Repudiating MAIL FROM > > Status of this Memo > > This memo describes an experimental procedure for handling received > e-mail. It does not specify an Internet standard of any kind. > Distribution of this memo is unlimited. > > Copyright Notice > > Copyright (C) The Internet Society (2002). All Rights Reserved. > > Abstract > > At the time of this writing, more than half of all e-mail received by > the author has a forged return address, due to the total absence of > address authentication in SMTP (see [RFC2821]). We present a simple > and backward compatible method whereby cooperating e-mail senders and > receivers can detect forged source/return addresses in e-mail. > > 1 - Introduction and Overview > > 1.1. Internet e-mail return addresses are nonrepudiable by design of the > relevant transport protocols (see [RFC2821]). Simply put, there is no > cause for ANY confidence in the proposition "this e-mail came from where > it says it came from." > > 1.2. Irresponsible actors who wish to transmit unwanted bulk e-mail > routinely use this designed-in lack of source/return authenticity to > hide their point of origin, which usually involves forging a valid > return address belonging to some highly visible and popular ISP (for > example, HOTMAIL.COM). > > 1.3. Recipients who wish to reject unwanted bulk e-mail containing > forged source/return addresses are prevented from doing so since the > addresses, as presented, are nonrepudiable by design. Simply put, there > would be too many false positives, and too much valid e-mail rejected, > if one were to program an e-mail relay to "reject all e-mail claiming to > be from HOTMAIL.COM" since, statistically, most e-mail claiming to be > from HOTMAIL.COM is actually from somewhere else. HOTMAIL.COM, in this > example, is a victim of forgery. > > > > Vixie Experimental [Page 1] > > RFC XXXX Repudiating MAIL FROM May 26, 2002 > > > 1.4. What's needed is a way to guaranty that each received e-mail > message did in fact come from some mail server or relay which can > rightfully originate or relay messages from the purported source/return > address. > > 1.5. Approaches of the form "use PGP" and "use SSL" are not scalable in > the short term since they depend on end-to-end action and there are just > too many endpoints. An effective solution has to be applicable to mail > relay, not just final delivery. > > 1.6. Valid ("wanted") e-mail must not be rejected by side effect or > partial adoption of this proposal. Source/return authenticity must be a > confidence effector, as in "we can be sure that this did not come from > where it claims" and simple uncertainty must remain in effect otherwise. > > 2 - Behaviour > > 2.1. Domain owners who wish their mail source/return information to be > repudiable will enter stylized MX RR's into their DNS data, whose owner > name is "MAIL-FROM", whose priority is zero, and whose servername > registers an outbound (border) relay for the domain. For example, to > tell the rest of the Internet who they should believe when they receive > mail claiming to be from VIXIE@ISC.ORG, the following DNS MX RR's should > be entered: > > $ORIGIN isc.org. > MAIL-FROM MX 0 rc > MX 0 rc1 > > In this example, hosts RC.ISC.ORG, and RC1.ISC.ORG are given as > appropriate places to originate mail from @ISC.ORG. Note that this > differs from the normal inbound MX RRset for this example domain: > > $ORIGIN isc.org. > @ MX 0 rc > MX 0 isrv4 > > So, the inbound mail server set partially overlaps with, but differs > from, the example outbound mail server set. This is quite common in the > Internet, and is the reason why the normal inbound mail server set > described by a domain's apex MX RRset cannot be used for repudiation > purposes. > > > > > > > Vixie Experimental [Page 2] > > RFC XXXX Repudiating MAIL FROM May 26, 2002 > > > 2.2. Second-stage relays such as ISP mail servers are often used and can > be described by adding as many relays as necessary to the MAIL-FROM MX > RRset. In our example, if ISC sometimes used UUNET for outbound mail > services, the DNS data describing this relationship might be as follows: > > $ORIGIN isc.org. > MAIL-FROM MX 0 rc > MX 0 rc1 > MX 0 uunet.uu.net. > > Let it be noted that a domain owner's power to repudiate forged e-mail > is only as strong as the security policy of its registered inbound and > outbound mail relays, and that if such a relay is (for example) open to > third party relay, then no value will be added by registering a domain > MAIL-FROM MX containing that relay, and no inbound MAIL-FROM checking > will be possible on final delivery relays for a domain @ MX containing > that relay. Multistage relays (both inbound and outbound) are a > breeding ground for anonymity unless they are very carefully configured. > > 2.3. SMTP receivers wishing to attempt repudiation on inbound e-mail > would check the SMTP (see [RFC2821]) MAIL FROM payload at the time of > receipt. The precise method to be used is as follows: > > > > > > > > > > > > > > > > > > > > > > > > > > > Vixie Experimental [Page 3] > > RFC XXXX Repudiating MAIL FROM May 26, 2002 > > > on (MAIL FROM mailfrom) { > switch (repudiated(mailfrom, ipsource)) > case tempfail: > smtpreply(450, "temporary dns failure, try again later") > break > case repudiated: > smtpreply(550, "surely you're joking") > dsn("5.7.1", "delivery not authorized") > invalidate() // reject all but QUIT and RSET > break > } > } > > repudiated(mailfrom, ipsource) = { > (lhs, rhs) = parse_addr(mailfrom); > // handle "MAIL FROM:<>" somehow > mxset = get_mx("MAIL-FROM" "." rhs); > if (mxset == NULL) > return nonrepudiated; > mxset += configured(perimeter_relays); > foreach mx (mxset) { > aset = get_a(mx.server); > if (ipsource IN aset) > return nonrepudiated; > } > return repudiated; > } > > (EDITOR'S NOTE: need to establish a value for 5xx.) > > The method amounts to "if there's a MAIL-FROM for the purported domain > and if the IP source isn't on the resulting list, then reject the mail". > Multistage inbound relays are allowed for, by implicitly appending one's > own outer perimeter relay names to every extant MAIL-FROM. > > 3 - Impact > > 3.1. This specification is optional, and will only affect cooperating > parties. Any domain owner who does not enter a MAIL-FROM will be > unaffected, and any SMTP receiver who does not look for a MAIL-FROM at > time of receipt will be unaffected. However, both parties working > together CAN work to repudiate forged e-mail return/source information. > > 3.2. Transport-level e-mail forwarding must be more explicit under this > specification. For example if VIXIE@NETBSD.ORG's account has a > > > > Vixie Experimental [Page 4] > > RFC XXXX Repudiating MAIL FROM May 26, 2002 > > > ".forward" file pointing at VIXIE@ISC.ORG, then e-mail sent to the > former will be received by the latter, but with no change in the payload > of SMTP MAIL FROM. Thus, ISC's inbound relays would have to be > configured to implicitly add NETBSD's outbound mail relays as > "multistage inbound relays." This could scale poorly and may add > pressure toward transport remailing (with a new envelope) rather than > transport forwarding (reusing the old envelope.) > > 3.3. Roaming hosts such as laptop computers will probably not be able to > be listed in the MAIL-FROM MX RR for their return address domain name, > and may be forced to use an intermediary for outbound e-mail. STARTTLS > or an SSL/SSH tunnel back "home" may become a necessary first hop for > mobile e-mail. > > 3.4. The likely endgame for this behaviour is to force senders of > unwanted bulk e-mail to stop lying about who they are, which is illegal > in meatspace anyway -- but such laws are unenforceable due to the nature > of the Internet's mail system. Under this proposal, any domain owner > who is the victim of forgery can respond by adding MAIL-FROM data to > their DNS zone, and any relay owner who is the victim of forged unwanted > e-mail can respond by checking for MAIL-FROM data upon receipt of all > incoming e-mail. > > 3.5. The DNS TTL for MAIL-FROM MX RRsets ought to be shorter than for > the corresponding domain's apex MX RR, since the cost of widely cached > wrong information is much higher for outbound repudiation data than for > inbound delivery data. Consider that an incomplete apex MX RR can cause > mail to be delivered by a suboptimal path, whereas an incomplete MAIL- > FROM MX RR can cause valid mail to be rejected by relays who attempt > repudiation. > > 4 - Security Considerations > > In the continuing absence of widely deployed security for DNS, this > proposal effectively places an access control list for forged > source/return information in a place where it can be attacked. However, > it must be noted that the current senders of forged unwanted bulk e-mail > are typically not technologically capable of attacking the DNS to insert > forged MAIL-FROM data. > > 5 - Acknowledgements > > This idea originated with Jim Miller in 1998. > > > > > > Vixie Experimental [Page 5] > > RFC XXXX Repudiating MAIL FROM May 26, 2002 > > > 5 - Author's Address > > Paul Vixie > 950 Charter Street > Redwood City, CA 94063 > +1 650 779 7000 > paul@vix.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Vixie Experimental [Page 6] > > > -- > 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 Dec 7 12:31:16 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02678 for ; Sat, 7 Dec 2002 12:31:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Kih6-000HDP-00 for namedroppers-data@psg.com; Sat, 07 Dec 2002 09:24:48 -0800 Received: from relay2.av8.net ([130.105.12.4] helo=citation.av8.net) by psg.com with esmtp (Exim 3.36 #2) id 18Kih4-000HDB-00 for namedroppers@ops.ietf.org; Sat, 07 Dec 2002 09:24:46 -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 MAA29786; Sat, 7 Dec 2002 12:16:34 -0500 Date: Sat, 7 Dec 2002 12:18:27 -0500 (EST) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: "Ayyasamy, Senthilkumar (UMKC-Student)" cc: Fred Baker , "Hallam-Baker, Phillip" , , , , Subject: RE: namedroppers, continued In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=2.9 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM, SPAM_PHRASE_05_08,TO_BE_REMOVED_REPLY,USER_AGENT_PINE, X_OSIRU_SPAM_SRC version=2.43 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This seems clever, however, it will also take significant computational effort to verify the computational effort was actually done. Even if a class of functions are found that are "easier" to verify than to compute, they will no doubt still take up a significant fraction of time. Also, all outgoing messages would need this computation, since a mailserver does not know who it has sent mail to in the past, and whether they are still in receipt of the verification. So then you would only be able to send 8000 messages a day, too. Clearly, that doesn't scale very well. It seems unlikely that this would change the percentage of spam, since it would merely reduce the total amount of mail sent. I haven't observed a recent proliferation of spam, however. Spam seems to be level. --Dean On Fri, 6 Dec 2002, Ayyasamy, Senthilkumar (UMKC-Student) wrote: > this is the work all about (yesterday's seminar in a MIT group) > > " If I don't know you, and you want your e-mail to appear in my > inbox, then you must attach to your message an easily verified > "proof of computational effort", just for me and just for this > message. > > If the proof of effort requires, say, 10 seconds to compute, then the > economics of sending spam are radically altered, as a single machine > can send only 8,000 messages per day. > > The recent proliferation of spam has lead to a renewed interest in > these ideas. This work is about both the choice of > functions that can be used to yield easily verifiable proofs of > computational effort, and architectures for implementing the proof of > effort approach. Filtering and/or forcing senders to pay in other > currencies, such as human attention and money, will be covered as time > permits" > > > for more details http://research.microsoft.com/research/sv/PennyBlack > > > > -- > 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 Dec 7 13:24:43 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03808 for ; Sat, 7 Dec 2002 13:24:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18KjUM-000Kxa-00 for namedroppers-data@psg.com; Sat, 07 Dec 2002 10:15:42 -0800 Received: from h-135-207-30-103.research.att.com ([135.207.30.103] helo=mail-green.research.att.com) by psg.com with esmtp (Exim 3.36 #2) id 18KjUJ-000Kt3-00 for namedroppers@ops.ietf.org; Sat, 07 Dec 2002 10:15:39 -0800 Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-green.research.att.com (Postfix) with ESMTP id 4A74A1E14D; Sat, 7 Dec 2002 13:15:08 -0500 (EST) Received: from berkshire.research.att.com (postal.research.att.com [135.207.23.30]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id NAA25780; Sat, 7 Dec 2002 13:15:06 -0500 (EST) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id CE80A7B6B; Sat, 7 Dec 2002 13:15:05 -0500 (EST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: Dean Anderson Cc: "Ayyasamy, Senthilkumar (UMKC-Student)" , Fred Baker , "Hallam-Baker, Phillip" , dwork@almaden.ibm.com, ietf@ietf.org, namedroppers@ops.ietf.org, iesg@ietf.org Subject: Re: namedroppers, continued Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 07 Dec 2002 13:15:05 -0500 Message-Id: <20021207181505.CE80A7B6B@berkshire.research.att.com> 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 In message , Dean An derson writes: >This seems clever, however, it will also take significant computational >effort to verify the computational effort was actually done. Even if a >class of functions are found that are "easier" to verify than to compute, >they will no doubt still take up a significant fraction of time. In fact, that's the easy part. You could demand that the sender compute 1,000,000 HMACs of the text, the envelope, the time of day, and a counter. The verifier could check 100 randomly-chosen ones -- if any fail, there's a forgery. (Well, you probably wouldn't want those values, since 1,000,000 HMACs would be a lot of data to transmit. But you get the general idea.) --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com ("Firewalls" book) -- 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 Dec 7 15:05:41 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06149 for ; Sat, 7 Dec 2002 15:05:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Kl3v-0002cm-00 for namedroppers-data@psg.com; Sat, 07 Dec 2002 11:56:31 -0800 Received: from mx03.gis.net ([208.218.130.11] helo=gis.net) by psg.com with esmtp (Exim 3.36 #2) id 18Kl3t-0002cV-00 for namedroppers@ops.ietf.org; Sat, 07 Dec 2002 11:56:29 -0800 Received: from tecotoo.www.gis.net ([67.30.188.226]) by mx03.gis.net; Sat, 07 Dec 2002 14:56:26 -0500 Received: from localhost (localhost [127.0.0.1]) by tecotoo.www.gis.net (NTMail 3.02.13) with ESMTP id la029495 for ; Sat, 7 Dec 2002 15:00:26 -0500 Message-Id: <4.3.1.2.20021207144447.037bacd0@pop.gis.net> X-Sender: mayer@pop.gis.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Sat, 07 Dec 2002 14:55:02 -0500 To: Dean Anderson From: Danny Mayer Subject: Re: in support of axfr-clarify Cc: namedroppers@ops.ietf.org In-Reply-To: References: <4.3.1.2.20021206160829.03856860@pop.gis.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Info: NTMail 3.02 Server on TECOTOO X-Rcpt-To: X-Spam-Status: No, hits=0.1 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM, REFERENCES,SPAM_PHRASE_00_01,TO_BE_REMOVED_REPLY, X_OSIRU_DUL version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Someone who constantly heaps abuse on people even when they're attempting to discuss issues for which this mailing list is designed shouldn't expect sympathy from anyone. It's very childish. Can we please get back to discussing issues? Danny At 11:34 AM 12/7/02, Dean Anderson wrote: >None of this is accurate. > >He may be yelling, but it is a result of sustained abuse over a long, long >period of time. Frankly, I wouldn't be nearly as patient. > > --Dean > >On Fri, 6 Dec 2002, Danny Mayer wrote: > > > At 01:58 PM 12/6/02, Dean Anderson wrote: > > >Bernsteins reaction is a natural response to harrassment, and deceptive > > >labeling regarding axfr-clarify. > > > > > > --Dean > > > > Yes, the natural response of a child who resorts to threads, abuse, > > harrassment, > > yells and screams to get their way, rather than a reasoned response. > All this > > from a professor. > > > > Danny > > > > > > > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- 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 Dec 7 18:58:35 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10417 for ; Sat, 7 Dec 2002 18:58:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Koez-000Kdl-00 for namedroppers-data@psg.com; Sat, 07 Dec 2002 15:47:01 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18KoeX-000KdH-00 for namedroppers@ops.ietf.org; Sat, 07 Dec 2002 15:46:34 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18KoeW-0003vm-00 for namedroppers@ops.ietf.org; Sat, 07 Dec 2002 15:46:32 -0800 In-reply-to: "Your message dated Sat, 07 Dec 2002 13:15:05 -0500" <20021207181505.CE80A7B6B@berkshire.research.att.com> Message-id: <01KPR6VCNJBM001ZTY@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: <20021207181505.CE80A7B6B@berkshire.research.att.com> Date: Sat, 07 Dec 2002 15:07:59 -0800 (PST) From: ned.freed@mrochek.com Subject: Re: namedroppers, continued To: "Steven M. Bellovin" Cc: Dean Anderson , "Ayyasamy, Senthilkumar (UMKC-Student)" , Fred Baker , "Hallam-Baker, Phillip" , dwork@almaden.ibm.com, ietf@ietf.org, namedroppers@ops.ietf.org, iesg@ietf.org X-Spam-Status: No, hits=2.9 required=5.0 tests=IN_REP_TO,NO_MX_FOR_FROM,NO_REAL_NAME,QUOTED_EMAIL_TEXT, REFERENCES,RESENT_TO,SPAM_PHRASE_02_03 version=2.43 X-Spam-Level: ** 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. ] > In message , Dean An > derson writes: > >This seems clever, however, it will also take significant computational > >effort to verify the computational effort was actually done. Even if a > >class of functions are found that are "easier" to verify than to compute, > >they will no doubt still take up a significant fraction of time. > In fact, that's the easy part. You could demand that the sender > compute 1,000,000 HMACs of the text, the envelope, the time of day, and > a counter. The verifier could check 100 randomly-chosen ones -- if any > fail, there's a forgery. (Well, you probably wouldn't want those > values, since 1,000,000 HMACs would be a lot of data to transmit. But > you get the general idea.) The exmaple given in the Microsoft paper was square roots in a finite field. These are computationally difficult to compute (lots of multiplication mod p) but easy to check (single multiplication mod p). I'm sure there are other examples -- finding candidate functions of this sort is *much* easier than finding, say, a public key algorithm. Ned -- 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 Dec 8 11:50:03 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04734 for ; Sun, 8 Dec 2002 11:50:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18L4Qt-000IE9-00 for namedroppers-data@psg.com; Sun, 08 Dec 2002 08:37:31 -0800 Received: from momotombo.techfak.uni-bielefeld.de ([129.70.136.107]) by psg.com with esmtp (Exim 3.36 #2) id 18L4Qo-000IDT-00 for namedroppers@ops.ietf.org; Sun, 08 Dec 2002 08:37:27 -0800 Received: from grimsvotn.TechFak.Uni-Bielefeld.DE (grimsvotn.TechFak.Uni-Bielefeld.DE [129.70.137.40]) by momotombo.TechFak.Uni-Bielefeld.DE (8.11.6+Sun/8.11.6/TechFak/pk+ro20010720) with ESMTP id gB8GbJU05865; Sun, 8 Dec 2002 17:37:19 +0100 (MET) Received: from localhost (pk@localhost) by grimsvotn.TechFak.Uni-Bielefeld.DE (8.11.6+Sun/8.9.1) with SMTP id gB8GbJT24931; Sun, 8 Dec 2002 17:37:19 +0100 (MET) Message-Id: <200212081637.gB8GbJT24931@grimsvotn.TechFak.Uni-Bielefeld.DE> X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: Michael Mealling Cc: Cricket Liu , namedroppers@ops.ietf.org Subject: Re: SRV RR Questions In-reply-to: Your message of "05 Dec 2002 18:41:49 EST." <1039131709.4922.21.camel@blackdell.neonym.net> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 Date: Sun, 08 Dec 2002 17:37:18 +0100 From: Peter Koch X-Spam-Status: No, hits=-2.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,X_AUTH_WARNING version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Michael Mealling wrote: > Is it possible to get some kind of clarification that this is indeed the > case and that I don't need to go update 3403 and 3404 just to stick an > underscore into a domain-name that doesn't need it? I did not find the critical section in 3403 but there is that example in section 5.1 of 3404. It seems to me that 'service' and 'protocol' shouldn't have been provided as domain name prefixes but instead as seperate strings in the first place. However, there's no option to change that now. RFC 2782 does not only specify the SRV RR but also the way applications or libraries are going to use this RR type to locate services. Unfortunately in "The format of the SRV RR" it explicitly requires the first two labels of the owner domain name to start with a '_'. So, following 2782 by the letter, your usage would not be covered by the SRV spec. Then, this does not make sense. On the other hand, the way you use the SRV RRs starts one layer below where 2782 steps in. You already have the "translated" version at hand, so why bother with "udp" and "tcp" at all? "foolink.udp.example.com" is as good or bad as "foolink.example.com". But then, if you have a SRV-aware "rcds" client (2nd example), it would ask for "_rcds._udp.example.com" and you'd end up with two parallel sub-namespaces for the same purpose (_udp and udp). So, for the sake of consistency, I'd think the '_' should always be used, especially in documentation and examples to reduce readers' confusion. -Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Dec 8 12:45:41 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05895 for ; Sun, 8 Dec 2002 12:45:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18L5PJ-000JvS-00 for namedroppers-data@psg.com; Sun, 08 Dec 2002 09:39:57 -0800 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #2) id 18L5PH-000JvG-00 for namedroppers@ops.ietf.org; Sun, 08 Dec 2002 09:39:55 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 1BE87379FB3 for ; Sun, 8 Dec 2002 17:39:55 +0000 (GMT) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: SRV RR Questions In-Reply-To: Message from Peter Koch of "Sun, 08 Dec 2002 17:37:18 +0100." <200212081637.gB8GbJT24931@grimsvotn.TechFak.Uni-Bielefeld.DE> X-Mailer: MH-E 7.0; nmh 1.0.4; Emacs 21.2 Date: Sun, 08 Dec 2002 17:39:55 +0000 Message-Id: <20021208173955.1BE87379FB3@as.vix.com> X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_05_08 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > RFC 2782 does not only specify the SRV RR but also the way applications or > libraries are going to use this RR type to locate services. Unfortunately > in "The format of the SRV RR" it explicitly requires the first two labels > of the owner domain name to start with a '_'. yes. however, it's amendable. we wanted to make sure that these names could not conflict with any naturally occuring names, and leading _ is naturally an error condition. think of _ as the BPV used in DS1 B8SZ to signal six 0-bits. > On the other hand, the way you use the SRV RRs starts one layer below where > 2782 steps in. You already have the "translated" version at hand, so why > bother with "udp" and "tcp" at all? "foolink.udp.example.com" is as good or > bad as "foolink.example.com". But then, if you have a SRV-aware "rcds" > client (2nd example), it would ask for "_rcds._udp.example.com" and you'd > end up with two parallel sub-namespaces for the same purpose (_udp and udp). > > So, for the sake of consistency, I'd think the '_' should always be used, > especially in documentation and examples to reduce readers' confusion. that'll certainly work. however, in the ENUM case, where you're building a tree from scratch, there really are not naturally occuring names to worry about conflicting with. if your SRV library insists on putting _'s in front of things, that may be the determining factor (assuming that you're planning to leverage existing SRV fetching logic in your deployment plan.) otherwise you could just put SRV RR's wherever you want them, in an otherwise known to be non-preexisting tree, like ENUM's. -- 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 Dec 8 13:18:17 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06460 for ; Sun, 8 Dec 2002 13:18:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18L5wO-000KpY-00 for namedroppers-data@psg.com; Sun, 08 Dec 2002 10:14:08 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #2) id 18L5wM-000KpM-00 for namedroppers@ops.ietf.org; Sun, 08 Dec 2002 10:14:06 -0800 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 18L5wM-000POE-00; Sun, 08 Dec 2002 10:14:06 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: SRV RR Questions References: <200212081637.gB8GbJT24931@grimsvotn.TechFak.Uni-Bielefeld.DE> <20021208173955.1BE87379FB3@as.vix.com> Message-Id: Date: Sun, 08 Dec 2002 10:14:06 -0800 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 Content-Transfer-Encoding: 7bit >> RFC 2782 does not only specify the SRV RR but also the way applications or >> libraries are going to use this RR type to locate services. Unfortunately >> in "The format of the SRV RR" it explicitly requires the first two labels >> of the owner domain name to start with a '_'. > yes. however, it's amendable. we wanted to make sure that these names > could not conflict with any naturally occuring names, and leading _ is > naturally an error condition. think of _ as the BPV used in DS1 B8SZ > to signal six 0-bits. o it would be nice to have a clue to whom you are replying o as far as the protocol is concerned, names begining with _ are no more 'un-natural' than names begining with any other octet o this is how we create increasing kink randy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Dec 8 13:18:52 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06479 for ; Sun, 8 Dec 2002 13:18:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18L5y3-000KtF-00 for namedroppers-data@psg.com; Sun, 08 Dec 2002 10:15:51 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #2) id 18L5y1-000Kt2-00 for namedroppers@ops.ietf.org; Sun, 08 Dec 2002 10:15:49 -0800 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 18L5y1-000PQa-00 for namedroppers@ops.ietf.org; Sun, 08 Dec 2002 10:15:49 -0800 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Sun, 8 Dec 2002 18:13:43 +0100 (CET) From: Ketil Froyn To: "Ayyasamy, Senthilkumar " cc: Fred Baker , "Hallam-Baker, Phillip" , , , , Subject: RE: namedroppers, continued X-Spam-Status: No, hits=-3.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,RESENT_TO, SPAM_PHRASE_02_03,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, 6 Dec 2002, Ayyasamy, Senthilkumar wrote: > If the proof of effort requires, say, 10 seconds to compute, then the > economics of sending spam are radically altered, as a single machine > can send only 8,000 messages per day. Wouldn't something like this cause problems for (large/free) email providers? They would probably need a lot of extra hardware to do all this computation. And until something like this is included in the standard, the receiver must accept mail from senders that don't implement this yet. I personally like the idea behind qconfirm (http://smarden.org/qconfirm/) and TMDA (http://tmda.net/). If I receive an email that I do not recognize or otherwise find to be authentic, a mail is sent back to the sender, requesting that they send a verification mail to a unique secret address. When a mail is received at this secret address, the original mail is delivered to me, and the secret address is removed. For a spammer, it is too expensive to receive and reply to all these mails. Ketil -- 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 Dec 8 13:43:30 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06937 for ; Sun, 8 Dec 2002 13:43:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18L6KT-000LXp-00 for namedroppers-data@psg.com; Sun, 08 Dec 2002 10:39:01 -0800 Received: from momotombo.techfak.uni-bielefeld.de ([129.70.136.107]) by psg.com with esmtp (Exim 3.36 #2) id 18L6KQ-000LXc-00 for namedroppers@ops.ietf.org; Sun, 08 Dec 2002 10:38:58 -0800 Received: from grimsvotn.TechFak.Uni-Bielefeld.DE (grimsvotn.TechFak.Uni-Bielefeld.DE [129.70.137.40]) by momotombo.TechFak.Uni-Bielefeld.DE (8.11.6+Sun/8.11.6/TechFak/pk+ro20010720) with ESMTP id gB8IcuU07553 for ; Sun, 8 Dec 2002 19:38:56 +0100 (MET) Received: from localhost (pk@localhost) by grimsvotn.TechFak.Uni-Bielefeld.DE (8.11.6+Sun/8.9.1) with SMTP id gB8IcuN25574 for ; Sun, 8 Dec 2002 19:38:56 +0100 (MET) Message-Id: <200212081838.gB8IcuN25574@grimsvotn.TechFak.Uni-Bielefeld.DE> X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: namedroppers@ops.ietf.org Subject: Re: SRV RR Questions In-reply-to: Your message of "Sun, 08 Dec 2002 10:14:06 PST." X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 Date: Sun, 08 Dec 2002 19:38:56 +0100 From: Peter Koch X-Spam-Status: No, hits=-2.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,X_AUTH_WARNING version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Randy Bush wrote: > o as far as the protocol is concerned, names begining with _ are no > more 'un-natural' than names begining with any other octet that's why I said "unfortunately" when referring to the "_" requirement in RFC 2782. While I understood and support the motivation for the "_" escape, the particular way the RR type is specified there is a bit misleading. RR types should be defined for owner names in general, not for specific labels or set of labels. This does, however, not mean, that certain applications (as in: usage scenarios) for an RR type could not restrict its usage. And now welcome to our regular hostname vs domainname debate -Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Dec 8 17:44:23 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11490 for ; Sun, 8 Dec 2002 17:44:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18L9tk-0002Mh-00 for namedroppers-data@psg.com; Sun, 08 Dec 2002 14:27:40 -0800 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #2) id 18L9ti-0002MV-00 for namedroppers@ops.ietf.org; Sun, 08 Dec 2002 14:27:38 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id A77EB379FB3 for ; Sun, 8 Dec 2002 22:27:37 +0000 (GMT) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: it appears that this whole "ask for AAAA before A" will be painful X-Mailer: MH-E 7.0; nmh 1.0.4; Emacs 21.2 Date: Sun, 08 Dec 2002 22:27:37 +0000 Message-Id: <20021208222737.A77EB379FB3@as.vix.com> X-Spam-Status: No, hits=2.1 required=5.0 tests=SPAM_PHRASE_00_01,UPPERCASE_25_50 version=2.43 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk warning: this is another installment of my long running series of diatribe against "stupid dns tricks" used by almost every form of load balancing product or service i've ever seen. -------- first let me show you who the nameservers are for "united.com" ;; ANSWER SECTION: united.com. 2D IN NS DC1LBS1.ULS-PROD.com. united.com. 2D IN NS DC2LBS1.ULS-PROD.com. ;; ADDITIONAL SECTION: DC1LBS1.ULS-PROD.com. 2D IN A 64.95.89.4 DC2LBS1.ULS-PROD.com. 2D IN A 64.95.88.4 ;; Total query time: 40 msec ;; FROM: ww.vix.com to SERVER: f.gtld-servers.com 192.35.51.30 -------- now let's ask it for the AAAA RR for www.united.com ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 6 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUERY SECTION: ;; www.united.com, type = AAAA, class = IN ;; Total query time: 78 msec ;; FROM: ww.vix.com to SERVER: 64.95.89.4 -------- to show you that it's not AAAA prejudice, let's look for an RT RR: ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 6 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUERY SECTION: ;; www.united.com, type = RT, class = IN ;; Total query time: 73 msec ;; FROM: ww.vix.com to SERVER: 64.95.89.4 -------- now let's let the load balancer do what it thinks its job is: ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUERY SECTION: ;; www.united.com, type = A, class = IN ;; ANSWER SECTION: www.united.com. 5S IN A 64.95.89.8 ;; Total query time: 66 msec ;; FROM: ww.vix.com to SERVER: 64.95.89.4 -------- SERVFAIL is the wrong answer. SERVFAIL is an indication, not that the type isn't known, but that the zone is invalid at that server. recursive servers are within their rights to cache SERVFAIL at , rather than at . the proper answer to a AAAA or RT question, if there are no RR's of that type at that name, is NOERROR/ANCOUNT=0. do we need a BCP draft recommending that SERVFAIL be ignored, in case it came from a load balancer? or shall we call the load balancers faulty, and let web sites like united.com be stranded in the new IPv6 era? -- 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 Dec 8 18:06:06 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11797 for ; Sun, 8 Dec 2002 18:06:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LAH2-00039v-00 for namedroppers-data@psg.com; Sun, 08 Dec 2002 14:51:44 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18LAGz-00039j-00 for namedroppers@ops.ietf.org; Sun, 08 Dec 2002 14:51:41 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18LAGy-0004ny-00 for namedroppers@ops.ietf.org; Sun, 08 Dec 2002 14:51:40 -0800 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Sun, 8 Dec 2002 22:29:36 +0000 (GMT) From: Lloyd Wood To: "Ayyasamy, Senthilkumar (UMKC-Student)" cc: Fred Baker , "Hallam-Baker, Phillip" , , , , Subject: RE: namedroppers, continued X-Spam-Status: No, hits=-2.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,RESENT_TO, SPAM_PHRASE_05_08,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, 6 Dec 2002, Ayyasamy, Senthilkumar (UMKC-Student) wrote: > " If I don't know you, and you want your e-mail to appear in my > inbox, then you must attach to your message an easily verified > "proof of computational effort", just for me and just for this > message. > > If the proof of effort requires, say, 10 seconds to compute, then > the economics of sending spam are radically altered, as a single > machine can send only 8,000 messages per day. tracking moore's law could be a problem. > The recent proliferation of spam has lead to a renewed interest in > these ideas. This work is about both the choice of functions that > can be used to yield easily verifiable proofs of computational > effort, and architectures for implementing the proof of effort > approach. Filtering and/or forcing senders to pay in other > currencies, such as human attention and money, will be covered as > time permits" "Sender pays" is good. The penny black stamp effectively introduced a flat-rate tax on sending letters, rather than a variable-rate tax on receiving them, effectively turning mail into a common good available to all society. The government also undercut private messaging operators and effectively put them out of business, but could use money earned towards other services for society (having simplified and saved on its operational costs along the way). So, computing as a social good - you want to send an email to someone you're unknown to, you've got to provide proof that you're participating in SETI@home, searching for big primes, in a distributed crypto challenge, working on processing public GIS information, autocomparing versions of typed ascii out-of-copyright texts (or raw CD rips?) for accuracy, processing gene data or archived NASA tapes or otherwise doing good things -- guess this would make each computing charity (give us your spare cycles) the ticket server or PKI manager, although you might want to try distributing that too. > for more details > http://research.microsoft.com/research/sv/PennyBlack I don't see any discussion there of the computation as a social good, or computational functions as utility functions. Microsoft, eh? http://www.glassinesurfer.com/f/gsrowlandhill.shtml -- and here's the obligatory mention of Jeremy Bentham. 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 Sun Dec 8 18:08:19 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11823 for ; Sun, 8 Dec 2002 18:08:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LANM-0003MT-00 for namedroppers-data@psg.com; Sun, 08 Dec 2002 14:58:16 -0800 Received: from relay2.av8.net ([130.105.12.4] helo=citation.av8.net) by psg.com with esmtp (Exim 3.36 #2) id 18LANK-0003MF-00 for namedroppers@ops.ietf.org; Sun, 08 Dec 2002 14:58:14 -0800 Received: from news.av8.net (news.av8.net [198.3.136.138]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id MAA27602; Sun, 8 Dec 2002 12:40:47 -0500 Date: Sun, 8 Dec 2002 12:42:40 -0500 (EST) From: Dean Anderson X-X-Sender: To: Danny Mayer cc: Subject: Re: in support of axfr-clarify In-Reply-To: <4.3.1.2.20021207144447.037bacd0@pop.gis.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.5 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,SPAM_PHRASE_00_01, TO_BE_REMOVED_REPLY,USER_AGENT_PINE,X_OSIRU_SPAM_SRC version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Indeed, you are correct. It is very childish to abuse someone attempting to discuss real issues. Can we please stop abusing and maligning Dan Bernstein? By contrast, Dan seems to have valid points, while you don't. --Dean On Sat, 7 Dec 2002, Danny Mayer wrote: > Someone who constantly heaps abuse on people even when they're > attempting to discuss issues for which this mailing list is designed > shouldn't expect sympathy from anyone. It's very childish. > > Can we please get back to discussing issues? > > Danny > > At 11:34 AM 12/7/02, Dean Anderson wrote: > >None of this is accurate. > > > >He may be yelling, but it is a result of sustained abuse over a long, long > >period of time. Frankly, I wouldn't be nearly as patient. > > > > --Dean > > > >On Fri, 6 Dec 2002, Danny Mayer wrote: > > > > > At 01:58 PM 12/6/02, Dean Anderson wrote: > > > >Bernsteins reaction is a natural response to harrassment, and deceptive > > > >labeling regarding axfr-clarify. > > > > > > > > --Dean > > > > > > Yes, the natural response of a child who resorts to threads, abuse, > > > harrassment, > > > yells and screams to get their way, rather than a reasoned response. > > All this > > > from a professor. > > > > > > Danny > > > > > > > > > > > > > >-- > >to unsubscribe send a message to namedroppers-request@ops.ietf.org with > >the word 'unsubscribe' in a single line as the message text body. > >archive: > > > -- > 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 Sun Dec 8 18:09:55 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11846 for ; Sun, 8 Dec 2002 18:09:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LAOL-0003Op-00 for namedroppers-data@psg.com; Sun, 08 Dec 2002 14:59:17 -0800 Received: from relay2.av8.net ([130.105.12.4] helo=citation.av8.net) by psg.com with esmtp (Exim 3.36 #2) id 18LAOJ-0003Oc-00 for namedroppers@ops.ietf.org; Sun, 08 Dec 2002 14:59:15 -0800 Received: from news.av8.net (news.av8.net [198.3.136.138]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id MAA27462; Sun, 8 Dec 2002 12:37:43 -0500 Date: Sun, 8 Dec 2002 12:39:23 -0500 (EST) From: Dean Anderson X-X-Sender: To: "Steven M. Bellovin" cc: "Ayyasamy, Senthilkumar (UMKC-Student)" , Fred Baker , "Hallam-Baker, Phillip" , , , , Subject: Re: namedroppers, continued In-Reply-To: <20021207181505.CE80A7B6B@berkshire.research.att.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.5 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,SPAM_PHRASE_02_03, TO_BE_REMOVED_REPLY,USER_AGENT_PINE,X_OSIRU_SPAM_SRC version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk To make them do all the work, and you do little to verify, you need a lot of things done independently, so that a random sample can be selected that is much smaller than the work they had to do. This will get bulky. The less they send, the larger the fraction of work you have to do in relation to theirs. And of course, you have to do the same amount of work on your outgoing messages as they do. The result is that it costs you much more than it costs the spammer. (since you have to do the work for both sending and receiving, and the spammer only has to do the work for sending. This would not result in a reduction of spam, as a percent of total mail. If everyone used this, it might (at best or worst) reduce the total mail sent, since the billions of legitimate messages sent each day would require significantly more work to send. Further, it would open one up to a denial of service type attack where garbage is sent, and you have to do the work to check the (invalid) signature, thereby wasting your cpu resources. Essentially, this shoots oneself in the foot. Or perhaps the CPU. --Dean On Sat, 7 Dec 2002, Steven M. Bellovin wrote: > In message , Dean An > derson writes: > >This seems clever, however, it will also take significant computational > >effort to verify the computational effort was actually done. Even if a > >class of functions are found that are "easier" to verify than to compute, > >they will no doubt still take up a significant fraction of time. > > In fact, that's the easy part. You could demand that the sender > compute 1,000,000 HMACs of the text, the envelope, the time of day, and > a counter. The verifier could check 100 randomly-chosen ones -- if any > fail, there's a forgery. (Well, you probably wouldn't want those > values, since 1,000,000 HMACs would be a lot of data to transmit. But > you get the general idea.) > > --Steve Bellovin, http://www.research.att.com/~smb (me) > http://www.wilyhacker.com ("Firewalls" book) > > > > -- > 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 Sun Dec 8 18:10:32 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11880 for ; Sun, 8 Dec 2002 18:10:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LAPa-0003TL-00 for namedroppers-data@psg.com; Sun, 08 Dec 2002 15:00:34 -0800 Received: from momotombo.techfak.uni-bielefeld.de ([129.70.136.107]) by psg.com with esmtp (Exim 3.36 #2) id 18LAPX-0003SM-00 for namedroppers@ops.ietf.org; Sun, 08 Dec 2002 15:00:32 -0800 Received: from grimsvotn.TechFak.Uni-Bielefeld.DE (grimsvotn.TechFak.Uni-Bielefeld.DE [129.70.137.40]) by momotombo.TechFak.Uni-Bielefeld.DE (8.11.6+Sun/8.11.6/TechFak/pk+ro20010720) with ESMTP id gB8N0RU11030; Mon, 9 Dec 2002 00:00:27 +0100 (MET) Received: from localhost (pk@localhost) by grimsvotn.TechFak.Uni-Bielefeld.DE (8.11.6+Sun/8.9.1) with SMTP id gB8N0Qf26648; Mon, 9 Dec 2002 00:00:27 +0100 (MET) Message-Id: <200212082300.gB8N0Qf26648@grimsvotn.TechFak.Uni-Bielefeld.DE> X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: it appears that this whole "ask for AAAA before A" will be painful In-reply-to: Your message of "Sun, 08 Dec 2002 22:27:37 GMT." <20021208222737.A77EB379FB3@as.vix.com> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 Date: Mon, 09 Dec 2002 00:00:26 +0100 From: Peter Koch X-Spam-Status: No, hits=-0.5 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_01_02,X_AUTH_WARNING version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > -------- to show you that it's not AAAA prejudice, let's look for an RT RR: Funny enough, try asking for "ANY" ... > SERVFAIL is the wrong answer. SERVFAIL is an indication, not that the type > isn't known, but that the zone is invalid at that server. recursive servers > are within their rights to cache SERVFAIL at , rather than at > . the proper answer to a AAAA or RT question, if there are And how do they know which zone it is that fails? www.United.COM may be in a seperate zone below United.COM, so if you receive a SERVFAIL for queries for www.United.COM you probably can't be sure what to cache anyway. In addition, not even RFC 2308 defines this type of caching. > no RR's of that type at that name, is NOERROR/ANCOUNT=0. One might argue that NOTIMP would also be fine, at least until the "unknown types" draft goes live. The "ANY" result would remain strange, though. -Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Dec 8 19:49:35 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13331 for ; Sun, 8 Dec 2002 19:49:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LBw1-00074V-00 for namedroppers-data@psg.com; Sun, 08 Dec 2002 16:38:09 -0800 Received: from relay2.av8.net ([130.105.12.4] helo=citation.av8.net) by psg.com with esmtp (Exim 3.36 #2) id 18LBvz-00074J-00 for namedroppers@ops.ietf.org; Sun, 08 Dec 2002 16:38:07 -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 TAA07167; Sun, 8 Dec 2002 19:32:16 -0500 Date: Sun, 8 Dec 2002 19:34:10 -0500 (EST) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: Lloyd Wood cc: ietf@ietf.org, , Subject: RE: namedroppers, continued In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=3.4 required=5.0 tests=IN_REP_TO,MARKETING,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,SPAM_PHRASE_03_05,USER_AGENT_PINE, X_OSIRU_SPAM_SRC version=2.43 X-Spam-Level: *** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Sun, 8 Dec 2002, Lloyd Wood wrote: > "Sender pays" is good. The penny black stamp effectively introduced a > flat-rate tax on sending letters, rather than a variable-rate tax on > receiving them, effectively turning mail into a common good available > to all society. You assume this really means "the spammer pays" [more]. But that isn't the case. This is based on the myth that somehow the receiver pays the entire cost of a spam message. This isn't true, and never was true. The sender is already paying, whether they are spammer or mailing list operator, or regular end user. The fact is that email is so cheap that it costs almost nothing per message to send and receive. It gets cheaper every day, as disks and bandwidth get cheaper and cheaper. The receiver doesn't pay any more than the sender pays. Real commercial spam happens because the cost of sending spam is less than the cost of sending letters or postcards. If you artificially made email expensive, it would be expensive for list operators and regular people as well. You mentioned a rate of one cent per message. That would not be enough to deter spam. A rate of ten cents per message would still be cheaper than postal mail, and so spammers would still exist. Much non-commmercial spam is sent by KLEZ or Nimda viruses. This sort of abuse would not be affected whatsoever. Note that KLEZ infections are already illegal. Think how much it would cost to send out namedroppers, (and the entire bulk of IETF standards related email) if each message to each recipient cost, say $0.10. Or even one cent per message per recipient. This proposal would essentially wipe out many if not most mailing list operators, and most ISPs. I made a proposal back in 1997 that would not eliminate spam, but would keep it out of your mailbox. My proposal was rejected because radicals demanded a complete ban on spam. In 1998, there was an opportunity to get anti-spam legislation passed. Unreasonable anti-spam radicals passed up that opportunity when they insisted on unrealistic demands, and exaggerated and factually wrong assertions about the cost of spam. They assumed they could "shout down" any opposition, as they shouted down more reasonable proposals. They were understandably and easily crushed by the Direct Marketing Association (DMA). You can still see my proposal at http://www.av8.com/H.4581/better.html This proposal would have been difficult for the DMA to challenge since they already accept these restrictions on postal mail. You have the radical anti-spam leadership to thank for your spam, and the fact that you don't have a universal opt-out list. The anti-spam effort was for all practical purposes completely crushed when Exactis successfully sued MAPS and demonstrated that blacklists are subject to the Sherman Anti Trust Act and that blacklists weren't protected by the First Amendment. I told Vixie this would happen in 1997. He assured me that anti-spammers could win by technical means. If it wasn't clear that he was wrong in 1997, (and it seemed pretty obvious even then), it is now painfully obvious that Vixie and the rest were very wrong. It is really time for new, reasonable, anti-spam leadership, not artifical changes to the cost of email, or schemes to try to make sending mail more expensive for the senders, and certainly not gyrations in the sending of namedroppers. Thanks to the ineptitude, lack of foresight, irrationality, and general unreasonableness of the anti-spam leadership, spam is here to stay. It is just a matter of degrees of how bad it will be. I note there is some legislation before the house and senate (HR 1017) on spam control, that reportedly isn't opposed by the DMA. However, these only control fraudulent spam. HR 1017 proposes extensions of 18 USC 1030, which makes it a fraudulent spam a crime, but the FBI probably won't bring charges for small violations. There is no provision for a civil action. Another bill (S.630) would require each spammer to maintain an opt-out list. You would have to contact each spammer, and have your email address added to their list, one by one. There would be thousands of spammers to contact. Note that my proposal would had a single opt-out list (the Post Office already maintains such a list for postal junk mail), and my proposal probably could have been passed into law in 1998. --Dean -- 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 Dec 8 20:50:38 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14250 for ; Sun, 8 Dec 2002 20:50:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LCzX-0009my-00 for namedroppers-data@psg.com; Sun, 08 Dec 2002 17:45:51 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18LCzI-0009mQ-00 for namedroppers@ops.ietf.org; Sun, 08 Dec 2002 17:45:36 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18LCzC-0004tT-00 for namedroppers@ops.ietf.org; Sun, 08 Dec 2002 17:45:30 -0800 Message-ID: <20021208233043.46501.qmail@cr.yp.to> References: <20021208222737.A77EB379FB3@as.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Date: 8 Dec 2002 23:30:43 -0000 Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: it appears that this whole "ask for AAAA before A" will be painful X-Spam-Status: No, hits=-1.0 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,RESENT_TO,SPAM_PHRASE_01_02 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Paul Vixie writes: > let web sites like united.com be stranded in the new IPv6 era? Wow. Do you think that IPv6 is some sort of unstoppable force that will beat united.com into submission? Has it ever occurred to you that users care a hell of a lot more about united.com than about IPv6? For further comments, see http://cr.yp.to/djbdns/ipv6mess.html. > SERVFAIL is an indication, not that the type isn't known, but that the > zone is invalid at that server. That's a wild oversimplification. SERVFAIL can indicate all sorts of other problems. > recursive servers are within their rights to cache SERVFAIL at That's absurd. Similarly, it's silly for a client to abandon A records merely because the AAAA-IPv6 connection attempt has failed. The A records are valid whether or not AAAA records exist. Obviously trying A first is better right now, although one can imagine a future world where trying AAAA first is better. None of this would ever have been an issue if people had used 16-byte A records instead of inventing a completely unnecessary AAAA type. ---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 Sun Dec 8 20:50:45 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14264 for ; Sun, 8 Dec 2002 20:50:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LD0Q-0009pQ-00 for namedroppers-data@psg.com; Sun, 08 Dec 2002 17:46:46 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18LD0N-0009pE-00 for namedroppers@ops.ietf.org; Sun, 08 Dec 2002 17:46:44 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18LD0H-0004ta-00 for namedroppers@ops.ietf.org; Sun, 08 Dec 2002 17:46:37 -0800 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Sun, 8 Dec 2002 23:56:14 +0000 (GMT) From: Lloyd Wood To: Randy Bush cc: "D. J. Bernstein" , , , Subject: Re: namedroppers, continued X-Spam-Status: No, hits=-3.5 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,RESENT_TO, SPAM_PHRASE_01_02,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, 6 Dec 2002, Randy Bush wrote: > > Okay, Bush: Put djb@cr.yp.to on the list of addresses from which > > submissions are automatically accepted. > > sorry bernstein. as your message also was addressed to lists to > which i subscribe, the copy to namedroppers-owner was deleted > locally due to dupe message-id: detection. As I said and as this has clearly demonstrated, Randy doesn't understand admin/policy separation, or that namedroppers-owner should be a completely different entity to Randy Bush (or at the very least, carefully and deliberately treated as such). djb _does_ understand admin/policy separation (as his software demonstrates) - but far too well, as he insists on applying it to all of his emails and addresses in a somewhat perverse and rather schizoid way. Paul Vixie writes: $ for the record, we must each work to create the world we want to $ live in (and that we want our children to live in.) our children and not all children? can't say I'm big on the Divine Rights of Parents. $ i'm not in universal agreement with dbj nor with randy bush, but i $ won't fault them for their passion about making the world more like $ whatever they each think "better" means. Oh, come on. This entire thread has been about each of them trying to make their personal email better for themselves, about whom they are naturally deeply, deeply passionate. L. hitler had loads of passion for remaking the world in his desired image. is this thread over now? -- 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 Dec 8 20:54:08 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14344 for ; Sun, 8 Dec 2002 20:54:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LD1r-0009sl-00 for namedroppers-data@psg.com; Sun, 08 Dec 2002 17:48:15 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18LD1o-0009sX-00 for namedroppers@ops.ietf.org; Sun, 08 Dec 2002 17:48:12 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18LD1n-0004tn-00 for namedroppers@ops.ietf.org; Sun, 08 Dec 2002 17:48:11 -0800 Message-ID: <001701c29f1f$9f04f520$e544903f@a> References: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit From: "Bill Cunningham" To: "Lloyd Wood" , "Ayyasamy, Senthilkumar \(UMKC-Student\)" Cc: "Fred Baker" , "Hallam-Baker, Phillip" , , , , Subject: Re: namedroppers, continued Date: Sun, 8 Dec 2002 20:09:24 -0500 X-Spam-Status: No, hits=1.7 required=5.0 tests=FROM_ENDS_IN_NUMS,MAILTO_TO_SPAM_ADDR,QUOTED_EMAIL_TEXT, REFERENCES,RESENT_TO,SPAM_PHRASE_05_08 version=2.43 X-Spam-Level: * 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. ] ---- Original Message ----- From: "Lloyd Wood" To: "Ayyasamy, Senthilkumar (UMKC-Student)" Cc: "Fred Baker" ; "Hallam-Baker, Phillip" ; ; ; ; Sent: Sunday, December 08, 2002 5:29 PM Subject: RE: namedroppers, continued > On Fri, 6 Dec 2002, Ayyasamy, Senthilkumar (UMKC-Student) wrote: > > > " If I don't know you, and you want your e-mail to appear in my > > inbox, then you must attach to your message an easily verified > > "proof of computational effort", just for me and just for this > > message. > > > > If the proof of effort requires, say, 10 seconds to compute, then > > the economics of sending spam are radically altered, as a single > > machine can send only 8,000 messages per day. > > tracking moore's law could be a problem. > > > The recent proliferation of spam has lead to a renewed interest in > > these ideas. This work is about both the choice of functions that > > can be used to yield easily verifiable proofs of computational > > effort, and architectures for implementing the proof of effort > > approach. Filtering and/or forcing senders to pay in other > > currencies, such as human attention and money, will be covered as > > time permits" > > "Sender pays" is good. The penny black stamp effectively introduced a > flat-rate tax on sending letters, rather than a variable-rate tax on > receiving them, effectively turning mail into a common good available > to all society. Lloyd, in the US we pay .37 to mail a first-class letter. I don't know how many pence you pay in the UK but we still have "spam" bulk rate unwanted solicitations. Forcing the sender to pay doesn't solve a spam problem. I don't see how in could. It would force everyone to have to pay a price. > The government also undercut private messaging operators and > effectively put them out of business, but could use money earned > towards other services for society (having simplified and saved on its > operational costs along the way). > > So, computing as a social good - you want to send an email to someone > you're unknown to, you've got to provide proof that you're > participating in SETI@home, searching for big primes, in a distributed > crypto challenge, working on processing public GIS information, > autocomparing versions of typed ascii out-of-copyright texts (or raw > CD rips?) for accuracy, processing gene data or archived NASA tapes or > otherwise doing good things -- guess this would make each computing > charity (give us your spare cycles) the ticket server or PKI manager, > although you might want to try distributing that too. > > > for more details > > http://research.microsoft.com/research/sv/PennyBlack > > I don't see any discussion there of the computation as a social good, > or computational functions as utility functions. Microsoft, eh? > > http://www.glassinesurfer.com/f/gsrowlandhill.shtml > -- and here's the obligatory mention of Jeremy Bentham. > > 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 Sun Dec 8 21:05:10 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14592 for ; Sun, 8 Dec 2002 21:05:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LDDk-000ASY-00 for namedroppers-data@psg.com; Sun, 08 Dec 2002 18:00:32 -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 18LDDh-000ARb-00 for namedroppers@ops.ietf.org; Sun, 08 Dec 2002 18:00:29 -0800 Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [192.139.46.20]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id gB91x6206984 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Sun, 8 Dec 2002 20:59:13 -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 gB91x4ft007237 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Sun, 8 Dec 2002 20:59:06 -0500 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 gB91wxG9007234 for ; Sun, 8 Dec 2002 20:59:03 -0500 Message-Id: <200212090159.gB91wxG9007234@sandelman.ottawa.on.ca> To: namedroppers@ops.ietf.org Subject: Re: it appears that this whole "ask for AAAA before A" will be painful In-reply-to: Your message of "Sun, 08 Dec 2002 22:27:37 GMT." <20021208222737.A77EB379FB3@as.vix.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Sun, 08 Dec 2002 20:58:58 -0500 From: Michael Richardson 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 >>>>> "Paul" == Paul Vixie writes: Paul> SERVFAIL is the wrong answer. SERVFAIL is an indication, not that the type Paul> isn't known, but that the zone is invalid at that server. recursive servers Paul> are within their rights to cache SERVFAIL at , rather than at Paul> . the proper answer to a AAAA or RT question, if there are Paul> no RR's of that type at that name, is NOERROR/ANCOUNT=0. Indeed. Paul> do we need a BCP draft recommending that SERVFAIL be ignored, in case it came Paul> from a load balancer? or shall we call the load balancers faulty, and let Paul> web sites like united.com be stranded in the new IPv6 era? I expect that the first part was rhetorical? How could we tell if it was a load balancer? This is something that places like rfc-ignorant.org should document. ] 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"); [ -- 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 Dec 8 22:53:41 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16532 for ; Sun, 8 Dec 2002 22:53:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LEoc-000FID-00 for namedroppers-data@psg.com; Sun, 08 Dec 2002 19:42:42 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18LEoV-000FHZ-00 for namedroppers@ops.ietf.org; Sun, 08 Dec 2002 19:42:36 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18LEoI-0000Sy-00 for namedroppers@ops.ietf.org; Sun, 08 Dec 2002 19:42:22 -0800 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Mon, 9 Dec 2002 03:14:43 +0000 (GMT) From: Lloyd Wood To: Dean Anderson cc: ietf@ietf.org, , , Subject: RE: namedroppers, continued X-Spam-Status: No, hits=-1.5 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,MARKETING,QUOTED_EMAIL_TEXT, RESENT_TO,SPAM_PHRASE_03_05,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 Sun, 8 Dec 2002, Dean Anderson wrote: > On Sun, 8 Dec 2002, Lloyd Wood wrote: > > "Sender pays" is good. The penny black stamp effectively introduced a > > flat-rate tax on sending letters, rather than a variable-rate tax on > > receiving them, effectively turning mail into a common good available > > to all society. > > You assume this really means "the spammer pays" [more]. that quote is excerpted out of context. > But that isn't the case. This is based on the myth that somehow the > receiver pays the entire cost of a spam message. This isn't true, > and never was true. It's true. It's an attention economy, where the recipients' lives and time are finite. But placing a value on time is tricky. > The sender is already paying, whether they are spammer or mailing > list operator, or regular end user. The fact is that email is so > cheap that it costs almost nothing per message to send and receive. > It gets cheaper every day, as disks and bandwidth get cheaper and > cheaper. The receiver doesn't pay any more than the sender pays. only if a purely fiscal definition is taken. > Real commercial spam happens because the cost of sending spam is > less than the cost of sending letters or postcards. this is very true. It's also true for physical commercial bulk mail, which gets special rates compared to individual letters or postcards. Bill Cunningham adds: $ Lloyd, in the US we pay .37 to mail a first-class letter. I don't $ know how many pence you pay in the UK but we still have "spam" bulk $ rate unwanted solicitations. ...that are paid for at commercial bulk rates vastly cheaper than the individual rate, which encourages them. That's what you get for running the postal service as a commercial business rather than as a emphasising the social good aspects. $ Forcing the sender to pay doesn't solve a spam problem. I don't see $ how in could. It would force everyone to have to pay a price. if everyone pays the same price, then those sending the most are most penalised. flat-rate. > If you artificially made email expensive, it would be expensive for > list operators and regular people as well. You mentioned a rate of > one cent per message. I did not mention such a rate; you've taken the Penny Black one-penny-over-150-years-ago and run with it. Perhaps you would care to actually read my entire message, and tailor your canned rant to it? The act of subscribing to a list indicates that you know the list, and you're less likely to reject mail from people you don't know that comes or also comes via the list, since you're interested in reading that list -- unless the list is a simple exploder with no filtering mechanisms itself, in which case, subscribers pester each other (rather than the list) for computational proofs until the list implements spam filtering. L. > That would not be enough to deter spam. A rate of ten cents per > message would still be cheaper than postal mail, and so spammers would > still exist. Much non-commmercial spam is sent by KLEZ or Nimda viruses. > This sort of abuse would not be affected whatsoever. Note that KLEZ > infections are already illegal. > > Think how much it would cost to send out namedroppers, (and the entire > bulk of IETF standards related email) if each message to each recipient > cost, say $0.10. Or even one cent per message per recipient. This > proposal would essentially wipe out many if not most mailing list > operators, and most ISPs. > > I made a proposal back in 1997 that would not eliminate spam, but would > keep it out of your mailbox. My proposal was rejected because radicals > demanded a complete ban on spam. In 1998, there was an opportunity to get > anti-spam legislation passed. Unreasonable anti-spam radicals passed up > that opportunity when they insisted on unrealistic demands, and > exaggerated and factually wrong assertions about the cost of spam. They > assumed they could "shout down" any opposition, as they shouted down more > reasonable proposals. They were understandably and easily crushed by the > Direct Marketing Association (DMA). You can still see my proposal at > http://www.av8.com/H.4581/better.html This proposal would have been > difficult for the DMA to challenge since they already accept these > restrictions on postal mail. You have the radical anti-spam leadership to > thank for your spam, and the fact that you don't have a universal opt-out > list. > > The anti-spam effort was for all practical purposes completely crushed > when Exactis successfully sued MAPS and demonstrated that blacklists are > subject to the Sherman Anti Trust Act and that blacklists weren't > protected by the First Amendment. I told Vixie this would happen in 1997. > He assured me that anti-spammers could win by technical means. If it > wasn't clear that he was wrong in 1997, (and it seemed pretty obvious even > then), it is now painfully obvious that Vixie and the rest were very > wrong. > > It is really time for new, reasonable, anti-spam leadership, not artifical > changes to the cost of email, or schemes to try to make sending mail more > expensive for the senders, and certainly not gyrations in the sending of > namedroppers. > > Thanks to the ineptitude, lack of foresight, irrationality, and general > unreasonableness of the anti-spam leadership, spam is here to stay. It is > just a matter of degrees of how bad it will be. I note there is some > legislation before the house and senate (HR 1017) on spam control, that > reportedly isn't opposed by the DMA. However, these only control > fraudulent spam. HR 1017 proposes extensions of 18 USC 1030, which makes > it a fraudulent spam a crime, but the FBI probably won't bring charges for > small violations. There is no provision for a civil action. > > Another bill (S.630) would require each spammer to maintain an opt-out > list. You would have to contact each spammer, and have your email address > added to their list, one by one. There would be thousands of spammers to > contact. > > Note that my proposal would had a single opt-out list (the Post Office > already maintains such a list for postal junk mail), and my proposal > probably could have been passed into law in 1998. > > --Dean > > -- 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 Dec 8 23:32:10 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17140 for ; Sun, 8 Dec 2002 23:32:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LFUW-000HMC-00 for namedroppers-data@psg.com; Sun, 08 Dec 2002 20:26:00 -0800 Received: from boreas.isi.edu ([128.9.160.161]) by psg.com with esmtp (Exim 3.36 #2) id 18LFUT-000HLz-00 for namedroppers@ops.ietf.org; Sun, 08 Dec 2002 20:25:57 -0800 Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6/8.11.2) id gB94Pac09995; Sun, 8 Dec 2002 20:25:36 -0800 (PST) From: Bill Manning Message-Id: <200212090425.gB94Pac09995@boreas.isi.edu> Subject: Re: it appears that this whole "ask for AAAA before A" will be painful In-Reply-To: <20021208222737.A77EB379FB3@as.vix.com> from Paul Vixie at "Dec 8, 2 10:27:37 pm" To: paul@vix.com (Paul Vixie) Date: Sun, 8 Dec 2002 20:25:36 -0800 (PST) Cc: 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=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 % do we need a BCP draft recommending that SERVFAIL be ignored, in case it came % from a load balancer? or shall we call the load balancers faulty, and let % web sites like united.com be stranded in the new IPv6 era? % the distinction here is that IPv4 and IPv6 are different protocols, much like SNA and DECnet are different. local optimizations e.g. load balancers designed for a subset of DNS capability under IPv4, should be recongnised as such when considering larger, global usefulness. while united.com may be a poor example, most sites (that will still be around) will adjust to adopt new techniques/technologies that are able to bring value, be that IPv6, DNSSEC, IDN or any other new feature that the DNS is asked to accomodate. my 0.02, don't accomodate such cruft. no bcp recommending SERVFAIL better would be a bcp pointing out the problems with minimialist, local optimizations. --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 Dec 9 00:09:52 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17985 for ; Mon, 9 Dec 2002 00:09:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LG5m-000JJQ-00 for namedroppers-data@psg.com; Sun, 08 Dec 2002 21:04:30 -0800 Received: from mx05.gis.net ([208.218.130.13] helo=gis.net) by psg.com with esmtp (Exim 3.36 #2) id 18LG5k-000JJB-00 for namedroppers@ops.ietf.org; Sun, 08 Dec 2002 21:04:28 -0800 Received: from tecotoo.www.gis.net ([67.30.189.30]) by mx05.gis.net; Mon, 09 Dec 2002 00:04:26 -0500 Received: from localhost (localhost [127.0.0.1]) by tecotoo.www.gis.net (NTMail 3.02.13) with ESMTP id wa029506 for ; Mon, 9 Dec 2002 00:08:43 -0500 Message-Id: <4.3.1.2.20021209000753.038253f0@pop.gis.net> X-Sender: mayer@pop.gis.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 09 Dec 2002 00:08:25 -0500 To: Dean Anderson From: Danny Mayer Subject: Re: in support of axfr-clarify Cc: In-Reply-To: References: <4.3.1.2.20021207144447.037bacd0@pop.gis.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Info: NTMail 3.02 Server on TECOTOO X-Rcpt-To: X-Spam-Status: No, hits=0.5 required=5.0 tests=IN_REP_TO,RCVD_IN_OSIRUSOFT_COM,REFERENCES, SPAM_PHRASE_00_01,X_OSIRU_DUL version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 12:42 PM 12/8/02, Dean Anderson wrote: >Indeed, you are correct. It is very childish to abuse someone attempting >to discuss real issues. Can we please stop abusing and maligning Dan >Bernstein? > >By contrast, Dan seems to have valid points, while you don't. You're confusing me with someone else. Danny > --Dean -- 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 Dec 9 00:15:23 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18052 for ; Mon, 9 Dec 2002 00:15:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LGDb-000Jm7-00 for namedroppers-data@psg.com; Sun, 08 Dec 2002 21:12:35 -0800 Received: from coconut.itojun.org ([219.101.47.130]) by psg.com with esmtp (Exim 3.36 #2) id 18LGDR-000Jj1-00 for namedroppers@ops.ietf.org; Sun, 08 Dec 2002 21:12:25 -0800 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id A89454B22 for ; Mon, 9 Dec 2002 14:12:23 +0900 (JST) To: namedroppers@ops.ietf.org In-reply-to: bmanning's message of Sun, 08 Dec 2002 20:25:36 PST. <200212090425.gB94Pac09995@boreas.isi.edu> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: it appears that this whole "ask for AAAA before A" will be painful Date: Mon, 09 Dec 2002 14:12:23 +0900 From: Jun-ichiro itojun Hagino Message-Id: <20021209051223.A89454B22@coconut.itojun.org> 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 >% do we need a BCP draft recommending that SERVFAIL be ignored, in case it came >% from a load balancer? or shall we call the load balancers faulty, and let >% web sites like united.com be stranded in the new IPv6 era? draft-itojun-jinmei-ipv6-issues-00.txt section 4.4 talks about the problem. i'm not too sure how to make this document progress, but anyways, it's a start. time for rfc1912bis? itojun -- 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 Dec 9 00:18:55 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18137 for ; Mon, 9 Dec 2002 00:18:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LGHU-000JxO-00 for namedroppers-data@psg.com; Sun, 08 Dec 2002 21:16:36 -0800 Received: from mx04.gis.net ([208.218.130.12] helo=gis.net) by psg.com with esmtp (Exim 3.36 #2) id 18LGHR-000Jw7-00 for namedroppers@ops.ietf.org; Sun, 08 Dec 2002 21:16:33 -0800 Received: from tecotoo.www.gis.net ([67.30.189.30]) by mx04.gis.net; Mon, 09 Dec 2002 00:16:32 -0500 Received: from localhost (localhost [127.0.0.1]) by tecotoo.www.gis.net (NTMail 3.02.13) with ESMTP id xa029507 for ; Mon, 9 Dec 2002 00:20:44 -0500 Message-Id: <4.3.1.2.20021209000917.037e3e00@pop.gis.net> X-Sender: mayer@pop.gis.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 09 Dec 2002 00:20:16 -0500 To: From: Danny Mayer Subject: rsync vs. axfr-clarify (was: in support of axfr-clarify) In-Reply-To: References: <4.3.1.2.20021207144447.037bacd0@pop.gis.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Info: NTMail 3.02 Server on TECOTOO X-Rcpt-To: X-Spam-Status: No, hits=0.5 required=5.0 tests=IN_REP_TO,RCVD_IN_OSIRUSOFT_COM,REFERENCES, SPAM_PHRASE_00_01,X_OSIRU_DUL version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I'd like to bring this back on track here. I'd like to look at what rsync (as recommended by the DJBDNS company) does and what axfr-clarify says to do. Let us say we have two servers A and B that are authorative for a zone. The contents of the zone reside in a file named Z on server A and in a file named Z' on server B. An admin adds records to file Z on server A and reloads the server. rsync notices the change to the file and transfers the delta to server B and merges the changes into file Z'. If I understand correctly rsync, the contents of file Z' is now identical to that of Z. Server B is now reloaded and can respond to queries on the new records. Isn't this exactly what axfr-clarify is trying to accomplish, i.e. the records in the zone should be transferred unchanged from server A to server B irrespective of other information that the server may have regarding some of the records? Why should AXFR be different in this respect from rsync? Danny -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Dec 9 00:50:48 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18735 for ; Mon, 9 Dec 2002 00:50:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LGlN-000LZ0-00 for namedroppers-data@psg.com; Sun, 08 Dec 2002 21:47:29 -0800 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #2) id 18LGlL-000LYn-00 for namedroppers@ops.ietf.org; Sun, 08 Dec 2002 21:47:27 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id D9300379FC6 for ; Mon, 9 Dec 2002 05:47:26 +0000 (GMT) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: it appears that this whole "ask for AAAA before A" will be painful In-Reply-To: Message from Bill Manning of "Sun, 08 Dec 2002 20:25:36 PST." <200212090425.gB94Pac09995@boreas.isi.edu> X-Mailer: MH-E 7.0; nmh 1.0.4; Emacs 21.2 Date: Mon, 09 Dec 2002 05:47:26 +0000 Message-Id: <20021209054726.D9300379FC6@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 > ... my 0.02, don't accomodate such cruft. ... too late. bind9's caching resolver already handled this condition by using lame servers as a last resort once all non-lame servers had been tried. this is bad for the network, since it means more queries will be spewed into the ether during actual lame-zone situations. it also insulates the fools who wrote whatever load balancer united.com uses from their deserved fate which is to go out of business (quicker) and not inflict their sloppy implementations on the rest of us. however, as of tonight, bind8 does the same thing, following the robustness principle. what this looks like is that SERVFAIL is now a nonfunctional encoding and that EDNS needs to enumerate the error conditions it was intended to signal, and then we can all live in peace until the load balancer fools learn about EDNS and decide to "implement" it. -- 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 Dec 9 05:40:27 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04359 for ; Mon, 9 Dec 2002 05:40:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LLB7-0009Y9-00 for namedroppers-data@psg.com; Mon, 09 Dec 2002 02:30:21 -0800 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.36 #2) id 18LLB4-0009XV-00 for namedroppers@ops.ietf.org; Mon, 09 Dec 2002 02:30:19 -0800 Received: from x22.ripe.net.ripe.net (x22.ripe.net [193.0.1.22]) by birch.ripe.net (8.12.5/8.11.6) with ESMTP id gB9ATivQ015243; Mon, 9 Dec 2002 11:29:44 +0100 Date: Mon, 9 Dec 2002 11:29:44 +0100 (CET) From: Bruce Campbell X-X-Sender: bc@x22.ripe.net To: Danny Mayer cc: namedroppers@ops.ietf.org Subject: Re: rsync vs. axfr-clarify (was: in support of axfr-clarify) In-Reply-To: <4.3.1.2.20021209000917.037e3e00@pop.gis.net> 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 Mon, 9 Dec 2002, Danny Mayer wrote: > Let us say we have two servers A and B that are authorative for a zone. > The contents of the zone reside in a file named Z on server A and in a file > named Z' on server B. > > An admin adds records to file Z on server A and reloads the server. rsync > notices the change to the file and transfers the delta to server B and merges > the changes into file Z'. If I understand correctly rsync, the contents of > file Z' > is now identical to that of Z. Server B is now reloaded and can respond to > queries on the new records. Yes. > Isn't this exactly what axfr-clarify is trying to accomplish, i.e. the records Nearly. > in the zone should be transferred unchanged from server A to server B > irrespective of other information that the server may have regarding some > of the records? Why should AXFR be different in this respect from rsync? The main difference between AXFR and rsync-over-ssh is that the latter produces an exact copy of a given _file_. The former SHOULD produce a functionally-identical copy of a given _zone_. ( I say 'SHOULD' because a number of implementations do not produce functionally-identical copies, due to confusion about the existing definition of AXFR, as has been noted previously. ) This means, since there is no set standard for an actual zone file, that you can only (reliably) do rsync-over-ssh if you have identical server software on both servers. If you have two servers using different zone file formats, that understand AXFR, you should be able to get working transfers of zones, without having to mess around with post-converting the zone file from one format to another, to say nothing of a separate process to detect changes and trigger a zone or server reload. Hence, I support the general need for a clarification of AXFR so that various nameserver implementations can reliably act as both primary or secondary depending on local configuration. --==-- 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 Dec 9 06:02:50 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04694 for ; Mon, 9 Dec 2002 06:02:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LLX0-000BMq-00 for namedroppers-data@psg.com; Mon, 09 Dec 2002 02:52:58 -0800 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.36 #2) id 18LLWx-000BMb-00 for namedroppers@ops.ietf.org; Mon, 09 Dec 2002 02:52:55 -0800 Received: from x22.ripe.net.ripe.net (x22.ripe.net [193.0.1.22]) by birch.ripe.net (8.12.5/8.11.6) with ESMTP id gB9AqrvQ024155 for ; Mon, 9 Dec 2002 11:52:53 +0100 Date: Mon, 9 Dec 2002 11:52:53 +0100 (CET) From: Bruce Campbell X-X-Sender: bc@x22.ripe.net To: namedroppers@ops.ietf.org Subject: Re: in support of axfr-clarify In-Reply-To: <200212051659.gB5GxOg06337@syn.hamachi.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,SPAM_PHRASE_00_01, USER_AGENT_PINE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ http://www.ietf.org/internet-drafts/draft-ietf-dnsext-axfr-clarify-05.txt ] On Thu, 5 Dec 2002, Bill Sommerfeld wrote: > I support the current axfr-clarify draft as-is. Section 3. could do with a reference to an updated RCODE listing (ie, which RFC was NOTAUTH defined in?) I would also like to see a clear exemption for responding to a zone transfer request if the master server feels that the slave has made too many queries in a short space of time (phrased in such a manner that the slave will get at least one response in a given time period). Section 6 is partially incorrect in stating that it does not solve any existing security-related problems, in that by removing ambiguity of which records to transfer, you are removing the possibility of errors in a given zone corrupting information in other zones (on the same server), and preventing the replication of such corruption further. Is good otherwise. --==-- 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 Dec 9 07:20:17 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05913 for ; Mon, 9 Dec 2002 07:20:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LMqN-000H3v-00 for namedroppers-data@psg.com; Mon, 09 Dec 2002 04:17:03 -0800 Received: from mx05.gis.net ([208.218.130.13] helo=gis.net) by psg.com with esmtp (Exim 3.36 #2) id 18LMqK-000H3j-00 for namedroppers@ops.ietf.org; Mon, 09 Dec 2002 04:17:00 -0800 Received: from tecotoo.www.gis.net ([63.214.103.176]) by mx05.gis.net; Mon, 09 Dec 2002 07:16:57 -0500 Received: from localhost (localhost [127.0.0.1]) by tecotoo.www.gis.net (NTMail 3.02.13) with ESMTP id za029509 for ; Mon, 9 Dec 2002 07:21:21 -0500 Message-Id: <4.3.1.2.20021209071110.0383b9e0@pop.gis.net> X-Sender: mayer@pop.gis.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 09 Dec 2002 07:21:01 -0500 To: Bruce Campbell From: Danny Mayer Subject: Re: rsync vs. axfr-clarify (was: in support of axfr-clarify) Cc: namedroppers@ops.ietf.org In-Reply-To: References: <4.3.1.2.20021209000917.037e3e00@pop.gis.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Info: NTMail 3.02 Server on TECOTOO X-Rcpt-To: X-Spam-Status: No, hits=-0.3 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM, REFERENCES,SPAM_PHRASE_02_03,X_OSIRU_DUL version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 05:29 AM 12/9/02, Bruce Campbell wrote: >On Mon, 9 Dec 2002, Danny Mayer wrote: > > > Let us say we have two servers A and B that are authorative for a zone. > > The contents of the zone reside in a file named Z on server A and in a file > > named Z' on server B. > > > > An admin adds records to file Z on server A and reloads the server. rsync > > notices the change to the file and transfers the delta to server B and > merges > > the changes into file Z'. If I understand correctly rsync, the contents of > > file Z' > > is now identical to that of Z. Server B is now reloaded and can respond to > > queries on the new records. > >Yes. > > > Isn't this exactly what axfr-clarify is trying to accomplish, i.e. the > records > >Nearly. > > > in the zone should be transferred unchanged from server A to server B > > irrespective of other information that the server may have regarding some > > of the records? Why should AXFR be different in this respect from rsync? > >The main difference between AXFR and rsync-over-ssh is that the latter >produces an exact copy of a given _file_. The former SHOULD produce a >functionally-identical copy of a given _zone_. > >( I say 'SHOULD' because a number of implementations do not produce > functionally-identical copies, due to confusion about the existing > definition of AXFR, as has been noted previously. ) > >This means, since there is no set standard for an actual zone file, that >you can only (reliably) do rsync-over-ssh if you have identical server >software on both servers. Thank you. I should have said functionally identical. An AXFR transfer has no defined order in the records transferred except that the first and last records be the SOA and identical and of course any comments that may have been in the original source file do not get transferred. >If you have two servers using different zone file formats, that understand >AXFR, you should be able to get working transfers of zones, without having >to mess around with post-converting the zone file from one format to >another, to say nothing of a separate process to detect changes and >trigger a zone or server reload. Yes, the storage of the data can be in any format, including a database. >Hence, I support the general need for a clarification of AXFR so that >various nameserver implementations can reliably act as both primary or >secondary depending on local configuration. > >--==-- >Bruce. Danny -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Dec 9 10:11:23 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12567 for ; Mon, 9 Dec 2002 10:11:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LPPn-0002mH-00 for namedroppers-data@psg.com; Mon, 09 Dec 2002 07:01:47 -0800 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #2) id 18LPPk-0002ll-00 for namedroppers@ops.ietf.org; Mon, 09 Dec 2002 07:01: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 gB9F1fYm010073 for ; Mon, 9 Dec 2002 10:01:41 -0500 (EST) Received: from [66.44.92.81] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id KAA26814 for ; Mon, 9 Dec 2002 10:01:36 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <20021208173955.1BE87379FB3@as.vix.com> References: <20021208173955.1BE87379FB3@as.vix.com> Date: Mon, 9 Dec 2002 09:56:13 -0500 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: SRV RR Questions Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=0.2 required=5.0 tests=IN_REP_TO,RCVD_IN_OSIRUSOFT_COM,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,X_OSIRU_DUL version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 17:39 +0000 12/8/02, Paul Vixie wrote: > Someone else wrote: >> RFC 2782 does not only specify the SRV RR but also the way applications or >> libraries are going to use this RR type to locate services. Unfortunately >> in "The format of the SRV RR" it explicitly requires the first two labels >> of the owner domain name to start with a '_'. > >yes. however, it's amendable. RFC 2782 is still at "just" proposed standard...awaiting implementation experience and interoperability before progressing to draft standard. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Dec 9 10:13:29 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12738 for ; Mon, 9 Dec 2002 10:13:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LPPk-0002lu-00 for namedroppers-data@psg.com; Mon, 09 Dec 2002 07:01:44 -0800 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #2) id 18LPPf-0002hb-00 for namedroppers@ops.ietf.org; Mon, 09 Dec 2002 07:01:39 -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 gB9F1ZYm010067; Mon, 9 Dec 2002 10:01:35 -0500 (EST) Received: from [66.44.92.81] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id KAA26810; Mon, 9 Dec 2002 10:01:33 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <20021209054726.D9300379FC6@as.vix.com> References: <20021209054726.D9300379FC6@as.vix.com> Date: Mon, 9 Dec 2002 09:49:57 -0500 To: Paul Vixie , namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: it appears that this whole "ask for AAAA before A" will be painful Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-0.1 required=5.0 tests=IN_REP_TO,RCVD_IN_OSIRUSOFT_COM,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_01_02,X_OSIRU_DUL version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 5:47 +0000 12/9/02, Paul Vixie wrote: >however, as of tonight, bind8 does the same thing, following the robustness >principle. what this looks like is that SERVFAIL is now a nonfunctional >encoding and that EDNS needs to enumerate the error conditions it was intended >to signal, and then we can all live in peace until the load balancer fools >learn about EDNS and decide to "implement" it. I agree with this. SERVFAIL has popped up in DNSSEC workshops to indicate two different errors - one is when validation has failed and one when the authoritative server(s) is down. What I've told students is: When you do, say, "dig www.tld1.example a" and you get SERVFAIL, issue: "dig www.tld1.example a +norec" and then "dig www.tld1.example +cd". If the answer to the first succeeds and the latter fails, the authority is not available. If the answer to both succeed, then it's a DNSSEC validation failure. If neither succeed, the problem is higher up the tree (like using the real root hints and not the workshop root hints). From an architectural viewpoint, a SERVFAIL may be generated because of an unsuccessful operation by the resolver element or the verifier element, if not from other elements too. (I started looking at architectural elements over the weekend, and haven't finished yet. But this popped up quickly.) ...The problem isn't AAAA vs. A, or what will be driving folks to upgrade in the future, the problem is that we've over-overloaded DNS failure notices. Another example is the referral "upward" which is interpreted as a lame server indication. This "assumption" is causing a problem for the DS RR. #define RANT #ifdef RANT One of the most overlooked elements of a system is error reporting. The main problem with BSD sockets lies here. In the effort to make network access look like file system access (remember "file/device independence" - all the rage in the 80's?) sockets didn't account for reporting errors beyond what was done for the file system. With little or no feedback, applications to this day suffer. (Besides the bad code, there have been a lot of bad coding habits from this.) I was going to give thoughts behind this, but after about a page of ranting about the old days and BSD sockets on VMS, I figured I was getting a bit off topic. #endif -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Dec 9 10:36:24 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14139 for ; Mon, 9 Dec 2002 10:36:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LPoV-0004h2-00 for namedroppers-data@psg.com; Mon, 09 Dec 2002 07:27:19 -0800 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #2) id 18LPo9-0004eB-00 for namedroppers@ops.ietf.org; Mon, 09 Dec 2002 07:26:58 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 81167379FB3 for ; Mon, 9 Dec 2002 15:26:54 +0000 (GMT) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: rsync vs. axfr-clarify (was: in support of axfr-clarify) In-Reply-To: Message from Danny Mayer of "Mon, 09 Dec 2002 07:21:01 EST." <4.3.1.2.20021209071110.0383b9e0@pop.gis.net> X-Mailer: MH-E 7.0; nmh 1.0.4; Emacs 21.2 Date: Mon, 09 Dec 2002 15:26:54 +0000 Message-Id: <20021209152654.81167379FB3@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 this discussion puts me in mind of the following text: > RFC 1034 Domain Concepts and Facilities November 1987 > > 4.3.5. Zone maintenance and transfers > > Part of the job of a zone administrator is to maintain the zones at all > of the name servers which are authoritative for the zone. When the > inevitable changes are made, they must be distributed to all of the name > servers. While this distribution can be accomplished using FTP or some > other ad hoc procedure, the preferred method is the zone transfer part > of the DNS protocol. rsync is thus accounted for. unless this thread intends to modify 1034's intent, which i've seen no evidence of, can you please take it to djbdns-workers@, or to some other implementation-specific forum? -- 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 Dec 9 11:04:33 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15326 for ; Mon, 9 Dec 2002 11:04:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LQEo-0006qb-00 for namedroppers-data@psg.com; Mon, 09 Dec 2002 07:54:30 -0800 Received: from [209.10.143.221] (helo=neonym.net) by psg.com with esmtp (Exim 3.36 #2) id 18LQEg-0006qN-00 for namedroppers@ops.ietf.org; Mon, 09 Dec 2002 07:54:22 -0800 Received: from [207.120.28.115] ([::ffff:207.120.28.115]) (AUTH: PLAIN michael, ) by neonym.net with esmtp; Sun, 08 Dec 2002 21:40:43 -0500 Subject: Re: SRV RR Questions From: Michael Mealling To: Peter Koch Cc: namedroppers@ops.ietf.org In-Reply-To: <200212081637.gB8GbJT24931@grimsvotn.TechFak.Uni-Bielefeld.DE> References: <200212081637.gB8GbJT24931@grimsvotn.TechFak.Uni-Bielefeld.DE> Organization: Harriman Heavy Industries, Inc. Message-Id: <1039449078.6874.55.camel@blackdell.neonym.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.2.0 Date: 09 Dec 2002 10:51:18 -0500 X-Spam-Status: No, hits=-1.5 required=5.0 tests=IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Sun, 2002-12-08 at 11:37, Peter Koch wrote: > Michael Mealling wrote: > > > Is it possible to get some kind of clarification that this is indeed the > > case and that I don't need to go update 3403 and 3404 just to stick an > > underscore into a domain-name that doesn't need it? > > I did not find the critical section in 3403 but there is that example in > section 5.1 of 3404. > It seems to me that 'service' and 'protocol' shouldn't have been provided as > domain name prefixes but instead as seperate strings in the first place. > However, there's no option to change that now. That example in 5.1 is an unfortunate once since there is no need for the 'udp' portion of the domain-name to be there. The point (as Paul says in another message) is that in the case of 3403 and 3404 one already knows the protocol and transport before the SRV query is done. The usage of SRV in this case is not to discovery a service but to merely find where (host, port) a previously discovered service can be found. > RFC 2782 does not only specify the SRV RR but also the way applications or > libraries are going to use this RR type to locate services. Unfortunately > in "The format of the SRV RR" it explicitly requires the first two labels > of the owner domain name to start with a '_'. So, following 2782 by the > letter, your usage would not be covered by the SRV spec. Then, this does > not make sense. Right, and the text that discussed other usages of SRV was lost during the final edit rounds on the document. > On the other hand, the way you use the SRV RRs starts one layer below where > 2782 steps in. You already have the "translated" version at hand, so why > bother with "udp" and "tcp" at all? "foolink.udp.example.com" is as good or > bad as "foolink.example.com". But then, if you have a SRV-aware "rcds" > client (2nd example), it would ask for "_rcds._udp.example.com" and you'd > end up with two parallel sub-namespaces for the same purpose (_udp and udp). If I have an SRV aware rcds client there should be a seperate record for 'arbitrary' rcds clients to contact that server. I.e. an RCDS server located via the method laid out in RFC 3404 is logically different than an RCDS server that can be contacted arbitrarily. Vastly different trust models as the one in 3404 is considered to be authoritative. Thus, anyone setting up an RCDS server could (and maybe should in lots of cases) have both records in there, pointing to possibly two different servers. > So, for the sake of consistency, I'd think the '_' should always be used, > especially in documentation and examples to reduce readers' confusion. But I think it is causing confusion. By putting the '_' in RFC 3404 based usages you are suggesting to the reader that the SRV usage is of the general case (i.e. you can and should contact this server for general RCDS usage when you actually shouldn't). IMHO, the solution should be for RFC 3404 to specify that it should NEVER allow underscores in SRV records so that it is explicitly _not_ confused with the full 2782 usage. -MM -- 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 Dec 9 16:30:24 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03067 for ; Mon, 9 Dec 2002 16:30:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LVE4-0008kJ-00 for namedroppers-data@psg.com; Mon, 09 Dec 2002 13:14:04 -0800 Received: from manukeneko.besserwisser.org ([213.212.3.220] helo=slimsixten.besserwisser.org ident=root) by psg.com with esmtp (Exim 3.36 #2) id 18LVE0-0008jx-00 for namedroppers@ops.ietf.org; Mon, 09 Dec 2002 13:14:00 -0800 Received: from localhost.besserwisser.org (mansaxel@localhost.besserwisser.org [127.0.0.1]) by slimsixten.besserwisser.org (8.12.6/8.12.2) with ESMTP id gB9LDpcv031083 for ; Mon, 9 Dec 2002 22:13:52 +0100 (CET) Date: Mon, 09 Dec 2002 21:52:33 +0100 From: =?ISO-8859-1?Q?M=E5ns_Nilsson?= To: namedroppers@ops.ietf.org Subject: Re: rsync vs. axfr-clarify (was: in support of axfr-clarify) Message-ID: <1879280000.1039467153@localhost> In-Reply-To: References: X-Mailer: Mulberry/2.2.1 (OpenBSD/x86) X-PGP-KEY: http://vvv.besserwisser.org/key MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-Spam-Status: No, hits=-1.5 required=5.0 tests=IN_REP_TO,MIME_LONG_LINE_QP,PGP_SIGNATURE, QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 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 QAA03067 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --On Monday, December 09, 2002 11:29:44 +0100 Bruce Campbell wrote: > Hence, I support the general need for a clarification of AXFR so that > various nameserver implementations can reliably act as both primary or > secondary depending on local configuration. I also would like to support the clarification of AXFR. The interoperable method becomes increasingly important as different implementations take new data storage and backend paradigms in use.[0] As a side note: While some zones have passed the size where AFXR ceases to be a practically feasible synchronisation method, these are in absolute minority -- I believe they can be counted on ones fingers today. Those reluctant or unable to promote or use AXFR might want to document their ideas in another draft, perhaps to DNSOP, as this is strictly a management issue, not a protocol one. - -- Måns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE We're sysadmins. To us, data is a protocol-overhead. [0] Out of the 4 or so implementations I've toyed with the last year, only one (BIND family) uses the classic file -- the others have switched to databases, most often dbm hashes. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (OpenBSD) iD8DBQE99QKU02/pMZDM1cURAk+KAJ9GEOHjlXQ5yOwrmonh4N7uRn9oxQCfTr6U lTHmkik9BIw6GDjAL+1NgOI= =AKWB -----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 Dec 9 16:32:43 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03158 for ; Mon, 9 Dec 2002 16:32:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LVMh-0009UX-00 for namedroppers-data@psg.com; Mon, 09 Dec 2002 13:22:59 -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 18LVMW-0009Tz-00 for namedroppers@ops.ietf.org; Mon, 09 Dec 2002 13:22:49 -0800 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id D231F18E0 for ; Mon, 9 Dec 2002 16:22:45 -0500 (EST) Date: Mon, 09 Dec 2002 16:22:45 -0500 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: Dropping denial of existence of wildcard In-Reply-To: <20021203145446.216891c4.olaf@ripe.net> References: <20021203145446.216891c4.olaf@ripe.net> 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: <20021209212245.D231F18E0@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 Tue, 3 Dec 2002 14:54:46 +0100, Olaf Kolkman wrote: > > The threats model does not document why denial of existence of > wildcards is needed ("in order to provide the desired services" does > not specify 'desired'). Just poor writing on my part. As used in that sentence, "desired services" means "data integrity and data origin authentication". -- 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 Dec 9 17:16:43 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05253 for ; Mon, 9 Dec 2002 17:16:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LW4r-000Dsl-00 for namedroppers-data@psg.com; Mon, 09 Dec 2002 14:08:37 -0800 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #2) id 18LW4m-000DsQ-00 for namedroppers@ops.ietf.org; Mon, 09 Dec 2002 14:08:32 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 12261379FB3 for ; Mon, 9 Dec 2002 22:08:32 +0000 (GMT) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: SRV RR Questions X-Mailer: MH-E 7.0; nmh 1.0.4; Emacs 21.2 Date: Mon, 09 Dec 2002 22:08:32 +0000 Message-Id: <20021209220832.12261379FB3@as.vix.com> X-Spam-Status: No, hits=-1.9 required=5.0 tests=EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Peter Koch writes: > Randy Bush wrote: > > > o as far as the protocol is concerned, names begining with _ are no > > more 'un-natural' than names begining with any other octet i thought that war was over. here's what joyce and --jon said: > From: rfc-ed@ISI.EDU > Date: Tue, 29 Oct 1996 12:58:18 -0800 > Posted-Date: Tue, 29 Oct 1996 12:58:18 -0800 > To: paul@vix.com > Subject: re: rfc-gulbrandsen-dns-rr-srvcs RFC-to-be > Cc: moore@cs.utk.edu, Harald.T.Alvestrand@uninett.no, rfc-ed@ISI.EDU > > Folks, > > Enclosed is a new version of the RFC-to-be, "A DNS RR for specifying > the location of services (DNS SRV)". We have removed the underbars. > We would like to publish this out if there are no comments. Please let > us know if this is okay with you. > > Thanks, Joyce and --jon. naturally, i now wish i had been less strident in my arguments in favour of the underbars -- mostly because the arguments about them and the flipping back and forth and having them vs. not having them has cost SRV quite a bit of deployment inertia. here's what steve traugott said, two years later: -------- To: Stuart Kwan cc: "'Paul A Vixie'" , namedroppers@internic.net Subject: Re: I-D ACTION:draft-ietf-dnsind-rfc2052bis-00.txt Date: Mon, 07 Sep 1998 01:06:03 -0600 From: Steve Traugott That's silly, Stuart. The omitted underscores were an editing mistake, the spec is in experimental state so that these sorts of things can be caught, and it was caught. Paul is trying to fix something that is broke. The reason is to avoid namespace collisions. That makes it a better standard. If you block this then Microsoft's name will be mud. Don't you want Microsoft to be known as a willing participant in enacting good standards instead? I know some of the sensitivites of the Beta 2 release that you're trying to deal with; I was a technology vice president at Chase Manhattan Bank when Beta 1 came out; we were a participant. I can tell you that as an IT manager (i.e.; your customer) I'd much rather see Microsoft do the right thing than take the expedient way out. Breaking beta installs is a one-time-only thing that affects a relatively small user base; leaving this RFC broken permanently will give us consequences we will all have to live with *forever*. Steve Stuart Kwan wrote: > Microsoft Windows NT 5.0 makes heavy use of the SRV RR, mainly for the > location of Active Directory servers. In the recently shipped Beta 2 > release of WinNT 5.0, Active Directory domain controllers use the dynamic > update protocol to register SRV RRs. Active Directory clients query for SRV > RRs. The current code uses RFC2052-spec names (no leading underscores). > > WinNT 5.0 could be characterized as an "Early Adopter" of the (experimental) > SRV RR. To prevent future incompatibilites, we would prefer that the > leading underscore not be reintroduced into the spec. > > Cheers, > - Stuart Kwan > Microsoft Corp. > > > -----Original Message----- > > From: Paul A Vixie [SMTP:paul@VIX.COM] > > Sent: Wednesday, September 02, 1998 12:51 PM > > To: namedroppers@internic.net > > Subject: Re: I-D ACTION:draft-ietf-dnsind-rfc2052bis-00.txt > > > > > Could you summarize what the changes are and why they are being made? > > > My quick scan of the new version didn't immediately pick up on > > > anything, but I didn't do a detailed comparison. I'm just sort of > > > curious since I hadn't heard anything about doing a rev to RFC2052 > > > until the announcement came out. I'd have thought at least a quick > > > mention at Chicago given that DNSIND didn't use all its allotted > > > time... > > > > > > -MAP > > > > The only difference is the putting back in of the _'s that the RFC Editor > > took out of the draft I'd submitted for Experimental status. To wit: > > > > @@ -42,39 +52,42 @@ > > (the word domain is used here in the strict RFC 1034 sense), and get > > back the names of any available servers. > > > > -Introductory example > > > > - When a SRV-cognizant web-browser wants to retrieve > > > > - http://www.asdf.com/ > > > > - it does a lookup of > > > > - http.tcp.www.asdf.com > > > > +Introductory example > > > > + When a SRV-cognizant web-browser wants to retrieve > > > > + http://www.asdf.com/ > > > > + it does a lookup of > > > > + _http._tcp.www.asdf.com > > > > and retrieves the document from one of the servers in the reply. The > > - example zone file near the end of the memo contains answering RRs for > > - this query. > > + example zone file near the end of this memo contains answering RRs > > + for this query. > > + > > > > The format of the SRV RR > > > > Here is the format of the SRV RR, whose DNS type code is 33: > > > > - Service.Proto.Name TTL Class SRV Priority Weight Port Target > > + _Service._Proto.Name TTL Class SRV Priority Weight Port Target > > > > (There is an example near the end of this document.) > > > > Service > > The symbolic name of the desired service, as defined in Assigned > > - Numbers or locally. > > + Numbers or locally. An underscore (_) is prepended to the > > + service identifier to avoid collisions with DNS labels that > > + occur in nature. > > > > Some widely used services, notably POP, don't have a single > > universal name. If Assigned Numbers names the service > > @@ -83,7 +96,9 @@ > > The Service is case insensitive. > > > > Proto > > - TCP and UDP are at present the most useful values > > + The symbolic name of the desired protocol, with an underscore > > + (_) prepended to prevent collisions with DNS labels that occur > > + in nature. _TCP and _UDP are at present the most useful values > > for this field, though any name defined by Assigned Numbers or > > locally may be used (as for Service). The Proto is case > > insensitive. > > @@ -182,31 +194,40 @@ > > > > All round numbers, wrote Dr. Johnson, are false, and these numbers > > are very round: A reply packet has a 30-byte overhead plus the name > > - of the service ("telnet.tcp.asdf.com" for instance); each SRV RR adds > > - 20 bytes plus the name of the target host; each NS RR in the NS > > + of the service (``_telnet._tcp.asdf.com'' for instance); each SRV RR > > + adds 20 bytes plus the name of the target host; each NS RR in the NS > > section is 15 bytes plus the name of the name server host; and > > finally each A RR in the additional data section is 20 bytes or so, > > and there are A's for each SRV and NS RR mentioned in the answer. > > @@ -233,14 +244,14 @@ > > A SRV-cognizant client SHOULD use this procedure to locate a list of > > servers and connect to the preferred one: > > > > - Do a lookup for QNAME=service.protocol.target, QCLASS=IN, > > + Do a lookup for QNAME=_service._protocol.target, QCLASS=IN, > > QTYPE=SRV. > > > > If the reply is NOERROR, ANCOUNT>0 and there is at least one SRV > > RR which specifies the requested Service and Protocol in the > > reply: > > > > If there is precisely one SRV RR, and its Target is "." > > (the root domain), abort. > > > > Else, for all such RR's, build a list of (Priority, Weight, > > @@ -308,7 +364,7 @@ > > or NS RR's.) > > > > - A future standard could specify that a SRV RR whose Protocol was > > - TCP and whose Service was SMTP would override RFC 974's rules > > + _TCP and whose Service was _SMTP would override RFC 974's rules > > with regard to the use of an MX RR. This would allow firewalled > > organizations with several SMTP relays to control the load > > distribution using the Weight field. > > @@ -316,6 +372,7 @@ > > - Future protocols could be designed to use SRV RR lookups as the > > means by which clients locate their servers. > > > > + > > Fictional example > > > > This is (part of) the zone file for asdf.com, a still-unused domain: > > @@ -326,20 +383,20 @@ > > NS server.asdf.com. > > NS ns1.ip-provider.net. > > NS ns2.ip-provider.net. > > - ftp.tcp SRV 0 0 21 server.asdf.com. > > - finger.tcp SRV 0 0 79 server.asdf.com. > > + _ftp._tcp SRV 0 0 21 server.asdf.com. > > + _finger._tcp SRV 0 0 79 server.asdf.com. > > ; telnet - use old-slow-box or new-fast-box if either is > > ; available, make three quarters of the logins go to > > ; new-fast-box. > > - telnet.tcp SRV 0 1 23 old-slow-box.asdf.com. > > > > > > > > -Gulbrandsen & Vixie Experimental [Page 6] > > +Gulbrandsen and Vixie Proposed [Page 7] > > > > -RFC 2052 DNS SRV RR October 1996 > > +RFC 2052bis DNS SRV RR September 1998 > > > > > > + _telnet._tcp SRV 0 1 23 old-slow-box.asdf.com. > > SRV 0 3 23 new-fast-box.asdf.com. > > ; if neither old-slow-box or new-fast-box is up, switch to > > ; using the sysdmin's box and the server > > @@ -347,22 +404,22 @@ > > SRV 1 0 23 server.asdf.com. > > ; HTTP - server is the main server, new-fast-box is the backup > > ; (On new-fast-box, the HTTP daemon runs on port 8000) > > - http.tcp SRV 0 0 80 server.asdf.com. > > + _http._tcp SRV 0 0 80 server.asdf.com. > > SRV 10 0 8000 new-fast-box.asdf.com. > > ; since we want to support both http://asdf.com/ and > > ; http://www.asdf.com/ we need the next two RRs as well > > - http.tcp.www SRV 0 0 80 server.asdf.com. > > + _http._tcp.www SRV 0 0 80 server.asdf.com. > > SRV 10 0 8000 new-fast-box.asdf.com. > > ; SMTP - mail goes to the server, and to the IP provider if > > ; the net is down > > - smtp.tcp SRV 0 0 25 server.asdf.com. > > + _smtp._tcp SRV 0 0 25 server.asdf.com. > > SRV 1 0 25 mailhost.ip-provider.net. > > @ MX 0 server.asdf.com. > > MX 1 mailhost.ip-provider.net. > > ; NNTP - use the IP providers's NNTP server > > - nntp.tcp SRV 0 0 119 nntphost.ip-provider.net. > > + _nntp._tcp SRV 0 0 119 nntphost.ip-provider.net. > > ; IDB is an locally defined protocol > > - idb.tcp SRV 0 0 2025 new-fast-box.asdf.com. > > + _idb._tcp SRV 0 0 2025 new-fast-box.asdf.com. > > ; addresses > > server A 172.30.79.10 > > old-slow-box A 172.30.79.11 > > @@ -377,98 +434,42 @@ > > ; backup A RR for www.asdf.com > > www A 172.30.79.10 > > ; NO other services are supported > > - *.tcp SRV 0 0 0 . > > - *.udp SRV 0 0 0 . > > + *._tcp SRV 0 0 0 . > > + *._udp SRV 0 0 0 . > > > > - In this example, a telnet connection to "asdf.com." needs an SRV > > - lookup of "telnet.tcp.asdf.com." and possibly A lookups of "new- > > - fast-box.asdf.com." and/or the other hosts named. The size of the > > + In this example, a telnet connection to ``asdf.com.'' needs an SRV > > + lookup of ``_telnet._tcp.asdf.com.'' and possibly A lookups of ``new- > > + fast-box.asdf.com.'' and/or the other hosts named. The size of the > > SRV reply is approximately 365 bytes: > > > > 30 bytes general overhead > > - 20 bytes for the query string, "telnet.tcp.asdf.com." > > - 130 bytes for 4 SRV RR's, 20 bytes each plus the lengths of "new- > > + 20 bytes for the query string, ``_telnet._tcp.asdf.com.'' > > > > > > > > -Gulbrandsen & Vixie Experimental [Page 7] > > +Gulbrandsen and Vixie Proposed [Page 8] > > > > -RFC 2052 DNS SRV RR October 1996 > > +RFC 2052bis DNS SRV RR September 1998 > > > > > > - fast-box", "old-slow-box", "server" and "sysadmins-box" - > > - "asdf.com" in the query section is quoted here and doesn't > > + 130 bytes for 4 SRV RR's, 20 bytes each plus the lengths of ``new- > > + fast-box'', ``old-slow-box'', ``server'' and ``sysadmins-box'' - > > + ``asdf.com'' in the query section is quoted here and doesn't > > need to be counted again. > > 75 bytes for 3 NS RRs, 15 bytes each plus the lengths of > > - "server", "ns1.ip-provider.net." and "ns2" - again, "ip- > > - provider.net." is quoted and only needs to be counted once. > > + ``server'', ``ns1.ip-provider.net.'' and ``ns2'' - again, ``ip- > > + provider.net.'' is quoted and only needs to be counted once. > > 120 bytes for the 6 A RR's mentioned by the SRV and NS RR's. > > > > -Refererences > > - > > - RFC 1918: Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G., > > - and E. Lear, "Address Allocation for Private Internets", > > - RFC 1918, February 1996. > > - > > - RFC 1916 Berkowitz, H., Ferguson, P, Leland, W. and P. Nesser, > > - "Enterprise Renumbering: Experience and Information > > - Solicitation", RFC 1916, February 1996. > > - > > - RFC 1912 Barr, D., "Common DNS Operational and Configuration > > - Errors", RFC 1912, February 1996. > > - > > - RFC 1900: Carpenter, B., and Y. Rekhter, "Renumbering Needs Work", > > - RFC 1900, February 1996. > > - > > - RFC 1920: Postel, J., "INTERNET OFFICIAL PROTOCOL STANDARDS", > > - STD 1, RFC 1920, March 1996. > > > > - RFC 1814: Gerich, E., "Unique Addresses are Good", RFC 1814, June > > - 1995. > > - > > - RFC 1794: Brisco, T., "DNS Support for Load Balancing", April 1995. > > - > > - RFC 1713: Romao, A., "Tools for DNS debugging", November 1994. > > - > > - RFC 1712: Farrell, C., Schulze, M., Pleitner, S., and D. Baldoni, > > - "DNS Encoding of Geographical Location", RFC 1712, November > > - 1994. > > - > > - RFC 1706: Manning, B. and R. Colella, "DNS NSAP Resource Records", > > - RFC 1706, October 1994. > > - > > - RFC 1700: Reynolds, J., and J. Postel, "ASSIGNED NUMBERS", > > - STD 2, RFC 1700, October 1994. > > - > > - RFC 1183: Ullmann, R., Mockapetris, P., Mamakos, L., and > > - C. Everhart, "New DNS RR Definitions", RFC 1183, November > > - 1990. > > - > > - > > - > > - > > -Gulbrandsen & Vixie Experimental [Page 8] > > - > > -RFC 2052 DNS SRV RR October 1996 > > - > > - > > - RFC 1101: Mockapetris, P., "DNS encoding of network names and other > > - types", RFC 1101, April 1989. > > - > > - RFC 1035: Mockapetris, P., "Domain names - implementation and > > - specification", STD 13, RFC 1035, November 1987. > > - > > - RFC 1034: Mockapetris, P., "Domain names - concepts and > > - facilities", STD 13, RFC 1034, November 1987. > > +Refererences > > > > - RFC 1033: Lottor, M., "Domain administrators operations guide", > > - RFC 1033, November 1987. > > + RFC 1034: Mockapetris, P., ``Domain names - concepts and > > + facilities'', RFC 1034, November 1987. > > > > - RFC 1032: Stahl, M., "Domain administrators guide", RFC 1032, > > - November 1987. > > + RFC 974: Partridge, C., ``Mail routing and the domain system'', RFC > > + 974, January 1986. > > > > - RFC 974: Partridge, C., "Mail routing and the domain system", > > - STD 14, RFC 974, January 1986. > > > > Security Considerations > > > > @@ -490,74 +491,17 @@ > > host names and addresses. The authors do not see any practical > > effect of this. > > > > - We assume that as the DNS-security people invent new features, DNS > > - servers will return the relevant RRs in the Additional Data section > > - when answering an SRV query. > > - > > - > > - > > - > > - > > - > > - > > - > > - > > - > > -Gulbrandsen & Vixie Experimental [Page 9] > > - > > -RFC 2052 DNS SRV RR October 1996 > > - > > - > > Authors' Addresses > > > > - Arnt Gulbrandsen > > - Troll Tech > > - Postboks 6133 Etterstad > > - N-0602 Oslo > > - Norway > > - > > - Phone: +47 22646966 > > - EMail: agulbra@troll.no > > - > > - > > - Paul Vixie > > - Vixie Enterprises > > - Star Route 159A > > - Woodside, CA 94062 > > - > > - Phone: (415) 747-0204 > > - EMail: paul@vix.com > > - > > - > > - > > - > > - > > - > > - > > - > > - > > + Arnt Gulbrandsen Paul Vixie > > + Troll Tech Internet Software Consortium > > + Postboks 6133 Etterstad 950 Charter Street > > + N-0602 Oslo, Norway Redwood City, CA 94063 > > + +47 22646966 +1 650 779 7001 > > + > > > > > > > > > > - > > - > > - > > - > > - > > - > > - > > - > > - > > - > > - > > - > > - > > - > > - > > - > > - > > - > > - > > -Gulbrandsen & Vixie Experimental [Page 10] > > - > > +Gulbrandsen and Vixie Proposed [Page 9] > > + > > \ No newline at end of file -------- -- Paul Vixie -- 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 Dec 9 18:57:23 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08923 for ; Mon, 9 Dec 2002 18:57:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LXfg-000OJc-00 for namedroppers-data@psg.com; Mon, 09 Dec 2002 15:50:44 -0800 Received: from pigeon.verisign.com ([65.205.251.71]) by psg.com with esmtp (Exim 3.36 #2) id 18LXfd-000OJH-00 for namedroppers@ops.ietf.org; Mon, 09 Dec 2002 15:50:41 -0800 Received: from vhqpostal-gw1.verisign.com (verisign.com [65.205.251.55]) by pigeon.verisign.com (8.12.1/) with ESMTP id gB9NnW48011602; Mon, 9 Dec 2002 15:49:32 -0800 (PST) Received: by vhqpostal-gw1.verisign.com with Internet Mail Service (5.5.2656.59) id ; Mon, 9 Dec 2002 15:50:38 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Paul Vixie'" , namedroppers@ops.ietf.org Subject: RE: SRV RR Questions Date: Mon, 9 Dec 2002 15:50:35 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_0045_01C29F9A.B62B34A0"; protocol="application/x-pkcs7-signature" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=4.1 required=5.0 tests=EXCHANGE_SERVER,MISSING_OUTLOOK_NAME,RCVD_IN_RFCI, SPAM_PHRASE_00_01 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_0045_01C29F9A.B62B34A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit In like vein there is a LOT of current interest in using SRV to locate XKMS services and other PKI services. I just want a character string to serve as an index term for an XKMS service, I don't give a hoot what it is, but if the group cannot decide what it should be quickly I will simply let the current draft go out with its own idea of what the string should be. This is a naming issue. It does not matter what the group chooses but there is a strictly limited time to make the choice. At present the draft specifies: _xkiss_soap_http._tcp _xkiss_soap_http._tcp There is an aligned PKIX draft with LDAP entries: _pkix_ldap._tcp To which it has been suggested that we add: _dpd_http._tcp _dpv_http._tcp _ocsp_http._tcp _cmp_http._tcp Donald Eastlake has suggested an alternative encoding for the higher level services : _xkms-xkiss-soap._http._tcp I really don't care what the name structure that is chosen is. But I do care that there is a choice made. Phill ------=_NextPart_000_0045_01C29F9A.B62B34A0 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 BQCgggGMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTIwOTIz NTAzNFowIwYJKoZIhvcNAQkEMRYEFOMBCCLWPcQJrrxVVEtUsuy8i0/DMFgGCSqGSIb3DQEJDzFL MEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcG BSsOAwIaMAoGCCqGSIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2Ug aXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChj KTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQO rwvJMA0GCSqGSIb3DQEBAQUABIGAbHRsx+x+gYZw2Siyspi2SCqJhYY//Kpdekry5zCRdLXrEXmO FB1zdqF3m6/ieK3YtYwZ7fpGKR8u0h4cv/r6VSa89bJ6FiSiHmh2OoF3ULbxSKqEXtwT6dhorFEy fPPiqlQJSVgIetM4buAzLxZsDCydSBBqJD+4bZjBld4hCF0AAAAAAAA= ------=_NextPart_000_0045_01C29F9A.B62B34A0-- -- 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 Dec 10 03:07:41 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01270 for ; Tue, 10 Dec 2002 03:07:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Lf8v-000NLL-00 for namedroppers-data@psg.com; Mon, 09 Dec 2002 23:49:25 -0800 Received: from stoneport.math.uic.edu ([131.193.178.160]) by psg.com with smtp (Exim 3.36 #2) id 18Lf8t-000NL9-00 for namedroppers@ops.ietf.org; Mon, 09 Dec 2002 23:49:23 -0800 Received: (qmail 4044 invoked by uid 1016); 10 Dec 2002 07:49:35 -0000 Date: 10 Dec 2002 07:49:35 -0000 Message-ID: <20021210074935.4042.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: draft-ietf-dnsext-axfr-clarify-05.txt References: <200212050024.gB50OQtB002433@drugs.dv.isc.org> <20021205021221.90417379FC6@as.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=1.0 required=5.0 tests=NO_OBLIGATION,REFERENCES,SPAM_PHRASE_03_05 version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Paul Vixie writes: > A zone's identity is what the primary master says it is. Nonsense. For example, I've seen a zone that was set up with * a European server that returns some European addresses and * a United States server that returns some United States addresses in an effort to reduce delays for users. (Of course, as I discussed in a previous message, clients are under no obligation to keep track of this difference.) There is no ``primary master'' for this zone. Your notion of ``zone identity'' is simply confused. As for your comments about the BIND 9-specific model of DNS being ``right'' while everybody else is ``wrong'': Do you seriously believe that this religious nonsense justifies imposing massive redeployment costs upon innocent users? If you want a new protocol, deploy a new protocol; there is absolutely no reason to break compatibility. ---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 Tue Dec 10 03:16:39 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01404 for ; Tue, 10 Dec 2002 03:16:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LfNh-000NlS-00 for namedroppers-data@psg.com; Tue, 10 Dec 2002 00:04:41 -0800 Received: from stoneport.math.uic.edu ([131.193.178.160]) by psg.com with smtp (Exim 3.36 #2) id 18LfNe-000NlG-00 for namedroppers@ops.ietf.org; Tue, 10 Dec 2002 00:04:38 -0800 Received: (qmail 7006 invoked by uid 1016); 10 Dec 2002 08:05:01 -0000 Date: 10 Dec 2002 08:05:01 -0000 Message-ID: <20021210080501.7005.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: rsync vs. axfr-clarify (was: in support of axfr-clarify) References: <4.3.1.2.20021207144447.037bacd0@pop.gis.net> <4.3.1.2.20021209000917.037e3e00@pop.gis.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=-0.8 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Danny Mayer writes: > Isn't this exactly what axfr-clarify is trying to accomplish No. My recommended use of rsync is to replicate complete _servers_. This has a simple meaning: the servers respond identically to every query. What you're trying to do is replicate separate _zones_. This is a much more complicated concept. Contrary to your previous claims, it does _not_ mean that the servers respond identically to every query in the zone; I explained in a previous message why that can't be true. ---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 Tue Dec 10 03:34:27 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01561 for ; Tue, 10 Dec 2002 03:34:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Lfn8-000OGc-00 for namedroppers-data@psg.com; Tue, 10 Dec 2002 00:30:58 -0800 Received: from stoneport.math.uic.edu ([131.193.178.160]) by psg.com with smtp (Exim 3.36 #2) id 18Lfn5-000OGO-00 for namedroppers@ops.ietf.org; Tue, 10 Dec 2002 00:30:55 -0800 Received: (qmail 10801 invoked by uid 1016); 10 Dec 2002 08:31:18 -0000 Date: 10 Dec 2002 08:31:18 -0000 Message-ID: <20021210083118.10800.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Cc: sob@harvard.edu Subject: Re: repeating records References: <20021204204941.81209.qmail@cr.yp.to> <200212042338.gB4NcZtB002203@drugs.dv.isc.org> 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 Okay. Andrews has specifically endorsed the three statements * ``DNS servers SHOULD NOT use LDAP'' and * ``DNS servers SHOULD NOT use EDNS0'' and * ``DNS servers SHOULD NOT use BIND 8's AXFR glue strategy'' because he claims that every DNS server implementor must understand and carefully weigh the implications (specifically, some minor efficiency issues) before doing any of these things. Is this the same Andrews who has been telling everybody to use EDNS0? ``SHOULD NOT use EDNS0,'' but please use it anyway? Does he understand how stupid he's making himself sound here? Andrews tries to defend his silly AXFR position by saying that ``zones are getting MUCH bigger'' and by pointing to DNSSEC. But bigger zones and DNSSEC make BIND 8's AXFR glue strategy even _less_ of an issue! The djbdns/BIND 9 strategy saves space _for repeated delegations_, not for miscellaneous records. In short, Andrews is making the ludicrous demand that every implementor worry about the .com zone. This is a transparent attempt to hold back progress in DNS server software. ---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 Tue Dec 10 05:09:58 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03049 for ; Tue, 10 Dec 2002 05:09:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LhCZ-000Q0B-00 for namedroppers-data@psg.com; Tue, 10 Dec 2002 02:01:19 -0800 Received: from manukeneko.besserwisser.org ([213.212.3.220] helo=slimsixten.besserwisser.org ident=root) by psg.com with esmtp (Exim 3.36 #2) id 18LhCX-000Pzu-00 for namedroppers@ops.ietf.org; Tue, 10 Dec 2002 02:01:17 -0800 Received: from localhost.besserwisser.org (mansaxel@localhost.besserwisser.org [127.0.0.1]) by slimsixten.besserwisser.org (8.12.6/8.12.2) with ESMTP id gBAA16cv008757 for ; Tue, 10 Dec 2002 11:01:06 +0100 (CET) Date: Tue, 10 Dec 2002 11:01:05 +0100 From: =?ISO-8859-1?Q?M=E5ns_Nilsson?= To: namedroppers@ops.ietf.org Subject: Re: rsync vs. axfr-clarify (was: in support of axfr-clarify) Message-ID: <2304390000.1039514465@localhost.besserwisser.org> In-Reply-To: <20021210080501.7005.qmail@cr.yp.to> References: <4.3.1.2.20021207144447.037bacd0@pop.gis.net> <4.3.1.2.20021209000917.037e3e00@pop.gis.net> <20021210080501.7005.qmail@cr.yp.to> X-Mailer: Mulberry/2.2.1 (OpenBSD/x86) X-PGP-KEY: http://vvv.besserwisser.org/key MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========3151530887==========" X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,MIME_LONG_LINE_QP,PGP_SIGNATURE_2, QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_02_03 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --==========3151530887========== Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable --On Tuesday, December 10, 2002 08:05:01 +0000 "D. J. Bernstein" wrote: > My recommended use of rsync is to replicate complete _servers_. This has > a simple meaning: the servers respond identically to every query. A cool concept. And a fringe case at best. I am hard pressed to find this situation in large and/or widespread management domains -- most servers are by intention or legacy somewhat unique. This also is an operational issue.=20 > What you're trying to do is replicate separate _zones_. This is a much > more complicated concept. Contrary to your previous claims, it does > _not_ mean that the servers respond identically to every query in the > zone; I explained in a previous message why that can't be true. So why are you attacking the AXFR concept by proposing something completely different, that does not fill the same need?=20 --=20 M=E5ns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE We're sysadmins. To us, data is a protocol-overhead. --==========3151530887========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (OpenBSD) iD8DBQE99bth02/pMZDM1cURAtnhAJ9IFMFVnlFWyHVJjOM277rzzL+OSQCbBmqi aSIdyE7GsloiKlNVw4FDxLI= =bUHk -----END PGP SIGNATURE----- --==========3151530887==========-- -- 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 Dec 10 05:26:24 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03213 for ; Tue, 10 Dec 2002 05:26:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LhXF-0000Sa-00 for namedroppers-data@psg.com; Tue, 10 Dec 2002 02:22:41 -0800 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.36 #2) id 18LhXC-0000Rz-00 for namedroppers@ops.ietf.org; Tue, 10 Dec 2002 02:22:38 -0800 Received: from x22.ripe.net.ripe.net (x22.ripe.net [193.0.1.22]) by birch.ripe.net (8.12.5/8.11.6) with ESMTP id gBAAM6vQ020024 for ; Tue, 10 Dec 2002 11:22:06 +0100 Date: Tue, 10 Dec 2002 11:22:06 +0100 (CET) From: Bruce Campbell X-X-Sender: bc@x22.ripe.net To: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-axfr-clarify-05.txt In-Reply-To: <20021210074935.4042.qmail@cr.yp.to> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,NO_OBLIGATION, QUOTED_EMAIL_TEXT,SPAM_PHRASE_03_05,USER_AGENT_PINE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On 10 Dec 2002, D. J. Bernstein wrote: > Paul Vixie writes: > > A zone's identity is what the primary master says it is. > > Nonsense. For example, I've seen a zone that was set up with > > * a European server that returns some European addresses and > * a United States server that returns some United States addresses > > in an effort to reduce delays for users. (Of course, as I discussed in a > previous message, clients are under no obligation to keep track of this > difference.) There is no ``primary master'' for this zone. Your notion > of ``zone identity'' is simply confused. Thats simply a different point of view for the clients, thus modifying the statement (to deal with non-orthodox configurations as above) to: ``A zone's identity is what the primary master for that particular view says it is.'' For most zones, there is a single view (global), and thus a single primary master. For other zones, there would be multiple 'primary' masters, quite likely based on network topology. ( Although it seems that implementations of topology-based DNS tricks use something akin to the BIND 'views' facility to have every nameserver for that zone return the 'nearest' results for a given client. Such are outside the general scope of transferring zones ) > As for your comments about the BIND 9-specific model of DNS being > ``right'' while everybody else is ``wrong'': Do you seriously believe > that this religious nonsense justifies imposing massive redeployment > costs upon innocent users? If you want a new protocol, deploy a new > protocol; there is absolutely no reason to break compatibility. Which specific 'massive' deployment costs? After all, someone who works for the BIND Company (as you put it) has explicitly stated that pre and post clarification servers will be able to interoperate, ie: In 200212020313.gB23D9gU034040@drugs.dv.isc.org, Mark Andrews states: : Note there are no *forced* upgrades happening here. The pre-clarify : servers will interoperate with the post-clarify servers. However : the post-clarify servers can be used in configurations where most : of the pre-clarify servers (those that merge data) can't. I daresay that your axfr client (unpatched) will be able to successfully retrieve zones from a post-clarify server, and that a post-clarify client will be able to successfully retrieve zones from your axfr master (patched for returning the appropriate rcode and id). ( I'm taking the above two from http://cr.yp.to/djbdns/axfr-clarify.html, which only gives detailed comments up to revision -02 of the draft ) --==-- 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 Tue Dec 10 09:28:46 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07057 for ; Tue, 10 Dec 2002 09:28:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Ll8B-0005ci-00 for namedroppers-data@psg.com; Tue, 10 Dec 2002 06:13:03 -0800 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.36 #2) id 18Ll87-0005bi-00 for namedroppers@ops.ietf.org; Tue, 10 Dec 2002 06:13:00 -0800 Received: from x22.ripe.net.ripe.net (x22.ripe.net [193.0.1.22]) by birch.ripe.net (8.12.5/8.11.6) with ESMTP id gBAECQvQ028889; Tue, 10 Dec 2002 15:12:26 +0100 Date: Tue, 10 Dec 2002 15:12:26 +0100 (CET) From: Bruce Campbell X-X-Sender: bc@x22.ripe.net To: namedroppers@ops.ietf.org cc: Danny Mayer Subject: Re: rsync vs. axfr-clarify (was: in support of axfr-clarify) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_05_08,USER_AGENT_PINE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, 9 Dec 2002, Bruce Campbell wrote: > This means, since there is no set standard for an actual zone file, that > you can only (reliably) do rsync-over-ssh if you have identical server > software on both servers. Hrm. There is a set standard for zone (MASTER) files in RFC1035 section 5 which I had forgotten about (and keen-eyed Bush immediately noted). The above paragraph thus should read: This means that you can only (reliably) do rsync-over-ssh if you have a common zone file format on both servers (eg the 'MASTER' zone format as per RFC1035 5.1). --==-- 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 Tue Dec 10 16:55:50 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22184 for ; Tue, 10 Dec 2002 16:55:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LrtY-000K4a-00 for namedroppers-data@psg.com; Tue, 10 Dec 2002 13:26:24 -0800 Received: from stoneport.math.uic.edu ([131.193.178.160]) by psg.com with smtp (Exim 3.36 #2) id 18LrtV-000K4M-00 for namedroppers@ops.ietf.org; Tue, 10 Dec 2002 13:26:21 -0800 Received: (qmail 2422 invoked by uid 1016); 10 Dec 2002 21:26:40 -0000 Date: 10 Dec 2002 21:26:40 -0000 Message-ID: <20021210212640.2421.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: rsync vs. axfr-clarify (was: in support of axfr-clarify) References: <4.3.1.2.20021207144447.037bacd0@pop.gis.net> <4.3.1.2.20021209000917.037e3e00@pop.gis.net> <20021210080501.7005.qmail@cr.yp.to> <2304390000.1039514465@localhost.besserwisser.org> 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 > > My recommended use of rsync is to replicate complete _servers_. This has > > a simple meaning: the servers respond identically to every query. > A cool concept. And a fringe case at best. In fact, even though BIND makes it unnecessarily difficult to set up, this is an extremely popular configuration. AXFR today has two main uses: (1) as a clumsy mechanism of replicating servers and (2) as a clumsy mechanism of editing zone files remotely. Except at companies that sell third-party DNS service, there's very little demand for any type of replication other than server replication. Yes, we can all point to examples such as arpa-vs.-root-servers.net, but those examples are the fringe case. ---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 Tue Dec 10 17:20:17 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22961 for ; Tue, 10 Dec 2002 17:20:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LsLJ-000LUi-00 for namedroppers-data@psg.com; Tue, 10 Dec 2002 13:55:05 -0800 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.36 #2) id 18LsLE-000LTz-00 for namedroppers@ops.ietf.org; Tue, 10 Dec 2002 13:55:01 -0800 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.5/8.12.5) with ESMTP id gBALsitB045122; Wed, 11 Dec 2002 08:54:44 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200212102154.gBALsitB045122@drugs.dv.isc.org> To: "D. J. Bernstein" Cc: namedroppers@ops.ietf.org, sob@harvard.edu From: Mark.Andrews@isc.org Subject: Re: repeating records In-reply-to: Your message of "10 Dec 2002 08:31:18 -0000." <20021210083118.10800.qmail@cr.yp.to> Date: Wed, 11 Dec 2002 08:54:44 +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 > Okay. Andrews has specifically endorsed the three statements > > * ``DNS servers SHOULD NOT use LDAP'' and I didn't say that. And it cannot be paraphrased as that. > * ``DNS servers SHOULD NOT use EDNS0'' and I didn't say that. And it cannot be paraphrased as that. > * ``DNS servers SHOULD NOT use BIND 8's AXFR glue strategy'' Yes. That is what ixfr-clarify says. > because he claims that every DNS server implementor must understand and > carefully weigh the implications (specifically, some minor efficiency > issues) before doing any of these things. > > Is this the same Andrews who has been telling everybody to use EDNS0? > ``SHOULD NOT use EDNS0,'' but please use it anyway? Does he understand > how stupid he's making himself sound here? Go read what I said again. > Andrews tries to defend his silly AXFR position by saying that ``zones > are getting MUCH bigger'' and by pointing to DNSSEC. But bigger zones > and DNSSEC make BIND 8's AXFR glue strategy even _less_ of an issue! The > djbdns/BIND 9 strategy saves space _for repeated delegations_, not for > miscellaneous records. > > In short, Andrews is making the ludicrous demand that every implementor > worry about the .com zone. This is a transparent attempt to hold back > progress in DNS server software. Do you realise how stupid you sound with these ridiculous assertions. Implementors should always be looking at the their clients needs. If you don't want to serve big zones then don't deal with their needs. Nothing in axfr-clarify stops you sending a record multiple times. No one is forcing you to only send one record. The only constraint is that the SOA record is sent exactly twice. Once as the first record. Once as the last record. Mark > ---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: -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Dec 10 18:22:13 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24683 for ; Tue, 10 Dec 2002 18:22:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Ltbk-000PIT-00 for namedroppers-data@psg.com; Tue, 10 Dec 2002 15:16:08 -0800 Received: from stoneport.math.uic.edu ([131.193.178.160]) by psg.com with smtp (Exim 3.36 #2) id 18Ltbh-000PIF-00 for namedroppers@ops.ietf.org; Tue, 10 Dec 2002 15:16:05 -0800 Received: (qmail 34121 invoked by uid 1016); 10 Dec 2002 23:16:25 -0000 Date: 10 Dec 2002 23:16:25 -0000 Message-ID: <20021210231625.34120.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: rsync vs. axfr-clarify (was: in support of axfr-clarify) References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=-0.8 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk When normal people replicate servers, they use the same software everywhere. For example, a normal person setting up replicated HTTP service uses the same HTTP software on both computers. Similarly, a normal person setting up replicated DNS service uses the same DNS software on both computers. There are certainly advantages to simple, stable configuration-file formats that can be read by many programs, but these advantages are practically irrelevant to server replication, and they're often outweighed by the benefits of better formats. Bruce Campbell writes: > There is a set standard for zone (MASTER) files in RFC1035 section 5 Sorry to bother you with the facts, but the BIND company keeps changing their zone-file format. You're kidding yourself if you think that the format is stable. Furthermore, zone files are only part of the BIND configuration; the named.conf format is even less stable. ---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 Tue Dec 10 18:32:00 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24820 for ; Tue, 10 Dec 2002 18:32:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LtlK-000PmI-00 for namedroppers-data@psg.com; Tue, 10 Dec 2002 15:26:02 -0800 Received: from pacific-carrier-annex.mit.edu ([18.7.21.83]) by psg.com with esmtp (Exim 3.36 #2) id 18LtlG-000PkZ-00 for namedroppers@ops.ietf.org; Tue, 10 Dec 2002 15:25:58 -0800 Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id SAA25083; Tue, 10 Dec 2002 18:25:56 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id SAA11899; Tue, 10 Dec 2002 18:25:55 -0500 (EST) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id SAA27556; Tue, 10 Dec 2002 18:25:54 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id SAA08046; Tue, 10 Dec 2002 18:25:54 -0500 (EST) To: "D. J. Bernstein" From: Derek Atkins Cc: namedroppers@ops.ietf.org Subject: Re: rsync vs. axfr-clarify (was: in support of axfr-clarify) References: <4.3.1.2.20021207144447.037bacd0@pop.gis.net> <4.3.1.2.20021209000917.037e3e00@pop.gis.net> <20021210080501.7005.qmail@cr.yp.to> <2304390000.1039514465@localhost.besserwisser.org> <20021210212640.2421.qmail@cr.yp.to> Date: 10 Dec 2002 18:25:54 -0500 In-Reply-To: <20021210212640.2421.qmail@cr.yp.to> Message-ID: Lines: 66 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 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,RCVD_IN_RELAYS_ORDB_ORG,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_03_05, TO_BE_REMOVED_REPLY,USER_AGENT,USER_AGENT_GNUS_UA, X_OSIRU_OPEN_RELAY version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Dan, Now I KNOW you're on crack. EVERY single DNS server that I've set up has used AXFR to do zone syncs. The reason: each server hosts a different set of zones. My primary and secondary servers are not mirrors of each other. They are not administrated by the same set of people. Indeed, the BCP REQUIRES that DNS servers be network-distributed to protect against single-point-of-failures. Setting up axfr is simple. I list my secondaries, and they just say "master ". There. Done. End of configuration. How could setting up a secondary be any easier than that? I would say that there is a LOT of demand for AXFR. Everyone out there than runs their own domain and actually follows the BCP needs AXFR. I'm certainly not willing to give my secondaries remote-access (even for rsync) to my server. Nor do I think the primaries for the zones for which I secondary would give me similar access. Dan, it's been a long time since our PGP V. X.509 discussions on the bus from Morristown to Picataway (I presume you still remember that conversation? I certainly do!). What I learned from that is the notion that there are necessarily multiple ways of doing something and not everyone agrees on the "right way". So you need to come up with some basic, minimal, in-band means to do what you want to do, and if people want to do something different, out of band, you need to allow them to do so. In this case, you need to standardize the AXFR (the simple in-band solution) but allow people to use the out-of-band (rsync) method if they so choose. However, since it is out-of-band, that implies it is out-of-scope and therefore should be taken elsewhere. Have a nice day, -derek "D. J. Bernstein" writes: > > > My recommended use of rsync is to replicate complete _servers_. This has > > > a simple meaning: the servers respond identically to every query. > > A cool concept. And a fringe case at best. > > In fact, even though BIND makes it unnecessarily difficult to set up, > this is an extremely popular configuration. AXFR today has two main uses: > > (1) as a clumsy mechanism of replicating servers and > (2) as a clumsy mechanism of editing zone files remotely. > > Except at companies that sell third-party DNS service, there's very > little demand for any type of replication other than server replication. > Yes, we can all point to examples such as arpa-vs.-root-servers.net, but > those examples are the fringe case. > > ---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: -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.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 Tue Dec 10 19:03:48 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25488 for ; Tue, 10 Dec 2002 19:03:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LuFA-0001Jr-00 for namedroppers-data@psg.com; Tue, 10 Dec 2002 15:56:52 -0800 Received: from stoneport.math.uic.edu ([131.193.178.160]) by psg.com with smtp (Exim 3.36 #2) id 18LuF6-0001Jf-00 for namedroppers@ops.ietf.org; Tue, 10 Dec 2002 15:56:48 -0800 Received: (qmail 50720 invoked by uid 1016); 10 Dec 2002 23:57:11 -0000 Date: 10 Dec 2002 23:57:11 -0000 Message-ID: <20021210235711.50719.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Cc: sob@harvard.edu Subject: Re: repeating records References: <20021210083118.10800.qmail@cr.yp.to> <200212102154.gBALsitB045122@drugs.dv.isc.org> 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 Andrews claims that every DNS implementor _must_ understand and carefully weigh the implications---specifically, a minor traffic increase for some zones---before using BIND 8's AXFR glue strategy. (``DNS servers SHOULD NOT use BIND 8's AXFR glue strategy.'') The following analogies show how silly Andrews's argument is: * ``DNS servers SHOULD NOT use BIND 8's AXFR glue strategy'' because another strategy sometimes generates less traffic. * ``DNS servers SHOULD NOT use EDNS0'' because the opposite choice usually generates less traffic. * ``DNS servers SHOULD NOT use AXFR'' because rsync practically always generates less traffic. * ``DNS servers SHOULD use bzip2-compressed zone transfers instead of gzip-compressed zone transfers'' because bzip2 usually generates less traffic than gzip. * ``DNS servers SHOULD use gzip-compressed zone transfers instead of bzip2-compressed zone transfers'' because gzip usually takes less CPU time than bzip2. * ``DNS servers SHOULD NOT serve records from an LDAP database'' because LDAP can be slow. I could go on like this for a while. Is there anyone other than Andrews who still doesn't understand why this is a misuse of ``SHOULD NOT''? In a previous message, I specifically asked Andrews about some of these examples: Do you also conclude that ... every DNS implementor _must_ understand and carefully weigh the implications before attempting to use EDNS0? (``DNS servers SHOULD NOT use EDNS0.'') His answer: ``Yes. The choice involved in EDNS are important.'' That's a clear, direct, specific endorsement of ``DNS servers SHOULD NOT use EDNS0''---but Andrews now claims that he never said that! Flip, flop, flip, flop. ---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 Tue Dec 10 20:05:04 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26525 for ; Tue, 10 Dec 2002 20:05:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LvDI-0004Ju-00 for namedroppers-data@psg.com; Tue, 10 Dec 2002 16:59:00 -0800 Received: from stoneport.math.uic.edu ([131.193.178.160]) by psg.com with smtp (Exim 3.36 #2) id 18LvDD-0004JI-00 for namedroppers@ops.ietf.org; Tue, 10 Dec 2002 16:58:55 -0800 Received: (qmail 69692 invoked by uid 1016); 11 Dec 2002 00:59:14 -0000 Date: 11 Dec 2002 00:59:14 -0000 Message-ID: <20021211005914.69691.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: rsync vs. axfr-clarify (was: in support of axfr-clarify) References: <4.3.1.2.20021207144447.037bacd0@pop.gis.net> <4.3.1.2.20021209000917.037e3e00@pop.gis.net> <20021210080501.7005.qmail@cr.yp.to> <2304390000.1039514465@localhost.besserwisser.org> <20021210212640.2421.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=-0.8 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Derek Atkins writes: > Setting up axfr is simple. I list my secondaries, and they just say > "master ". There. Done. End of configuration. How > could setting up a secondary be any easier than that? What do you do when you change named.conf---for example, to add a zone? You have to copy the changes to the secondary. With server replication, this is handled automatically. > each server hosts a different set of zones. My primary and secondary > servers are not mirrors of each other. They are not administrated by > the same set of people. That configuration is much less popular than you appear to realize. See http://cr.yp.to/djbdns/third-party.html for further comments. > out-of-band (rsync) Your notion of ``out-of-band'' is religious nonsense. Does it frighten you that the FTP protocol uses more than one port? ---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 Tue Dec 10 20:31:12 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27279 for ; Tue, 10 Dec 2002 20:31:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Lvci-0005f1-00 for namedroppers-data@psg.com; Tue, 10 Dec 2002 17:25:16 -0800 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.36 #2) id 18Lvce-0005eA-00 for namedroppers@ops.ietf.org; Tue, 10 Dec 2002 17:25:13 -0800 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.5/8.12.5) with ESMTP id gBB1OttB046451; Wed, 11 Dec 2002 12:24:55 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200212110124.gBB1OttB046451@drugs.dv.isc.org> To: "D. J. Bernstein" Cc: namedroppers@ops.ietf.org, sob@harvard.edu From: Mark.Andrews@isc.org Subject: Re: repeating records In-reply-to: Your message of "10 Dec 2002 23:57:11 -0000." <20021210235711.50719.qmail@cr.yp.to> Date: Wed, 11 Dec 2002 12:24:55 +1100 X-Spam-Status: No, hits=0.5 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Andrews claims that every DNS implementor _must_ understand and > carefully weigh the implications---specifically, a minor traffic > increase for some zones---before using BIND 8's AXFR glue strategy. > (``DNS servers SHOULD NOT use BIND 8's AXFR glue strategy.'') This is perfect example of why the section is there. There you go again, not analysing the requirements. You are assuming that there is always a *minor traffic increase*. You as a implementor are not in a position to say if a given increase in traffic is minor or not as you do not have enough details of the conditions underwhich the transmission is taking place. 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 Tue Dec 10 20:42:22 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27460 for ; Tue, 10 Dec 2002 20:42:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Lvpf-0006OO-00 for namedroppers-data@psg.com; Tue, 10 Dec 2002 17:38:39 -0800 Received: from pacific-carrier-annex.mit.edu ([18.7.21.83]) by psg.com with esmtp (Exim 3.36 #2) id 18Lvpc-0006O8-00 for namedroppers@ops.ietf.org; Tue, 10 Dec 2002 17:38:36 -0800 Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id UAA10693; Tue, 10 Dec 2002 20:38:35 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id UAA22856; Tue, 10 Dec 2002 20:38:34 -0500 (EST) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id UAA23786; Tue, 10 Dec 2002 20:38:34 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id UAA08299; Tue, 10 Dec 2002 20:38:34 -0500 (EST) To: "D. J. Bernstein" From: Derek Atkins Cc: namedroppers@ops.ietf.org Subject: Re: rsync vs. axfr-clarify (was: in support of axfr-clarify) References: <4.3.1.2.20021207144447.037bacd0@pop.gis.net> <4.3.1.2.20021209000917.037e3e00@pop.gis.net> <20021210080501.7005.qmail@cr.yp.to> <2304390000.1039514465@localhost.besserwisser.org> <20021210212640.2421.qmail@cr.yp.to> <20021211005914.69691.qmail@cr.yp.to> Date: 10 Dec 2002 20:38:34 -0500 In-Reply-To: <20021211005914.69691.qmail@cr.yp.to> Message-ID: Lines: 58 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-1.0 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,RCVD_IN_RELAYS_ORDB_ORG,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_02_03,USER_AGENT, USER_AGENT_GNUS_UA,X_OSIRU_OPEN_RELAY version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk "D. J. Bernstein" writes: > Derek Atkins writes: > > Setting up axfr is simple. I list my secondaries, and they just say > > "master ". There. Done. End of configuration. How > > could setting up a secondary be any easier than that? > > What do you do when you change named.conf---for example, to add a zone? > You have to copy the changes to the secondary. With server replication, > this is handled automatically. If I am the primary, I email it to the maintainer of the secondardies and say "add this section to named.conf". If I'm the secondary, then the admin of the primary usually contacts me with similar information. The configuration of the zones themselves are nearly static; changing the IP addresses of primary and secondary servers is rare -- certainly much more rare than changing the zone data. The point is that each DNS server is autonomous. There is no requirement that NS1.FOO.EXAMPLE. and NS5.BAR.EXAMPLE., which both happen to be authoritative for the QUUX.EXAMPLE zone, be mirrors of each other. > Your notion of ``out-of-band'' is religious nonsense. Does it frighten > you that the FTP protocol uses more than one port? Religious nonsense, eh? Dan, are you trying to be intentionally belligerent or are you just unaware of how your tone comes across in email? I don't recall you being this quick to judge, nor do I remember you trying to be mean or hostile, but then again I was much younger then. If your tone is accidental, may I suggest you "tone down" your messages in the future? Personally, I'm trying to have a peaceful conversation here, and honestly I'm not sure how to interpret your message. Regardless, I do have to wonder how is it nonsense to call "use protocol Y to communicate data for protocol X" out-of-band, when protocol-X has its own way of communicating that very same data? As for FTP, does it frighten me in what way? The FTP spec clearly has the PORT command documented. It is part of the FTP protocol specification. I think it was a poor design choice, but then again I wasn't there at the time it was created (and besides, that was not the question). No, the FTP PORT callback channel is not "out of band", because it is just a second connection that remains part of the ftp protocol. No, out of band is when some protocol says to "run this _OTHER_ protocol to copy data from A to B". Note that in this case (for DNS zone files) I can use email, ssh, ftp, http, or even the US Postal Service and OCR to transmit zone data. Indeed, there are LOTS of "out-of-band" means to transfer the data. There are, however, two "in-band" methods defined by the DNS specification, called AXFR and IXFR. Let's not confuse apples with kumquats here. :-) -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.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 Tue Dec 10 21:17:47 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28182 for ; Tue, 10 Dec 2002 21:17:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LwHw-0007u0-00 for namedroppers-data@psg.com; Tue, 10 Dec 2002 18:07:52 -0800 Received: from stoneport.math.uic.edu ([131.193.178.160]) by psg.com with smtp (Exim 3.36 #2) id 18LwHt-0007to-00 for namedroppers@ops.ietf.org; Tue, 10 Dec 2002 18:07:49 -0800 Received: (qmail 85148 invoked by uid 1016); 11 Dec 2002 02:08:09 -0000 Date: 11 Dec 2002 02:08:09 -0000 Message-ID: <20021211020809.85147.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: rsync vs. axfr-clarify (was: in support of axfr-clarify) References: <4.3.1.2.20021207144447.037bacd0@pop.gis.net> <4.3.1.2.20021209000917.037e3e00@pop.gis.net> <20021210080501.7005.qmail@cr.yp.to> <2304390000.1039514465@localhost.besserwisser.org> <20021210212640.2421.qmail@cr.yp.to> <20021211005914.69691.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 Derek Atkins writes: > Religious nonsense, eh? Yes. Instead of rationally evaluating the costs and benefits of two different protocol extension mechanisms, you declare that one mechanism (new query types) is ``part of the protocol,'' while the other one (new ports) is ``out of band'' and therefore not subject to discussion here. That's religious nonsense. > The point is that each DNS server is autonomous. There is no > requirement that NS1.FOO.EXAMPLE. and NS5.BAR.EXAMPLE., which both > happen to be authoritative for the QUUX.EXAMPLE zone, be mirrors of > each other. I didn't say that server replication was required. I said that it's popular. ---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 Tue Dec 10 21:26:27 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28384 for ; Tue, 10 Dec 2002 21:26:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LwWc-0008eQ-00 for namedroppers-data@psg.com; Tue, 10 Dec 2002 18:23:02 -0800 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.36 #2) id 18LwWa-0008d7-00 for namedroppers@ops.ietf.org; Tue, 10 Dec 2002 18:23:00 -0800 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id VAA00361; Tue, 10 Dec 2002 21:22:58 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id VAA25599; Tue, 10 Dec 2002 21:22:58 -0500 (EST) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id VAA06954; Tue, 10 Dec 2002 21:22:57 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id VAA08372; Tue, 10 Dec 2002 21:22:57 -0500 (EST) To: "D. J. Bernstein" From: Derek Atkins Cc: namedroppers@ops.ietf.org Subject: Re: rsync vs. axfr-clarify (was: in support of axfr-clarify) References: <4.3.1.2.20021207144447.037bacd0@pop.gis.net> <4.3.1.2.20021209000917.037e3e00@pop.gis.net> <20021210080501.7005.qmail@cr.yp.to> <2304390000.1039514465@localhost.besserwisser.org> <20021210212640.2421.qmail@cr.yp.to> <20021211005914.69691.qmail@cr.yp.to> <20021211020809.85147.qmail@cr.yp.to> Date: 10 Dec 2002 21:22:56 -0500 In-Reply-To: <20021211020809.85147.qmail@cr.yp.to> Message-ID: Lines: 34 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-4.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_RELAYS_ORDB_ORG,REFERENCES,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_01_02,USER_AGENT,USER_AGENT_GNUS_UA version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk "D. J. Bernstein" writes: > Derek Atkins writes: > > Religious nonsense, eh? > > Yes. Instead of rationally evaluating the costs and benefits of two > different protocol extension mechanisms, you declare that one mechanism > (new query types) is ``part of the protocol,'' while the other one (new > ports) is ``out of band'' and therefore not subject to discussion here. Could you answer me how AXFR can be considered a "new query type" or even a "protcol extension"? It seems to be defined as far back as RFC-883, which, if memory serves, is the original DNS definition.... Therefore, it would seem to imply that it is a core DNS element, having been there from the beginning. If people have found problems with the AXFR then that would certainly be within scope of this list. > That's religious nonsense. Well, I'm very sorry you feel that way. This _IS_ the namedroppers list after all, for discussion of the DNS protocol (of which AXFR is clearly part). I am certainly open to the concept of using alternate methods (outside the DNS protocol) to transmit DNS information, but it is quite frankly out of scope for the DNS protocol discussion list. Such discussion _may_ be appropriate for a DNS operations mailing list, but last I checked this was not such a list. -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.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 Tue Dec 10 22:52:27 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00537 for ; Tue, 10 Dec 2002 22:52:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Lxnu-000Cwj-00 for namedroppers-data@psg.com; Tue, 10 Dec 2002 19:44:58 -0800 Received: from stoneport.math.uic.edu ([131.193.178.160]) by psg.com with smtp (Exim 3.36 #2) id 18Lxns-000CwP-00 for namedroppers@ops.ietf.org; Tue, 10 Dec 2002 19:44:56 -0800 Received: (qmail 12034 invoked by uid 1016); 11 Dec 2002 03:45:18 -0000 Date: 11 Dec 2002 03:45:18 -0000 Message-ID: <20021211034518.12033.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: rsync vs. axfr-clarify (was: in support of axfr-clarify) References: <4.3.1.2.20021207144447.037bacd0@pop.gis.net> <4.3.1.2.20021209000917.037e3e00@pop.gis.net> <20021210080501.7005.qmail@cr.yp.to> <2304390000.1039514465@localhost.besserwisser.org> <20021210212640.2421.qmail@cr.yp.to> <20021211005914.69691.qmail@cr.yp.to> <20021211020809.85147.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 Derek Atkins writes: > Could you answer me how AXFR can be considered a "new query type" or > even a "protcol extension"? You said ``AXFR and IXFR.'' If you're going to start drawing some religious line between protocol options defined many years ago and protocol options defined more recently, you'll have to put IXFR on the same side of the line as rsync. > I am certainly open to the concept of using alternate methods > (outside the DNS protocol) to transmit DNS information, but it is > quite frankly out of scope for the DNS protocol discussion list. What exactly do you mean by ``the DNS protocol''? Please try to avoid knee-jerk religious answers. For example, if you define ``the DNS protocol'' as ``whatever runs on port 53,'' then you're making the absurd claim that it's ``out of scope'' to discuss Larson's proposal to put DNSSEC on another port. ---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 Tue Dec 10 23:50:25 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01525 for ; Tue, 10 Dec 2002 23:50:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Lyju-000Fz1-00 for namedroppers-data@psg.com; Tue, 10 Dec 2002 20:44:54 -0800 Received: from pacific-carrier-annex.mit.edu ([18.7.21.83]) by psg.com with esmtp (Exim 3.36 #2) id 18Lyjs-000Fym-00 for namedroppers@ops.ietf.org; Tue, 10 Dec 2002 20:44:52 -0800 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id XAA09654; Tue, 10 Dec 2002 23:44:50 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id XAA06474; Tue, 10 Dec 2002 23:44:50 -0500 (EST) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id XAA26753; Tue, 10 Dec 2002 23:44:49 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id XAA08605; Tue, 10 Dec 2002 23:44:49 -0500 (EST) To: "D. J. Bernstein" From: Derek Atkins Cc: namedroppers@ops.ietf.org Subject: Re: rsync vs. axfr-clarify (was: in support of axfr-clarify) References: <4.3.1.2.20021207144447.037bacd0@pop.gis.net> <4.3.1.2.20021209000917.037e3e00@pop.gis.net> <20021210080501.7005.qmail@cr.yp.to> <2304390000.1039514465@localhost.besserwisser.org> <20021210212640.2421.qmail@cr.yp.to> <20021211005914.69691.qmail@cr.yp.to> <20021211020809.85147.qmail@cr.yp.to> <20021211034518.12033.qmail@cr.yp.to> Date: 10 Dec 2002 23:44:49 -0500 In-Reply-To: <20021211034518.12033.qmail@cr.yp.to> Message-ID: Lines: 21 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-1.0 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,RCVD_IN_RELAYS_ORDB_ORG,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_GNUS_UA,X_OSIRU_OPEN_RELAY version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk "D. J. Bernstein" writes: > Derek Atkins writes: > > Could you answer me how AXFR can be considered a "new query type" or > > even a "protcol extension"? > > You said ``AXFR and IXFR.'' If you're going to start drawing some > religious line between protocol options defined many years ago and > protocol options defined more recently, you'll have to put IXFR on the > same side of the line as rsync. No, because IXFR works within the DNS framework and rsync does not. It's sort of like comparing DNSSec and PGP. They are completely separate ideas, even if they can solve the same sorts of problems. -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.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 Wed Dec 11 00:25:15 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02228 for ; Wed, 11 Dec 2002 00:25:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LzEo-000Hkm-00 for namedroppers-data@psg.com; Tue, 10 Dec 2002 21:16:50 -0800 Received: from stoneport.math.uic.edu ([131.193.178.160]) by psg.com with smtp (Exim 3.36 #2) id 18LzEk-000HkV-00 for namedroppers@ops.ietf.org; Tue, 10 Dec 2002 21:16:46 -0800 Received: (qmail 28118 invoked by uid 1016); 11 Dec 2002 05:17:09 -0000 Date: 11 Dec 2002 05:17:09 -0000 Message-ID: <20021211051709.28117.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: rsync vs. axfr-clarify (was: in support of axfr-clarify) References: <20021210080501.7005.qmail@cr.yp.to> <2304390000.1039514465@localhost.besserwisser.org> <20021210212640.2421.qmail@cr.yp.to> <20021211005914.69691.qmail@cr.yp.to> <20021211020809.85147.qmail@cr.yp.to> <20021211034518.12033.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 Derek Atkins writes: > IXFR works within the DNS framework and rsync does not. More religious nonsense. You still haven't defined ``the DNS protocol''; if I ask you to define ``the DNS framework,'' are you going to dodge that too, and start babbling about ``the DNS approach''? > It's sort of like comparing DNSSec and PGP. They are completely > separate ideas, even if they can solve the same sorts of problems. In fact, there would be quite a few advantages to using PGP signatures inside DNS: software is already widely available for key generation, signature generation, and signature verification. Are your religious views blinding you to this possibility? ---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 Dec 11 04:33:26 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29608 for ; Wed, 11 Dec 2002 04:33:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18M32e-0002no-00 for namedroppers-data@psg.com; Wed, 11 Dec 2002 01:20:32 -0800 Received: from manukeneko.besserwisser.org ([213.212.3.220] helo=slimsixten.besserwisser.org ident=root) by psg.com with esmtp (Exim 3.36 #2) id 18M32c-0002nb-00 for namedroppers@ops.ietf.org; Wed, 11 Dec 2002 01:20:30 -0800 Received: from localhost.besserwisser.org (mansaxel@localhost.besserwisser.org [127.0.0.1]) by slimsixten.besserwisser.org (8.12.6/8.12.2) with ESMTP id gBB9KHX3001276 for ; Wed, 11 Dec 2002 10:20:17 +0100 (CET) Date: Wed, 11 Dec 2002 10:20:16 +0100 From: =?ISO-8859-1?Q?M=E5ns_Nilsson?= To: namedroppers@ops.ietf.org Subject: Re: rsync vs. axfr-clarify (was: in support of axfr-clarify) Message-ID: <173390000.1039598416@localhost.besserwisser.org> X-Mailer: Mulberry/2.2.1 (OpenBSD/x86) X-PGP-KEY: http://vvv.besserwisser.org/key MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========1888156916==========" X-Spam-Status: No, hits=-0.7 required=5.0 tests=MIME_LONG_LINE_QP,PGP_SIGNATURE_2,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --==========1888156916========== Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable --On Tuesday, December 10, 2002 21:26:40 +0000 "D. J. Bernstein" wrote: >> > My recommended use of rsync is to replicate complete _servers_. This >> > has a simple meaning: the servers respond identically to every query. >> A cool concept. And a fringe case at best. >=20 > In fact, even though BIND makes it unnecessarily difficult to set up, > this is an extremely popular configuration. AXFR today has two main uses: >=20 > (1) as a clumsy mechanism of replicating servers and > (2) as a clumsy mechanism of editing zone files remotely. (3) Debugging of horribly b0rken setups.=20 > Except at companies that sell third-party DNS service, there's very > little demand for any type of replication other than server replication. > Yes, we can all point to examples such as arpa-vs.-root-servers.net, but > those examples are the fringe case. This could just turn into another proportions debate, so I'll try not to. But, my experience is that cloned servers are rare, but do exist. They typically are multimasters; ie there is a parallel zone/config file generator that simultaneously builds a config outside of the DNS protocol.=20 Thus, I argue, this is not namedroppers matter, and somebody should shut me up.=20 --=20 M=E5ns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE We're sysadmins. To us, data is a protocol-overhead. --==========1888156916========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (OpenBSD) iD8DBQE99wNR02/pMZDM1cURArX/AJ4/Zc/rVGsa3PRiF20T7azyNCVt1gCcDCSQ PxpKPysVLDOPxDNa7n8NuOQ= =6xYW -----END PGP SIGNATURE----- --==========1888156916==========-- -- 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 Dec 11 04:44:07 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29723 for ; Wed, 11 Dec 2002 04:44:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18M3Fk-00033X-00 for namedroppers-data@psg.com; Wed, 11 Dec 2002 01:34:04 -0800 Received: from manukeneko.besserwisser.org ([213.212.3.220] helo=slimsixten.besserwisser.org ident=root) by psg.com with esmtp (Exim 3.36 #2) id 18M3Fg-00033E-00 for namedroppers@ops.ietf.org; Wed, 11 Dec 2002 01:34:01 -0800 Received: from localhost.besserwisser.org (mansaxel@localhost.besserwisser.org [127.0.0.1]) by slimsixten.besserwisser.org (8.12.6/8.12.2) with ESMTP id gBB9XnX3024064; Wed, 11 Dec 2002 10:33:49 +0100 (CET) Date: Wed, 11 Dec 2002 10:33:49 +0100 From: =?ISO-8859-1?Q?M=E5ns_Nilsson?= To: "D. J. Bernstein" , namedroppers@ops.ietf.org Subject: Re: rsync vs. axfr-clarify (was: in support of axfr-clarify) Message-ID: <182350000.1039599229@localhost.besserwisser.org> In-Reply-To: <20021211051709.28117.qmail@cr.yp.to> References: <20021210080501.7005.qmail@cr.yp.to> <2304390000.1039514465@localhost.besserwisser.org> <20021210212640.2421.qmail@cr.yp.to> <20021211005914.69691.qmail@cr.yp.to> <20021211020809.85147.qmail@cr.yp.to> <20021211034518.12033.qmail@cr.yp.to> <20021211051709.28117.qmail@cr.yp.to> X-Mailer: Mulberry/2.2.1 (OpenBSD/x86) X-PGP-KEY: http://vvv.besserwisser.org/key MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========2140277794==========" X-Spam-Status: No, hits=-2.0 required=5.0 tests=IN_REP_TO,PGP_SIGNATURE_2,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_02_03 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --==========2140277794========== Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable --On Wednesday, December 11, 2002 05:17:09 +0000 "D. J. Bernstein" wrote: > More religious nonsense. You still haven't defined ``the DNS protocol''; > if I ask you to define ``the DNS framework,'' are you going to dodge > that too, and start babbling about ``the DNS approach''? Please, Dan.=20 The point we (at least I am) are trying to make is that "Hey, it is fine to use whatever [server|zone] replication mechanism, but we believe that only AXFR and other methods that use DNS messages like IXFR are on-topic for this forum." It is not a judgement -- I for one am using ftp for one of the zones I slave -- but more of a stay-on-topic requirement.=20 The dnsop wg has a mailing list, which probably is the better IETF forum for this, but I do believe that the topic of "how to replicate DNS data out of band" is best at home in a systems administration forum, of which there are a multitude.=20 IF you believe that AXFR is so broken that it needs to be replaced with something completely different, then find out a method, write a draft and make it so good that we all see that this is the future. THAT would be on-topic.=20 Regards,=20 --=20 M=E5ns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE We're sysadmins. To us, data is a protocol-overhead. --==========2140277794========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (OpenBSD) iD8DBQE99wZ902/pMZDM1cURAm3eAKCWS3ZkThEv9QHT/6mNCtBDb44/ugCeNLJv 7/ls/IeG94XLt1TGwoH/1OA= =d/qA -----END PGP SIGNATURE----- --==========2140277794==========-- -- 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 Dec 11 11:49:44 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12245 for ; Wed, 11 Dec 2002 11:49:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18M9pz-000Gcl-00 for namedroppers-data@psg.com; Wed, 11 Dec 2002 08:35:55 -0800 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.36 #2) id 18M9pt-000GcP-00 for namedroppers@ops.ietf.org; Wed, 11 Dec 2002 08:35:50 -0800 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id LAA16440 for ; Wed, 11 Dec 2002 11:35:47 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id LAA05865 for ; Wed, 11 Dec 2002 11:33:45 -0500 (EST) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id LAA18530 for ; Wed, 11 Dec 2002 11:33:45 -0500 (EST) Received: (from ghudson@localhost) by error-messages.mit.edu (8.9.3) id LAA09103; Wed, 11 Dec 2002 11:33:42 -0500 Date: Wed, 11 Dec 2002 11:33:42 -0500 Message-Id: <200212111633.LAA09103@error-messages.mit.edu> From: Greg Hudson To: namedroppers@ops.ietf.org In-reply-to: <20021210235711.50719.qmail@cr.yp.to> Subject: Re: repeating records X-Spam-Status: No, hits=2.9 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM, RCVD_IN_RELAYS_ORDB_ORG,SPAM_PHRASE_00_01, X_OSIRU_OPEN_RELAY version=2.43 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Ideally, an RFC uses SHOULD when the working group feels that an analysis of a tradeoff should generally go in one direction, but that an implementor could reasonably choose the other direction after thinking about it carefully. Dan Bernstein wrote: > * ``DNS servers SHOULD NOT use BIND 8's AXFR glue strategy'' because > another strategy sometimes generates less traffic. The tradeoff here is between code simplicity and traffic savings. Since you believe that code simplicity is important and that the traffic savings never reach the level of significance, you side with simplicity. That's fine, but if working group consensus is against you on that point (which is not my call), then the use of SHOULD NOT is still appropriate. If you said that IETF RFCs tended to erroneously choose complex algorithms over simple ones for minor benefit, I might agree. But instead, you've attempted a bizarre reductio ad absurdum. Dan Bernstein wrote: > * ``DNS servers SHOULD NOT use EDNS0'' because the opposite choice > usually generates less traffic. The tradeoff here is between extended functionality and traffic savings. So it's not a very good analogy. > * ``DNS servers SHOULD NOT use AXFR'' because rsync practically > always generates less traffic. But rsync accomplishes different goals, as you've pointed out--server replication versus zone replication. (If, as you assert, zone replication is not commonly desired, then perhaps AXFR should bite the dust, but I think the working group remains unconvinced on that point.) Certainly, people should generally use the software which most closely matches their needs. In the situation where zone replication is desired--and particularly when software independence is required--the tradeoff here is between a better functionality match and traffic savings. Still not a very good analogy. > * ``DNS servers SHOULD use bzip2-compressed zone transfers instead of > gzip-compressed zone transfers'' because bzip2 usually generates > less traffic than gzip. > * ``DNS servers SHOULD use gzip-compressed zone transfers instead of > bzip2-compressed zone transfers'' because gzip usually takes less > CPU time than bzip2. Either of these statements might be reasonable for an RFC to make--if the working group genuinely felt one way or another about the bandwidth vs. time tradeoff, which seems unlikely--but obviously not both. -- 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 Dec 11 12:13:53 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13044 for ; Wed, 11 Dec 2002 12:13:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18MAHF-000Hzc-00 for namedroppers-data@psg.com; Wed, 11 Dec 2002 09:04:05 -0800 Received: from fxodpr13.extra.daimlerchrysler.com ([129.9.82.74]) by psg.com with esmtp (Exim 3.36 #2) id 18MAH9-000HyT-00 for namedroppers@ops.ietf.org; Wed, 11 Dec 2002 09:03:59 -0800 Received: (from uucp@localhost) by fxodpr13.extra.daimlerchrysler.com (8.11.4/8.9.0) id gBBH3tW07372 for ; Wed, 11 Dec 2002 12:03:55 -0500 (EST) Received: from unknown(53.231.71.237) by fxodpr13.extra.daimlerchrysler.com via csmap (V6.0) id srcAAA80ayzo; Wed, 11 Dec 02 12:03:55 -0500 Received: from odmrspr1-pf0.oddc.chrysler.com ([129.9.202.19]) by odconpr2-hme0.oddc.chrysler.com (Mail-Gear 2.0.0 bld 58) with SMTP id M2002121112035420698 for ; Wed, 11 Dec 2002 12:03:54 -0500 Received: from daimlerchrysler.com ([53.231.58.61]) by odmrspr1-pf0.oddc.chrysler.com (8.11.2/8.11.2/daimlerchrysler-relay-1.1-kcd) with ESMTP id gBBH3s127800 for ; Wed, 11 Dec 2002 12:03:55 -0500 (EST) Message-ID: <3DF77052.3090209@daimlerchrysler.com> Date: Wed, 11 Dec 2002 12:05:22 -0500 From: Kevin Darcy User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Autoslaving (was Re: rsync vs. axfr-clarify (was: in support of axfr-clarify)) References: <4.3.1.2.20021207144447.037bacd0@pop.gis.net> <4.3.1.2.20021209000917.037e3e00@pop.gis.net> <20021210080501.7005.qmail@cr.yp.to> <2304390000.1039514465@localhost.besserwisser.org> <20021210212640.2421.qmail@cr.yp.to> <20021211005914.69691.qmail@cr.yp.to> In-Reply-To: <20021211005914.69691.qmail@cr.yp.to> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-3.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES,SPAM_PHRASE_02_03, USER_AGENT,USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit D. J. Bernstein wrote: >Derek Atkins writes: > > >>Setting up axfr is simple. I list my secondaries, and they just say >>"master ". There. Done. End of configuration. How >>could setting up a secondary be any easier than that? >> >> > >What do you do when you change named.conf---for example, to add a zone? >You have to copy the changes to the secondary. With server replication, >this is handled automatically. > Well, perhaps this is as good a time as any to raise the fact that I've been working on an "auto-slaving" mechanism. The basic idea is that upon receipt of a signed NOTIFY from a particular entity, a slave can, if configured to do so, automatically configure itself as a slave for the zone being NOTIFY'ed. I've already started implementing this in the BIND 9 codebase, but the general concept is not implementation-specific and could conceivably be supported by any implementation that handles signed NOTIFYs. I bring this up not only to provide a middle-ground alternative between the two extremes presented thusfar, i.e. manually set up AXFR/IXFR slaves versus handling everything automatically through server replication, but also to elicit opinions as to whether this (perhaps unforeseen) use of NOTIFY requires any protocol standards action (Jim Reid has already weighed in with his opinion that it *does* require protocol standards action, but I disagree). Other opinions? - Kevin P.S. Mark (Andrews), have you seen my BIND 9 patch for this? -- 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 Dec 11 12:49:55 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14455 for ; Wed, 11 Dec 2002 12:49:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18MAt9-000Jnl-00 for namedroppers-data@psg.com; Wed, 11 Dec 2002 09:43:15 -0800 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #2) id 18MAt6-000Jn4-00 for namedroppers@ops.ietf.org; Wed, 11 Dec 2002 09:43:12 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 23FE7379FC6 for ; Wed, 11 Dec 2002 17:43:12 +0000 (GMT) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Autoslaving (was Re: rsync vs. axfr-clarify (was: in support of axfr-clarify)) In-Reply-To: Message from Kevin Darcy of "Wed, 11 Dec 2002 12:05:22 EST." <3DF77052.3090209@daimlerchrysler.com> X-Mailer: MH-E 7.0; nmh 1.0.4; Emacs 21.2 Date: Wed, 11 Dec 2002 17:43:12 +0000 Message-Id: <20021211174312.23FE7379FC6@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'd like to register my somewhat passive opposition to in-band autoslaving as a defined function of the protocol. out of band methods, like putting a list of zones into a "meta-zone" and transferring/postprocessing that, work fine. if we do it in-band, we'll need a way to not just add slaves but also move and replace and delete them. i'm perfectly happy just keeping an out of band list of who i want slaving what. far less complexity inside the dns implementation itself that way. "cron" is my friend. -- 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 Dec 11 14:11:09 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16859 for ; Wed, 11 Dec 2002 14:11:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18MC6s-000Ooc-00 for namedroppers-data@psg.com; Wed, 11 Dec 2002 11:01:30 -0800 Received: from fxodpr13.extra.daimlerchrysler.com ([129.9.82.74]) by psg.com with esmtp (Exim 3.36 #2) id 18MC6j-000Onf-00 for namedroppers@ops.ietf.org; Wed, 11 Dec 2002 11:01:21 -0800 Received: (from uucp@localhost) by fxodpr13.extra.daimlerchrysler.com (8.11.4/8.9.0) id gBBJ1ES02082 for ; Wed, 11 Dec 2002 14:01:14 -0500 (EST) Received: from unknown(53.231.71.237) by fxodpr13.extra.daimlerchrysler.com via csmap (V6.0) id srcAAAKDaiee; Wed, 11 Dec 02 14:01:14 -0500 Received: from odmrspr1-pf0.oddc.chrysler.com ([129.9.202.19]) by odconpr2-hme0.oddc.chrysler.com (Mail-Gear 2.0.0 bld 58) with SMTP id M2002121114011402114 for ; Wed, 11 Dec 2002 14:01:14 -0500 Received: from daimlerchrysler.com ([53.231.58.61]) by odmrspr1-pf0.oddc.chrysler.com (8.11.2/8.11.2/daimlerchrysler-relay-1.1-kcd) with ESMTP id gBBJ1E128324 for ; Wed, 11 Dec 2002 14:01:14 -0500 (EST) Message-ID: <3DF78BD4.3080909@daimlerchrysler.com> Date: Wed, 11 Dec 2002 14:02:44 -0500 From: Kevin Darcy User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: Autoslaving (was Re: rsync vs. axfr-clarify (was: in support of axfr-clarify)) References: <20021211174312.23FE7379FC6@as.vix.com> In-Reply-To: <20021211174312.23FE7379FC6@as.vix.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-3.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul Vixie wrote: >i'd like to register my somewhat passive opposition to in-band autoslaving >as a defined function of the protocol. out of band methods, like putting >a list of zones into a "meta-zone" and transferring/postprocessing that, >work fine. if we do it in-band, we'll need a way to not just add slaves >but also move and replace and delete them. i'm perfectly happy just keeping >an out of band list of who i want slaving what. far less complexity inside >the dns implementation itself that way. "cron" is my friend. > I don't see that the mechanism I have outlined, when limited in scope to slave "adds", complicates the protocol _per_se_. After all, the master is going to send initial NOTIFYs to all of its configured slaves anyway, regardless of whether they are already configured to be slaves or not, and it is going to sign those NOTIFYs if it is configured to do so. How is there any more protocol complexity if the slave takes the receipt of that signed NOTIFY as a trigger to perform more-work-than-usual behind the scenes? As for auto-UN-slaving, I see no reason why slave "adds" and slave "deletes" necessarily need to use the same mechanism. If I were to automate auto-UN-slaving at all, I'd probably base it on whether the putative master starts responding non-authoritatively to refresh checks. Perhaps there could be a configurable threshold, e.g. "x successive nonauth refresh-check responses and the zone gets deleted" in order to bridge temporary configuration errors on the master. On the other hand, one of the beauties of having an automatic NOTIFY-based autoslaving ("add") mechanism is that if a slave were to accidentally -- or perhaps as a result of being hacked -- stop being a slave for a zone, it automatically heals itself the next time the zone changes and another NOTIFY gets sent out for it. I'm not sure what you mean by "mov[ing] and replac[ing]" slave zones. In my conceptualization of autoslaving, a given nameserver is either slave for a zone or not slave for it. So there are only "adds" and "deletes" to the list of zones that a given nameserver slaves from some other given nameserver. I view the details of how those slave zones are configured within the slave (e.g. what servers down the delegation graph should get NOTIFYs, who can query the zone, update-forwarding configuration, etc.) to be out-of-scope of the autoslaving mechanism _per_se_. Eventually, it might be useful to take a look at the requirements -- or lack of same -- for a "nameserver configuration control" protocol. Given the current lay of the land, I could see this being implemented through SNMP somehow. The autoslaving mechanism I have proposed and partially implemented, is a targeted, short- to medium- solution at best, not a first pass at or a first step towards a comprehensive configuration-control solution. In any case, the question on the table here is: does a NOTIFY-based autoslaving mechanism require protocol-standards action, given that, on the one hand, it doesn't change the wire format at all, but, on the other, adds more "baggage" to NOTIFY than was originally intended? The question of whether it's a good idea or not is probably better suited to another forum. - Kevin -- 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 Dec 11 14:11:39 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16910 for ; Wed, 11 Dec 2002 14:11:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18MC4d-000Oe2-00 for namedroppers-data@psg.com; Wed, 11 Dec 2002 10:59:11 -0800 Received: from adsl-63-197-0-204.dsl.snfc21.pacbell.net ([63.197.0.204] helo=guava.araneus.fi) by psg.com with esmtp (Exim 3.36 #2) id 18MC4a-000OdY-00 for namedroppers@ops.ietf.org; Wed, 11 Dec 2002 10:59:08 -0800 Received: (from gson@localhost) by guava.araneus.fi (8.11.6/8.11.6) id gBBIwvi06662; Wed, 11 Dec 2002 10:58:57 -0800 (PST) Date: Wed, 11 Dec 2002 10:58:57 -0800 (PST) Message-Id: <200212111858.gBBIwvi06662@guava.araneus.fi> To: Bruce Campbell Cc: namedroppers@ops.ietf.org Subject: Re: in support of axfr-clarify In-Reply-To: References: <200212051659.gB5GxOg06337@syn.hamachi.org> X-Mailer: VM 7.04 under Emacs 20.7.1 From: gson@nominum.com (Andreas Gustafsson) X-Spam-Status: No, hits=-1.9 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_01_02 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Bruce Campbell writes: > [ http://www.ietf.org/internet-drafts/draft-ietf-dnsext-axfr-clarify-05.txt ] > > Section 3. could do with a reference to an updated RCODE listing (ie, > which RFC was NOTAUTH defined in?) I don't see such references in other pending drafts or recent RFCs. For example, RFC2845 and RFC2930 mention NOTAUTH but neither references an RCODE listing. The draft already contains sufficient information for implementation since it explicitly states the numeric value of the NOTAUTH RCODE, and if you need to know the defining RFC it is easily found through . > I would also like to see a clear exemption for responding to a zone > transfer request if the master server feels that the slave has made too > many queries in a short space of time (phrased in such a manner that the > slave will get at least one response in a given time period). What exactly do you mean by "not responding" in this case? Not sending the zone data, or not even sending a single message with an RCODE indicating an error? The former is already allowed; it would be a case of the server being "unable or unwilling" to provide a transfer. The latter would be a bad idea for the same reasons it is a bad idea in the "unauthorized slave" case that was recently extensively discussed (to put it mildly) on namedroppers. > Section 6 is partially incorrect in stating that it does not solve any > existing security-related problems, in that by removing ambiguity of which > records to transfer, you are removing the possibility of errors in a given > zone corrupting information in other zones (on the same server), and > preventing the replication of such corruption further. I think saying that the draft "solves" this problem would be too strong; for one thing, I don't want to imply that corrupting zone data was previously allowed. I'd rather err on the side of caution than make a potentially controversial claim of improved security; this draft has seen more than its share of controversy already. > Is good otherwise. -- Andreas Gustafsson, gson@nominum.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Dec 11 14:33:57 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17752 for ; Wed, 11 Dec 2002 14:33:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18MCSv-00001f-00 for namedroppers-data@psg.com; Wed, 11 Dec 2002 11:24:17 -0800 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.36 #2) id 18MCSs-000Pzw-00 for namedroppers@ops.ietf.org; Wed, 11 Dec 2002 11:24:14 -0800 Received: from x22.ripe.net.ripe.net (x22.ripe.net [193.0.1.22]) by birch.ripe.net (8.12.5/8.11.6) with ESMTP id gBBJNfvQ020609; Wed, 11 Dec 2002 20:23:41 +0100 Date: Wed, 11 Dec 2002 20:23:41 +0100 (CET) From: Bruce Campbell X-X-Sender: bc@x22.ripe.net To: Andreas Gustafsson cc: namedroppers@ops.ietf.org Subject: Re: in support of axfr-clarify In-Reply-To: <200212111858.gBBIwvi06662@guava.araneus.fi> 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 On Wed, 11 Dec 2002, Andreas Gustafsson wrote: [ ah, a sensible mail ;) ] > Bruce Campbell writes: > > [ http://www.ietf.org/internet-drafts/draft-ietf-dnsext-axfr-clarify-05.txt ] > > > > Section 3. could do with a reference to an updated RCODE listing (ie, > > which RFC was NOTAUTH defined in?) > > I don't see such references in other pending drafts or recent RFCs. > For example, RFC2845 and RFC2930 mention NOTAUTH but neither > references an RCODE listing. The draft already contains sufficient > information for implementation since it explicitly states the numeric > value of the NOTAUTH RCODE, and if you need to know the defining RFC > it is easily found through . Actually, both 2845 and 2930 refer to (in their References) 2136, where NotAuth is defined (for reasons other than an RCODE listing). Could 2136 be added to the References section for completeness? > > I would also like to see a clear exemption for responding to a zone > > transfer request if the master server feels that the slave has made too > > many queries in a short space of time (phrased in such a manner that the > > slave will get at least one response in a given time period). > > What exactly do you mean by "not responding" in this case? Not > sending the zone data, or not even sending a single message with an > RCODE indicating an error? Not acknowledging the request at all, terminating the connection immediately. > The former is already allowed; it would be a case of the server being > "unable or unwilling" to provide a transfer. The latter would be a > bad idea for the same reasons it is a bad idea in the "unauthorized > slave" case that was recently extensively discussed (to put it mildly) > on namedroppers. The (corner) case that I'm thinking of is a large DNS server (for instance, a root server) under a DDoS where Bad People(tm) are getting said large DNS server to swamp its outbound link in replying to (lots of) bogus AXFR queries. Even if they're just short replies, its still avoidable traffic. ( I'm trying to avoid possibilities where some dweeb claims that we must do this behaviour because 'It Is Written', I'm also trying to avoid possibilities where more creative DNS-based attacks are used. ) On 'unauthorised clients', I'm quite happy for said large DNS server to reply 'Refused' up to a point. Beyond that point, we should be able to ignore irritating clients on that particular type of request. > > Section 6 is partially incorrect in stating that it does not solve any > > existing security-related problems, in that by removing ambiguity of which > > records to transfer, you are removing the possibility of errors in a given > > zone corrupting information in other zones (on the same server), and > > preventing the replication of such corruption further. > > I think saying that the draft "solves" this problem would be too > strong; for one thing, I don't want to imply that corrupting zone data > was previously allowed. Hrm, that sounds like you're pointing the finger at implementors for corruption caused through misinterpretation of existing standards (which is ok). Ok, skip this point. > I'd rather err on the side of caution than > make a potentially controversial claim of improved security; this > draft has seen more than its share of controversy already. Heh. --==-- 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 Wed Dec 11 14:38:24 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17864 for ; Wed, 11 Dec 2002 14:38:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18MCZh-0000Sm-00 for namedroppers-data@psg.com; Wed, 11 Dec 2002 11:31:17 -0800 Received: from momotombo.techfak.uni-bielefeld.de ([129.70.136.107]) by psg.com with esmtp (Exim 3.36 #2) id 18MCZc-0000SQ-00 for namedroppers@ops.ietf.org; Wed, 11 Dec 2002 11:31:12 -0800 Received: from grimsvotn.TechFak.Uni-Bielefeld.DE (grimsvotn.TechFak.Uni-Bielefeld.DE [129.70.137.40]) by momotombo.TechFak.Uni-Bielefeld.DE (8.11.6+Sun/8.11.6/TechFak/pk+ro20010720) with ESMTP id gBBJV8U23809; Wed, 11 Dec 2002 20:31:09 +0100 (MET) Received: from localhost (pk@localhost) by grimsvotn.TechFak.Uni-Bielefeld.DE (8.11.6+Sun/8.9.1) with SMTP id gBBJV8c04978; Wed, 11 Dec 2002 20:31:08 +0100 (MET) Message-Id: <200212111931.gBBJV8c04978@grimsvotn.TechFak.Uni-Bielefeld.DE> X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: Kevin Darcy Cc: namedroppers@ops.ietf.org Subject: Re: Autoslaving (was Re: rsync vs. axfr-clarify (was: in support of axfr-clarify)) In-reply-to: Your message of "Wed, 11 Dec 2002 14:02:44 EST." <3DF78BD4.3080909@daimlerchrysler.com> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 Date: Wed, 11 Dec 2002 20:31:08 +0100 From: Peter Koch X-Spam-Status: No, hits=-2.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_02_03,X_AUTH_WARNING version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Kevin Darcy wrote: > I don't see that the mechanism I have outlined, when limited in scope to > slave "adds", complicates the protocol _per_se_. After all, the master that dependds on your service model. There is not necessarily a 1:1 relationship between master and slave, which is why "server replication" is not applicable in many cases. Then, a slave may depend upon several masters (i.e. may offer 2ndary service to multiple parties). So, you need some notion of ownership wrt the zones to be slaved. In addition, you need a channel to communicate back some status information, i.e. addition succeeded/failed for reason x. We've developed a simple request-response protocol some years ago and did NOT use DNS as a "transport" mechanism, not only because TSIG wasn't yet around. > that signed NOTIFY as a trigger to perform more-work-than-usual behind > the scenes? Usually you have more information available than just "slave zone exapmle.com off dns.example.net". There are - yet implementation specific - details which need to be piggybacked to the slave request. AXFR limits, some people seem to believe in them, are one example. You could prenegotiate and configure some of these, but I do not believe DNS is the best or canonical way to accomplish this task (although, for XFR limits in particular, that could quite simply be done in band, i.e. within that particular zone). > Perhaps there could be a configurable threshold, e.g. "x successive > nonauth refresh-check responses and the zone gets deleted" in order to > bridge temporary configuration errors on the master. On the other hand, Also here, a careful design would take into account the current delegation status of that particular zone. > one of the beauties of having an automatic NOTIFY-based autoslaving > ("add") mechanism is that if a slave were to accidentally -- or perhaps > as a result of being hacked -- stop being a slave for a zone, it > automatically heals itself the next time the zone changes and another > NOTIFY gets sent out for it. Well, a cracker wouldn't have to stop at the DoS level, they'd insert false information. Anyway, from an operational perspective I do not really like the idea, because it is already difficult enough to explain to the average part time DNS zone maintainer that these things do not happen automagically. If they'd work automagically only *sometimes*, that might be worse. > my conceptualization of autoslaving, a given nameserver is either slave > for a zone or not slave for it. So there are only "adds" and "deletes" It can be slave with different sources (owners) of a zone. > Eventually, it might be useful to take a look at the requirements -- or > lack of same -- for a "nameserver configuration control" protocol. Given I'd like to discuss this further but I suggest we take this off the list, because it is not really DNS related. In fact, it looks a bit similar to what happens at the registry-registrar level. -Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Dec 11 15:23:47 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19344 for ; Wed, 11 Dec 2002 15:23:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18MDGP-00034d-00 for namedroppers-data@psg.com; Wed, 11 Dec 2002 12:15:25 -0800 Received: from fxodpr13.extra.daimlerchrysler.com ([129.9.82.74]) by psg.com with esmtp (Exim 3.36 #2) id 18MDGK-0002yF-00 for namedroppers@ops.ietf.org; Wed, 11 Dec 2002 12:15:20 -0800 Received: (from uucp@localhost) by fxodpr13.extra.daimlerchrysler.com (8.11.4/8.9.0) id gBBKEmR17640 for ; Wed, 11 Dec 2002 15:14:48 -0500 (EST) Received: from unknown(53.231.71.237) by fxodpr13.extra.daimlerchrysler.com via csmap (V6.0) id srcAAAdfa4CI; Wed, 11 Dec 02 15:14:48 -0500 Received: from odmrspr1-pf0.oddc.chrysler.com ([129.9.202.19]) by odconpr2-hme0.oddc.chrysler.com (Mail-Gear 2.0.0 bld 58) with SMTP id M2002121115144805014 for ; Wed, 11 Dec 2002 15:14:48 -0500 Received: from daimlerchrysler.com ([53.231.58.61]) by odmrspr1-pf0.oddc.chrysler.com (8.11.2/8.11.2/daimlerchrysler-relay-1.1-kcd) with ESMTP id gBBKEl117564 for ; Wed, 11 Dec 2002 15:14:47 -0500 (EST) Message-ID: <3DF79D12.6000308@daimlerchrysler.com> Date: Wed, 11 Dec 2002 15:16:18 -0500 From: Kevin Darcy User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: Autoslaving (was Re: rsync vs. axfr-clarify (was: in support of axfr-clarify)) References: <200212111931.gBBJV8c04978@grimsvotn.TechFak.Uni-Bielefeld.DE> In-Reply-To: <200212111931.gBBJV8c04978@grimsvotn.TechFak.Uni-Bielefeld.DE> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-3.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES,SPAM_PHRASE_02_03, USER_AGENT,USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Peter Koch wrote: >Kevin Darcy wrote: > > > >>I don't see that the mechanism I have outlined, when limited in scope to >>slave "adds", complicates the protocol _per_se_. After all, the master >> >> > >that dependds on your service model. There is not necessarily a 1:1 relationship >between master and slave, which is why "server replication" is not applicable >in many cases. Then, a slave may depend upon several masters (i.e. may offer >2ndary service to multiple parties). So, you need some notion of ownership >wrt the zones to be slaved. In addition, you need a channel to communicate >back some status information, i.e. addition succeeded/failed for reason x. >We've developed a simple request-response protocol some years ago and did NOT >use DNS as a "transport" mechanism, not only because TSIG wasn't yet around. > > I already have a notion of ownership in what I've implemented so far. An "autoslave" can have multiple masters for any given zone. As for status reporting, the master can always query the zone and see if the putative slave answers authoritatively. I don't see the need for a special "channel". >>that signed NOTIFY as a trigger to perform more-work-than-usual behind >>the scenes? >> >> > >Usually you have more information available than just "slave zone exapmle.com >off dns.example.net". There are - yet implementation specific - details which >need to be piggybacked to the slave request. AXFR limits, some people seem >to believe in them, are one example. You could prenegotiate and configure >some of these, but I do not believe DNS is the best or canonical way to >accomplish this task (although, for XFR limits in particular, that could >quite simply be done in band, i.e. within that particular zone). > Right. I'm putting all of that stuff out of scope. The mechanism I'm talking about just adds a slave zone. The details of how that slave zone is configured is up to the slave, possibly using some out-of-band information from the master. >>Perhaps there could be a configurable threshold, e.g. "x successive >>nonauth refresh-check responses and the zone gets deleted" in order to >>bridge temporary configuration errors on the master. On the other hand, >> >> > >Also here, a careful design would take into account the current delegation >status of that particular zone. > I don't quite catch your drift. What do you mean by "delegation status"? You mean whether the zone is delegated from its parent or not? I'm not sure what bearing this has on master/slave replication. >>one of the beauties of having an automatic NOTIFY-based autoslaving >>("add") mechanism is that if a slave were to accidentally -- or perhaps >>as a result of being hacked -- stop being a slave for a zone, it >>automatically heals itself the next time the zone changes and another >>NOTIFY gets sent out for it. >> >> > >Well, a cracker wouldn't have to stop at the DoS level, they'd insert false >information. > The NOTIFY was signed, I'm assuming if that is in place, the zone transfers are signed too. Why would someone require NOTIFYs to be signed but then accept a zone transfer based on weaker authentication or no authentication at all? That seems rather remiss. >Anyway, from an operational perspective I do not really like >the idea, because it is already difficult enough to explain to the average >part time DNS zone maintainer that these things do not happen automagically. >If they'd work automagically only *sometimes*, that might be worse. > Is it better to have a patchwork of homegrown solutions to the problem? Or to force everyone into DJB's server-replication model? It is precisely because I'm sick and tired of my own homegrown solution, that I started working on this... >>my conceptualization of autoslaving, a given nameserver is either slave >>for a zone or not slave for it. So there are only "adds" and "deletes" >> >> > >It can be slave with different sources (owners) of a zone. > Right, slaves and masters for a given zone is potentially a many-to-many relationship. But between two given nameservers, either a given zone is being replicated between them, or it isn't. >>Eventually, it might be useful to take a look at the requirements -- or >>lack of same -- for a "nameserver configuration control" protocol. Given >> >> > >I'd like to discuss this further but I suggest we take this off the list, >because it is not really DNS related. In fact, it looks a bit similar to what >happens at the registry-registrar level. > Can I count that as implicitly a voice in support of "not a protocol change" then? :-) - Kevin -- 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 Dec 11 15:30:00 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19552 for ; Wed, 11 Dec 2002 15:30:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18MDQH-0003c5-00 for namedroppers-data@psg.com; Wed, 11 Dec 2002 12:25:37 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18MDQB-0003bf-00 for namedroppers@ops.ietf.org; Wed, 11 Dec 2002 12:25:32 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18MDQA-000NPw-00 for namedroppers@ops.ietf.org; Wed, 11 Dec 2002 12:25:30 -0800 In-Reply-To: <3DF77052.3090209@daimlerchrysler.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Wed, 11 Dec 2002 20:36:39 +0100 (CET) From: Bruce Campbell To: Kevin Darcy cc: namedroppers@ops.ietf.org Subject: Re: Autoslaving (was Re: rsync vs. axfr-clarify (was: in support of axfr-clarify)) X-Spam-Status: No, hits=-3.5 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,RESENT_TO, SPAM_PHRASE_01_02,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 Wed, 11 Dec 2002, Kevin Darcy wrote: > Well, perhaps this is as good a time as any to raise the fact that I've > been working on an "auto-slaving" mechanism. The basic idea is that upon http://archive.iecc.com/article/spamtools/20010608005 --==-- 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 Thu Dec 12 02:35:20 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15532 for ; Thu, 12 Dec 2002 02:35:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18MNWt-000B1t-00 for namedroppers-data@psg.com; Wed, 11 Dec 2002 23:13:07 -0800 Received: from 12-234-90-219.client.attbi.com ([12.234.90.219] ident=x8nvlfgcaw6lukxr) by psg.com with esmtp (Exim 3.36 #2) id 18MNWq-000B1h-00 for namedroppers@ops.ietf.org; Wed, 11 Dec 2002 23:13:04 -0800 Received: from 12-234-90-219.client.attbi.com (q1utrskkzu2wc4s1@localhost [127.0.0.1]) by 12-234-90-219.client.attbi.com (8.12.6/8.12.6) with ESMTP id gBC7D2eZ053353 for ; Wed, 11 Dec 2002 23:13:03 -0800 (PST) (envelope-from DougB@DougBarton.net) Received: from localhost (doug@localhost) by 12-234-90-219.client.attbi.com (8.12.6/8.12.6/Submit) with ESMTP id gBC7D1tR053350 for ; Wed, 11 Dec 2002 23:13:02 -0800 (PST) X-Authentication-Warning: 12-234-90-219.client.attbi.com: doug owned process doing -bs Date: Wed, 11 Dec 2002 23:13:01 -0800 (PST) From: Doug Barton X-X-Sender: doug@12-234-90-219.client.attbi.com To: namedroppers@ops.ietf.org Subject: Re: rsync vs. axfr-clarify (was: in support of axfr-clarify) In-Reply-To: <20021210212640.2421.qmail@cr.yp.to> Message-ID: <20021211225706.U47604-100000@12-234-90-219.client.attbi.com> References: <4.3.1.2.20021207144447.037bacd0@pop.gis.net> <4.3.1.2.20021209000917.037e3e00@pop.gis.net> <20021210080501.7005.qmail@cr.yp.to> <2304390000.1039514465@localhost.besserwisser.org> <20021210212640.2421.qmail@cr.yp.to> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-5.5 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_SPARSE,SPAM_PHRASE_01_02,X_AUTH_WARNING version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 10 Dec 2002, D. J. Bernstein wrote: > In fact, even though BIND makes it unnecessarily difficult to set up, > this is an extremely popular configuration. AXFR today has two main uses: > > (1) as a clumsy mechanism of replicating servers and > (2) as a clumsy mechanism of editing zone files remotely. > > Except at companies that sell third-party DNS service, there's very > little demand for any type of replication other than server replication. > Yes, we can all point to examples such as arpa-vs.-root-servers.net, but > those examples are the fringe case. I have to disagree. I am the DNS administrator for a fairly large enterprise, and I'm also responsible for the name servers used in our DNS reselling program. I have roughly 200 name servers, in dozens of geographic locations all over the world, some authoritative, most resolvers. I have several different masters, each with a unique subset of zones it's responsible for. Each of the slaves sucks down some zones from the various masters, but no single server gets all the zones from any of the masters. In short, while there are subsets of slaves that all have the same configurations, there isn't anyplace in my company where the concept of "server replication" would apply. AXFR is crucial to the success of my configuration(s). Note, I haven't even touched on the issue of sharing information with third parties, whether I'm slaving from them, or they are slaving from me (I have some of each). Now you can argue whether or not I'm a "typical" user, or whether all the gymnastics are actually needed. (In fact, the current configuration is both simpler and more reliable than when I took over, but I digress.) However, AXFR definitely provides me the flexibility I need to deal with my situation (as I perceive it). -- "We have known freedom's price. We have shown freedom's power. And in this great conflict, ... we will see freedom's victory." - George W. Bush, President of the United States State of the Union, January 28, 2002 Do YOU Yahoo!? -- 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 Dec 12 07:43:45 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21058 for ; Thu, 12 Dec 2002 07:43:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18MSFB-000Jeu-00 for namedroppers-data@psg.com; Thu, 12 Dec 2002 04:15:09 -0800 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.36 #2) id 18MSF8-000Je2-00 for namedroppers@ops.ietf.org; Thu, 12 Dec 2002 04:15:07 -0800 Received: from x22.ripe.net.ripe.net (x22.ripe.net [193.0.1.22]) by birch.ripe.net (8.12.5/8.11.6) with ESMTP id gBCCEqvQ005004 for ; Thu, 12 Dec 2002 13:14:52 +0100 Date: Thu, 12 Dec 2002 13:14:52 +0100 (CET) From: Bruce Campbell X-X-Sender: bc@x22.ripe.net To: namedroppers@ops.ietf.org Subject: Re: rsync vs. axfr-clarify (was: in support of axfr-clarify) In-Reply-To: <20021210231625.34120.qmail@cr.yp.to> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02,USER_AGENT_PINE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On 10 Dec 2002, D. J. Bernstein wrote: > Bruce Campbell writes: > > There is a set standard for zone (MASTER) files in RFC1035 section 5 > > Sorry to bother you with the facts, but the BIND company keeps changing > their zone-file format. You're kidding yourself if you think that the > format is stable. Lets see. I stated that there is a set, implementation non-specific, standard for zone files. You replied that a specific implementation, the 'BIND company', keeps changing their zone file format. Ergo, to use your methods of summarising, you are in support of AXFR between different nameserver implementations, and possibly different versions of the one implementation. ( Although to play Devils Advocate, after downloading sample BIND distributions and checking the example zones, the synxtax of the zone file that BIND will accept has not changed between BIND 4.8 and 9.2.2rc1 ) > Furthermore, zone files are only part of the BIND > configuration; the named.conf format is even less stable. Point being? ( as in, we're talking about zone files, not server configuration files ) --==-- 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 Thu Dec 12 14:25:53 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08538 for ; Thu, 12 Dec 2002 14:25:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18MYlB-0009T0-00 for namedroppers-data@psg.com; Thu, 12 Dec 2002 11:12:37 -0800 Received: from adsl-63-197-0-204.dsl.snfc21.pacbell.net ([63.197.0.204] helo=guava.araneus.fi) by psg.com with esmtp (Exim 3.36 #2) id 18MYl7-0009Sf-00 for namedroppers@ops.ietf.org; Thu, 12 Dec 2002 11:12:33 -0800 Received: (from gson@localhost) by guava.araneus.fi (8.11.6/8.11.6) id gBCJCPK08491; Thu, 12 Dec 2002 11:12:25 -0800 (PST) Date: Thu, 12 Dec 2002 11:12:25 -0800 (PST) Message-Id: <200212121912.gBCJCPK08491@guava.araneus.fi> To: Bruce Campbell Cc: namedroppers@ops.ietf.org Subject: Re: in support of axfr-clarify In-Reply-To: References: <200212111858.gBBIwvi06662@guava.araneus.fi> X-Mailer: VM 7.04 under Emacs 20.7.1 From: gson@nominum.com (Andreas Gustafsson) X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_02_03 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Bruce Campbell writes: > Actually, both 2845 and 2930 refer to (in their References) 2136, where > NotAuth is defined (for reasons other than an RCODE listing). Could 2136 > be added to the References section for completeness? I suppose it could; that's just an editorial change. Added. > > > I would also like to see a clear exemption for responding to a zone > > > transfer request if the master server feels that the slave has made too > > > many queries in a short space of time (phrased in such a manner that the > > > slave will get at least one response in a given time period). > > > > What exactly do you mean by "not responding" in this case? Not > > sending the zone data, or not even sending a single message with an > > RCODE indicating an error? > > Not acknowledging the request at all, terminating the connection > immediately. [...] > The (corner) case that I'm thinking of is a large DNS server (for > instance, a root server) under a DDoS where Bad People(tm) are getting > said large DNS server to swamp its outbound link in replying to (lots of) > bogus AXFR queries. Even if they're just short replies, its still > avoidable traffic. It's quite a small amount of traffic compared to the TCP connection setup and teardown overhead - 14 bytes, to be precise. In any case, I don't think making a specific exemption as part of the AXFR protocol itself makes sense. A DDoSer could cause just as much harm by sending (e.g.) type A queries over TCP, and almost as much harm just by opening lots of TCP connections without actually sending queries. A defense against this type of attack would have to work at a lower level in the AXFR/DNS/TCP/IP protocol stack, by dropping excessive requests regardless of type or even by dropping excessive TCP connections without trying to receive a request at all. If you do that, you are simply refusing to speak the AXFR (or even DNS) protocol, not closing the connection as part of the AXFR protocol. -- Andreas Gustafsson, gson@nominum.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 13 12:41:51 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29378 for ; Fri, 13 Dec 2002 12:41:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Mtcw-0009Uk-00 for namedroppers-data@psg.com; Fri, 13 Dec 2002 09:29:30 -0800 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.36 #2) id 18Mtck-0009U6-00 for namedroppers@ops.ietf.org; Fri, 13 Dec 2002 09:29:18 -0800 Received: from x22.ripe.net.ripe.net (x22.ripe.net [193.0.1.22]) by birch.ripe.net (8.12.5/8.11.6) with ESMTP id gBDHSwvQ010660; Fri, 13 Dec 2002 18:28:59 +0100 Date: Fri, 13 Dec 2002 18:28:58 +0100 (CET) From: Bruce Campbell X-X-Sender: bc@x22.ripe.net To: Andreas Gustafsson cc: namedroppers@ops.ietf.org Subject: Re: in support of axfr-clarify In-Reply-To: <200212121912.gBCJCPK08491@guava.araneus.fi> 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 On Thu, 12 Dec 2002, Andreas Gustafsson wrote: > Bruce Campbell writes: > > Actually, both 2845 and 2930 refer to (in their References) 2136, where > > NotAuth is defined (for reasons other than an RCODE listing). Could 2136 > > be added to the References section for completeness? > > I suppose it could; that's just an editorial change. Added. Thanks. > > > What exactly do you mean by "not responding" in this case? Not > > > sending the zone data, or not even sending a single message with an > > > RCODE indicating an error? > > > > Not acknowledging the request at all, terminating the connection > > immediately. > [...] > > The (corner) case that I'm thinking of is a large DNS server (for > > instance, a root server) under a DDoS where Bad People(tm) are getting > > said large DNS server to swamp its outbound link in replying to (lots of) > > bogus AXFR queries. Even if they're just short replies, its still > > avoidable traffic. > > It's quite a small amount of traffic compared to the TCP connection > setup and teardown overhead - 14 bytes, to be precise. ( Well, I wasn't going to be worried about TCP teardown persay ) > > In any case, I don't think making a specific exemption as part of the > AXFR protocol itself makes sense. Ok. > A DDoSer could cause just as much > harm by sending (e.g.) type A queries over TCP, [snippery] I've also reached the same conclusions, and think that I can find a more general exception (ie, not specific to axfr). This particular point can be dropped. --==-- 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 Fri Dec 13 14:05:36 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02015 for ; Fri, 13 Dec 2002 14:05:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18MuzD-000Csk-00 for namedroppers-data@psg.com; Fri, 13 Dec 2002 10:56:35 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18Muyu-000Cro-00 for namedroppers@ops.ietf.org; Fri, 13 Dec 2002 10:56:16 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18Muyt-0002LJ-00 for namedroppers@ops.ietf.org; Fri, 13 Dec 2002 10:56:15 -0800 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Mon, 9 Dec 2002 03:14:43 +0000 (GMT) From: Lloyd Wood To: Dean Anderson cc: ietf@ietf.org, , , Subject: RE: namedroppers, continued X-Spam-Status: No, hits=-1.5 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,MARKETING,QUOTED_EMAIL_TEXT, RESENT_TO,SPAM_PHRASE_03_05,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 Sun, 8 Dec 2002, Dean Anderson wrote: > On Sun, 8 Dec 2002, Lloyd Wood wrote: > > "Sender pays" is good. The penny black stamp effectively introduced a > > flat-rate tax on sending letters, rather than a variable-rate tax on > > receiving them, effectively turning mail into a common good available > > to all society. > > You assume this really means "the spammer pays" [more]. that quote is excerpted out of context. > But that isn't the case. This is based on the myth that somehow the > receiver pays the entire cost of a spam message. This isn't true, > and never was true. It's true. It's an attention economy, where the recipients' lives and time are finite. But placing a value on time is tricky. > The sender is already paying, whether they are spammer or mailing > list operator, or regular end user. The fact is that email is so > cheap that it costs almost nothing per message to send and receive. > It gets cheaper every day, as disks and bandwidth get cheaper and > cheaper. The receiver doesn't pay any more than the sender pays. only if a purely fiscal definition is taken. > Real commercial spam happens because the cost of sending spam is > less than the cost of sending letters or postcards. this is very true. It's also true for physical commercial bulk mail, which gets special rates compared to individual letters or postcards. Bill Cunningham adds: $ Lloyd, in the US we pay .37 to mail a first-class letter. I don't $ know how many pence you pay in the UK but we still have "spam" bulk $ rate unwanted solicitations. ...that are paid for at commercial bulk rates vastly cheaper than the individual rate, which encourages them. That's what you get for running the postal service as a commercial business rather than as a emphasising the social good aspects. $ Forcing the sender to pay doesn't solve a spam problem. I don't see $ how in could. It would force everyone to have to pay a price. if everyone pays the same price, then those sending the most are most penalised. flat-rate. > If you artificially made email expensive, it would be expensive for > list operators and regular people as well. You mentioned a rate of > one cent per message. I did not mention such a rate; you've taken the Penny Black one-penny-over-150-years-ago and run with it. Perhaps you would care to actually read my entire message, and tailor your canned rant to it? The act of subscribing to a list indicates that you know the list, and you're less likely to reject mail from people you don't know that comes or also comes via the list, since you're interested in reading that list -- unless the list is a simple exploder with no filtering mechanisms itself, in which case, subscribers pester each other (rather than the list) for computational proofs until the list implements spam filtering. L. > That would not be enough to deter spam. A rate of ten cents per > message would still be cheaper than postal mail, and so spammers would > still exist. Much non-commmercial spam is sent by KLEZ or Nimda viruses. > This sort of abuse would not be affected whatsoever. Note that KLEZ > infections are already illegal. > > Think how much it would cost to send out namedroppers, (and the entire > bulk of IETF standards related email) if each message to each recipient > cost, say $0.10. Or even one cent per message per recipient. This > proposal would essentially wipe out many if not most mailing list > operators, and most ISPs. > > I made a proposal back in 1997 that would not eliminate spam, but would > keep it out of your mailbox. My proposal was rejected because radicals > demanded a complete ban on spam. In 1998, there was an opportunity to get > anti-spam legislation passed. Unreasonable anti-spam radicals passed up > that opportunity when they insisted on unrealistic demands, and > exaggerated and factually wrong assertions about the cost of spam. They > assumed they could "shout down" any opposition, as they shouted down more > reasonable proposals. They were understandably and easily crushed by the > Direct Marketing Association (DMA). You can still see my proposal at > http://www.av8.com/H.4581/better.html This proposal would have been > difficult for the DMA to challenge since they already accept these > restrictions on postal mail. You have the radical anti-spam leadership to > thank for your spam, and the fact that you don't have a universal opt-out > list. > > The anti-spam effort was for all practical purposes completely crushed > when Exactis successfully sued MAPS and demonstrated that blacklists are > subject to the Sherman Anti Trust Act and that blacklists weren't > protected by the First Amendment. I told Vixie this would happen in 1997. > He assured me that anti-spammers could win by technical means. If it > wasn't clear that he was wrong in 1997, (and it seemed pretty obvious even > then), it is now painfully obvious that Vixie and the rest were very > wrong. > > It is really time for new, reasonable, anti-spam leadership, not artifical > changes to the cost of email, or schemes to try to make sending mail more > expensive for the senders, and certainly not gyrations in the sending of > namedroppers. > > Thanks to the ineptitude, lack of foresight, irrationality, and general > unreasonableness of the anti-spam leadership, spam is here to stay. It is > just a matter of degrees of how bad it will be. I note there is some > legislation before the house and senate (HR 1017) on spam control, that > reportedly isn't opposed by the DMA. However, these only control > fraudulent spam. HR 1017 proposes extensions of 18 USC 1030, which makes > it a fraudulent spam a crime, but the FBI probably won't bring charges for > small violations. There is no provision for a civil action. > > Another bill (S.630) would require each spammer to maintain an opt-out > list. You would have to contact each spammer, and have your email address > added to their list, one by one. There would be thousands of spammers to > contact. > > Note that my proposal would had a single opt-out list (the Post Office > already maintains such a list for postal junk mail), and my proposal > probably could have been passed into law in 1998. > > --Dean > > -- 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 Dec 14 14:22:15 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08117 for ; Sat, 14 Dec 2002 14:22:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18NHej-0006ck-00 for namedroppers-data@psg.com; Sat, 14 Dec 2002 11:08:57 -0800 Received: from relay2.av8.net ([130.105.12.4] helo=citation.av8.net) by psg.com with esmtp (Exim 3.36 #2) id 18NHed-0006cB-00 for namedroppers@ops.ietf.org; Sat, 14 Dec 2002 11:08:51 -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 OAA00434; Sat, 14 Dec 2002 14:03:11 -0500 Date: Sat, 14 Dec 2002 14:05:12 -0500 (EST) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: Lloyd Wood cc: ietf@ietf.org, , , Subject: RE: namedroppers, continued In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.1 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,SPAM_PHRASE_02_03,USER_AGENT_PINE, X_OSIRU_SPAM_SRC version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, 9 Dec 2002, Lloyd Wood wrote: > On Sun, 8 Dec 2002, Dean Anderson wrote: > > > On Sun, 8 Dec 2002, Lloyd Wood wrote: > > > "Sender pays" is good. The penny black stamp effectively introduced a > > > flat-rate tax on sending letters, rather than a variable-rate tax on > > > receiving them, effectively turning mail into a common good available > > > to all society. > > > > You assume this really means "the spammer pays" [more]. > > that quote is excerpted out of context. I don't think its out of context. You assume your scheme will only increase the costs for the spammer, and make it less economical to spam. This is a false assumption on your part. Your scheme increases the cost for everyone, and indeed it increases the cost for legitimate email more than it increases the cost of spamming. In other words, it makes it _even_more_economical_ to spam. This is the kind of "shoot your self in the foot" thing as when Sanford Wallace and Cyberpromo lost his T1, and spammers turned to dialup. The dialups cost less than T1's, and so it was even cheaper to spam, and harder to find out who was behind it. The anti-spammers made it cheaper to spam, and harder to determine who the spammers really were. At least CyberPromo could be identified, sued, made to obey the law and court orders. > > But that isn't the case. This is based on the myth that somehow the > > receiver pays the entire cost of a spam message. This isn't true, > > and never was true. > > It's true. It's an attention economy, where the recipients' lives and > time are finite. But placing a value on time is tricky. This argument was raised (and rejected) in the 1970's with regard to junk postal mail. > > The sender is already paying, whether they are spammer or mailing > > list operator, or regular end user. The fact is that email is so > > cheap that it costs almost nothing per message to send and receive. > > It gets cheaper every day, as disks and bandwidth get cheaper and > > cheaper. The receiver doesn't pay any more than the sender pays. > > only if a purely fiscal definition is taken. That is the only definition you can take, absent additional legislation. > > Real commercial spam happens because the cost of sending spam is > > less than the cost of sending letters or postcards. > > this is very true. It's also true for physical commercial bulk mail, > which gets special rates compared to individual letters or postcards. > > Bill Cunningham adds: > > $ Lloyd, in the US we pay .37 to mail a first-class letter. I don't > $ know how many pence you pay in the UK but we still have "spam" bulk > $ rate unwanted solicitations. > > ...that are paid for at commercial bulk rates vastly cheaper than the > individual rate, which encourages them. That's what you get for > running the postal service as a commercial business rather than as a > emphasising the social good aspects. > > $ Forcing the sender to pay doesn't solve a spam problem. I don't see > $ how in could. It would force everyone to have to pay a price. > > if everyone pays the same price, then those sending the most are most > penalised. flat-rate. Uhh, not exactly. They pay more in total, but it doesn't matter as long as the advertising costs are low enough that they are still selling products at a profit. > > If you artificially made email expensive, it would be expensive for > > list operators and regular people as well. You mentioned a rate of > > one cent per message. > > I did not mention such a rate; you've taken the Penny Black > one-penny-over-150-years-ago and run with it. Perhaps you would care > to actually read my entire message, and tailor your canned rant to it? I read your whole message, and I read it again just now. Perhaps I wasn't clear: Your assertion about the benefits of flat rate vs variable rate are irrelevant. Whatever the value (flat rate or variable rate), if its less than the bulk postal rate, plus the cost of printing, stuffing, etc, it will still be more economical to send spam than to use bulk postal mail. And, as above, it is dubious there is a variable rate involved in spam. However, even if there was a variable rate, it wouldn't make any difference. > The act of subscribing to a list indicates that you know the list, and > you're less likely to reject mail from people you don't know that > comes or also comes via the list, since you're interested in reading > that list -- unless the list is a simple exploder with no filtering > mechanisms itself, in which case, subscribers pester each other > (rather than the list) for computational proofs until the list > implements spam filtering. The computational proofs cost you more than they cost the spammer. And in the end, the spammer can do them, and it won't make any difference so long as the cost is still low enough to be economical. --Dean -- 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 Dec 14 22:26:39 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17017 for ; Sat, 14 Dec 2002 22:26:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18NPHv-000GiB-00 for namedroppers-data@psg.com; Sat, 14 Dec 2002 19:17:55 -0800 Received: from stoneport.math.uic.edu ([131.193.178.160]) by psg.com with smtp (Exim 3.36 #2) id 18NPHs-000Ghz-00 for namedroppers@ops.ietf.org; Sat, 14 Dec 2002 19:17:52 -0800 Received: (qmail 42775 invoked by uid 1016); 15 Dec 2002 03:18:15 -0000 Date: 15 Dec 2002 03:18:14 -0000 Message-ID: <20021215031814.42774.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Cc: sob@harvard.edu Subject: Re: repeating records References: <20021210083118.10800.qmail@cr.yp.to> <200212102154.gBALsitB045122@drugs.dv.isc.org> <20021210235711.50719.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 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 Greg Hudson writes: > Ideally, an RFC uses SHOULD when the working group feels that an > analysis of a tradeoff should generally go in one direction No. That violates RFC 2119, section 6. These decisions are _not_ up to the working group. They are up to the implementors and, ultimately, the users. When speedups actually make a difference for the users, the users notice and select implementations accordingly. When a tradeoff is good for some users and bad for others, implementations end up offering a variety of options, and users end up choosing options accordingly. The free market does a good job of matching speedups to the users who benefit from them. Telling implementors that they ``SHOULD'' choose one option---that they must carefully consider the consequences before doing anything else---is naive, misguided, paternalistic, anti-competitive behavior. Even if * you think that some users will benefit from the option; or * you think that some users _need_ the option; or * you think that _most_ users need the option; or, as an extreme, * you _know_ that most users need the option; it is still wrong to discourage implementors from making choices that are better for the _other_ users. The only legitimate reason for a protocol specification to make a choice is to prevent actual harm, such as an interoperability failure. Example: You may think that there's no good reason for DNS servers to retrieve data from LDAP databases. You may have performance statistics showing that thousands of DNS servers can't possibly tolerate the CPU time or network bandwidth of these LDAP lookups. It's still wrong for you to tell implementors that they ``SHOULD NOT use LDAP''---that they must carefully consider the consequences before using LDAP. That's not your decision to make. Getting back to the example that started this discussion, namely the bandwidth consumed by BIND 8's AXFR glue repetitions: It is wrong to demand that implementors carefully consider the consequences before using the BIND 8 strategy. This would be true even if there were a bunch of sites that cared about this absurdly small bandwidth issue and that insisted on software avoiding the BIND 8 strategy. These decisions don't belong in protocol specifications. ---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 Dec 14 22:56:46 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17691 for ; Sat, 14 Dec 2002 22:56:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18NPo5-000Hcr-00 for namedroppers-data@psg.com; Sat, 14 Dec 2002 19:51:09 -0800 Received: from stoneport.math.uic.edu ([131.193.178.160]) by psg.com with smtp (Exim 3.36 #2) id 18NPo3-000Hcf-00 for namedroppers@ops.ietf.org; Sat, 14 Dec 2002 19:51:07 -0800 Received: (qmail 47318 invoked by uid 1016); 15 Dec 2002 03:51:30 -0000 Date: 15 Dec 2002 03:51:30 -0000 Message-ID: <20021215035130.47317.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: repeating records References: <20021210235711.50719.qmail@cr.yp.to> <200212110124.gBB1OttB046451@drugs.dv.isc.org> 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_02_03 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Mark.Andrews@isc.org writes: > You as a implementor are not in a position to say if a given increase > in traffic is minor or not as you do not have enough details of the > conditions underwhich the transmission is taking place. Of course, Andrews thinks that he's an exception to this rule; that he is in a position to say that BIND 8's AXFR glue repetition is a massive waste of bandwidth; that it was irresponsible of the BIND company to ignore this crucial issue for so many years; that all implementors must carefully consider the consequences before repeating BIND 8's mistake. I'm looking forward to draft-bindcompany-gzip9-00.txt, which says that all DNS software distribution through tar.gz format SHOULD use the -9 option to gzip, and draft-bindcompany-logging-00.txt, which says that all UNIX DNS software SHOULD support logging to files as an efficient alternative to syslog. ---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 Dec 16 09:00:20 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05116 for ; Mon, 16 Dec 2002 09:00:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18NvYJ-000Jj1-00 for namedroppers-data@psg.com; Mon, 16 Dec 2002 05:44:59 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #2) id 18NvYG-000Jip-00 for namedroppers@ops.ietf.org; Mon, 16 Dec 2002 05:44:56 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04595; Mon, 16 Dec 2002 08:41:55 -0500 (EST) Message-Id: <200212161341.IAA04595@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-ipv6-name-auto-reg-00.txt Date: Mon, 16 Dec 2002 08:41:55 -0500 X-Spam-Status: No, hits=4.9 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO, SPAM_PHRASE_00_01,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 Auto-Registration for Plugged-in IPv6 Nodes Author(s) : H. Kitamura Filename : draft-ietf-dnsext-ipv6-name-auto-reg-00.txt Pages : 21 Date : 2002-12-11 This document describes a scheme of 'Domain Name Auto-Registration for Plugged-in IPv6 Nodes' mechanism that makes it possible to register both regular and inverse domain name information of plugged- in IPv6 nodes to DNS servers automatically. Since IPv6 addresses are too long to remember and EUI64-based addresses are too complicated to remember, there are strong requirements to use logical names that are easy to remember instead of IPv6 addresses to specify IPv6 nodes and to register domain name information of plugged-in IPv6 nodes automatically. In order to meet the requirements, a mechanism is proposed as one of the IPv6 auto-configuration (plug and play) functions. After the Address Autoconfiguration [ADDR-AUTO] has been executed, it works as a succeeding plug and play mechanism. This document clarifies problems that we meet when we apply the Dynamic Updates in the DNS [DYN-DNS] to automatic domain name information registration mechanisms. This document describes the Domain Name Auto-Registration mechanism as a solution to these problems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ipv6-name-auto-reg-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-ipv6-name-auto-reg-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-ipv6-name-auto-reg-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: <2002-12-16085818.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-ipv6-name-auto-reg-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-ipv6-name-auto-reg-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-12-16085818.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Dec 16 11:09:35 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09204 for ; Mon, 16 Dec 2002 11:09:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Nxec-000NP2-00 for namedroppers-data@psg.com; Mon, 16 Dec 2002 07:59:38 -0800 Received: from fxshpr08.extra.daimlerchrysler.com ([129.9.80.165] helo=fxshpr06.extra.daimlerchrysler.com) by psg.com with esmtp (Exim 3.36 #2) id 18NxeY-000NOd-00 for namedroppers@ops.ietf.org; Mon, 16 Dec 2002 07:59:35 -0800 Received: (from uucp@localhost) by fxshpr06.extra.daimlerchrysler.com (8.11.4/8.9.0) id gBGFwbL25720 for ; Mon, 16 Dec 2002 10:58:38 -0500 (EST) Received: from nodnsquery(129.9.147.104) by fxshpr08.extra.daimlerchrysler.com via csmap (V6.0) id srcAAAeiaWoY; Mon, 16 Dec 02 10:58:37 -0500 Received: from odmrspr1-pf0.oddc.chrysler.com ([129.9.202.19]) by shconpr2-hme0.shdc.chrysler.com (Mail-Gear 2.0.0 bld 58) with SMTP id M2002121610592707459 for ; Mon, 16 Dec 2002 10:59:27 -0500 Received: from daimlerchrysler.com ([53.231.58.71]) by odmrspr1-pf0.oddc.chrysler.com (8.11.2/8.11.2/daimlerchrysler-relay-1.1-kcd) with ESMTP id gBGFxQT01139 for ; Mon, 16 Dec 2002 10:59:27 -0500 (EST) Message-ID: <3DFDF89F.2090702@daimlerchrysler.com> Date: Mon, 16 Dec 2002 11:00:31 -0500 From: Kevin Darcy User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: repeating records References: <20021210083118.10800.qmail@cr.yp.to> <200212102154.gBALsitB045122@drugs.dv.isc.org> <20021210235711.50719.qmail@cr.yp.to> <20021215031814.42774.qmail@cr.yp.to> In-Reply-To: <20021215031814.42774.qmail@cr.yp.to> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MOZILLA_UA, X_ACCEPT_LANG version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit D. J. Bernstein wrote: >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 > >Greg Hudson writes: > > >>Ideally, an RFC uses SHOULD when the working group feels that an >>analysis of a tradeoff should generally go in one direction >> >> > >No. That violates RFC 2119, section 6. These decisions are _not_ up to >the working group. They are up to the implementors and, ultimately, the >users. > >When speedups actually make a difference for the users, the users notice >and select implementations accordingly. When a tradeoff is good for some >users and bad for others, implementations end up offering a variety of >options, and users end up choosing options accordingly. The free market >does a good job of matching speedups to the users who benefit from them. > >Telling implementors that they ``SHOULD'' choose one option---that they >must carefully consider the consequences before doing anything else---is >naive, misguided, paternalistic, anti-competitive behavior. Even if > > * you think that some users will benefit from the option; or > * you think that some users _need_ the option; or > * you think that _most_ users need the option; or, as an extreme, > * you _know_ that most users need the option; > >it is still wrong to discourage implementors from making choices that >are better for the _other_ users. The only legitimate reason for a >protocol specification to make a choice is to prevent actual harm, such >as an interoperability failure. > >Example: You may think that there's no good reason for DNS servers to >retrieve data from LDAP databases. You may have performance statistics >showing that thousands of DNS servers can't possibly tolerate the CPU >time or network bandwidth of these LDAP lookups. It's still wrong for >you to tell implementors that they ``SHOULD NOT use LDAP''---that they >must carefully consider the consequences before using LDAP. That's not >your decision to make. > >Getting back to the example that started this discussion, namely the >bandwidth consumed by BIND 8's AXFR glue repetitions: It is wrong to >demand that implementors carefully consider the consequences before >using the BIND 8 strategy. This would be true even if there were a bunch >of sites that cared about this absurdly small bandwidth issue and that >insisted on software avoiding the BIND 8 strategy. These decisions don't >belong in protocol specifications. > > > > Dan, Can you suggest less normative verbiage than "carefully consider the consequences"? Carefully considering the consequences is something that good implementors should be doing *anyway*, for *all* aspects of their implementation. So, on that basis, "carefully considering the consequences" isn't even nudging them in a particular direction... - Kevin -- 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 Dec 16 14:03:46 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14528 for ; Mon, 16 Dec 2002 14:03:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18O0Hl-00036E-00 for namedroppers-data@psg.com; Mon, 16 Dec 2002 10:48:13 -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 18O0Hh-000361-00 for namedroppers@ops.ietf.org; Mon, 16 Dec 2002 10:48:10 -0800 Received: from ENGILL.ogud.com (mail.dc.ogud.com [10.20.30.6]) by ogud.com (8.11.6/8.11.6) with ESMTP id gBGIlha41867 for ; Mon, 16 Dec 2002 13:47:43 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <5.1.1.6.2.20021216134649.017410b8@localhost> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Mon, 16 Dec 2002 13:47:23 -0500 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: DNSEXT IETF-55 WG mintues Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=4.6 required=5.0 tests=OPT_IN,RCVD_IN_RFCI,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: **** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk IETF-55 Atlanta DNSEXT WG Minutes Chair: Olafur Gudmundsson ogud@ogud.com Randy Bush (absent) Note takers: Jun-ichiro itojun Hagino Scott Rose Date: 2002/November/19 13:00-14:00 EST (18:00-19:00 UTC) Agenda Bash WG document status RFC editor: Restrict KEY, Roadmap, Obsolete IQuery IESG: AD is secure, AXFR clarify, Unknown Types, DS WG last call complete pending changes: Opcode Discover WG last call: RFC1886bis, DNSSEC Opt-In, TKEY Renewal 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. RFC1886/AAAAbis Vladimir Ksinant presenting RFC 1886 Update: goal: push AAAA to draft standard tests done in July '02 Results: minor changes in 1886 needed Status of draft: 00 in Sept, now -01 in Oct. Now in WG last call - comment now please. dnssec protocol changes opt-in David Blacka 03 to 04: editorial 02 to 03: interaction with wild-cards clarification ad-bit clarification validation process changes made more explicit increases code complexity 2 independent code exists decreased cost in big registries (signing/whatever) way NXDOMAIN works in presence of DS and opt-in how NXDOMAIN change affect application? There was a comment that security section needs stronger language, Clearly list the need for zone transfer protection and risk from zone hijacking of opt-outed delegations. Authors agreed examine if the current text is insufficient . Opt-in issues: Rob Austein opinions about OPT-IN from a study done by Rob and Roy A. - 1. Corner cases are actually DNSSEC issues, not OPT-in specific. 2. DNSSEC pushes a change to the cache algorithm that is considered standard in DNS today. You have to keep things together under query names now in order to build auth chain. Especially when NXT RRs are involved. 3. OPT IN does make the code more complex - resolvers have to be more intelligent now. 4. No workshop experience dealing with OPT-IN. That would be nice, since DS has shown problems. 5. It seems to help large delegation heavy zones, but not resolvers. 6. From a technical (coding) viewpoint: the costs are larger than the benefits. However, higher, operational interests may rule the day. Mark Kosters stated there are 2 independent implementations of opt-in authorative server code. and 2 "independent" implementations of resolver, both done by the same person in two different code bases. There where some discussion on if Opt-in is delaying or enabling the roll-out of DNSSEC. All the speakers stressed the need for some kind of DNSSEC Real Soon Now. DS status Olafur Gudmundsson Implementations: 1 resolver (or 2) 2 server implementation 3 different management tools in development 3 workshops since Yokohama 3 under specified corner cases found - need to specify what child server returns for DS query at apex parent not found - if child is served by the same server as ancestor other than parent - RFC2535 capable caches have problem with DS are there more undiscovered? one more document update to deal with ancestor problem solution: resolver detects this from authority section and asks for delegation information on parent nameservers and then asks them the question. TIME TO DECIDE if DS goes forward, is close. There's no way to determine if all relays are DS capable, does this require flag to state if DNS entity is DS aware? Discussion addressed the problems experienced with DNSSEC failing due to middle boxes that do not understand DNSSEC types or DS processing. Is it acceptable during deployment to not be able to do DNSSEC resolution, or should DNSSEC require "clear path"? The sense of the room was that broken middle-boxes need to be updated and as long as DNSSEC answers are not messing up middle boxes it is acceptable to be only able to do DNSSEC resolution in places where resolvers can talk directly to authorative servers. KS flag in KEY: Olaf Kolkman version 03 of draft. Using a bit in the flags of the KEY record to denote a Key signing key. No protocol value assigned, for user/operator use only. Going to WG last call. Wild-card optimization: Olaf Kolkman assumption: one needs proof for non-existence of a wild-cards the proof is to be supplied in the common case where there is no wild-card in a zone that proof is complicated and somewhat expensive in terms of computational resources and packet size is there a way to signal that there is no wild-card in a zone? proposal: use a bit in the NXT RR's type bitmap to signal non-existence of wild-cards the meaning: there is no wild-card expansion possible of any name in the zone's namespace spanned by a NXT RR simplest algorithm to set the bit turn it on on all NXT RRs in the zone if there are no wild-cards in the zone turn it off on all NXT RRs in the zone if there is any wild-card in the zone pro: shortcut to a simple and fast code path for server and resolver smaller footprint con: bypassed in the common case, the complicated verification code is still needed RR type code without RR backward incompatible current version of doc the suggested algorithm for setting the bit contain an error clarifications are needed what's next update the draft does the working group think this is a sane path dnssec protocol specs need to describe algorithm for denial of authentication of wild-cards if not, resolver implementers will do it wrong no need for more than 2 NXT RRs? if it makes things more complicated, object. There where some questions about savings on the wire (about 150 bytes in the common case). Requires more code, not a lot in resolvers, some in servers, a lot in signers. Take issues to the mailing list. Domain Name Auto Registration for plugged in IPv6 nodes: Hiroshi Kitamura This document is in a need of home for working group review is DNSEXT the right home ? The DNSEXT chairs have suggested advancing the document either as informational or experimental RFC. Authors would like a working group last call for that status. Erik Nordmark commented that he thinks Experimental is a better status for this as it might be promoted to standards track if it becomes widely used. After author updates document chair is to start working group last call. End of meeting. -- 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 Dec 16 14:57:17 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15826 for ; Mon, 16 Dec 2002 14:57:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18O1FQ-0005Uf-00 for namedroppers-data@psg.com; Mon, 16 Dec 2002 11:49:52 -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 18O1FN-0005UT-00 for namedroppers@ops.ietf.org; Mon, 16 Dec 2002 11:49:50 -0800 Received: from ENGILL.ogud.com (mail.dc.ogud.com [10.20.30.6]) by ogud.com (8.11.6/8.11.6) with ESMTP id gBGJnNa41974; Mon, 16 Dec 2002 14:49:23 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <5.1.1.6.2.20021204134414.025498e0@localhost> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Mon, 16 Dec 2002 14:49:24 -0500 To: "D. J. Bernstein" , iesg@ietf.org From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: Re: DNSEXT WGLC Summary: AXFR clarify Cc: namedroppers@ops.ietf.org, ietf@ietf.org In-Reply-To: <20021117174553.55961.qmail@cr.yp.to> References: <5.1.1.6.2.20021113115011.016d7490@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=1.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI,REFERENCES, SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 12:45 2002-11-17, D. J. Bernstein wrote: >Gudmundsson writes: > > DNSEXT has completed it's review of this document and requests that > > it be advanced to Proposed standard. > >Excuse me? When did that happen? The document is highly controversial. >The conclusion of the July meeting was ``Not ready to go: axfr-clarify, >too bind specific.'' There were no subsequent public discussions. Highly controversial is relative term, few individuals do not make a document "controversial". As for the no public discussion that is answered in following email to namedroppers: http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg02116.html Where Randy explains that he had technical doubts if it was unnecessarily overly-definitive document, after off-line technical discussions with me and others he removed his hold. The minutes from Yokohama could be better on what else he said. We both knew your position when we forwarded the document to the area director. >In fact, it's even worse than that: this so-called ``clarification'' is >specific to _BIND 9_. It imposes requirements incompatible with BIND 8, >djbdns, and probably a bunch more widely deployed servers. > >http://cr.yp.to/djbdns/axfr-clarify.html gives detailed explanations of >my ten objections to this document. To summarize: > > * ``Timeline'': This document obviously does not have consensus. This > is the fourth time that Gudmundsson has tried to ram this document > through the process by misrepresenting the WG discussions. With only you objecting to the document and number of members of the working supporting it, how can we as WG chairs draw other conclusion that there is a rough consensus? Anyway the document is being forwarded to the IESG for review and they will issue a IETF last call where you and others that object to the document can restate your case. The following message refutes all your points better than I can http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg01885.html Your understanding of 1034 disagrees with some other implementors. Your understanding of 1034 does make it impossible to implement IXFR. My message to namedroppers was to the point WG agrees this document is a good thing, and that there are some dissenters from the consensus of the WG. Dan, no-one has veto power in the work of the IETF your childish behavior and outbursts do not harm anyone but yourself and the valid technical points you attempt to make. 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 Dec 17 04:13:53 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09998 for ; Tue, 17 Dec 2002 04:13:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18ODY9-0002Lv-00 for namedroppers-data@psg.com; Tue, 17 Dec 2002 00:58:01 -0800 Received: from stoneport.math.uic.edu ([131.193.178.160]) by psg.com with smtp (Exim 3.36 #2) id 18ODY6-0002Lj-00 for namedroppers@ops.ietf.org; Tue, 17 Dec 2002 00:57:58 -0800 Received: (qmail 86384 invoked by uid 1017); 17 Dec 2002 08:58:22 -0000 Date: 17 Dec 2002 08:58:22 -0000 Message-ID: <20021217085822.86383.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: iesg@ietf.org Cc: namedroppers@ops.ietf.org, ietf@ietf.org Subject: Re: DNSEXT WGLC Summary: AXFR clarify References: <5.1.1.6.2.20021113115011.016d7490@localhost> <5.1.1.6.2.20021204134414.025498e0@localhost> 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 DNSEXT chair Olafur Gudmundsson, who has been paid for BIND work, writes: > only you objecting to the document There have been public objections from Aaron Swartz, Felix von Leitner, Len Budney, Kenji Rikitake, Dean Anderson, Sam Trenholme (MaraDNS implementor), and of course me (djbdns implementor)---plus an unknown number of people whose messages to namedroppers have been silently discarded by Randy Bush. Meanwhile, axfr-clarify is being pushed primarily by people with financial interests in BIND. The Yokohama minutes say ``too bind specific'' with no hint of any dispute about that, and the Atlanta minutes don't indicate any further discussion. What's most damning, of course, is the simple fact that the objections are being ignored. http://cr.yp.to/djbdns/axfr-clarify.html explains in detail what's wrong with the BIND company's arguments; the BIND company responds by repeating the arguments and ignoring the objections. ---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 Tue Dec 17 05:00:16 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10589 for ; Tue, 17 Dec 2002 05:00:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18OEPy-0004VR-00 for namedroppers-data@psg.com; Tue, 17 Dec 2002 01:53:38 -0800 Received: from maya40.nic.fr ([192.134.4.151]) by psg.com with esmtp (Exim 3.36 #2) id 18OEPw-0004VE-00 for namedroppers@ops.ietf.org; Tue, 17 Dec 2002 01:53:36 -0800 Received: from vespucci.nic.fr (postfix@vespucci.nic.fr [192.134.4.68]) by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id gBH9rSkS757144; Tue, 17 Dec 2002 10:53:29 +0100 (CET) Received: by vespucci.nic.fr (Postfix, from userid 1000) id 91D5C10FA2; Tue, 17 Dec 2002 10:53:28 +0100 (CET) Date: Tue, 17 Dec 2002 10:53:28 +0100 From: Stephane Bortzmeyer To: "D. J. Bernstein" Cc: iesg@ietf.org, namedroppers@ops.ietf.org, ietf@ietf.org Subject: Re: DNSEXT WGLC Summary: AXFR clarify Message-ID: <20021217095328.GA25961@nic.fr> References: <5.1.1.6.2.20021113115011.016d7490@localhost> <5.1.1.6.2.20021204134414.025498e0@localhost> <20021217085822.86383.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021217085822.86383.qmail@cr.yp.to> User-Agent: Mutt/1.3.28i X-Operating-System: Debian GNU/Linux 3.0 X-Kernel: Linux 2.4.18-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ X-Spam-Status: No, hits=-2.4 required=5.0 tests=IN_REP_TO,NOSPAM_INC,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, Dec 17, 2002 at 08:58:22AM -0000, D. J. Bernstein wrote a message of 26 lines which said: > DNSEXT chair Olafur Gudmundsson, who has been paid for BIND work, writes: For me, this is too much. For those who use procmail: :0 * ^From:.*D. J. Bernstein /dev/null -- 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 Dec 18 14:15:15 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16192 for ; Wed, 18 Dec 2002 14:15:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Oj9x-0000iY-00 for namedroppers-data@psg.com; Wed, 18 Dec 2002 10:43:09 -0800 Received: from [68.49.60.118] (helo=ogud.com) by psg.com with esmtp (Exim 3.36 #2) id 18Oj9u-0000fB-00 for namedroppers@ops.ietf.org; Wed, 18 Dec 2002 10:43:06 -0800 Received: from ENGILL.ogud.com (ns.dc.ogud.com [10.20.30.6]) by ogud.com (8.11.6/8.11.6) with ESMTP id gBIIgtN05736; Wed, 18 Dec 2002 13:42:56 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <5.1.1.6.2.20021218133820.02a95870@localhost> X-Sender: post@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Wed, 18 Dec 2002 13:42:05 -0500 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Delegation signer-12 Cc: Erik Nordmark Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=3.1 required=5.0 tests=RCVD_IN_RFCI,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: *** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Version 12 addresses the ancestor problem, by requiring the resolver to detect this situation and recover by discovering the NS records for the parent. Versions 10 and 11 addressed the issue of return codes from child servers when asked about the DS record. This completes all outstanding issues that have been raised in the working group, I hope the IESG will now process the document. Olafur (DS editor) -- 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 Dec 18 18:49:02 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22270 for ; Wed, 18 Dec 2002 18:49:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Onmp-000GHA-00 for namedroppers-data@psg.com; Wed, 18 Dec 2002 15:39:35 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18Onml-000GGW-00 for namedroppers@ops.ietf.org; Wed, 18 Dec 2002 15:39:31 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18Onmh-0001PP-00 for namedroppers@ops.ietf.org; Wed, 18 Dec 2002 17:39:28 -0600 Message-Id: <200212181810.gBIIA4D09150@gamma.isi.edu> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart To: IETF-Announce: ; Subject: RFC 3445 on Limiting the Scope of the KEY Resource Record (RR) Cc: rfc-editor@rfc-editor.org, namedroppers@ops.ietf.org From: rfc-editor@rfc-editor.org Date: Wed, 18 Dec 2002 10:10:04 -0800 X-Spam-Status: No, hits=2.6 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,RESENT_TO,SPAM_PHRASE_00_01, TO_MALFORMED version=2.43 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3445 Title: Limiting the Scope of the KEY Resource Record (RR) Author(s): D. Massey, S. Rose Status: Standards Track Date: December 2002 Mailbox: masseyd@isi.edu, scott.rose@nist.gov Pages: 10 Characters: 20947 Updates: 2535 I-D Tag: draft-ietf-dnsext-restrict-key-for-dnssec-04.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3445.txt This document limits the Domain Name System (DNS) KEY Resource Record (RR) to only keys used by the Domain Name System Security Extensions (DNSSEC). The original KEY RR used sub-typing to store both DNSSEC keys and arbitrary application keys. Storing both DNSSEC and application keys with the same record type is a mistake. This document removes application keys from the KEY record by redefining the Protocol Octet field in the KEY RR Data. As a result of removing application keys, all but one of the flags in the KEY record become unnecessary and are redefined. Three existing application key sub-types are changed to reserved, but the format of the KEY record is not changed. This document updates RFC 2535. This document is a product of the DNS Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <021218100617.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3445 --OtherAccess Content-Type: Message/External-body; name="rfc3445.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <021218100617.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Dec 18 23:10:19 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28347 for ; Wed, 18 Dec 2002 23:10:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Orj0-00065f-00 for namedroppers-data@psg.com; Wed, 18 Dec 2002 19:51:54 -0800 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.36 #2) id 18Oriu-000641-00 for namedroppers@ops.ietf.org; Wed, 18 Dec 2002 19:51:48 -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 gBJ3phdv044664 for ; Thu, 19 Dec 2002 14:51:45 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200212190351.gBJ3phdv044664@drugs.dv.isc.org> To: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: draft-ietf-dnsext-keyrr-key-signing-flag-04.txt Date: Thu, 19 Dec 2002 14:51:43 +1100 X-Spam-Status: No, hits=1.8 required=5.0 tests=NO_REAL_NAME,SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk There are multiple conflicting definitions of what a KSK is. With the DS record [5] the concept of key-signing and zone-signing keys has been introduced. Key-signing keys are the keys that sign the keyset only. In general, key-signing keys are the keys that are pointed to by DS records and are the first keys to be used when following a chain of trust into the zone. The key-signing keys only sign the KEY RRset at the apex of a zone, zone- signing keys sign all other data in a zone. We propose a flag to distinguish the key- signing key from other keys in the KEY RR set during DNSSEC operations. By setting the KSK flag on a particular key, zone administrators indicate that that key SHOULD be used as the secure entry point for their zone. Therefore zone administrators SHOULD set the bit only for zone keys that are used to sign the KEY RRset and are intended to act as the first link in the chain of trust for their zone. The last sentence should be changed to: Therefore zone administrators SHOULD set the bit only for zone keys that are used to sign the KEY RRset only and are intended to act as the first link in the chain of trust for their zone. to bring the definitions into alignment. There should be a note that if KSK is set on a key that there MUST be other keys without KSK set to sign the rest of the zone's contents as KSK's are restricted to only signing the KEY RRset. 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 Thu Dec 19 02:58:52 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11143 for ; Thu, 19 Dec 2002 02:58:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18OvOO-000LWN-00 for namedroppers-data@psg.com; Wed, 18 Dec 2002 23:46:52 -0800 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.36 #2) id 18OvOL-000LTV-00 for namedroppers@ops.ietf.org; Wed, 18 Dec 2002 23:46:50 -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 gBJ7kbvP020757; Thu, 19 Dec 2002 08:46:37 +0100 Date: Thu, 19 Dec 2002 08:46:37 +0100 From: "Olaf M. Kolkman" To: Mark.Andrews@isc.org Cc: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-keyrr-key-signing-flag-04.txt Message-Id: <20021219084637.7a26ff23.olaf@ripe.net> In-Reply-To: <200212190351.gBJ3phdv044664@drugs.dv.isc.org> References: <200212190351.gBJ3phdv044664@drugs.dv.isc.org> 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=-1.5 required=5.0 tests=IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > There are multiple conflicting definitions of what a KSK is. > Ack, addressed. I will wait for other comments before pushing 05.txt. --Olaf --------------------------------------------| Olaf M. Kolkman | www.ripe.net/disi -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Dec 19 07:54:14 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15320 for ; Thu, 19 Dec 2002 07:54:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Ozzm-0006NW-00 for namedroppers-data@psg.com; Thu, 19 Dec 2002 04:41:46 -0800 Received: from [129.6.50.151] (helo=fs3.antd.nist.gov) by psg.com with esmtp (Exim 3.36 #2) id 18Ozzd-0006Mp-00 for namedroppers@ops.ietf.org; Thu, 19 Dec 2002 04:41:38 -0800 Received: from BARNACLE (barnacle.antd.nist.gov [129.6.55.185]) by fs3.antd.nist.gov (8.11.6/8.11.6) with SMTP id gBJCf8m15849; Thu, 19 Dec 2002 07:41:08 -0500 Message-ID: <006b01c2a75b$e71104f0$b9370681@antd.nist.gov> From: "Scott Rose" To: , References: <200212190351.gBJ3phdv044664@drugs.dv.isc.org> Subject: Re: draft-ietf-dnsext-keyrr-key-signing-flag-04.txt Date: Thu, 19 Dec 2002 07:41:07 -0500 Organization: NIST MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=3.0 required=5.0 tests=NOSPAM_INC,NO_MX_FOR_FROM,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,TO_BE_REMOVED_REPLY,USER_AGENT_OE version=2.43 X-Spam-Level: *** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit If I remember the discussions that brought the KSK draft out: It was never meant to be a protocol relevant bit, but a administrator/human readable bit. The problem found during the workshops was the inability to distinguish between keys just by their fingerprint. So a bit was proposed to signify which KEY RR held the KEY signing key. A conscious decision was made to make this a "human readable only" bit in the flags and not assign any protocol value to it. It would have lead to more complexity for the resolver and the spec that is unnecessary. Not all zones will have KEYs and KSKs and should not be made to have them. A resolver shouldn't care if the KSK bit is one and it is still used to sign the zone. Scott ----- Original Message ----- From: To: Sent: Wednesday, December 18, 2002 10:51 PM Subject: Re: draft-ietf-dnsext-keyrr-key-signing-flag-04.txt > > There are multiple conflicting definitions of what a KSK is. > > With the DS record [5] the concept of key-signing and zone-signing > keys has been introduced. Key-signing keys are the keys that sign > the keyset only. In general, key-signing keys are the keys that are > pointed to by DS records and are the first keys to be used when > following a chain of trust into the zone. The key-signing keys only > sign the KEY RRset at the apex of a zone, zone- signing keys sign all > other data in a zone. We propose a flag to distinguish the key- > signing key from other keys in the KEY RR set during DNSSEC > operations. > > By setting the KSK flag on a particular key, zone administrators > indicate that that key SHOULD be used as the secure entry point for > their zone. Therefore zone administrators SHOULD set the bit only > for zone keys that are used to sign the KEY RRset and are intended to > act as the first link in the chain of trust for their zone. > > The last sentence should be changed to: > > Therefore zone administrators SHOULD set the bit only > for zone keys that are used to sign the KEY RRset only and are intended to > act as the first link in the chain of trust for their zone. > > to bring the definitions into alignment. > > There should be a note that if KSK is set on a key that there > MUST be other keys without KSK set to sign the rest of the zone's > contents as KSK's are restricted to only signing the KEY RRset. > > 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: -- 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 Dec 19 08:53:41 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16134 for ; Thu, 19 Dec 2002 08:53:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18P0yZ-0009CI-00 for namedroppers-data@psg.com; Thu, 19 Dec 2002 05:44:35 -0800 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.36 #2) id 18P0yU-0009Bw-00 for namedroppers@ops.ietf.org; Thu, 19 Dec 2002 05:44:31 -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 gBJDiMdv046416; Fri, 20 Dec 2002 00:44:22 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200212191344.gBJDiMdv046416@drugs.dv.isc.org> To: "Scott Rose" Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: draft-ietf-dnsext-keyrr-key-signing-flag-04.txt In-reply-to: Your message of "Thu, 19 Dec 2002 07:41:07 CDT." <006b01c2a75b$e71104f0$b9370681@antd.nist.gov> Date: Fri, 20 Dec 2002 00:44:22 +1100 X-Spam-Status: No, hits=0.6 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02, TO_BE_REMOVED_REPLY version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > If I remember the discussions that brought the KSK draft out: It was never > meant to be a protocol relevant bit, but a administrator/human readable bit. > The problem found during the workshops was the inability to distinguish > between keys just by their fingerprint. So a bit was proposed to signify > which KEY RR held the KEY signing key. > > A conscious decision was made to make this a "human readable only" bit in > the flags and not assign any protocol value to it. It would have lead to > more complexity for the resolver and the spec that is unnecessary. Not all > zones will have KEYs and KSKs and should not be made to have them. A > resolver shouldn't care if the KSK bit is one and it is still used to sign > the zone. > > Scott The resolver doesn't care. The signer however does. Signing the entire zone with a KSK defeats the purpose of having a KSK. No one is saying that you have to have a KSK but if you have a KSK you need a ZSK (Zone Signing Key) key as well otherwise you have to sign the whole zone with a key that is tagged as KSK but is being used as a ZSK. You should be able to take a zone with multiple keys and just be able to sign it and have everything work. By that I mean KSKs sign just the KEY RRset. The ZSKs sign the entire zone including the KEY RRset. If you don't have a KSK then the zone just gets signed with ZSKs The KSK flag can also be used to seperate out the KSKs, if there are both types of keys, to send to the parent otherwise it defaults to all the keys. Note not all key may want to be sent at key rollover. The KSK flag is being used to identify a key that is being used to perform a certian role. Both humans and software need to look at the flag. While I can sign a zone with a non tagged KSK and a ZSK it's much easier and less error prone to just tag the key and let the software handle it. Mark > ----- Original Message ----- > From: > To: > Sent: Wednesday, December 18, 2002 10:51 PM > Subject: Re: draft-ietf-dnsext-keyrr-key-signing-flag-04.txt > > > > > > There are multiple conflicting definitions of what a KSK is. > > > > With the DS record [5] the concept of key-signing and zone-signing > > keys has been introduced. Key-signing keys are the keys that sign > > the keyset only. In general, key-signing keys are the keys that are > > pointed to by DS records and are the first keys to be used when > > following a chain of trust into the zone. The key-signing keys only > > sign the KEY RRset at the apex of a zone, zone- signing keys sign all > > other data in a zone. We propose a flag to distinguish the key- > > signing key from other keys in the KEY RR set during DNSSEC > > operations. > > > > By setting the KSK flag on a particular key, zone administrators > > indicate that that key SHOULD be used as the secure entry point for > > their zone. Therefore zone administrators SHOULD set the bit only > > for zone keys that are used to sign the KEY RRset and are intended to > > act as the first link in the chain of trust for their zone. > > > > The last sentence should be changed to: > > > > Therefore zone administrators SHOULD set the bit only > > for zone keys that are used to sign the KEY RRset only and are intended > to > > act as the first link in the chain of trust for their zone. > > > > to bring the definitions into alignment. > > > > There should be a note that if KSK is set on a key that there > > MUST be other keys without KSK set to sign the rest of the zone's > > contents as KSK's are restricted to only signing the KEY RRset. > > > > 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: > -- 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 Thu Dec 19 09:38:16 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16933 for ; Thu, 19 Dec 2002 09:38:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18P1iH-000BIx-00 for namedroppers-data@psg.com; Thu, 19 Dec 2002 06:31:49 -0800 Received: from [129.6.16.93] (helo=postmark.nist.gov) by psg.com with esmtp (Exim 3.36 #2) id 18P1i9-000BHX-00 for namedroppers@ops.ietf.org; Thu, 19 Dec 2002 06:31:41 -0800 Received: from P612389 (gorilla.antd.nist.gov [129.6.55.20]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id gBJEUpA8003600; Thu, 19 Dec 2002 09:30:51 -0500 (EST) Message-ID: <001f01c2a76b$30ac6960$14370681@P612389> From: "Scott Rose" To: , References: <200212191344.gBJDiMdv046416@drugs.dv.isc.org> Subject: Re: draft-ietf-dnsext-keyrr-key-signing-flag-04.txt Date: Thu, 19 Dec 2002 09:30:33 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=2.9 required=5.0 tests=NO_MX_FOR_FROM,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_01_02,TO_BE_REMOVED_REPLY,USER_AGENT_OE version=2.43 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I think we're in agreement here. The KSK is for the admin and signer software and not for the resolver or server. The KSK has no protocol value, only some operational value to help differentiate it from any ZSKs in the zone. Though technically, a key with the KSK bit set could be used as a ZSK, and the only KEY in the zone. It is silly to do that, but for the protocol, it should be acceptable. I don't think there should be language in the spec saying that if a KEY RR has the KSK bit set, there MUST be another ZSK in the zone. It should only have a software/admin meaning, not a protocol meaning. The main thing I am against is assigning a more stringent (i.e. RFC2119) meaning to the bit. Scott ----- Original Message ----- From: To: "Scott Rose" Cc: Sent: Thursday, December 19, 2002 8:44 AM Subject: Re: draft-ietf-dnsext-keyrr-key-signing-flag-04.txt > > > If I remember the discussions that brought the KSK draft out: It was never > > meant to be a protocol relevant bit, but a administrator/human readable bit. > > The problem found during the workshops was the inability to distinguish > > between keys just by their fingerprint. So a bit was proposed to signify > > which KEY RR held the KEY signing key. > > > > A conscious decision was made to make this a "human readable only" bit in > > the flags and not assign any protocol value to it. It would have lead to > > more complexity for the resolver and the spec that is unnecessary. Not all > > zones will have KEYs and KSKs and should not be made to have them. A > > resolver shouldn't care if the KSK bit is one and it is still used to sign > > the zone. > > > > Scott > > The resolver doesn't care. The signer however does. Signing > the entire zone with a KSK defeats the purpose of having a > KSK. No one is saying that you have to have a KSK but if > you have a KSK you need a ZSK (Zone Signing Key) > key as well otherwise you have to sign the whole zone with > a key that is tagged as KSK but is being used as a ZSK. > > You should be able to take a zone with multiple keys and > just be able to sign it and have everything work. By that > I mean KSKs sign just the KEY RRset. The ZSKs sign the > entire zone including the KEY RRset. If you don't have > a KSK then the zone just gets signed with ZSKs > > The KSK flag can also be used to seperate out the KSKs, > if there are both types of keys, to send to the parent > otherwise it defaults to all the keys. Note not all key > may want to be sent at key rollover. > > The KSK flag is being used to identify a key that is being > used to perform a certian role. Both humans and software > need to look at the flag. While I can sign a zone with a > non tagged KSK and a ZSK it's much easier and less error > prone to just tag the key and let the software handle it. > > Mark > > > > ----- Original Message ----- > > From: > > To: > > Sent: Wednesday, December 18, 2002 10:51 PM > > Subject: Re: draft-ietf-dnsext-keyrr-key-signing-flag-04.txt > > > > > > > > > > There are multiple conflicting definitions of what a KSK is. > > > > > > With the DS record [5] the concept of key-signing and zone-signing > > > keys has been introduced. Key-signing keys are the keys that sign > > > the keyset only. In general, key-signing keys are the keys that are > > > pointed to by DS records and are the first keys to be used when > > > following a chain of trust into the zone. The key-signing keys only > > > sign the KEY RRset at the apex of a zone, zone- signing keys sign all > > > other data in a zone. We propose a flag to distinguish the key- > > > signing key from other keys in the KEY RR set during DNSSEC > > > operations. > > > > > > By setting the KSK flag on a particular key, zone administrators > > > indicate that that key SHOULD be used as the secure entry point for > > > their zone. Therefore zone administrators SHOULD set the bit only > > > for zone keys that are used to sign the KEY RRset and are intended to > > > act as the first link in the chain of trust for their zone. > > > > > > The last sentence should be changed to: > > > > > > Therefore zone administrators SHOULD set the bit only > > > for zone keys that are used to sign the KEY RRset only and are intended > > to > > > act as the first link in the chain of trust for their zone. > > > > > > to bring the definitions into alignment. > > > > > > There should be a note that if KSK is set on a key that there > > > MUST be other keys without KSK set to sign the rest of the zone's > > > contents as KSK's are restricted to only signing the KEY RRset. > > > > > > 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: > > > -- > 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 Thu Dec 19 10:10:50 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17622 for ; Thu, 19 Dec 2002 10:10:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18P2EL-000Cqz-00 for namedroppers-data@psg.com; Thu, 19 Dec 2002 07:04:57 -0800 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.36 #2) id 18P2EG-000CoU-00 for namedroppers@ops.ietf.org; Thu, 19 Dec 2002 07:04:52 -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 gBJF4DvP031908; Thu, 19 Dec 2002 16:04:13 +0100 Date: Thu, 19 Dec 2002 16:04:13 +0100 From: "Olaf M. Kolkman" To: "Scott Rose" Cc: Mark.Andrews@isc.org, namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-keyrr-key-signing-flag-04.txt Message-Id: <20021219160413.43d26b9c.olaf@ripe.net> In-Reply-To: <001f01c2a76b$30ac6960$14370681@P612389> References: <200212191344.gBJDiMdv046416@drugs.dv.isc.org> <001f01c2a76b$30ac6960$14370681@P612389> 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=-3.0 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT, REFERENCES,SPAM_PHRASE_01_02,TO_BE_REMOVED_REPLY version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Does this text address both your concern? It uses SHOULD instead of MUST.
By setting the KSK flag on a particular key, zone administrators indicate that that key SHOULD be used as the secure entry point for their zone. Therefore zone administrators SHOULD set the bit only for zone keys that are used to sign the KEY RR set only and are intended to act as the first link in the chain of trust for their zone. If KSK is set on any KEY in the apex KEY RR set, there SHOULD be other keys without KSK set to sign the rest of the zone's contents as key signing keys are restricted to only signing the KEY RR set. --Olaf On Thu, 19 Dec 2002 09:30:33 -0500 "Scott Rose" wrote: > I think we're in agreement here. The KSK is for the admin and signer > software and not for the resolver or server. The KSK has no protocol value, > only some operational value to help differentiate it from any ZSKs in the > zone. > > Though technically, a key with the KSK bit set could be used as a ZSK, and > the only KEY in the zone. It is silly to do that, but for the protocol, it > should be acceptable. I don't think there should be language in the spec > saying that if a KEY RR has the KSK bit set, there MUST be another ZSK in > the zone. It should only have a software/admin meaning, not a protocol > meaning. > > The main thing I am against is assigning a more stringent (i.e. RFC2119) > meaning to the bit. > Scott > > > ----- Original Message ----- > From: > To: "Scott Rose" > Cc: > Sent: Thursday, December 19, 2002 8:44 AM > Subject: Re: draft-ietf-dnsext-keyrr-key-signing-flag-04.txt > > > > > > > If I remember the discussions that brought the KSK draft out: It was > never > > > meant to be a protocol relevant bit, but a administrator/human readable > bit. > > > The problem found during the workshops was the inability to distinguish > > > between keys just by their fingerprint. So a bit was proposed to > signify > > > which KEY RR held the KEY signing key. > > > > > > A conscious decision was made to make this a "human readable only" bit > in > > > the flags and not assign any protocol value to it. It would have lead > to > > > more complexity for the resolver and the spec that is unnecessary. Not > all > > > zones will have KEYs and KSKs and should not be made to have them. A > > > resolver shouldn't care if the KSK bit is one and it is still used to > sign > > > the zone. > > > > > > Scott > > > > The resolver doesn't care. The signer however does. Signing > > the entire zone with a KSK defeats the purpose of having a > > KSK. No one is saying that you have to have a KSK but if > > you have a KSK you need a ZSK (Zone Signing Key) > > key as well otherwise you have to sign the whole zone with > > a key that is tagged as KSK but is being used as a ZSK. > > > > You should be able to take a zone with multiple keys and > > just be able to sign it and have everything work. By that > > I mean KSKs sign just the KEY RRset. The ZSKs sign the > > entire zone including the KEY RRset. If you don't have > > a KSK then the zone just gets signed with ZSKs > > > > The KSK flag can also be used to seperate out the KSKs, > > if there are both types of keys, to send to the parent > > otherwise it defaults to all the keys. Note not all key > > may want to be sent at key rollover. > > > > The KSK flag is being used to identify a key that is being > > used to perform a certian role. Both humans and software > > need to look at the flag. While I can sign a zone with a > > non tagged KSK and a ZSK it's much easier and less error > > prone to just tag the key and let the software handle it. > > > > Mark > > > > > > > ----- Original Message ----- > > > From: > > > To: > > > Sent: Wednesday, December 18, 2002 10:51 PM > > > Subject: Re: draft-ietf-dnsext-keyrr-key-signing-flag-04.txt > > > > > > > > > > > > > > There are multiple conflicting definitions of what a KSK is. > > > > > > > > With the DS record [5] the concept of key-signing and zone-signing > > > > keys has been introduced. Key-signing keys are the keys that sign > > > > the keyset only. In general, key-signing keys are the keys that > are > > > > pointed to by DS records and are the first keys to be used when > > > > following a chain of trust into the zone. The key-signing keys > only > > > > sign the KEY RRset at the apex of a zone, zone- signing keys sign > all > > > > other data in a zone. We propose a flag to distinguish the key- > > > > signing key from other keys in the KEY RR set during DNSSEC > > > > operations. > > > > > > > > By setting the KSK flag on a particular key, zone administrators > > > > indicate that that key SHOULD be used as the secure entry point for > > > > their zone. Therefore zone administrators SHOULD set the bit only > > > > for zone keys that are used to sign the KEY RRset and are intended > to > > > > act as the first link in the chain of trust for their zone. > > > > > > > > The last sentence should be changed to: > > > > > > > > Therefore zone administrators SHOULD set the bit only > > > > for zone keys that are used to sign the KEY RRset only and are > intended > > > to > > > > act as the first link in the chain of trust for their zone. > > > > > > > > to bring the definitions into alignment. > > > > > > > > There should be a note that if KSK is set on a key that there > > > > MUST be other keys without KSK set to sign the rest of the zone's > > > > contents as KSK's are restricted to only signing the KEY RRset. > > > > > > > > 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: > > > > > -- > > 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: > --------------------------------------------| 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 Thu Dec 19 12:50:30 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21419 for ; Thu, 19 Dec 2002 12:50:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18P4cU-000KOc-00 for namedroppers-data@psg.com; Thu, 19 Dec 2002 09:38:02 -0800 Received: from [129.6.16.93] (helo=postmark.nist.gov) by psg.com with esmtp (Exim 3.36 #2) id 18P4bx-000KJx-00 for namedroppers@ops.ietf.org; Thu, 19 Dec 2002 09:37:29 -0800 Received: from P612389 (gorilla.antd.nist.gov [129.6.55.20]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id gBJHaPA8002302; Thu, 19 Dec 2002 12:36:25 -0500 (EST) Message-ID: <004801c2a785$1c62c840$14370681@P612389> From: "Scott Rose" To: "Olaf M. Kolkman" Cc: References: <200212191344.gBJDiMdv046416@drugs.dv.isc.org><001f01c2a76b$30ac6960$14370681@P612389> <20021219160413.43d26b9c.olaf@ripe.net> Subject: Re: draft-ietf-dnsext-keyrr-key-signing-flag-04.txt Date: Thu, 19 Dec 2002 12:36:06 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=2.9 required=5.0 tests=NO_MX_FOR_FROM,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_01_02,TO_BE_REMOVED_REPLY,USER_AGENT_OE version=2.43 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This sounds like a good section to add. I think it addresses the concerns without calling for a spec change. Scott ----- Original Message ----- From: "Olaf M. Kolkman" To: "Scott Rose" Cc: ; Sent: Thursday, December 19, 2002 10:04 AM Subject: Re: draft-ietf-dnsext-keyrr-key-signing-flag-04.txt > > > > Does this text address both your concern? It uses SHOULD instead of MUST. > >
> > > By setting the KSK flag on a particular key, zone administrators > indicate that that key SHOULD be used as the secure entry point for > their zone. Therefore zone administrators SHOULD set the bit only for > zone keys that are used to sign the KEY RR set only and are intended > to act as the first link in the chain of trust for their zone. If KSK > is set on any KEY in the apex KEY RR set, there SHOULD be other keys > without KSK set to sign the rest of the zone's contents as key signing > keys are restricted to only signing the KEY RR set. > > > > --Olaf > > > > On Thu, 19 Dec 2002 09:30:33 -0500 > "Scott Rose" wrote: > > > I think we're in agreement here. The KSK is for the admin and signer > > software and not for the resolver or server. The KSK has no protocol value, > > only some operational value to help differentiate it from any ZSKs in the > > zone. > > > > Though technically, a key with the KSK bit set could be used as a ZSK, and > > the only KEY in the zone. It is silly to do that, but for the protocol, it > > should be acceptable. I don't think there should be language in the spec > > saying that if a KEY RR has the KSK bit set, there MUST be another ZSK in > > the zone. It should only have a software/admin meaning, not a protocol > > meaning. > > > > The main thing I am against is assigning a more stringent (i.e. RFC2119) > > meaning to the bit. > > Scott > > > > > > ----- Original Message ----- > > From: > > To: "Scott Rose" > > Cc: > > Sent: Thursday, December 19, 2002 8:44 AM > > Subject: Re: draft-ietf-dnsext-keyrr-key-signing-flag-04.txt > > > > > > > > > > > If I remember the discussions that brought the KSK draft out: It was > > never > > > > meant to be a protocol relevant bit, but a administrator/human readable > > bit. > > > > The problem found during the workshops was the inability to distinguish > > > > between keys just by their fingerprint. So a bit was proposed to > > signify > > > > which KEY RR held the KEY signing key. > > > > > > > > A conscious decision was made to make this a "human readable only" bit > > in > > > > the flags and not assign any protocol value to it. It would have lead > > to > > > > more complexity for the resolver and the spec that is unnecessary. Not > > all > > > > zones will have KEYs and KSKs and should not be made to have them. A > > > > resolver shouldn't care if the KSK bit is one and it is still used to > > sign > > > > the zone. > > > > > > > > Scott > > > > > > The resolver doesn't care. The signer however does. Signing > > > the entire zone with a KSK defeats the purpose of having a > > > KSK. No one is saying that you have to have a KSK but if > > > you have a KSK you need a ZSK (Zone Signing Key) > > > key as well otherwise you have to sign the whole zone with > > > a key that is tagged as KSK but is being used as a ZSK. > > > > > > You should be able to take a zone with multiple keys and > > > just be able to sign it and have everything work. By that > > > I mean KSKs sign just the KEY RRset. The ZSKs sign the > > > entire zone including the KEY RRset. If you don't have > > > a KSK then the zone just gets signed with ZSKs > > > > > > The KSK flag can also be used to seperate out the KSKs, > > > if there are both types of keys, to send to the parent > > > otherwise it defaults to all the keys. Note not all key > > > may want to be sent at key rollover. > > > > > > The KSK flag is being used to identify a key that is being > > > used to perform a certian role. Both humans and software > > > need to look at the flag. While I can sign a zone with a > > > non tagged KSK and a ZSK it's much easier and less error > > > prone to just tag the key and let the software handle it. > > > > > > Mark > > > > > > > > > > ----- Original Message ----- > > > > From: > > > > To: > > > > Sent: Wednesday, December 18, 2002 10:51 PM > > > > Subject: Re: draft-ietf-dnsext-keyrr-key-signing-flag-04.txt > > > > > > > > > > > > > > > > > > There are multiple conflicting definitions of what a KSK is. > > > > > > > > > > With the DS record [5] the concept of key-signing and zone-signing > > > > > keys has been introduced. Key-signing keys are the keys that sign > > > > > the keyset only. In general, key-signing keys are the keys that > > are > > > > > pointed to by DS records and are the first keys to be used when > > > > > following a chain of trust into the zone. The key-signing keys > > only > > > > > sign the KEY RRset at the apex of a zone, zone- signing keys sign > > all > > > > > other data in a zone. We propose a flag to distinguish the key- > > > > > signing key from other keys in the KEY RR set during DNSSEC > > > > > operations. > > > > > > > > > > By setting the KSK flag on a particular key, zone administrators > > > > > indicate that that key SHOULD be used as the secure entry point for > > > > > their zone. Therefore zone administrators SHOULD set the bit only > > > > > for zone keys that are used to sign the KEY RRset and are intended > > to > > > > > act as the first link in the chain of trust for their zone. > > > > > > > > > > The last sentence should be changed to: > > > > > > > > > > Therefore zone administrators SHOULD set the bit only > > > > > for zone keys that are used to sign the KEY RRset only and are > > intended > > > > to > > > > > act as the first link in the chain of trust for their zone. > > > > > > > > > > to bring the definitions into alignment. > > > > > > > > > > There should be a note that if KSK is set on a key that there > > > > > MUST be other keys without KSK set to sign the rest of the zone's > > > > > contents as KSK's are restricted to only signing the KEY RRset. > > > > > > > > > > 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: > > > > > > > -- > > > 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: > > > > > > --------------------------------------------| 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 Thu Dec 19 13:17:14 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22098 for ; Thu, 19 Dec 2002 13:17:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18P54v-000M9b-00 for namedroppers-data@psg.com; Thu, 19 Dec 2002 10:07:25 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18P54r-000M6W-00 for namedroppers@ops.ietf.org; Thu, 19 Dec 2002 10:07:21 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18P54L-0001ao-00; Thu, 19 Dec 2002 12:06:50 -0600 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Scott Rose" Cc: Subject: Re: draft-ietf-dnsext-keyrr-key-signing-flag-04.txt References: <200212190351.gBJ3phdv044664@drugs.dv.isc.org> <006b01c2a75b$e71104f0$b9370681@antd.nist.gov> Message-Id: Date: Thu, 19 Dec 2002 12:06:50 -0600 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 Content-Transfer-Encoding: 7bit > If I remember the discussions that brought the KSK draft out: It was never > meant to be a protocol relevant bit, but a administrator/human readable bit. > The problem found during the workshops was the inability to distinguish > between keys just by their fingerprint. So a bit was proposed to signify > which KEY RR held the KEY signing key. exactly > A conscious decision was made to make this a "human readable only" bit in > the flags and not assign any protocol value to it. thank you 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 Sat Dec 21 13:38:18 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10104 for ; Sat, 21 Dec 2002 13:38:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18PoGi-0006un-00 for namedroppers-data@psg.com; Sat, 21 Dec 2002 10:22:36 -0800 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #2) id 18PoGg-0006uV-00 for namedroppers@ops.ietf.org; Sat, 21 Dec 2002 10:22:34 -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 gBLIMSYm008613; Sat, 21 Dec 2002 13:22:28 -0500 (EST) Received: from [66.44.89.139] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id NAA25196; Sat, 21 Dec 2002 13:22:23 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 (Unverified) Message-Id: In-Reply-To: <5.1.1.6.2.20021218133820.02a95870@localhost> References: <5.1.1.6.2.20021218133820.02a95870@localhost> Date: Fri, 20 Dec 2002 21:07:56 -0500 To: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_?= =?iso-8859-1?Q?Gu=F0mundsson?= , namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: Delegation signer-12 Cc: Erik Nordmark Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" X-Spam-Status: No, hits=1.1 required=5.0 tests=DATE_IN_PAST_12_24,IN_REP_TO,MIME_LONG_LINE_QP, RCVD_IN_OSIRUSOFT_COM,REFERENCES,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,TO_BE_REMOVED_REPLY,X_OSIRU_DUL version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA10104 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 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. At 13:42 -0500 12/18/02, Ólafur Guðmundsson wrote: > > >Version 12 addresses the ancestor problem, by requiring the resolver to >detect this situation and recover by discovering the NS records for >the parent. >Versions 10 and 11 addressed the issue of return codes from child servers >when asked about the DS record. > >This completes all outstanding issues that have been raised in the working >group, I hope the IESG will now process the document. > > Olafur (DS editor) > > > >-- >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: From owner-namedroppers@ops.ietf.org Sat Dec 21 13:39:55 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10145 for ; Sat, 21 Dec 2002 13:39:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18PoGP-0006uH-00 for namedroppers-data@psg.com; Sat, 21 Dec 2002 10:22:17 -0800 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #2) id 18PoGM-0006ty-00 for namedroppers@ops.ietf.org; Sat, 21 Dec 2002 10:22:14 -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 gBLIMBYm008590; Sat, 21 Dec 2002 13:22:11 -0500 (EST) Received: from [66.44.89.139] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id NAA25174; Sat, 21 Dec 2002 13:22:09 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 (Unverified) Message-Id: In-Reply-To: <200212191344.gBJDiMdv046416@drugs.dv.isc.org> References: <200212191344.gBJDiMdv046416@drugs.dv.isc.org> Date: Fri, 20 Dec 2002 18:08:29 -0500 To: Mark.Andrews@isc.org, "Scott Rose" From: Edward Lewis Subject: Re: draft-ietf-dnsext-keyrr-key-signing-flag-04.txt Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=0.7 required=5.0 tests=DATE_IN_PAST_12_24,IN_REP_TO,RCVD_IN_OSIRUSOFT_COM, REFERENCES,SIGNATURE_SHORT_DENSE,SPAM_PHRASE_03_05, X_OSIRU_DUL version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 0:44 +1100 12/20/02, Mark.Andrews@isc.org wrote: > The resolver doesn't care. The signer however does. Signing > the entire zone with a KSK defeats the purpose of having a > KSK. No one is saying that you have to have a KSK but if > you have a KSK you need a ZSK (Zone Signing Key) > key as well otherwise you have to sign the whole zone with > a key that is tagged as KSK but is being used as a ZSK. Agggh NO!!! Agggh NO!!! Agggh NO!!! (But I say it with love.) In the verifier, the bit must be ignored. In the signer, the bit must only be used to prepare the key for exposure to the parent for DS RR processing. (Note: I do not mean the signer must use the bit to prepare the key for sending to the parent. I mean that the signer, if the implementation chooses to do so at all, must *only* use the bit for that purpose.) In the key generator, the bit can be set. In "whatever-generates the DS RR from the KEY RR" may read the bit to determine that this is a key for which a DS is desired. As for why "Agggh NO!!": what if the child zone has just one key? That key is both the KSK (needs DS) and ZSK. Another reason to not do this: Please don't repeat the mistake of the A/C bits of the 2535 flags field - the "authentication prohibited" and "confidentiality prohibited" goof ups. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Sun Dec 22 17:14:33 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06535 for ; Sun, 22 Dec 2002 17:14:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18QDvI-00062k-00 for namedroppers-data@psg.com; Sun, 22 Dec 2002 13:46:12 -0800 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.36 #2) id 18QDvE-00062J-00 for namedroppers@ops.ietf.org; Sun, 22 Dec 2002 13:46:08 -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 gBMLjedv059266; Mon, 23 Dec 2002 08:45:42 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200212222145.gBMLjedv059266@drugs.dv.isc.org> To: Edward Lewis Cc: "Scott Rose" , namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: draft-ietf-dnsext-keyrr-key-signing-flag-04.txt In-reply-to: Your message of "Fri, 20 Dec 2002 18:08:29 CDT." Date: Mon, 23 Dec 2002 08:45:40 +1100 X-Spam-Status: No, hits=0.8 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_03_05 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > At 0:44 +1100 12/20/02, Mark.Andrews@isc.org wrote: > > The resolver doesn't care. The signer however does. Signing > > the entire zone with a KSK defeats the purpose of having a > > KSK. No one is saying that you have to have a KSK but if > > you have a KSK you need a ZSK (Zone Signing Key) > > key as well otherwise you have to sign the whole zone with > > a key that is tagged as KSK but is being used as a ZSK. > > Agggh NO!!! > Agggh NO!!! > Agggh NO!!! > > (But I say it with love.) > > In the verifier, the bit must be ignored. > > In the signer, the bit must only be used to prepare the key for > exposure to the parent for DS RR processing. (Note: I do not mean > the signer must use the bit to prepare the key for sending to the > parent. I mean that the signer, if the implementation chooses to do > so at all, must *only* use the bit for that purpose.) > > In the key generator, the bit can be set. > > In "whatever-generates the DS RR from the KEY RR" may read the bit to > determine that this is a key for which a DS is desired. > > As for why "Agggh NO!!": what if the child zone has just one key? > That key is both the KSK (needs DS) and ZSK. Then you don't set KSK in the first place or you tell the signer to ignore the KSK and use the key to sign all the data sets. A KSK key is by definition a KEY that *only* signs the zone key. There is no benefit in a KSK if a KSK signs the entire zone. > Another reason to not do this: Please don't repeat the mistake of the > A/C bits of the 2535 flags field - the "authentication prohibited" > and "confidentiality prohibited" goof ups. This a flag to tell the signer what to do. It is NOT enforced by the resolver. > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-703-227-9854 > ARIN Research Engineer > -- 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 Mon Dec 23 09:33:47 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03755 for ; Mon, 23 Dec 2002 09:33:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18QTUf-0006Ck-00 for namedroppers-data@psg.com; Mon, 23 Dec 2002 06:23:45 -0800 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #2) id 18QTUa-0006CO-00 for namedroppers@ops.ietf.org; Mon, 23 Dec 2002 06:23:41 -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 gBNENaYm026002; Mon, 23 Dec 2002 09:23:36 -0500 (EST) Received: from [66.44.89.139] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id JAA22718; Mon, 23 Dec 2002 09:23:35 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <200212222145.gBMLjedv059266@drugs.dv.isc.org> References: <200212222145.gBMLjedv059266@drugs.dv.isc.org> Date: Mon, 23 Dec 2002 09:08:02 -0500 To: Mark.Andrews@isc.org, Edward Lewis From: Edward Lewis Subject: Re: draft-ietf-dnsext-keyrr-key-signing-flag-04.txt Cc: "Scott Rose" , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=1.6 required=5.0 tests=FROM_AND_TO_SAME_6,IN_REP_TO,RCVD_IN_OSIRUSOFT_COM, REFERENCES,SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01, X_OSIRU_DUL version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 8:45 +1100 12/23/02, Mark.Andrews@isc.org wrote: > There is no benefit in a KSK if a KSK signs the entire zone. The topic here isn't a "KSK" but a "bit to indicate that this is intended to be a key-signing key." I've not been persuaded to make a formal distinction between a ZSK and KSK within the protocol. I have been persuaded to indicate the intent of the key manager to use a key as "one that is to be referenced by a DS RR." From discussions held over the past year, the sentiment has been that this bit is intended to help applications differentiate on key management and to help the manual process of key management. The bit is not intended as a in-protocol policy tool. I.e., as far as the in-band protocol is concerned, the distinction between KSK and ZSK is not made. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Dec 23 16:17:02 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15425 for ; Mon, 23 Dec 2002 16:17:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18QZnw-000PmF-00 for namedroppers-data@psg.com; Mon, 23 Dec 2002 13:08:04 -0800 Received: from boreas.isi.edu ([128.9.160.161]) by psg.com with esmtp (Exim 3.36 #2) id 18QZnu-000Pm0-00 for namedroppers@ops.ietf.org; Mon, 23 Dec 2002 13:08:02 -0800 Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6/8.11.2) id gBNL7xc13012; Mon, 23 Dec 2002 13:07:59 -0800 (PST) From: Bill Manning Message-Id: <200212232107.gBNL7xc13012@boreas.isi.edu> Subject: Re: DNSEXT WGLC Summary: Opcode-discover-00 In-Reply-To: <5.1.1.6.2.20021113121657.01be1e20@localhost> from =?ISO-8859-1?Q?=D3lafur_Gudmundsson=2FDNSEXT_co=2Dchair?= at "Nov 13, 2 12:33:40 pm" To: ogud@ogud.com (=?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair) Date: Mon, 23 Dec 2002 13:07:59 -0800 (PST) Cc: 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=0.1 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_01_02,TO_BE_REMOVED_REPLY version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit % % This working group last call has concluded. % This work meets the technical criteria to be to be published as EXPERIMENTAL. % % Authors are requested to make the following changes before the document % is advanced to the IESG. % % 0. Number all sections that have titles. % 1. In the last paragraph before IANA consideration: % Add a comment that a responder to DISCOVER, in some cases is not a % traditional DNS server, it could be a special purpose software. % 2. References section needs to be broken into two "Normative References" % and "Informational References", please fill out references fully. % % Olafur % % % >This starts a 2 week last call for this document, the document is % >slated to be published as EXPERIMENTAL. % > % >http://www.ietf.org/internet-drafts/draft-dnsext-opcode-discover-00.txt % > % >This document specifies a new opcode that is used to discover DNS servers % >within the multicast scope of the address sent to. % > % >The authors main focus is to get a IANA assigned opcode for experimentation, % >does this document provide enough technical details for the framework to be % >experimented with. % > % >This working group last call completes on August 30'th 2002. % > % > 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: % A revised version of this document, addressing the three points listed above, has been resent to the ID maintainer. It should hit the archives soon. If you would like a copy prior to its appearance in the ID repository, please let me know. --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 Tue Dec 24 08:40:42 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07288 for ; Tue, 24 Dec 2002 08:40:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Qp6D-000JLG-00 for namedroppers-data@psg.com; Tue, 24 Dec 2002 05:27:57 -0800 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.36 #2) id 18Qp69-000JJq-00 for namedroppers@ops.ietf.org; Tue, 24 Dec 2002 05:27:53 -0800 Received: from ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.5/8.11.6) with ESMTP id gBODRcvP028433; Tue, 24 Dec 2002 14:27:38 +0100 Message-Id: <200212241327.gBODRcvP028433@birch.ripe.net> To: Edward Lewis cc: Mark.Andrews@isc.org, "Scott Rose" , namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-keyrr-key-signing-flag-04.txt In-Reply-To: Message from Edward Lewis of "Fri, 20 Dec 2002 18:08:29 EST." Date: Tue, 24 Dec 2002 14:27:38 +0100 From: Olaf Kolkman 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 * In the signer, the bit must only be used to prepare the key for * exposure to the parent for DS RR processing. (Note: I do not mean * the signer must use the bit to prepare the key for sending to the * parent. I mean that the signer, if the implementation chooses to do * so at all, must *only* use the bit for that purpose.) Bind's dnssec-signzone now uses -k to indicate which keysigning keys. I would love to see the bit used so that do not need to be specified and the -k flag (or whatever letter you want to assign) only is sufficient. As a result of using the flag you would have your pre-prepared keysets, epp encapulation or registry form as output... but that is up to the implementor and it's clients. The draft does specifically say that the bit does NOT modify the protocol and MUST NOT be used during verification. * In the key generator, the bit can be set. That would be handy :-). --Olaf -- 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 Dec 24 09:35:49 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08094 for ; Tue, 24 Dec 2002 09:35:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Qq2x-000MGY-00 for namedroppers-data@psg.com; Tue, 24 Dec 2002 06:28:39 -0800 Received: from [129.6.16.93] (helo=postmark.nist.gov) by psg.com with esmtp (Exim 3.36 #2) id 18Qq2q-000ME7-00 for namedroppers@ops.ietf.org; Tue, 24 Dec 2002 06:28:32 -0800 Received: from P612389 (asynce054.nist.gov [129.6.31.54]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id gBOERnA8017008; Tue, 24 Dec 2002 09:27:50 -0500 (EST) Message-ID: <000001c2ab56$0f207e00$361f0681@P612389> From: "Scott Rose" To: "Edward Lewis" , Cc: References: <200212222145.gBMLjedv059266@drugs.dv.isc.org> Subject: Re: draft-ietf-dnsext-keyrr-key-signing-flag-04.txt Date: Mon, 23 Dec 2002 09:12:58 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=3.8 required=5.0 tests=DATE_IN_PAST_24_48,NO_MX_FOR_FROM,QUOTED_EMAIL_TEXT, REFERENCES,SPAM_PHRASE_00_01,USER_AGENT_OE version=2.43 X-Spam-Level: *** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > > > In "whatever-generates the DS RR from the KEY RR" may read the bit to > > determine that this is a key for which a DS is desired. > > > > As for why "Agggh NO!!": what if the child zone has just one key? > > That key is both the KSK (needs DS) and ZSK. > > Then you don't set KSK in the first place or you tell the > signer to ignore the KSK and use the key to sign all the > data sets. > > A KSK key is by definition a KEY that *only* signs the zone > key. > > There is no benefit in a KSK if a KSK signs the entire zone. > Correct, but if the admin is stupid enough to sign a zone with a KSK, and not include a zone key (ie. the zone key has the KSK bit set). The admin shouldn't be punished. After the signer is done - the KSK bit loses all meaning. The resolver, verifier and servers should not assigning any specially meaning to the KSK on a KEY RR. > > Another reason to not do this: Please don't repeat the mistake of the > > A/C bits of the 2535 flags field - the "authentication prohibited" > > and "confidentiality prohibited" goof ups. > > This a flag to tell the signer what to do. It is NOT > enforced by the resolver. > Correct again. This bit is signer-meaningful only. > > -- > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > Edward Lewis +1-703-227-9854 > > ARIN Research Engineer > > > -- > Mark Andrews, Internet Software Consortium > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org > Scott -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: