RE: Palladium (TCP/MS)
Good Morning Valdis -Original Message- From: [EMAIL PROTECTED] [mailto:Valdis.Kletnieks;vt.edu] Sent: 29 October 2002 15:39 To: Sean Jones Cc: [EMAIL PROTECTED] Subject: Re: Palladium (TCP/MS) You're close. You'd want this for multihomed servers, so a PTR query works as you'd expect. Consider this case: www.big-corp.com A 10.0.0.10 A 192.186.10.10 mail.big-corp.com A 10.0.0.10 A 172.16.23.10 Then you'd want to have PTRs as follows: 192.168.10.10 PTR www.big-corp.com 172.16.23.10 PTR mail.big-corp.com (and then the magic) 10.0.0.10 PTR www.big-corp.com PTR mail.big-corp.com If you don't have 2 PTR records for that last, you can get into the situation where a system will look up the A record for www, get the IP address, then do a PTR to sanity-check, get back only the mail. address, and get upset. Having both PTR records means that you'll be able to find one to match to the original hostname either way... Forgive my ignorance, but I thought email was handled by Mail eXchange (MX) records, thus a PTR would not be required? Thinking along a bit more, setting the routers shouldn't be a big issue, after all Cisco have been producing routers IPv6 capable for a fair while now, so surely they could incorporate multiple PTR records within the routers capability? Routers don't have anything at all to do with PTR records. What I said was that if a company wanted to block all access to Microsoft's servers, they'd have to keep continual track of all the IP addresses in use - which can be interesting if round-robin DNS or other similar things are in use. I understand where I went wrong. But I doubt that any commercial enterprise would want to block access to MS servers in RL. Regards Sean Jones
Re: Palladium (TCP/MS)
On Fri, 01 Nov 2002 08:48:35 GMT, Sean Jones said: Forgive my ignorance, but I thought email was handled by Mail eXchange (MX) records, thus a PTR would not be required? Just because an MTA follows an MX to find where to send a piece of mail doesn't mean that other things don't use PTR records for other purposes. To consider the headers in your note: Received: from mm_w2k1.micromedical.local (mailgate.peakflowmeter.co.uk [62.49.78.214] (may be forged)) by dagger.cc.vt.edu (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AUE74943; Fri, 01 Nov 2002 03:56:05 -0500 (EST) You might think about where peakflowmeter came from -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech msg09221/pgp0.pgp Description: PGP signature
Re: Palladium (TCP/MS)
Sean Jones wrote: I understand where I went wrong. But I doubt that any commercial enterprise would want to block access to MS servers in RL. Well, it'd be a good way to inhibit people from sneaking Windows into the company. -- /===\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centivinc.com| |Centiv|My opinions are my own. | |===| |If you're going to walk on thin ice, you might as well *dance*!| \===/
Re: mail headers for announce
The recipient list is a pretty poor way to deal with things when you get mail sent to multiple lists you're on, and often the To: line ends up with nothing at all. The Return-Path: is generally the surest way to know which of the lists each of the messages was sent to. I've tried lots of things over the years, and Return-Path: is what works the best. I'm on a few hundred mailing lists so the matter is somewhat important to me. On the other hand, when someone replies to you on most mailing-lists (To: you, Cc: m-l), at least _I_ don't want those hundreds of messages in my inbox, rather in the respective folders (both direct mail and the mailing-list version with Return-Path:). some people want the personal copies, some don't. I like to maintain reliable archives of the lists to which I subscribe, and having a separate address for each list works well for that. but it does mean that if a message is cross-posted to multiple lists to which I subscribe, I get a separate copy of the message from each list, in addition to any personal copies I might have received. duplicate suppression is best done on the recipient end. unfortunately for the cause of duplicate suppression there is a trend toward lists munging messages more and more (adding trailers or frobs to subject lines). I have a fair number of filters to remove those frobs from subject lines - not only do they alter the messages, they make one-line-per-message summaries (e.g. from/date/subject) harder to read. Keith
Re: mail headers for announce
Perry, Wednesday, October 30, 2002, 1:38:54 PM, you wrote: Perry As I use Return-Path: headers to filter my mail, this has gotten Perry annoying, Yes, I can indeed kludge around it, but is there a Perry particular reason for this being done? Using return-path is a bit like paying attention to what mailbox a postal letter is dropped into. looking for ietf-announce in the recipient list works better. d/ -- Dave Crocker mailto:dave;tribalwise.com TribalWise http://www.tribalwise.com t +1.408.246.8253; f +1.408.850.1850
kernelizing the network resolver
Hi everyone, Please check out http://infs.sourceforge.net for a novel INternet FileSystem (INFS) package which appears to be ideally suited to cell phones and other small devices or appliances. By pushing the DNS resolution to the kernel, INFS means to achieve the following: - eliminates sockaddr_t handling in the user space, allowing application code to become free of IPv4/IPv6 (or for that matter raw Ethernet or ATM) dependencies; - reduces the number of context switches going from application to resolver and back; - provides robust kernel multitasking for the resolution process, avoiding buggy or unsafe multithreading in application-based resolvers (like in netscape); - reduces the overall code footprint - the filesystem name tree cache is reused, sockaddr_t handling code in applications gone. This is still a pre-alpha version, sufficient only to illustrate the concept. A few system calls need to be added to completely eliminate any need for handling sockaddr_t in user space. Also, the dns response parsing can be improved - it currently gets confused with CNAME records (e.g. from www.microsoft.com), tho' it does tolerate multiple A records (e.g. from www.ibm.com). To the anonymous referees of my sigcomm submission earlier this year on the Namespace Addressing Principle: you might recognize that I was proposing INFS - but it was untried till May. the full thesis is not yet final (but the global Internet self-management algorithms hinted at are now described in the draft Annals paper at http://www.columbia.edu/~vg96/papers). I look forward to comments, education*, help... Sincerely, -prasad. -- * finally a true student: no longer at ibm or anywhere!
Re: Palladium (TCP/MS)
On Fri, 01 Nov 2002 09:10:59 EST, John Stracke [EMAIL PROTECTED] said: Sean Jones wrote: I understand where I went wrong. But I doubt that any commercial enterprise would want to block access to MS servers in RL. Well, it'd be a good way to inhibit people from sneaking Windows into the company. And in addition, not all the net is a commercial enterprise. There's a very large worldwide presence in the gov/edu/org arenas - and a *LOT* of those organizations have political, philosophical, or other reasons for blocking Microsoft. I'm sure there's privately held companies that can afford to have similar views - and I'm waiting for a shareholder suit against the board of a publicly held company for decreasing profits by continuing to permit the use a certain MUA even though it's one of the leading causes of virus and worm propagation... -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech msg09226/pgp0.pgp Description: PGP signature
RE: Palladium (TCP/MS)
Good Afternoon again Valdis -Original Message- From: [EMAIL PROTECTED] [mailto:Valdis.Kletnieks;vt.edu] Sent: 01 November 2002 13:35 To: Sean Jones Cc: [EMAIL PROTECTED] Subject: Re: Palladium (TCP/MS) Received: from mm_w2k1.micromedical.local (mailgate.peakflowmeter.co.uk [62.49.78.214] (may be forged)) by dagger.cc.vt.edu (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AUE74943; Fri, 01 Nov 2002 03:56:05 -0500 (EST) You might think about where peakflowmeter came from I cheat with Exchange 2000. I manage a number of domains, and in order to make my job simpler, I have all of these domains forwarded to one domain via my ISP, then sort them on the Exchange server. Regards Sean
Re: mail headers for announce
Dave Crocker wrote: Using return-path is a bit like paying attention to what mailbox a postal letter is dropped into. Or perhaps what post offices it went through on the way. -- /===\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centivinc.com| |Centiv|My opinions are my own. | |===| |If you're going to walk on thin ice, you might as well *dance*!| \===/
Re: kernelizing the network resolver
V Guruprasad wrote: - eliminates sockaddr_t handling in the user space, allowing application code to become free of IPv4/IPv6 (or for that matter raw Ethernet or ATM) dependencies; Doesn't using a shared library for the resolver give you the same benefit? It's in user space, but it's not in the app. - reduces the number of context switches going from application to resolver and back; Do you have data showing these context switches are a problem? To me, it seems like you're optimizing something that doesn't take up that much time anyway--what apps spend that much CPU time on DNS lookups? - provides robust kernel multitasking for the resolution process, avoiding buggy or unsafe multithreading in application-based resolvers (like in netscape); Again, the same thing can be done with a good shared lib. Most current Unices include gethostbyname_r(), which is thread-safe. Netscape just started too early, when threading support in the OS was still pretty uneven. - reduces the overall code footprint - the filesystem name tree cache is reused, sockaddr_t handling code in applications gone. Again, shared libs also reduce duplicate code (though not data; for that you do need the kernel, or a daemon). -- /===\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centivinc.com| |Centiv|My opinions are my own. | |===| |If you're going to walk on thin ice, you might as well *dance*!| \===/
Re: anyone remember when the root servers were hi-jacked? (fwd)
Michael, Thursday, October 31, 2002, 6:28:08 PM, you wrote: Michael http://www.law.miami.edu/~froomkin/articles/icann-body.htm#B170 Michael tells the story as best I could reconstruct it. There are footnotes to Michael the documents I could find. Notice that Professor Froomkin's To his detractors text does not attempt any balance by offering any other explanation. As even Prof. Froomkin notes, things were fragile back then. That included concern over the possibility that NSI would go rogue. NSI controlled the master root. The one that all others took their data from. Jon needed to test the ability to switch to a different master DNS root, to make sure that there were ways to route around this concern over NSI. That's all the test was. Jon was clear about the need for this, weeks before the test. All anyone needed to do was ask him, rather than engage in unfounded, inflammatory speculation. The other point that folks keep forgetting is that Jon had been issuing operation directives for the root servers since the inception of the DNS. How can one take over something that one has been responsible for over its entire existence? All of the storm and fury has been from people who have had nothing to do with the running of the DNS, but instead have focused strictly on the politics of it. (In fact, it was quite interesting to see that a year of federal inter-agency task force meetings -- including Magaziner's participation -- took place with most participants having almost no understanding of DNS technical basics. We had to arrange a tutorial for them.) d/ -- Dave Crocker mailto:dave;tribalwise.com TribalWise http://www.tribalwise.com t +1.408.246.8253; f +1.408.850.1850
Re: anyone remember when the root servers were hi-jacked? (fwd)
[EMAIL PROTECTED] would be a fine place to discuss this further, as it is (by definition) about (albeit recent) Internet history ;-) Joe Craig Simon wrote: I've got a lot of information on this which I'd be happy to share and exchange, but I still need and want more details. I'm not sure the IETF list is the best place to discuss this matter, however, and if anyone can suggest an alternative site, I'd gladly participate there. Please be aware that I got it partly wrong in my 1998 paper that Michael Froomkin cited regarding that incident. I apologize for a misstatement which may have been widely propagated. To clarify, the server operators who complied with the redirection request were pulling the root zone from a separate machine at ISI -- DNSROOT.IANA.ORG -- not B. The research I've done on this is a central part of my Ph.D. dissertation. Anyone who has been holding their breath waiting to read it is long dead by now, but I am advancing. It's interesting stuff. I don't have any after-the-fact explanation from Jon Postel himself regarding his motivation, but I disagree with the statement that his goal was to embarrass the USG. Though it's fair to say that he was acting partly in reaction to pressures from members of CORE, I think his primary rationale was a deeply held conception of loyalty to the Internet community and its processes. I argue that he put that sense of loyalty ahead of loyalty to the officers of the US Government and their clearly stated wishes, as expressed by Ira Magaziner. It took a plain threat of coercion from the USG to make him bow and reverse the move. The problem of divided loyalty and authority in the Internet community stretches back to RFC 1174, and was tested in the redirection incident. Also, while John Gilmore was evidently an important agent leading the call for the redirection -- at that particular time -- Paul Vixie evidently was not -- at that particular time. Vixie had urged such a move in the past, when the atmosphere was not so charged, but his role in the Jan 1998 episode seems to have been similar to that of the other operators who complied with the request. They went along, even with raised eyebrows, but they trusted Postel's judgment and acted with loyalty to him and the processes he represented. Again, I'd be willing to engage this further, and I'd be thrilled to be set straight if I've got any other flat facts wrong. Right now I'm most interested in getting nitty gritty details about the negotiations between CORE and Ira Magaziner in late 97 early 98, if anyone here can help me with that. I'm even more interested in the September 1995 discussion that ultimately allowed NSI to begin charging for names, but Don Mitchell hasn't answered my emails. Craig Simon Michael Froomkin - U.Miami School of Law wrote: http://www.law.miami.edu/~froomkin/articles/icann-body.htm#B170 tells the story as best I could reconstruct it. There are footnotes to the documents I could find. On Thu, 31 Oct 2002 [EMAIL PROTECTED] wrote: I'm looking for sources of information on the hi-jacking of the usg root servers by Postel, Gilmore and Vixie. Anyone remember this? It was on Jan 27 1998 when postel convenced a number of the root operators to switch the primary from a root to f root (paul vixie). This seems to have been done to embarrase the federal government - Ira magaziner the presidential science advisor took a birdy and treatened postel with a visit from the men in black. I can understand magaziners disposition at the time. The postel test was a day prior to the Jan 28 release of the presidential green paper and left magaziner holding the eggs so to speak. thanks in advance for any links you may have in your archives. - This message was passed through [EMAIL PROTECTED], which is a sublist of [EMAIL PROTECTED] Not all messages are passed. Decisions on what to pass are made solely by Raffaele D'Albenzio.
Re: kernelizing the network resolver
V Guruprasad [EMAIL PROTECTED] writes: Please check out http://infs.sourceforge.net for a novel INternet FileSystem (INFS) package which appears to be ideally suited to cell phones and other small devices or appliances. By pushing the DNS resolution to the kernel, INFS means to achieve the following: This isn't really appropriate for the IETF mailing list. Perry
Re: Palladium (TCP/MS)
Wha? they go outlaw windows? Shareholders wont do non of that in realm of lawsuits because M$ the media done a good job at brain neutering the masses and furthering intellectual ejemitysp in the schools. Damn, I taking cis-2 and they concentrate in M$ details of operation and not on raw talent, teacher go ding you in the grade dept. if your comment block is not just so perfect... shit. --chris 11/1/02 7:15:08 AM, [EMAIL PROTECTED] wrote: On Fri, 01 Nov 2002 09:10:59 EST, John Stracke [EMAIL PROTECTED] said: Sean Jones wrote: I understand where I went wrong. But I doubt that any commercial enterprise would want to block access to MS servers in RL. Well, it'd be a good way to inhibit people from sneaking Windows into the company. And in addition, not all the net is a commercial enterprise. There's a very large worldwide presence in the gov/edu/org arenas - and a *LOT* of those organizations have political, philosophical, or other reasons for blocking Microsoft. I'm sure there's privately held companies that can afford to have similar views - and I'm waiting for a shareholder suit against the board of a publicly held company for decreasing profits by continuing to permit the use a certain MUA even though it's one of the leading causes of virus and worm propagation... -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech
Re: Palladium (TCP/MS)
On Fri, 01 Nov 2002 15:30:34 GMT, Sean Jones [EMAIL PROTECTED] said: You might think about where peakflowmeter came from I cheat with Exchange 2000. I manage a number of domains, and in order to make my job simpler, I have all of these domains forwarded to one domain via my ISP, then sort them on the Exchange server. Yes. I meant how did my mail system get peakflowmeter's name... Also, contemplate why there's a may be forged in there... -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech msg09235/pgp0.pgp Description: PGP signature
Re: anyone remember when the root servers were hi-jacked? (fwd)
That included concern over the possibility that NSI would go rogue. NSI *did* go rogue. They're still levying a toll on much of the net. What ended up becoming ICANN was originally an attempt to keep NSI in check - too bad it's mostly turned out to be ineffective. If there was a mistake made, it was in ever letting the master root be controlled by a for-profit company. By the time Jon tried his 'experiment' it was (sadly) far too late. Keith
SNMP MIB
Does anyone know what SNMP MIB or OID value I can use to know "what mac-addresses are associated to what switch ports" on a Cisco 1900 switch. Thanks, PB
