RE: Possibly OT, definately humor. rDNS is to policy set by federal law.
We do not have any problem with SORBS. We use SORBS entire list with the exception of the DUL at all of our client sites. I have worked with Mat for years, and despite our differences with regard to DUL lists, our relationship has always been both respectful and cordial. This guy was talking out the wrong end of his anatomy, and Mat called him on it. You can like SORBS (as I do), or not like them, that's your choice, and I will respect all of you for it. But a follow-up bashing SORBS listing policies certainly went off topic if the original premise of the post was maybe a little off topic. I think what we're talking about here as the larger issue is your dog in your yard. Your dog is free to take a crap in your yard all it likes, but when your dog comes over to my yard and takes a crap, I might build a fence. I might also conscript something like Mat's service, or Steve Lindford's service, or mine to keep my yard clean, if that means your dog doesn't get to play in my yard... well that's just unfortunate for you. (or in another manner of speaking, I could care less) And damn, I think I just equated all of my volunteer time to the equivalent of a pooper-scooper... ooh well. Andrew D Kirch - All Things IT Office: 317-755-0200 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of S. Ryan Sent: Thursday, March 15, 2007 10:42 PM To: Steve Sobol Cc: Matthew Sullivan; nanog@merit.edu Subject: Re: Possibly OT, definately humor. rDNS is to policy set by federal law. Nothing is wrong with what he posted. The guy is a moron. However, I was taking my 15 min of fame to jab at SORBS policy of listing people on their respective lists. It's dysfunctional and broken, but that again is just my opinion. Oh and, of course publicly humiliating the guy is certainly not that cool. However, while it's not really above me to do the same, he could have removed the email address so spammers aren't adding to that guys list of problems. Anyway, don't mind me. I just wanted to add to the off-topic drivel Mat posted since I can't stand SORBS. : Steve Sobol wroteth on 3/15/2007 7:31 PM: On Thu, 15 Mar 2007, S. Ryan wrote: Typical SORBS behavior. While this guy can demand all he wants, doesn't mean he will get what he wants or that he's right or wrong. What's wrong with what Mat posted? The guy claiming DNS is regulated by federal law is an idiot. Not that I always agree with what Mat says, but the guy's claims are obviously and patently false. The claims, in fact, are so ridiculous that I tend to think he's making them to weasel out of solving the problem that got him listed in the first place. People doing that *deserve* to be publically ridiculed. When I talk to Mat I generally have no problems having a civil and productive discussion with him. But I don't start out with an attitude, and I don't cook up absurd stories to try to get out of fixing my spam problem. (Not that I have one, but if I did, I'd not try to weasel out of fixing it.) Personally, we gave up using SORBS because of it's very high false-positive ratio YMMV; at $DAYJOB we don't seem to have the same problem. Disclaimer: My opinions, not my boss's, etc.
Re: what the heck do i do now?
Matthew Sullivan wrote: Andrew - Supernews wrote: Warren == Warren Kumari [EMAIL PROTECTED] writes: Warren Sure, but if we could all agree that 127.255.255.255 (or Warren something) means that the BL has been shutdown then in the Warren future this sort of issue could be mitigated. You don't need to agree on something - it's already possible to apply automated checks to a DNSBL that detect all known methods of shutting it down. You could also say if it returns anything outside of 127.0.0.0/8 then it's dead - that would stop it the moment it is wildcarded. In any case the software writers would need to be persuaded to alter it in code. / Mat No amount of good software can make up for a bad administrator. The question is how much notice is appropriate on both a legal and practical measure. Sadly, as we all know, there are plenty of unqualified, or apathetic (e-mail) administrators on the Internet, some of whom have their systems configured such that they cause damage to the Internet-at-large (The Dlink NTP fiasco comes to mind, among others), some of which damages only certain domains (this particular case, the Osirusoft case, and others). According to The Internet Archive, Paul posted a notice on October 11, 2001 that maps.vix.com was replaced with the following notice: MAPS.VIX.COM is no longer a valid URL MAPS is no longer associated with Vixie Enterprises, and the MAPS.VIX.COM URL has long since been replaced by http://mail-abuse.org/.; This notice was taken down on or after August 8, 2002. It was posted for almost a full year, this posting period ended almost 5 years ago. Is there a point where enough is enough? When do I as a RBL administrator/owner stop being responsible for the incompetence of Joe Blow postmaster? Andrew
RE: BGP blackhole routers available to public?
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Nash Sent: Friday, January 26, 2007 9:22 AM To: Gregory Edigarov Cc: nanog@merit.edu Subject: Re: BGP blackhole routers available to public? On Fri, 26 Jan 2007, Gregory Edigarov wrote: I was looking over the internet for them, but it seems that I would get a much quicker answer from the list. Can somebody show me any good public BGP blackhole routers? -- Which begs the question.. why would you deploy a public blackhole route table? - billn Perhaps, and I might be wrong, he's referring to an updating list of BOGON/MARTIAN sources. Assuming this to be true, I tend to reference the following list: http://www.cymru.com/Bogons/. Andrew D Kirch - All Things IT Office: 317-755-0202 Cell: 317-507-1192 si hoc legere scis nimium eruditiones habes.
RE: [cacti-announce] Cacti 0.8.6j Released (fwd)
Maybe this is overly naïve, but what about the ability to auto-magically import and search various vendor SNMP/WMI MIBs? I can think of 3 open source NMS that do a good job if you set up all 3 to monitor the network, but they all overlap and none of them really do a good job. I also am using a closed-source NMS at work that does little more than minimal on-system agent monitoring of Windows/Linux based servers (disk space cpu memory utilization). Good graphing, good alerts, good SNMP integration, granularity, and escalation, as well as pretty executive reports to keep PHB's happy (and that display the system as 5 9's uptime no matter how many times the mail server crashed!). The reason why the open-source tools don't work is a lack of comprehensive coverage of Cisco, third party network kit, Linux and Windows. It just doesn't quite do it all. The reason why the closed-source tool didn't work (in my mind) is that it just doesn't have the flexibility to deal with anything other than what it's expecting. I've submitted a few dozen support tickets with them (and they will remain nameless) simply because of a lack of SNMP knowledge on their part. Please forgive me for all above M$ specific references, I work in a MS and *IX environment. Andrew D Kirch - All Things IT Office: 317-755-0202 si hoc legere scis nimium eruditiones habes. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ray Burkholder Sent: Wednesday, January 24, 2007 1:12 PM To: nanog@merit.edu Subject: RE: [cacti-announce] Cacti 0.8.6j Released (fwd) I see a reference in the response to RTG. RTG's claim to fame looks like speed. I've done some work with Cricket and have figured out a way to get at it's schema. I've been looking at mating Cricket' s 'getter and schema with Drraw and genDevConfig tools and putting a Mason based HTML wrapper around the whole thing so people can pick and choose the components of charts they want to see (per chart), (per page). And by filling in simple web forms, it would be easy to generate command lines for genDevConfig to go out and create the customized SNMP queries that are needed for Dial-Peers, Cisco's Quality of Service, etc. Would anyone be interested in such a contraption? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Vixie Sent: Wednesday, January 24, 2007 13:43 To: nanog@merit.edu Subject: Re: [cacti-announce] Cacti 0.8.6j Released (fwd) [EMAIL PROTECTED] (Jason LeBlanc) writes: After looking for 'the ideal' tool for many years, it still amazes me that no one has built it. Bulk gets, scalable schema and good portal/UI. RTG is better than MRTG, but the config/db/portal are still lacking. if funding were available, i know some developers we could hire to build the ultimate scalable pluggable network F/L/OSS management/monitoring system. if funding's not available then we're depending on some combination of hobbiests (who've usually got rent to pay, limiting their availability for this work) and in-house toolmakers at network owners (who've usually got other work to do, or who would be under pressure to monetize/license/patent the results if That Much Money was spent in ways that could otherwise directly benefit their competitors.) been there, done that, got the t-shirt. is there funding available yet? like, $5M over three years? spread out over 50 network owners that's ~$3K a month. i don't see that happening in a consolidation cycle like this one, but hope springs eternal. give randy and hank the money, they'll take care of this for us once and for all. -- Paul Vixie -- Scanned for viruses and dangerous content at http://www.oneunified.net and is believed to be clean. -- Scanned for viruses and dangerous content at http://www.oneunified.net and is believed to be clean.
RE: Outages mailing list
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Albert Meyer Sent: Thursday, September 28, 2006 3:45 PM To: William Allen Simpson Cc: NANOG Subject: Re: Outages mailing list William Allen Simpson wrote: Don't forget to CC all the traffic to NANOG list. Please don't do that. We don't need more pontification from Gadi. This new separate list sounds like a great idea, if only because it will distract him from NANOG-L. I don't post much but I read NANOG-L for the operational content, and the off-topic posts generated by Gadi and his supporters/detractors significantly reduce the SNR. I've been sending him private emails asking him to stop polluting NANOG-L for some time, but those emails have had no effect, nor have the numerous public requests posted to the list by others. Hoping that another list will entice him away seems to be our only hope, and forwarding that list here would defeat the purpose. So, the jist of your argument is hey everybody! Lets create a new list so I don't have to maintain a killfile! sarcasmThis seems like an intelligent suggestion to me!/sarcasm Please take the time to invest in a killfile. It will save you from listening to their pontificating, and us from listening to you whine. Andrew
RE: Watch your replies (was Kremen....)
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Frank Coluccio Sent: Wednesday, September 13, 2006 3:48 PM To: nanog@merit.edu; [EMAIL PROTECTED] Subject: Re: Watch your replies (was Kremen) Perhaps the list should be turned into a wiki; and no, while I'd like to, I'm not at this time volunteering to admin ;) I might just to watch the hilarity. Is there any real interest in this? MediaWiki with restricted editing for people on the NANOG list. Andrew
RE: private ip addresses from ISP
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Bonomi Sent: Tuesday, May 23, 2006 9:22 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: private ip addresses from ISP Date: Tue, 23 May 2006 03:33:34 -0400 From: Richard A Steenbergen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: private ip addresses from ISP On Mon, May 22, 2006 at 04:30:37PM -0400, Andrew Kirch wrote: 3) You are seeing packets with source IPs inside private space arriving at your interface from your ISP? ... Sorry to dig this up from last week but I have to strongly disagree with point #3. From RFC 1918 Because private addresses have no global meaning, routing information about private networks shall not be propagated on inter-enterprise links, and packets with private source or destination addresses should not be forwarded across such links. Routers in networks not using private address space, especially those of Internet service providers, are expected to be configured to reject (filter out) routing information about private networks. The ISP shouldn't be leaving anything to the end-user, these packets should be dropped as a matter of course, along with any routing advertisements for RFC 1918 space(From #1). ISP's who leak 1918 space into my network piss me off, and get irate phone calls for their trouble. The section you quoted from RFC1918 specifically addresses routes, not packets. I quote, from the material cited above: ..., and packets with private source or destination addresses should not be forwarded across such links. ... There are some types of packets that can legitimately have RFC1918 source addresses -- 'TTL exceeded' for example -- that one should legitimately allow across network boundaries. If you're receiving RFC1918 *routes* from anyone, you need to thwack them over the head with a cluebat a couple of times until the cluey filling oozes out. If you're receiving RFC1918 sourced packets, for the most part you really shouldn't care. *I* care. When those packets contain 'malicious' content, for example. When the provider =cannot= tell me which of _their_own_customers_ originated that attack, for example. (This provider has inbound source-filtering on their Internet 'gateway' routers, but *not* on their customer-facing equipment (either inbound or outbound.) It's even more comical when the NSP uses RFC1918 space internally, and does *not* filter those source addresses from their customers. There are semi-legitimate reasons for packets with those sources addresses to float around the Internet, and they don't hurt anything. I guess you don't mind paying for transit of packets that _cannot_possibly_ have any legitimate purpose on your network. Some of us, on the other hand, _do_ object. YMMV Well said, I think that Robert has done a phenomenal job of summing up my point. I don't want this trash on my network. The pertinent RFC says it shouldn't be entering my network from *your* network (for varying values of your). I don't buy the argue that the end user should decide what traffic they do and don't want when the RFC states unequivocally that the traffic shouldn't be there. Even reasonably large networks are often run by people with no appreciable networking experience, MCSE, MCP MCP+I etc. This is a simple fact of life. Andrew
RE: private ip addresses from ISP
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Schwartz Sent: Wednesday, May 17, 2006 1:37 PM To: [EMAIL PROTECTED] Subject: RE: private ip addresses from ISP Our router is running BGP and connecting to our upstream provider with /30 network. Our log reveals that there are private IP addresses reaching our router's interface that is facing our upstream ISP. How could this be possible? Should upstream ISP be blocking private IP address according to standard configuration? Could the packet be stripped and IP be converted somehow during the transition? It happens in many Tier-1 ISP though ! Thank you for your information Do you mean: 1) You are seeing BGP routes for addresses inside private space? 2) You are seeing packets with destination IPs inside private space arriving at your interface from your ISP? 3) You are seeing packets with source IPs inside private space arriving at your interface from your ISP? If 1, feel free to filter them. You ISP probably uses them internally and is leaking them to you. Feel free to complain if you want. If 2, make sure you aren't advertising routes into RFC1918 space to your ISP. If not, you should definitely ask them what's up. If 3, that's normal. These are packets your ISP received that are addressed to you and the ISP is leaving to you the decision of whether to accept them or not. Feel free to filter them out if you wish. (It won't break anything that's not already broken.) Sorry to dig this up from last week but I have to strongly disagree with point #3. From RFC 1918 Because private addresses have no global meaning, routing information about private networks shall not be propagated on inter-enterprise links, and packets with private source or destination addresses should not be forwarded across such links. Routers in networks not using private address space, especially those of Internet service providers, are expected to be configured to reject (filter out) routing information about private networks. The ISP shouldn't be leaving anything to the end-user, these packets should be dropped as a matter of course, along with any routing advertisements for RFC 1918 space(From #1). ISP's who leak 1918 space into my network piss me off, and get irate phone calls for their trouble. Andrew
Re: http://weblog.disgu.st down
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 william(at)elan.net wrote: I think you're confusing nanog-l with #nanog On Wed, 21 Dec 2005, Tyrone Chickenbone wrote: ne one able to reach0r this site, it appearz to be d0wnz0rs!!! sev0!!! 0h n0z!!! supply of cirpple and midget scat pix0rz gone!!!1 __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com right #nanog is 3 doors down to the left loaded with kiddies that simply don't matter to network infrastructure. Also could we please quickly kill this thread as it's utterly unimportant. - -- Andrew D Kirch | Abusive Hosts Blocking List | www.ahbl.org Security Admin | Summit Open Source Development Group | www.sosdg.org Key fingerprint = 4106 3338 1F17 1E6F 8FB2 8DFA 1331 7E25 C406 C8D2 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDqaDpEzF+JcQGyNIRAtf8AJ40sxmaE01kYBPO/9a90Q0MRjULFgCgmNw5 1A7XistyQphKs2bvMRZqaFs= =3CF3 -END PGP SIGNATURE-
