Re: d000::/8 from AS28716
On Tue, Jan 12, 2010 at 1:33 AM, Pierfrancesco Caci wrote: .. > Maybe next time drop me a line when it's happening, I don't see the > route from the customer now. Can still be seen on routeviews... a ghost route, perhaps? route-views6.routeviews.org> show bgp d000:: BGP routing table entry for d000::/8 Paths: (1 available, best #1, table Default-IP-Routing-Table) Not advertised to any peer 33437 29748 3257 6762 28716 2001:4810::1 from 2001:4810::1 (66.117.34.140) Origin IGP, localpref 100, valid, external, best Community: 3257:3300 3257:3301 3257:5033 Last update: Tue Jan 12 13:10:31 2010 -- -J
Re: d000::/8 from AS28716
:-> "James" == James Hess writes: > On Tue, Jan 12, 2010 at 1:33 AM, Pierfrancesco Caci wrote: > .. >> Maybe next time drop me a line when it's happening, I don't see the >> route from the customer now. > Can still be seen on routeviews... a ghost route, perhaps? Yes. -- --- Pierfrancesco Caci | Network & System Administrator - INOC-DBA: 6762*PFC p.c...@seabone.net | Telecom Italia Sparkle - http://etabeta.noc.seabone.net/
Re: DNS queries for . IN A return rcode 2 SERVFAIL from windows DNS recursing resolvers
Joe Maimon writes: > Hey all, > > This must be old news for everyone else. While looking at a dns monitor > on a load balancer that defaulted to . A queries to check liveliness on > DNS resolvers, it became quite clear that windows 2000/2003 DNS server > appears to return rcode=2 for queries looking for an A record for the > root. The resolvers appear to work properly in all other regards. well, there is no A RR for the root domain. RCODE=2 is still an error, you should receive RCODE=0 ANCOUNT=0 for an unused RR type. but many resolvers get confused when the root domain is the QNAME, so let's assume that you're using one of those. > So the monitors were switched to localhost. A > > (Is this a bad idea?) probably. there is no "localhost" in the root zone. this name is a TCP/IP stack convention, not a standard. for health monitoring purposes you should probably choose one of your own local names, since there's almost certainly no local intelligence in your resolver about them. that means to look up one of your own names the resolver probably has to iterate downward from the root zone to the top level and all the way down to your authority nameservers. (the problem here is, you may be testing more than you intend, and a failure in your own authority server or in the delegation path to it would look the same as an IP path failure or a resolver problem.) > A little testing later and the results for . A are: > > Windows NT 4, ancount=0, authority=1, rcode=0 > Windows 2000, rcode=2 > Windows 2003, rcode=2 > bind, ancount=0, authority=1, rcode=0 > > To my (inexpert) eyes that doesnt seem quite right. probably resolver bugs, either in those TCP/IP stacks or in the "recursive nameserver" they are using. (is the same recursive nameserver used in all four tests?) > I cant seem to find any online information regarding this difference of > behavior. > > Enlightenment appreciated. i suggest re-asking this over on dns-operati...@lists.dns-oarc.net, since it a bit deep in the DNS bits for a general purpose list like NANOG. -- Paul Vixie KI6YSY
Senderbase contact
Any Senderbase contacts on list? I am having problems getting some questions answered through normal channels. thanks, -Drew
Re: SORBS on autopilot?
On Jan 11, 2010, at 11:11 AM, Jon Lewis wrote: > http://tools.ietf.org/id/draft-msullivan-dnsop-generic-naming-schemes-00.txt At the risk of hijacking the thread, is this draft considered to be of importance outside of SORBS' domain at all? When handling a /24 that ended up on the DUL -- I feel this thread's pain -- I made the case that this draft expired years ago by the book and never got any further. The DUL companies like SORBS, Trend Micro, et. al. all point to this document as justification for their practices, however; wouldn't that be considered violating it, given the preamble on page 1? The vibe I got from a number of administrators I talked to about it was "why would a standards document assume an IPv4/IPv6 unicast address is a residential customer with a modem, forcing those with allocations to prove that they are not residentially allocated rather than the other way around?" If it remains the magic document to get SORBS to pay attention to you, and nothing more, that would be ideal. JS
Re: SORBS on autopilot?
On Tue, 12 Jan 2010, Jed Smith wrote: http://tools.ietf.org/id/draft-msullivan-dnsop-generic-naming-schemes-00.txt At the risk of hijacking the thread, is this draft considered to be of importance outside of SORBS' domain at all? When handling a /24 that ended up on the DUL -- I feel this thread's pain -- I made the case that this draft expired years ago by the book and never got any further. The DUL companies like SORBS, Trend Micro, et. al. all point to this document as justification for their practices, however; wouldn't that be considered violating it, given the preamble on page 1? Sure, it's expired and never made it to RFC status. But are the "DUL"'s really pointing at it as justification for their policies, or simply pointing to it as a handy place to find a set of reasonably sensible suggested practices for DNS naming schemes. If there's another similar document, I'm not aware of it. I don't know that following the schemes the draft proposes is required for keeping IPs off any "DUL", but I sure wish people would at least read it and consider some of the ideas presented...namely that their DNS naming scheme should clearly indicate an IP's purpose, at least if they want that IP to be useful for sending email. For example, take the following IPs and their PTRs 70.42.226.181 sm-70-42-226-181.quepasa.com 78.228.245.8mad26-1-78-228-245-8.fbx.proxad.net 83.185.129.102 m83-185-129-102.cust.tele2.se 118.137.228.242 fm-ip-118.137.228.242.fast.net.id 189.84.86.106 189-84-86-106.marinter.com.br All of them have recently tried sending mail. How many are mail servers? As the vast majority of spam now comes from bot-infected end user systems, it's increasinly important to be able to easily differentiate mail servers from !mail servers. rDNS is a cheap and easy (or at least it can be if the provider chooses) way to do it. Those who choose to ignore the ideas presented in draft-msullivan-dnsop-generic-naming-schemes-00.txt do so at their own peril. -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Is FRR protection good enough?
Hi, I am doing some research on the backup routing issue. I know Fast ReRoute bypass routing such as MPLS FRR is used by many networks. You may have experienced with this thing pretty well, and can teach me a little bit. My question is: current FRR scheme seems only guarantee network reachability under link/node failure, but not bandwidth (say, if my primary link is carrying 1Gbps, but my bypass path has a capacity of only 100Mbps, then the bandwidth for the traffic under failure is limited). Do you think the reachability level of protection is good enough? Has anyone here encountered any issues with FRR (say, bypass routing could not save your network service during unexpected accident, e.g., concurrent failures of multiple devices)? Is there any example case (or any news and reports regarding this question) I can study? Another thing I want to understand is: if I want to protect a lot of links/nodes (in addition to a few major ones), is the configuration job easy of difficult? My knowledge so far tells me that it is not easy at all. I don't know what is going on in practice. If you can share your experience with me, it will be great. Many Thanks, sando
Re: SORBS on autopilot?
On Tue, 12 Jan 2010 11:51:47 EST, Jed Smith said: > The vibe I got from a number of administrators I talked to about it was "why > would a standards document assume an IPv4/IPv6 unicast address is a > residential > customer with a modem, forcing those with allocations to prove that they are > not residentially allocated rather than the other way around?" What percent of allocated globally routed IP addresses are residential endpoints, and what percent are in data centers? What's the better base assumption if your goal is "I don't want to talk to address ranges that are full of botted boxes"? There's a *reason* why "default deny" is a well-known security policy. pgpuALDMT1zOL.pgp Description: PGP signature
Re: SORBS on autopilot?
on Tue, Jan 12, 2010 at 11:51:47AM -0500, Jed Smith wrote: > The vibe I got from a number of administrators I talked to about it > was "why would a standards document assume an IPv4/IPv6 unicast > address is a residential customer with a modem, forcing those with > allocations to prove that they are not residentially allocated rather > than the other way around?" Well, of course. Any idiot can tell just by looking at any PTR that the IP to which it corresponds is obviously an IPv4 unicast address! I think they teach that in elementary school now. I know I got high marks on how to identify mail sources hidden behind NATs, ISP-outsourced university residential network blocks, and snowshoe spammers using burner domains with hostnames "borrowed" from real hosts in other domains. But there was this one kid in my class who simply couldn't see when a host with a IP-derived, hexadecimal generic name was obviously a broadcast address. Poor guy. Even when it emitted spam he had trouble seeing that it wasn't actually possible, because clearly the PTR is always correct. OTOH, those of us who were out sick when they dealt out the magic PTR meaning decoder rings need a little more help. If I had my way, all PTRs would be clear, unambiguous strings of tokens that indicated their use, their assignment type, the technology or technologies in use, and so on. In reality, we have names like these to contend with (naturally, this example's IP whois simply indicates it's part of a /16): 183.87.5.131.static-dynamic.nivyah.com [183.87.5.131] And if you're trying to classify such naming conventions, as I do with my Enemieslist project, or if you're trying to build and/or maintain a DUL, as Michelle does, well, that sucks. It's far better when the naming is clear, eg u1524.spam-source.sprintnet.ru [81.22.1.89] n081022008237.avoid-mail-from-theese-hosts.sprintnet.ru [81.22.8.237] or, more informatively: host-79-141-236-93.dynamic.pptp.planeta.starnet.ru [79.141.236.93] host-94-102-86-87.static.pppoe.planeta.starnet.ru [94.102.86.87] or, because there's always a joker (both names have since been updated): alameda.net.has.not.owned.this.ip.for.more.then.four.years [209.0.51.16] this.ptr.is.named.in.honor.of.arin.nac.net [66.246.175.3] (heh) just to pick a few. At the very least, customer-assigned blocks ought to have a SWIP and a comment showing whether they're dynamic or static, residential or business class, and so forth. A surprising example, given the paucity of such examples in the .pl TLD, is dialog.net.pl, which does exactly that: inetnum:87.105.24.0 - 87.105.24.255 netname:DIALOGNET descr: Static Broadband Services descr: Telefonia Dialog S.A. - Dialog Telecom country:PL inetnum:62.87.215.0 - 62.87.215.255 netname:DIALOGNET descr: Dynamic Broadband Services descr: Telefonia Dialog S.A. - Dialog Telecom country:PL So, if the Poles (well, some Poles) can do it, why can't we simply end the endless back and forth over why SORBS is evil, and start adopting sane and clear naming conventions for PTRs? Given how easy it is to modify a $GENERATE statement, I should think you've spent far more energy on arguing about why you're being wronged than it would have taken to fix your problem. -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w: http://hesketh.com/ antispam news and intelligence to help you stop spam: http://enemieslist.com/
Re: Is FRR protection good enough?
On Tue, 12 Jan 2010 12:33:46 EST, Ye Wang said: > My question is: current FRR scheme seems only guarantee network reachability > under link/node failure, but not bandwidth (say, if my primary link is > carrying 1Gbps, but my bypass path has a capacity of only 100Mbps, then the > bandwidth for the traffic under failure is limited). Do you think the > reachability level of protection is good enough? That's a total "it depends" question. We've had several instances where backhoe fade or hardware issues have killed our primary off-site link and taken 80% of our bandwidth with it, and we just put up a "The Internet Will Be Slow For A Bit" notice and keep going, as most of our traffic is basically bulk data transfer and we're OK as long as all the bits eventually arrive. For other organizations, the resulting slowdown may be totally unacceptable - if you're doing a lot of video streaming or VoIP, it would be fatal. pgpjRLq4GYngt.pgp Description: PGP signature
Re: SORBS on autopilot?
Steven, take it easy please. Given the first few replies I received, allow me to clarify, now that I've successfully hijacked the thread and apparently angered the anti-spam crowd: I am quite aware of the problem and do not disagree that there needs to be a way to identify what IP endpoints are residential CPE. I simply have some problems with /this/ current incarnation of a best practice, and I was querying whether it had applicability outside of the SORBS/Trend Micro world. Honestly, I feel that PTRs are the least reliable way to make such a decision. Depending on the chain of delegation, a server operator may not have access to modify his PTR record and might not be able to change it. Several operators have annoyingly odd delegation patterns. PTRs are just bad news for any kind of useful decision on, other than "PTR-matches-A". Given the amount of IRC abuse PTRs have seen, the consequential abuse of IPv4 allocation to support exotic PTRs, and the resulting limitation of PTR alteration that many providers practice I just don't like PTRs overall for anything meaningful. I also disagree with space being assumed dynamic unless it is declared static -- helpfully, I have been reminded that consumer CPE equipment is a large number of IPv4 endpoints, but I still think space should be assumed static unless declared dynamic. The burden really should be upon the providers of dynamic services to inform us that their allocations are a dynamic pool; good luck with this, however. Getting a standards-track solution that is reliable, cost-effective for home Internet providers to get on board with, and that has very little wiggle-room for discretion (this current incarnation has quite a bit) is necessary for me to be on board with such classification techniques. That said, I am not the guru that others on this list are and I am unprepared to present an alternative; I am simply pointing out that I'd like to see an alternative. Let me reiterate: I'm not disputing the challenges that network operators face with network abuse, I am simply disagreeing with this draft, its authorship, the sour taste you get from reading it because it's so far past expiration, and its motives in current practice. It's akin to me disagreeing with daylight savings time because it tries to fix energy consumption from lighting. JS
Re: SORBS on autopilot?
On Jan 12, 2010, at 10:31 AM, Jed Smith wrote: > > Given the first few replies I received, allow me to clarify, now that I've > ... apparently angered the anti-spam crowd: > I wouldn't say that necessarily accurate. I could be considered part of the "anti-spam crowd", seeing as that's my line of work. I think DULs are a really dumb way to block spam. Making a binary decision off of information that's wrong as often as it's right it's a great way to create collateral damage and just generally cause more headaches for everyone. Sure, you could take PTR content into account as _part_ of your decision on how to treat incoming e-mail (or connections, for that matter), but it should never be the _whole_ decision. Keeping track of observed behavior is much more indicative of whether an IP is going to send you spam than just assuming all IPs are dynamic until proven otherwise (through some laborious 12-step process, possibly including bribes^H^H^H^H^H^Hdonations). There are several enterprise-class, best-of-breed vendors using the former technique rather than the latter. I think you'll find it's low-end, unsophisticated outfits who use the latter method. Yes PTRs should be more accurate and informative, but very often the people standing up mail servers aren't the people who have control over the DNS and barely even understand how it works. Many organizations who have access to directly edit their forward zones don't have that kind of access to their reverse zones and find updating that information to be somewhat of an arcane process. DNS should really be taught in schools. -- bk
Re: SORBS on autopilot?
On Tue, Jan 12, 2010 at 11:51:47AM -0500, Jed Smith wrote: > On Jan 11, 2010, at 11:11 AM, Jon Lewis wrote: > The vibe I got from a number of administrators I talked to about it was "why > would a standards document assume an IPv4/IPv6 unicast address is a > residential > customer with a modem, forcing those with allocations to prove that they are > not residentially allocated rather than the other way around?" Because a default allow policy doesn't work in today's environment. Blocking generic and residential addresses is the single most effective thing we've ever done to reduce spam. Most legit senders don't want to look like a compromised box in someone's bedroom anyway. -- Dave - Nobody believed that I could build a space station here. So I built it anyway. It sank into the vortex. So I built another one. It sank into the vortex. The third station burned down, fell over then sank into the vortex. The fourth station just vanished. And the fifth station, THAT stayed!
Re: SORBS on autopilot?
Jed Smith wrote: Depending on the chain of delegation, a server operator may not have access to modify his PTR record and might not be able to change it. It's a common belief among network operators that if a "server operator" doesn't have access/ability to modify the PTR record for a server, it's a good sign that the server shouldn't be used to send email, but instead should send email thru an email server provided by their upstream access provider. The people who manage those servers, who can't or won't fix the PTR *or* send email thru an email server provided by their access provider, think it is critically important that the rest of the internet receive their missives. They are mistaken. Their missives come from "a bad neighborhood" (IPs with PTR formats that are strongly associated with botnets) where the odds of any email being desired by the recipient are extremely low. If they want their email to avoid being treated as spam then they need to move to a better neighborhood (fix the PTR) or send from a server located in a better neighborhood (a server with a correct PTR for a mail server). Endlessly whining "I wanna, I wanna, I can't, You should, I wanna" over and over isn't going to change anything. Other networks aren't going to change how they filter based on PTR for someone who can't properly assign the PTR for their mail server. jc
Re: SORBS on autopilot?
On Jan 12, 2010, at 1:48 PM, Dave Martin wrote: > On Tue, Jan 12, 2010 at 11:51:47AM -0500, Jed Smith wrote: >> On Jan 11, 2010, at 11:11 AM, Jon Lewis wrote: >> The vibe I got from a number of administrators I talked to about it was "why >> would a standards document assume an IPv4/IPv6 unicast address is a >> residential >> customer with a modem, forcing those with allocations to prove that they are >> not residentially allocated rather than the other way around?" > > Because a default allow policy doesn't work in today's environment. Blocking based on PTR alone is dangerous, is what I'm saying. I know default deny is important, but the decision can only be minorly influenced by PTR, not entirely made on it. There needs to be a better way, but there isn't. JS
Re: SORBS on autopilot?
On 01/12/2010 10:48 AM, Dave Martin wrote: On Tue, Jan 12, 2010 at 11:51:47AM -0500, Jed Smith wrote: On Jan 11, 2010, at 11:11 AM, Jon Lewis wrote: The vibe I got from a number of administrators I talked to about it was "why would a standards document assume an IPv4/IPv6 unicast address is a residential customer with a modem, forcing those with allocations to prove that they are not residentially allocated rather than the other way around?" Because a default allow policy doesn't work in today's environment. Blocking generic and residential addresses is the single most effective thing we've ever done to reduce spam. Really? You mean that if you stopped doing this you'd have trillions, or quadrillions of spams per day instead now? I'm skeptical. Mike
Re: SORBS on autopilot?
On Jan 12, 2010, at 10:48 AM, Dave Martin wrote: > On Tue, Jan 12, 2010 at 11:51:47AM -0500, Jed Smith wrote: >> On Jan 11, 2010, at 11:11 AM, Jon Lewis wrote: >> The vibe I got from a number of administrators I talked to about it was "why >> would a standards document assume an IPv4/IPv6 unicast address is a >> residential >> customer with a modem, forcing those with allocations to prove that they are >> not residentially allocated rather than the other way around?" > > Because a default allow policy doesn't work in today's environment. There are lots of other ways to deny that don't cause massive collateral damage. Allowing IPs with "suspicious" PTRs to attempt a connection doesn't mean their mail is delivered, or even that their connection will succeed. There are better ways to deny. > Blocking generic and residential addresses is the single most effective > thing we've ever done to reduce spam. Not surprising, but at what cost of false positives? Maybe your organization is different, but the ones I talk to are much more worried about missing a single e-mail than blocking an extra 1,000. > Most legit senders don't want to look like a compromised box in > someone's bedroom anyway. There are literally thousands of companies who don't grasp the difference, or have little ability to influence their appearance. I listen to the guy in the next cube over say "setup your RDNS" probably half a dozen times a day. He's lucky if they even understand what he said most of the time. Most people just do not grok DNS--even when they're given simple templates to fill out, cut, and paste they still manage to screw it up, or simply ignore it. The membership of this list probably has one of the highest concentrations of DNS-clue in the world, but it's not representative of most organizations with an e-mail server. -- bk
Re: SORBS on autopilot?
On Jan 12, 2010, at 2:11 PM, Michael Thomas wrote: > On 01/12/2010 10:48 AM, Dave Martin wrote: >> On Tue, Jan 12, 2010 at 11:51:47AM -0500, Jed Smith wrote: >>> On Jan 11, 2010, at 11:11 AM, Jon Lewis wrote: >>> The vibe I got from a number of administrators I talked to about it was "why >>> would a standards document assume an IPv4/IPv6 unicast address is a >>> residential >>> customer with a modem, forcing those with allocations to prove that they are >>> not residentially allocated rather than the other way around?" >> >> Because a default allow policy doesn't work in today's environment. >> >> Blocking generic and residential addresses is the single most effective >> thing we've ever done to reduce spam. > > Really? You mean that if you stopped doing this you'd have trillions, > or quadrillions of spams per day instead now? I'm skeptical. 1) Is this really the place to talk about SORBS? 2) Your reply to Dave's post is not useful. It's not even useful if you consider it pure hyperbole for effect. There are many ways to reduce spam, the "single most effective" does not stop even 50%. 3) Should people really argue over what other people do with their own machines? You don't like SORBS, don't use it. Someone you need to talk to likes SORBS, make them stop, or conform. Might as well argue over a website using HTTPS when you don't like encryption. -- TTFN, patrick P.S. Just to be clear, I don't like SORBS. I don't use it either. And I prefer the "make them stop", to the point that I would simply not e-mail someone if I were listed and they used SORBS. (But I'm not listed, so it's easy for me to say.)
Re: SORBS on autopilot?
On 01/12/2010 11:34 AM, Patrick W. Gilmore wrote: On Jan 12, 2010, at 2:11 PM, Michael Thomas wrote: On 01/12/2010 10:48 AM, Dave Martin wrote: On Tue, Jan 12, 2010 at 11:51:47AM -0500, Jed Smith wrote: On Jan 11, 2010, at 11:11 AM, Jon Lewis wrote: The vibe I got from a number of administrators I talked to about it was "why would a standards document assume an IPv4/IPv6 unicast address is a residential customer with a modem, forcing those with allocations to prove that they are not residentially allocated rather than the other way around?" Because a default allow policy doesn't work in today's environment. Blocking generic and residential addresses is the single most effective thing we've ever done to reduce spam. Really? You mean that if you stopped doing this you'd have trillions, or quadrillions of spams per day instead now? I'm skeptical. 1) Is this really the place to talk about SORBS? I'm not the one who brought up SORBS. My post didn't even have anything to do with SORBS. 2) Your reply to Dave's post is not useful. It's not even useful if you consider it pure hyperbole for effect. There are many ways to reduce spam, the "single most effective" does not stop even 50%. 3) Should people really argue over what other people do with their own machines? You don't like SORBS, don't use it. Someone you need to talk to likes SORBS, make them stop, or conform. Might as well argue over a website using HTTPS when you don't like encryption. Who said anything about SORBS? Not me. Sorry. My post had to do with whether rDNS is doing much of anything in this day and age. I'm dubious. Spammers don't seem to have any impediment because on it. Mike
Re: Identifying residential CPE IP addresses? (was: SORBS on autopilot?)
On Jan 12, 2010, at 2:34 PM, Patrick W. Gilmore wrote: > On Jan 12, 2010, at 2:11 PM, Michael Thomas wrote: > > 3) Should people really argue over what other people do with their own > machines? You don't like SORBS, don't use it. Someone you need to talk to > likes SORBS, make them stop, or conform. Might as well argue over a website > using HTTPS when you don't like encryption. I don't think the discussion is about SORBS, I think it's about this standards draft that SORBS points to. Here, I'll lay out what I'm saying simply (and retitle the thread so the SORBS issue will go away): 1. Your mailserver receives a connection from a previously-unknown relay. Although this discussion is meta to mail, it's the most prime example. 2. Very quickly, your mailserver must make a spot decision on whether the connecting IP address is a residential modem or a racked server. This information might be important in an administrator's decision, via his rules, to accept or reject any message that relay offers. (To reiterate: the problem is determination of sender, not an attempt to determine if the incoming mail is legitimate. This is beyond that.) 3. Currently, the solution is to consult the PTR, which this draft -- which coincidentally is written by the administrator of SORBS -- recommends. 4. For other reasons laid out in this thread, PTR is not the best choice. Additionally, administrators of mailservers who have no idea what a PTR is -- although their entry fee to the Internet mail system is debatable it will not be discussed here -- are now punished by blocklists like SORBS and Trend Micro with the simple crime of not knowing to PTR their mail server with something that screams "static allocation, not CPE". I note, with a heavy hand, that there are no widely-disseminated standards governing the reverse DNS of an Internet host other than this draft, but administrators make decisions on it anyway. 5. What else does your mailserver use? What could it use? Are there any desirable candidates for a standards-track behavior for determining the "class" of an IP (i.e., iPhone, home CPE, colo'd server, grid node, and so on). Should there be? My original goal here was educational -- I'd like to hear if anybody has given this question serious pause aside from putting silly restrictions on what can go in a PTR, and basing a heavy decision on said PTR. Are there any applications for such a test, outside of mail? I've apparently hit a nerve, and I'm sorry for that. JS
Re: SORBS on autopilot?
on Tue, Jan 12, 2010 at 01:31:06PM -0500, Jed Smith wrote: > Steven, take it easy please. > > Given the first few replies I received, allow me to clarify, now that I've > successfully hijacked the thread and apparently angered the anti-spam crowd: Oh, I'm not angry, if anything I'm disappointed by the massive ongoing failure on the part of some of the folks responsible for PTR naming to deal with the FACT that people are ALREADY using PTRs to discriminate against probably infected spam-sending hosts. And the willingness of so many to argue against the adoption of sane naming conventions. And the amount of time that gets spent by people offering up their opinion on whether PTRs have any value at all (they do) and suggesting that maybe we should just eat all the abuse, forever, without making any efforts to stop it at our perimeters. But I've come to expect it from nanog. It happens that the doc that M. Sullivan wrote contains certain recommendations. It's not the only draft to do so. It doesn't matter to me what people do, as long as they're consistent (unlike, say, vsnl.net.in), as long as they don't mix dynamic and static naming (like RIMA-TDE), as long as it's not idiotic (like volia.net) and as long as they do /something/. But I've already tracked almost 50K naming conventions over the past six years or so; *I* don't *need* you to be sane or to agree with me or M. on specific tokens you should use, or to even agree that PTRs make a reliable indicator of legitimacy for SMTP emitters. That boat has sailed, that dog's been hunting for *years*, it's not an issue. Major AS appliance and AV vendors are already using these practices, period. > Honestly, I feel that PTRs are the least reliable way to make such a > decision. Well, be that as it may, other people don't share that opinion. And they're running mail servers, or writing software that runs antispam appliances, or they're sharing datasets on how to block mail from generics on lists like spam-l. It's ALREADY HAPPENING and has been for several years. To be more specific - I've looked at several hundred thousand IPs with PTRs, and analyzed and classified their naming conventions, to the tune of ~48K patterns in ~26K domains, over the last six years. PTRs are a very useful tool for SMTP, and a very useful tool for finding bots. Period. Yes, many PTRs are too generic to say with certainty "this IP is a dynamic/residential host", but many are not (approximately 13K out of that 48K are dynamics, 12K are statics, and others are generic - 13K or so - and still others are weird mixes like NATs and resnets). Why? Because other netops have discovered that providing a degree of transparency is reducing their abuse load, because it allows everyone else to reject from their dynamics. Helping Spamhaus PBL, SORBS, and everyone else classifying /your networks/ make the right decision is important, whatever your opinion of whether trusting PTRs is "smart". > Depending on the chain of delegation, a server operator may not have > access to modify his PTR record and might not be able to change it. And that's the rest of the network's problem how? > Several operators have annoyingly odd delegation patterns. So? > PTRs are just bad news for any kind of useful decision on, other than > "PTR-matches-A". Given the amount of IRC abuse PTRs have seen, the > consequential abuse of IPv4 allocation to support exotic PTRs, and the > resulting limitation of PTR alteration that many providers practice I > just don't like PTRs overall for anything meaningful. So, because a few blocks have silly.irc.scrip.kiddy.rdns the rest is not to be trusted? I've got 48K patterns against your occasional IRC script kiddy abuse that say otherwise. If a host wants to claim in SMTP that it's 18715194033.user.veloxzone.com.br [187.15.194.33] and I know that IP is residential, I have no reason to doubt it. Even if (as in this case) the PTR doesn't reverse-resolve. Even more so, I'd say. And even more if (as in this case) that host tried to send me nine spams (six to forged/bogus addresses based on mine) in the past three minutes. > I also disagree with space being assumed dynamic unless it is declared > static -- helpfully, I have been reminded that consumer CPE equipment > is a large number of IPv4 endpoints, but I still think space should be > assumed static unless declared dynamic. The burden really should be > upon the providers of dynamic services to inform us that their > allocations are a dynamic pool; good luck with this, however. I agree with you completely. Fortunately, genericity (rather than "static" versus "dynamic") matters even more. Yes, we classify patterns as applying to static hosts if that's what we can determine. But we score static generics as well, and treat them as suspect. And so do a lot of other folks, either using our data or otherwise. You're in a different position than most of the end user ISPs here; as a provider of web hosting and colo, you're going t
BGP testbed tools
This is obviously a rookie question, but I haven't found anything by searching. I'm looking to set up a small testbed to simulate our internal network topology, and I want to have a realistic BGP table from the fake "upstream" routers. Ideally what I'd like to do is dump the BGP table from our production routers, strip the immediate neighbor AS, and load the table into Quagga or OpenBGPD to advertise. I'm running into two problems: how do you dump BGP tables in a machine-parseable format from IOS, and how do you make the route server advertise the routes as they were in the original table, including the full AS-path, communities, etc? If Quagga/OpenBGPD aren't the right tools, I'm happy to use something else. This seems like it would be a pretty standard thing to do, but none of the tools I've found seem aimed at this sort of testbed. Thanks! -Ben Jencks
Re: SORBS on autopilot?
Just a couple of corrections to two of the posts in this thread: >I simply have some problems with /this/ current incarnation of a best practice, and I was querying whether it had applicability outside of the SORBS/Trend Micro world. I think you are mixing/confusing SORBS and MAPS. MAPS was bought by Trend and is run as a service based on subscription fees. SORBS is whatever it is. If you don't like SORBS, that's great, but don't tar Trend with that brush. >2) Your reply to Dave's post is not useful. It's not even useful if >you consider it pure hyperbole for effect. There are many ways to >reduce spam, the "single most effective" does not stop even 50%. Actually, that's not true. I don't want to get into an argument about "single most effective," but I can guarantee that using a good reputation service will block more than 50% of the incoming spam to your network. The leading ones normally hit the 80% range. In fact, many of the popular anti-spam appliances are completely miserable at the content filter end which is applied post-reputation service; without reputation filtering, they wouldn't be worth using. (My information is based on monthly testing of anti-spam appliances we have conducted for the past 5 years. For example, this month we are looking at 43 different appliances and 25 reputation sevices) jms -- Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 Senior Partner, Opus One Phone: +1 520 324 0494 j...@opus1.comhttp://www.opus1.com/jms
Re: SORBS on autopilot?
On Tue, 12 Jan 2010 11:27:32 PST, Brian Keefer said: > On Jan 12, 2010, at 10:48 AM, Dave Martin wrote: > listen to the guy in the next cube over say "setup your RDNS" probably > half a dozen times a day. It's funny that you say that in reply to Dave's note - I usually wear headphones in the office so I don't have to listen to Dave in the next cube saying "fix your RDNS" over and over to clueless admins.. ;) pgpDN4QwC3JFe.pgp Description: PGP signature
Re: SORBS on autopilot?
On Jan 12, 2010, at 3:27 PM, Joel M Snyder wrote: >> 2) Your reply to Dave's post is not useful. It's not even useful if >> you consider it pure hyperbole for effect. There are many ways to >> reduce spam, the "single most effective" does not stop even 50%. > > Actually, that's not true. I don't want to get into an argument about > "single most effective," but I can guarantee that using a good reputation > service will block more than 50% of the incoming spam to your network. The > leading ones normally hit the 80% range. A good reputation service is not using a single criteria. But you didn't want to get into an argument, and I agree it's not worth arguing over. The point was, trying to imply that not using DUL would result in "quadrillions" more spam is not useful. And I stand behind that. -- TTFN, patrick
Baidu Contact
I'm looking for a technical contact at Baidu.com. Please contact me off list if you can help. Thanks! Greg Schwimer
Re: Identifying residential CPE IP addresses? (was: SORBS on autopilot?)
on Tue, Jan 12, 2010 at 02:59:55PM -0500, Jed Smith wrote: > 4. For other reasons laid out in this thread, PTR is not the best choice. > Additionally, administrators of mailservers who have no idea what a PTR > is -- although their entry fee to the Internet mail system is debatable > it will not be discussed here -- are now punished by blocklists like > SORBS and Trend Micro with the simple crime of not knowing to PTR their > mail server with something that screams "static allocation, not CPE". Mild correction: it's FAR BETTER to use something that screams I AM A MAIL SERVER WITH A LEGITIMATE PURPOSE AND A COMPETENT ADMIN rather than just using yet another generic static naming convention. :-) Because using generic static naming is falling victim to the rather baseless assumption that all statics should be allowed to send mail, which is just ridiculous. We've got a /27 (we're a web app dev shop) and only one of those IPs is a mail source, one is a NAT, one is a VPN box, several others run Web servers and other services, and so could possibly emit mail but likely only to us, and we can always whitelist if need be. I assume that the case is similar in other organizations; their static IPs far outnumber their canonical mail servers. Of course, I asked for appropriate custom PTRs for all of them, but still - the point stands, especially for those who think that generic static PTRs are sufficient for a modern mail infrastructure. I don't care who your ISP is, I care who you supposedly are, because if I see that your mail server (or other hosts on your network) are infected, compromised, or otherwise sources of abuse directed at my network, I want to deal with /you/, not with your upstream's abuse desk triage. > I note, with a heavy hand, that there are no widely-disseminated > standards governing the reverse DNS of an Internet host other than this > draft, but administrators make decisions on it anyway. On that and on a wide variety of other criteria, yes. -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w: http://hesketh.com/ antispam news and intelligence to help you stop spam: http://enemieslist.com/
Re: SORBS on autopilot?
On Tue, Jan 12, 2010 at 10:48:31AM -0800, Brian Keefer wrote: > I wouldn't say that necessarily accurate. I could be considered > part of the "anti-spam crowd", seeing as that's my line of work. > I think DULs are a really dumb way to block spam. Making a binary > decision off of information that's wrong as often as it's right it's > a great way to create collateral damage and just generally cause more > headaches for everyone. I've done a little bit of work in the anti-spam area as well (starting around 1983) and I can tell you that your viewpoint about DULs is roughly half a decade out of date. With the rise of 100M+ zombies, it has long since become a best practice to block outright anything that looks like, smells like, feels like it's not a real live mail server. (And many things that are.) One of the best ways to do that is to reject all mail from anything without a PTR, and a lot of things *with* PTRs matching certain well-known/well-understood patterns. Hence the work of various DULs, the EnemiesList project, and others. They have long since proven their marked superiority to other methods in terms of accuracy, resource cost, maintainability, scalability, resistance to countermeasures, and other applicable metrics. They're some of the very best tools we have, and anyone with even a little bit of clue is using them for all they're worth. Default-permit mail system policies which don't implement these are years behind best current practices. PTR allocation policies which pretend that this doesn't work or shouldn't work or won't work are years behind best current practices. As an aside, there is no such thing as "collateral damage" in this context, because there is no such thing as "damage". This point was discussed extensively on the IRTF-ASRG mailing list nearly two years ago in the discussion over Chris Lewis's RFC on DNSBL operational procedures, and I believe I presented a clinching set of arguments there as to why that's the case -- certainly enough to get that language removed from the draft. You might want to read that list's archives to see why that phrase has absolutely no place in any anti-spam discussion. I suggest that further discussion of this move to spam-l, where it's probably much more appropriate than NANOG. ---Rsk
Re: SORBS on autopilot?
On Tue, Jan 12, 2010 at 11:11:13AM -0800, Michael Thomas wrote: > On 01/12/2010 10:48 AM, Dave Martin wrote: > >On Tue, Jan 12, 2010 at 11:51:47AM -0500, Jed Smith wrote: > >>On Jan 11, 2010, at 11:11 AM, Jon Lewis wrote: > >>The vibe I got from a number of administrators I talked to about it was "why > >>would a standards document assume an IPv4/IPv6 unicast address is a > >>residential > >>customer with a modem, forcing those with allocations to prove that they are > >>not residentially allocated rather than the other way around?" > > > >Because a default allow policy doesn't work in today's environment. > > > >Blocking generic and residential addresses is the single most effective > >thing we've ever done to reduce spam. > > Really? You mean that if you stopped doing this you'd have trillions, > or quadrillions of spams per day instead now? I'm skeptical. We did stop. We used to maintain our own list. Dealing with it, and the support issues it caused ate up a lot of time. It stopped about half of the mess that was offered to us. Right now we're quarantining and blocking via other means a lot more than we used to. And no, it doesn't mean we get trillions or quadrillions of spams a day now. No single method we use stops even 60%. (and probably not even that.) Now we can point the users at our vendor, and use the time for other things. We do get more spam, but we're probably coming out ahead in cost/return sense. I'll note that we blocked generic names, as well as obvious end user names. I'd love a more standard nameing policy. -- Dave - Nobody believed that I could build a space station here. So I built it anyway. It sank into the vortex. So I built another one. It sank into the vortex. The third station burned down, fell over then sank into the vortex. The fourth station just vanished. And the fifth station, THAT stayed!
Re: I don't need no stinking firewall!
On Jan 6, 2010, at 3:56 PM, Brian Johnson wrote: >> -Original Message- >> From: Brian Keefer [mailto:ch...@smtps.net] >> Sent: Wednesday, January 06, 2010 3:12 PM >> To: Brian Johnson >> Cc: NANOG list >> Subject: Re: I don't need no stinking firewall! > > >> >> IMO you're better off making sure only the services you intend to >> provide are listening, and that those services are hardened >> appropriately for public exposure. > > OK. This is obvious to anyone with experience in these things. But I > also believe in a layered approach. It never hurts to add more layers to > prevent human error or even internal breaches as the different systems > are under the control of different equipment (servers, routers, > switches, security devices). It's like two supports holding up something > without knowing if the other one is doing its job. Both need to pull the > full weight in case the other fails. I disagree. "Never" is pretty absolute. If that were true there would be no limit to the number of layers. Realistically I have experienced the harm from having firewalls in the network path. I have witnessed too many video sessions that either couldn't be started or had the sessions dropped prematurely because of firewalls. When the worms were infecting machines a couple of years ago our network was robust and stable and I identified and blocked infected machines quickly. Other universities shut down their residence halls or large portions of their network because their firewalls rolled over and died otherwise from all of the scanning from inside their network. I have talked to universities who consider the firewall the canary of the network world, its the first box in the network to cease functioning when there is a problem. Others have already mentioned the troubleshooting nightmares that firewalls generate, I would consider that a harm also. --- Bruce Curtis bruce.cur...@ndsu.edu Certified NetAnalyst II701-231-8527 North Dakota State University
Re: BGP testbed tools
On 2010-01-12 21:27, Ben Jencks wrote: > This is obviously a rookie question, but I haven't found anything by > searching. I'm looking to set up a small testbed to simulate our > internal network topology, and I want to have a realistic BGP table > from the fake "upstream" routers. Ideally what I'd like to do is dump > the BGP table from our production routers, strip the immediate > neighbor AS, and load the table into Quagga or OpenBGPD to advertise. > I'm running into two problems: how do you dump BGP tables in a > machine-parseable format from IOS, and how do you make the route > server advertise the routes as they were in the original table, > including the full AS-path, communities, etc? If Quagga/OpenBGPD > aren't the right tools, I'm happy to use something else. Use libbgpdump from ris.ripe.net to get raw data from http://data.ris.ripe.net/ (you're looking for newest bview file), and dump them using bgpdump to something easily to parse. Then using bgpsimple (from googlecode) simulate a peer with specific number of prefixes advertised - up to the limit of the contents of the file. You can spoof next-hop, AS, etc. As for the attribute manipulation, fire up a couple of VMWare/VirtualBox/vimage instances with quagga/openbgpd to accept the prefixes from bgpsimple and mangle them in some manner. Here you go. -- "Everything will be okay in the end. | Łukasz Bromirski If it's not okay, it's not the end. | http://lukasz.bromirski.net
Re: BGP testbed tools
This might do what you need: MDFMT - MRT dump file manipulation toolkit http://caia.swin.edu.au/urp/bgp/tools.html On Tue, Jan 12, 2010 at 3:27 PM, Ben Jencks wrote: > This is obviously a rookie question, but I haven't found anything by > searching. I'm looking to set up a small testbed to simulate our > internal network topology, and I want to have a realistic BGP table > from the fake "upstream" routers. Ideally what I'd like to do is dump > the BGP table from our production routers, strip the immediate > neighbor AS, and load the table into Quagga or OpenBGPD to advertise. > I'm running into two problems: how do you dump BGP tables in a > machine-parseable format from IOS, and how do you make the route > server advertise the routes as they were in the original table, > including the full AS-path, communities, etc? If Quagga/OpenBGPD > aren't the right tools, I'm happy to use something else. > > This seems like it would be a pretty standard thing to do, but none of > the tools I've found seem aimed at this sort of testbed. > > Thanks! > > -Ben Jencks > >
Re: Default Passwords for World Wide Packets/Lightning Edge Equipment
A password recovery method I've found very frustrating is to use the serial number or similar value that's on a label on the bottom of the equipment. It's just fine for desktop hardware - but for rack-mounted gear, it's not uncommon to find out that you need this information *after* somebody's racked and stacked the hardware, and therefore you either need to unscrew it (if it was screwed into the rack) or drag it out (if it wasn't screwed in for some reason like missing wing-brackets or 23-inch telco racks or random junk piled on top of it, etc.), and possibly uncable it as well, depending on how much slack is in the cabling, and you almost certainly want to power it down first, and you need to have enough flashlights and reading glasses to deal with reading the bottom of the equipment lying down on the floor of the data center. Yes, you *should* be able to find the serial number by looking in the accurate complete up-to-date spreadsheet of equipment inventory records, or at least the previous-user-printed Dymo-label on the front of the box. But if you had that quality of records, you probably wouldn't need to be running password recovery anyway. (Disclaimer: I'm currently working in a development lab, not operations, so ideally this doesn't reflect the state of our production data centers :-) Most of the time it doesn't reflect our lab either, but occasionally it does, and of course loaner equipment often arrives in random condition.
Re: Default Passwords for World Wide Packets/Lightning Edge Equipment
On Tue, 12 Jan 2010 17:50:37 PST, Bill Stewart said: > A password recovery method I've found very frustrating is to use the > serial number or similar value that's on a label on the bottom of the > equipment. Related pet peeve: Inventory and asset control people that stick a sticker on hardware and then expect to be able to scan the barcode at a later date. Works fine if the barcode sticker actually ends up facing the front or the back of the rack. But occasionally, the sticker ends up stuck on an empty space on the printed circuit board of a upgrade blade that's plugged into a chassis... pgpORvq0cySnH.pgp Description: PGP signature
more news from Google
I must say I'll have to take a step back from my previous position/postings having read this article. I just can't figure out their /ANGLE/. :) http://googleblog.blogspot.com/2010/01/new-approach-to-china.html Well played, google? /kc -- Ken Chase - k...@heavycomputing.ca - +1 416 897 6284 - Toronto CANADA Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W.
RE: BGP testbed tools
This is how you can do it with Quagga: http://wiki.nil.com/Use_Quagga_to_generate_BGP_routes You could write a Perl (or whatever your favorite scripting language is) script to get Quagga/IOS configuration from live BGP data, but it would be non-trivial and the resulting configuration would be enormous. I know there was a similar discussion months ago on the NANOG mailing list; browse the archives. Ivan Pepelnjak blog.ioshints.info / www.ioshints.info > -Original Message- > From: Ben Jencks [mailto:b...@bjencks.net] > Sent: Tuesday, January 12, 2010 9:28 PM > To: nanog@nanog.org > Subject: BGP testbed tools > > This is obviously a rookie question, but I haven't found anything by > searching. I'm looking to set up a small testbed to simulate our > internal network topology, and I want to have a realistic BGP table > from the fake "upstream" routers. Ideally what I'd like to do is dump > the BGP table from our production routers, strip the immediate > neighbor AS, and load the table into Quagga or OpenBGPD to advertise. > I'm running into two problems: how do you dump BGP tables in a > machine-parseable format from IOS, and how do you make the route > server advertise the routes as they were in the original table, > including the full AS-path, communities, etc? If Quagga/OpenBGPD > aren't the right tools, I'm happy to use something else. > > This seems like it would be a pretty standard thing to do, but none of > the tools I've found seem aimed at this sort of testbed. > > Thanks! > > -Ben Jencks >
RE: more news from Google
I for one would be really happy to see them follow through with this. I was very disappointed when they agreed to censor search results, although I can understand why they did so from a business standpoint... it seemed to go against the google mantra of "do no evil"... I'm skeptical if they'll go through with it... Stefan Fouant, CISSP, JNCIE-M/T www.shortestpathfirst.net GPG Key ID: 0xB5E3803D > -Original Message- > From: Ken Chase [mailto:m...@sizone.org] > Sent: Wednesday, January 13, 2010 12:24 AM > To: nanog@nanog.org > Subject: more news from Google > > I must say I'll have to take a step back from my previous > position/postings > having read this article. > > I just can't figure out their /ANGLE/. :) > > http://googleblog.blogspot.com/2010/01/new-approach-to-china.html > > Well played, google? > > /kc > -- > Ken Chase - k...@heavycomputing.ca - +1 416 897 6284 - Toronto CANADA > Heavy Computing - Clued bandwidth, colocation and managed linux VPS > @151 Front St. W.
RE: BGP testbed tools
> -Original Message- > From: Ben Jencks [mailto:b...@bjencks.net] > Sent: Tuesday, January 12, 2010 3:28 PM > To: nanog@nanog.org > Subject: BGP testbed tools > > This is obviously a rookie question, but I haven't found anything by > searching. I'm looking to set up a small testbed to simulate our > internal network topology, and I want to have a realistic BGP table > from the fake "upstream" routers. Ideally what I'd like to do is dump > the BGP table from our production routers, strip the immediate > neighbor AS, and load the table into Quagga or OpenBGPD to advertise. > I'm running into two problems: how do you dump BGP tables in a > machine-parseable format from IOS, and how do you make the route > server advertise the routes as they were in the original table, > including the full AS-path, communities, etc? If Quagga/OpenBGPD > aren't the right tools, I'm happy to use something else. > > This seems like it would be a pretty standard thing to do, but none of > the tools I've found seem aimed at this sort of testbed. Cisco has a tool called RouteM which they use for lots of BGP scalability testing. I used it a lot back in my testing days at UU. Basically you just saved the contents of "show ip route" and you could replay that using the tool. Man I wish I saved that tool somewhere, it was incredibly valuable. You might be able find someone out there that still has this tool. And please get me an extra copy if you do manage to find it ;) Stefan Fouant, CISSP, JNCIE-M/T www.shortestpathfirst.net GPG Key ID: 0xB5E3803D
Re: more news from Google
Seems logical, after all. Considering the (bad) performances of Google search engine in China compared to Chinese competitors, and considering the fact that wouldn't change a bit in the future, closing offices wouldn't be a bad thing. That doesn't mean closing R&D centers. Ben Le 13/01/2010 06:24, Ken Chase a écrit : I must say I'll have to take a step back from my previous position/postings having read this article. I just can't figure out their /ANGLE/. :) http://googleblog.blogspot.com/2010/01/new-approach-to-china.html Well played, google? /kc
Re: Default Passwords for World Wide Packets/Lightning Edge Equipment
Dymo-style solutions are somewhat lacking when it comes to some complex boxes. Equipment configs, mods, firmware versions, etc can all be fitted onto a nice big sheet that can be slipped back into the rack without much problem in most cases A nifty solution I often claim to have invented in the last century is to spray-adhesive an A4 (or equivalent US size) plastic pocket/"punched pocket" on the TOP face of the equipment before you slide it in, such that a single piece of A4 just protrudes from the front of the rack when you use a self-adhesive tab on it's TOP edge. (the TOP 's above are emphasized, ignore them at your peril; in the first case the plastic will be destroyed the first time the equipment is de-racked and in the second the tab will pull off easily. Problems can be prevented by placing two tabs on the paper, one on each side, exactly over each other.) The trick, to ensure subsequent re-insertion (which is much harder than it seems if you don't) is to also firmly stick a tab to the UPPER INSIDE of the plastic wallet opening. To re-insert, gently lift the plastic tab up. All of this takes up under a millimeter and (unless the equipment designer was drunk) doesn't affect ventilation. On rolling ships, however, the papers require a bit of insulation tape across adjacent case-fronts after each use. /end_stationary_geek_mode pics off-list on request if that doesn't make sense. Gord On Tue, 2010-01-12 at 17:50 -0800, Bill Stewart wrote: > A password recovery method I've found very frustrating is to use the > serial number or similar value that's on a label on the bottom of the > equipment. It's just fine for desktop hardware - but for rack-mounted > gear, it's not uncommon to find out that you need this information > *after* somebody's racked and stacked the hardware, and therefore you > either need to unscrew it (if it was screwed into the rack)
