Re: Notice: Fradulent RIPE ASNs
In message a5dad1a3-9cc9-4560-93bd-85f9e9128...@steffann.nl, Sander Steffann san...@steffann.nl wrote: Sorry, but you post this information on public mailing lists where it can be discussed but where no action can be taken... I think that you mistake formalized centralized action for action more broadly and generally. In fact, it is my belief that action has already been taken, within some networks, to firewall themselves off from the miscreant ASNs and IP blocks that I reported on. (And based upon my beliefs regading these ASNs and IP blocks I would highly recommend that others who have not yet done so follow suit, along with any and all IP space being announced in routes from AS2876.) Nobody else will take your research and submit it to a third party. It's your research: either you submit it to the RIPE NCC and action will be taken where appropriate... As I have already stated, I have no faith whatsoever in the last part of that assertion, and thus elect not to waste my time. These kinds of problems have been going on for literally years now, primarily originating out of Romania. If RIPE seriously wanted to shut down all of this fradulent activity, they could have and would have done so long before now. In the three years since the following report was written, what has changed? Anything? http://threatpost.com/en_us/blogs/attackers-buying-own-data-centers-botnets-spam-122109 It is impossible at that stage in the process for the RIPE NCC to determine that a company is involved in illegal activity. The member in question later proved to be a front for RBN, RIPE said in a statement on the case. But the allocation was made in 2006 and it wasn't until May 2008 that RIPE was able to close down the LIR and get the IP space back. Excuse me, but really? Two *^%$#@ years, just to get some space back from the notorious RBN?? In most regions, a new organization requesting a large allocation will have to go through a fairly rigorous process to show the need for the address space... But not in the RIPE region, apparently. Regards, rfg P.S. ASNs are not nearly in as short supply as IPv4 addresses are, however there _are_ only a finite number of them, and they should not be wasted. As I understand it, generally speaking if you are too small to own even at least one router, then you most certainly do not need your own ASN. I have noted however that the last hop on all traceroutes to all of the domains mentioned in my initial report seems to be 193.226.166.214. The router at that address is, I believe, the router immediately in front of the server(s) that are serving up the home pages for these fraudlent false-front entities. That IP belongs to AS5606 aka GTS Telecom SRL... *not* to any one of these bogus fradulent pseudo-entities. So, within the RIPE region, it appears that one can obtain one's own ASN... or even perhaps a couple dozen of them... without even owning a single router. Somewhow this does not seem to me to be an efficient allocation of finite number resources. P.P.S. Before anyone asks, no, the fact that all routes to all of the web servers for all of the domains mentioned in my initial report all pass through 193.226.166.214 (just before the last hop in all cases) is most certainly *not* the only bit of evidence that indicates that all of these 18 fradulent false-front entities were created/registered/implemented by a single hand (which I am confident they all were). There is plenty more evidence that supports this view also. One has only to look just very slightly below the surface. The evidence is abundant. P.P.P.S. Long before I posted my report here this week, it was already well and widely known that JUMP.RO has an unfortunate tendency to provide IP space to fictitious entities engaged primarily in spamming: http://www.spamhaus.org/rokso/evidence/ROK9107/world-company-register-eu-business-register/rogue-ases-as43332-as4 If the good folks at RIPE NCC have not already known about this for some time then I would suggest that some of them may perhaps be working overtime to avoid knowing. On the other hand, if the RIPE folks have in fact known about what JUMP.RO has been up to, based on earlier published reports of their quastionable activities, then that begs the obvious question: What has RIPE done about this so far? Anything? I'm sure that your urging of me to take further action with respect to this matter is well intentioned, but you have your urging pointed in the wrong direction, I think. The primary onus for further action lies elsewhere.
Re: Notice: Fradulent RIPE ASNs
In message cap-gugvs-kcyosknns+v8r1gdkbpmkuufm1engqvhqh0pr0...@mail.gmail.com William Herrin b...@herrin.us wrote: What is your goal here? Primarily to inform. Forewarned is forearmed. Wouldn't you agree? Is there some action that any particular NANOG participant should take based on your opinion? Dropping all route announcements from the 18 fraudlent ASNs I listed, together with all those from AS2876, and avoiding propagating any of said routes to any other parties would, I think, be an altogether prudent step for all concerned. Unless of couse your are hosting one or more spam research organizations that are eager to collect as much spam as possible. Regards, rfg P.S. It is most probably unnecessary to worry about blocking route announcements relating to any of the separate set of five bogus ASNs documented here: http://www.spamhaus.org/rokso/evidence/ROK9107/world-company-register-eu-business-register/rogue-ases-as43332-as4441 It is unnecessary to block any such route announcements because owing to the good work Spamhaus did already in publicising these other five rogue ASNs... which also got all of their IP space from JUMP.RO... none of them is even announcing routes anymore. (Well, at least that's what it looks like from where I am sitting.)
Re: Notice: Fradulent RIPE ASNs
On Tue, Jan 15, 2013 at 11:36:04PM +0100, Sander Steffann wrote: Sorry, but you post this information on public mailing lists where it can be discussed but where no action can be taken [...] That's not exactly correct. Lots of people on this list are perfectly capable of taking a variety of actions (based on this information) should they choose to do so. I have. I do not understand why you're so adamant about sending this information to an organization primarily distinguished by its incompetence and negligence. If they were actually DOING THEIR JOBS in even minimally diligent fashion, then Ron wouldn't needed to write that note or do the research behind it, because this wouldn't be happening. ---rsk
Re: Notice: Fradulent RIPE ASNs
I do not understand why you're so adamant about sending this information to an organization primarily distinguished by its incompetence and negligence. If they were actually DOING THEIR JOBS in even minimally diligent fashion, then Ron wouldn't needed to write that note or do the research behind it, because this wouldn't be happening. this kind of mostly unfounded vitriole is silly and damages your credibility. no one seriously believes that the RIPE NCC (which is managed by all of its members) is primarily distinguished by their incompetence and negligence. i believe this conversation has now gotten to the plonk stage. can someone compare them to hitler so that we can move on? cheers, t
Re: Notice: Fradulent RIPE ASNs
On Wed, Jan 16, 2013 at 10:07:40AM -0500, Todd Underwood wrote: no one seriously believes that the RIPE NCC (which is managed by all of its members) is primarily distinguished by their incompetence and negligence. Really? Then why, pray tell, haven't they made it a practice to routinely (let's say, once a month) ask the people over at Spamhaus: Hey folks, do you see anything wonky in the space we manage? and then act immediately and decisively on what they get back for an answer? I don't want to speak for Spamhaus, but I suspect that they would be delighted to provide that response, particularly if it led to swift and effective action to make the problem(s) go away. And while I don't always agree with their positions, I've *rarely* found mistakes in their research: they're thorough. (So's Ron, by the way.) This isn't complicated. This isn't expensive. This doesn't require new technology or anything fancy. It's basic due diligence. Yet it clearly hasn't happened. Why the hell not? We live in a time when abuse is epidemic. It's costing us a fortune, and I don't just mean in financial terms, although certainly that's bad enough all by itself. But it doesn't just magically fall out of the sky and land on our servers or routers, or at port 25 on our mail servers. It comes from *somewhere*, and it does so on *somebody's* watch. And when it does so on a chronic and systemic basis, surely it is reasonable to ask questions like Why, if we can so clearly see it arriving at our operation, can they not see it leaving theirs? or Why aren't people paying attention to the primary/most useful sources of information about their own operations? So it's (well past) time to stop giving people a pass for looking the other way or failing to look at all. It's my, your, and everyone's professional responsibility to do everything we possibly can to prevent the networks, hosts, and resources we run from being part of the problem. So yeah: incompetence and negligence are the best words I can find to describe failure to do that. What would you call it? ---rsk
RE: looking glass for Level 3
Ben, Our looking glass platform is indeed back online and now supports IPv6 traceroutes, pings and BGP lookups in the interface (although the web site itself is still only available via IPv4). If you encounter any problems, oddities, or suggestions, please feel free to contact me off list and I'll work with engineering to address them. Again, I apologize for the inconvenience. Please resume enjoying the use of this free tool! :) Dave From: Ben Bartsch [mailto:uwcable...@gmail.com] Sent: Tuesday, January 15, 2013 8:14 AM To: Siegel, David Cc: N. Max Pierson; Cameron Daniel; nanog@nanog.org Subject: Re: looking glass for Level 3 http://lg.level3.net/ is online from Baton Rouge, LA. Any official word from Level3? -bb On Wed, Jan 2, 2013 at 9:27 AM, Siegel, David dave.sie...@level3.commailto:dave.sie...@level3.com wrote: Hi Folks, The site is offline as a result of some security issues that were discovered. As soon as we've got it patched we'll put it back online. Sorry for any inconvenience this may be causing. Dave -Original Message- From: N. Max Pierson [mailto:nmaxpier...@gmail.commailto:nmaxpier...@gmail.com] Sent: Friday, December 28, 2012 11:06 AM To: Cameron Daniel Cc: nanog@nanog.orgmailto:nanog@nanog.org Subject: Re: looking glass for Level 3 Same here. http://lg.level3.net has been down for over a week for me. I know someone in operations I can open a ticket with. On Fri, Dec 28, 2012 at 5:18 AM, Cameron Daniel cdan...@nurve.com.aumailto:cdan...@nurve.com.auwrote: I've had issues getting to it for a week or so. Their NOC was unresponsive when queried. On 2012-12-28 8:23 pm, Peter Ehiwe wrote: I normally use the 3rd one you mentioned but they seem to be down at the moment. Rgds Peter, Sent from my Asus Transformer Pad On Dec 28, 2012 1:51 AM, Tassos Chatzithomaoglou ach...@forthnetgroup.grmailto:ach...@forthnetgroup.gr wrote: Anyone have any looking glass for Level 3? The following seem not to be working http://www.level3.com/**LookingGlass/http://www.level3.com/LookingG lass/ http://lg.level3.net/bgp/bgp.**cgi http://lg.level3.net/bgp/bgp.cgi http://lookingglass.level3.**net/ http://lookingglass.level3.net/ -- Tassos
Re: Notice: Fradulent RIPE ASNs
I'll bet Hitler would have used his real name on the whois entries. There. Now I think we're done. Matt On Jan 16, 2013 7:09 AM, Todd Underwood toddun...@gmail.com wrote: I do not understand why you're so adamant about sending this information to an organization primarily distinguished by its incompetence and negligence. If they were actually DOING THEIR JOBS in even minimally diligent fashion, then Ron wouldn't needed to write that note or do the research behind it, because this wouldn't be happening. this kind of mostly unfounded vitriole is silly and damages your credibility. no one seriously believes that the RIPE NCC (which is managed by all of its members) is primarily distinguished by their incompetence and negligence. i believe this conversation has now gotten to the plonk stage. can someone compare them to hitler so that we can move on? cheers, t
Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6
From the article: Faced with the shortage of IPv4 addresses and the failure of IPv6 to take off, British ISP PlusNet is testing carrier-grade network address translation CG-NAT, where potentially all the ISP's customers could be sharing one IP address, through a gateway. The move is controversial as it could make some Internet services fail, but PlusNet says it is inevitable, and only a test at this stage. http://tech.slashdot.org/story/13/01/16/1417244/uk-isp-plusnet-testing-carrier-grade-nat-instead-of-ipv6 I'm only here to bring you the news. So don't complain to me... -- http://tlmc.fredan.se
Re: Notice: Fradulent RIPE ASNs
it's nice that we've proceded to insult our colleagues. many thanks to mr. petach for achieving the end of this thread. thank you all for participating. On Wed, Jan 16, 2013 at 10:54 AM, Rich Kulawiec r...@gsp.org wrote: On Wed, Jan 16, 2013 at 10:07:40AM -0500, Todd Underwood wrote: no one seriously believes that the RIPE NCC (which is managed by all of its members) is primarily distinguished by their incompetence and negligence. Really? Then why, pray tell, haven't they made it a practice to routinely (let's say, once a month) ask the people over at Spamhaus: Hey folks, do you see anything wonky in the space we manage? and then act immediately and decisively on what they get back for an answer? I don't want to speak for Spamhaus, but I suspect that they would be delighted to provide that response, particularly if it led to swift and effective action to make the problem(s) go away. And while I don't always agree with their positions, I've *rarely* found mistakes in their research: they're thorough. (So's Ron, by the way.) This isn't complicated. This isn't expensive. This doesn't require new technology or anything fancy. It's basic due diligence. Yet it clearly hasn't happened. Why the hell not? We live in a time when abuse is epidemic. It's costing us a fortune, and I don't just mean in financial terms, although certainly that's bad enough all by itself. But it doesn't just magically fall out of the sky and land on our servers or routers, or at port 25 on our mail servers. It comes from *somewhere*, and it does so on *somebody's* watch. And when it does so on a chronic and systemic basis, surely it is reasonable to ask questions like Why, if we can so clearly see it arriving at our operation, can they not see it leaving theirs? or Why aren't people paying attention to the primary/most useful sources of information about their own operations? So it's (well past) time to stop giving people a pass for looking the other way or failing to look at all. It's my, your, and everyone's professional responsibility to do everything we possibly can to prevent the networks, hosts, and resources we run from being part of the problem. So yeah: incompetence and negligence are the best words I can find to describe failure to do that. What would you call it? ---rsk
Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6
On Wed, 16 Jan 2013, fredrik danerklint wrote: From the article: Faced with the shortage of IPv4 addresses and the failure of IPv6 to take off, British ISP PlusNet is testing carrier-grade network address translation CG-NAT, where potentially all the ISP's customers could be sharing one IP address, through a gateway. The move is controversial as it could make some Internet services fail, but PlusNet says it is inevitable, and only a test at this stage. I would hope that PlusNet has valid, well-thought-out reasons for deploying CGN instead of IPv6. Not knowing those, I can only jugde their position on its face: foolish and short-sighted. To quote a NANOG veteran: I encourage my competitors to do this :) jms
Re: Problem with email to Hawaiilink.net email
On 1/15/2013 19:19, david peahi wrote: Does anyone know of any problems in Hawaii with email or DNS problems? Sending from gmail.com and pacbell.net domains, I get: host mail.hawaiilink.net[24.43.223.114] said: 553 5.1.8 emailaddr...@pacbell.net ... Domain of sender address emailaddr...@pacbell.net does not exist (in reply to MAIL FROM command) Regards, David See thread on [outages] currently going on regarding outages happening at the moment in Hawaii, https://puck.nether.net/pipermail/outages/2013-January/005072.html -- staticsafe O ascii ribbon campaign - stop html mail - www.asciiribbon.org Please don't top post - http://goo.gl/YrmAb
Re: Notice: Fradulent RIPE ASNs
On Wed, Jan 16, 2013 at 10:54 AM, Rich Kulawiec r...@gsp.org wrote: On Wed, Jan 16, 2013 at 10:07:40AM -0500, Todd Underwood wrote: no one seriously believes that the RIPE NCC (which is managed by all of its members) is primarily distinguished by their incompetence and negligence. Really? Then why, pray tell, haven't they made it a practice to routinely (let's say, once a month) ask the people over at Spamhaus: Hey folks, do you see anything wonky in the space we manage? and then act immediately and decisively on what they get back for an answer? I don't want to speak for Spamhaus, but I suspect that they would be delighted to provide that response, particularly if it led to swift and effective action to make the problem(s) go away. And while I don't always agree with their positions, I've *rarely* found mistakes in their research: they're thorough. (So's Ron, by the way.) This isn't complicated. This isn't expensive. This doesn't require new technology or anything fancy. It's basic due diligence. Yet it clearly hasn't happened. Why the hell not? Hi Rich, Since this is NANOG, not a forum which represents Internet activities on the Continent, perhaps a better set of questions would be: 1. Has SPAMHAUS attempted to feed relevant portions of their knowledge into ARIN's reporting system for fraudulent registrations and, 2. Understanding that ARIN can only deal with fraudulent registrations, not any other kind of bad-actor behavior, are there improvements to ARIN's process which would help SPAMHAUS and similar organizations feed ARIN actionable knowledge? Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6
On 16 January 2013 16:31, Justin M. Streiner strei...@cluebyfour.orgwrote: On Wed, 16 Jan 2013, fredrik danerklint wrote: From the article: Faced with the shortage of IPv4 addresses and the failure of IPv6 to take off, British ISP PlusNet is testing carrier-grade network address translation CG-NAT, where potentially all the ISP's customers could be sharing one IP address, through a gateway. The move is controversial as it could make some Internet services fail, but PlusNet says it is inevitable, and only a test at this stage. I would hope that PlusNet has valid, well-thought-out reasons for deploying CGN instead of IPv6. Not knowing those, I can only jugde their position on its face: foolish and short-sighted. A lot of ISPs have customers who are foolish and short-sighted (or customers unable to move away from suppliers who are foolish and short-sighted,) and need to support those customers. I'd be very surprised if this move isn't in addition to IPv6 support, even though the article reads as though it is instead of IPv6 support. In other words, it makes sense to be able to support customers who won't move to IPv6 in the short-medium term, even though in the long term it's inevitable. Dan
Re: Notice: Fradulent RIPE ASNs
There have been previous incidents in the ARIN region .. Nothing on the grand scale of what Ron is describing, and just saying, Arin does liaise with the Anti spam world rather better than this. On Wednesday, January 16, 2013, William Herrin wrote: Hi Rich, Since this is NANOG, not a forum which represents Internet activities on the Continent, perhaps a better set of questions would be: 1. Has SPAMHAUS attempted to feed relevant portions of their knowledge into ARIN's reporting system for fraudulent registrations and, 2. Understanding that ARIN can only deal with fraudulent registrations, not any other kind of bad-actor behavior, are there improvements to ARIN's process which would help SPAMHAUS and similar organizations feed ARIN actionable knowledge? -- --srs (iPad)
Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6
On Wed, Jan 16, 2013 at 11:31 AM, Justin M. Streiner strei...@cluebyfour.org wrote: I would hope that PlusNet has valid, well-thought-out reasons for deploying CGN instead of IPv6. Not knowing those, I can only jugde their position on its face: foolish and short-sighted. Move along, nothing to see here. Barring a few fanatics, everyone here has known for several years now that CGN would be required for continuing IPv4 support regardless of the progress of IPv6. If you spin it right, it's a Free network-based firewall to be installed next month. Opt out here if you don't want it. And the fewer than 1 in 10 folks who opt out really aren't a problem. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Notice: Fradulent RIPE ASNs
Please, please someone go to http://meemsy.com/videos/add/24 and create 'Hitler reacts to the fraudulent Romanian ASNs' After that we can move on. :=) ~C. On 1/16/13 2:01 PM, Matthew Petach wrote: I'll bet Hitler would have used his real name on the whois entries. There. Now I think we're done. Matt On Jan 16, 2013 7:09 AM, Todd Underwood toddun...@gmail.com wrote: I do not understand why you're so adamant about sending this information to an organization primarily distinguished by its incompetence and negligence. If they were actually DOING THEIR JOBS in even minimally diligent fashion, then Ron wouldn't needed to write that note or do the research behind it, because this wouldn't be happening. this kind of mostly unfounded vitriole is silly and damages your credibility. no one seriously believes that the RIPE NCC (which is managed by all of its members) is primarily distinguished by their incompetence and negligence. i believe this conversation has now gotten to the plonk stage. can someone compare them to hitler so that we can move on? cheers, t
Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6
On Wed, 16 Jan 2013, Daniel Ankers wrote: In other words, it makes sense to be able to support customers who won't move to IPv6 in the short-medium term, even though in the long term it's inevitable. I agree, IPv6 isn't an answer to we're out of IPv4 addresses right now. So CGNAT44 i combination with IPv6 rollout makes perfect sense. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6
I would hope that PlusNet has valid, well-thought-out reasons for deploying CGN instead of IPv6. Not knowing those, I can only jugde their position on its face: foolish and short-sighted. Move along, nothing to see here. Barring a few fanatics, everyone here has known for several years now that CGN would be required for continuing IPv4 support regardless of the progress of IPv6. If you spin it right, it's a Free network-based firewall to be installed next month. Opt out here if you don't want it. And the fewer than 1 in 10 folks who opt out really aren't a problem. Even tough you have very good arguments, my suggestion would be to have a class A network (I got that right, right?) for all the users and only having 6rd as service on that network. -- //fredan http://tlmc.fredan.se
Re: Dreamhost hijacking my prefix...
On 1/11/13 8:28 PM, Scott Weeks wrote: --- andree+na...@toonk.nl wrote: From: Andree Toonk andree+na...@toonk.nl Here's some more data showing an announcement for 150.182.208.0/20 originated by 26347 http://www.ris.ripe.net/mt/rissearch-result.html?aspref=150.182.208.0%2F20preftype=EMATCHrrc_id=1000peer=ALLstartday=20130111starthour=00startmin=00startsec=00endday=20130111endhour=19endmin=16endsec=26outype=htmlsubmit=Search.submit=type - RIPE needs to fix on their web site: Please turn on the cookies on your browser to view this site. It doesn't have to be this way... scott Hello Scott, I took a look at this site and unfortunately the use of cookies is very ingrained into the code. Removing the requirement breaks all functionality of www.ris.ripe.net and changing the functionality would require a rewrite of the site. Our intention is that http://stat.ripe.net/ will replace all functionality currently under www.ris.ripe.net. If RIPEstat doesn't provide the functionality you are looking for, please request it by emailing us at s...@ripe.net. Regards John
Re: Notice: Fradulent RIPE ASNs
ni lar has requested to add someone, and so has kanchana, so i think our group reservation is full will try to check this morning to confirm On Wed, 16 Jan 2013, Matthew Petach wrote: I'll bet Hitler would have used his real name on the whois entries. There. Now I think we're done. Matt On Jan 16, 2013 7:09 AM, Todd Underwood toddun...@gmail.com wrote: I do not understand why you're so adamant about sending this information to an organization primarily distinguished by its incompetence and negligence. If they were actually DOING THEIR JOBS in even minimally diligent fashion, then Ron wouldn't needed to write that note or do the research behind it, because this wouldn't be happening. this kind of mostly unfounded vitriole is silly and damages your credibility. no one seriously believes that the RIPE NCC (which is managed by all of its members) is primarily distinguished by their incompetence and negligence. i believe this conversation has now gotten to the plonk stage. can someone compare them to hitler so that we can move on? cheers, t
Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6
On Wed, Jan 16, 2013 at 12:09 PM, fredrik danerklint fredan-na...@fredan.se wrote: Barring a few fanatics, everyone here has known for several years now that CGN would be required for continuing IPv4 support regardless of the progress of IPv6. If you spin it right, it's a Free network-based firewall to be installed next month. Opt out here if you don't want it. And the fewer than 1 in 10 folks who opt out really aren't a problem. Even tough you have very good arguments, my suggestion would be to have a class A network (I got that right, right?) for all the users and only having 6rd as service on that network. ARIN and IETF cooperated last year to allocate 100.64.0.0/10 for CGN use. See RFC 6598. This makes it possible to implement a CGN while conflicting with neither the user's RFC1918 activity nor the general Internet's use of assigned addresses. Hijacking a /8 somewhere instead is probably not a great move. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: RIPE cookies [was]: Dreamhost hijacking my prefix...
--- jb...@ripe.net wrote: From: john jb...@ripe.net - On 1/11/13 8:28 PM, Scott Weeks wrote: - RIPE needs to fix on their web site: Please turn on the cookies on your browser to view this site. It doesn't have to be this way... - I took a look at this site and unfortunately the use of cookies is very ingrained into the code. Removing the requirement breaks all functionality of www.ris.ripe.net and changing the functionality would require a rewrite of the site. Our intention is that http://stat.ripe.net/ will replace all functionality currently under www.ris.ripe.net. If RIPEstat doesn't provide the functionality you are looking for, please request it by emailing us at s...@ripe.net. -- Hi john, First, thank you for responding. Second, what a bummer that RIPE's code was written that way in the first place. If it's done that way in stat.ripe.net as well, I (and others who are security-minded) will never get to use your site. Maybe give brian at merit a holler before writing stat.ripe.net in such a way that one MUST allow cookies just to look at the site. Maybe it's too late already. :-( I haven't looked, yet... scott
Suggestions for the future on your web site: (was cookies, and before that Re: Dreamhost hijacking my prefix...)
On 1/16/2013 9:40 AM, john wrote: I took a look at this site and unfortunately the use of cookies is very ingrained into the code. Removing the requirement breaks all functionality of www.ris.ripe.net and changing the functionality would require a rewrite of the site. Sooner or later, you'll get to a place where you consider a major update, and perhaps then you'll consider emulating NANOG's site. However... Our intention is that http://stat.ripe.net/ will replace all functionality currently under www.ris.ripe.net. If RIPEstat doesn't provide the functionality you are looking for, please request it by emailing us at s...@ripe.net. I was curious, and I went to look at it. Please consider using some other color than lovely amber yellow you've chosen. It's very pretty, and exhausting to look at for any length of time. I'm a HUGE fan of gray scales, and of text. I see that you want a cookie when I want to look at one of the videos, but blocking it doesn't hurt me. Here's where you did something right. The video plays on my (pretty old) Firefox, which has no Flash (hooray!). The cookie stays around for a YEAR (if I let it), and has the following stuff: Name: stat-csrftoken Content: 7f12a95b8e274ab940287407a14fc348 Host: stat.ripe.net Path: / Send For: Any type of connection Expires: Wednesday, January 15, 2014 11:29:34 AM To your credit, you only ask once, but you ought to ask zero times. The site's not bad, but please consider changing the yellow to black. Less beauty, more utility. -- Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. Brian W. Kernighan
Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6
Even tough you have very good arguments, my suggestion would be to have a class A network (I got that right, right?) for all the users and only having 6rd as service on that network. ARIN and IETF cooperated last year to allocate 100.64.0.0/10 for CGN use. See RFC 6598. This makes it possible to implement a CGN while conflicting with neither the user's RFC1918 activity nor the general Internet's use of assigned addresses. Hijacking a /8 somewhere instead is probably not a great move. Ok. If I have calculated the netmasks right that would mean to set aside: 2001:0DB8:6440::/42 for the use of 6rd service: 2001:0DB8:6440:::/64 = 100.64.0.0 2001:0DB8:647F:::/64 = 100.127.255.255 -- //fredan http://tlmc.fredan.se
Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6
Hi, If I have calculated the netmasks right that would mean to set aside: 2001:0DB8:6440::/42 for the use of 6rd service: 2001:0DB8:6440:::/64 = 100.64.0.0 2001:0DB8:647F:::/64 = 100.127.255.255 You probably should add a few extra bits for subnetting behind the 6rd CPE. Delegating one /64 would be annoying as more and more CPEs have separate home/office/guest networks. Giving a /56 to each customer would be good and would only take an IPv6 /34 to map from 100.64.0.0/10. That is a quarter of the smallest IPv6 allocation an ISP can get. ISPs can get plenty of IPv6 address space these days if they need it. Smaller ISPs don't need to map the whole 100.64.0.0/10, they could just start with 100.64.0.0/16 for example, which would only take a /40 to give every customer a /56. More blocks can always be added to the 6rd setup later. Cheers, Sander
Intermittent incorrect DNS resolution?
Hi everyone, I'm having an unusual DNS problem and would appreciate feedback. For the zones in question, primary DNS is provided by GoDaddy and secondary DNS by DNS Made Easy. Over a week ago we made changes to several A records (including wildcards on two different zones), all already having a TTL no greater than one hour. The new IPs on those A records have taken many millions of requests since the changes. Occasionally, a small amount of traffic appears at the old IPs that those A records had. This is HTTP traffic. Packet captures of this traffic show various Host headers. Attempting to resolve those various Host headers from various networks in Canada against various random private and public resolvers and against the authoritative NSs all yield correct results (i.e. new IPs). However, both GoDaddy and DNS Made Easy use anycast, which makes it less likely that I can see the entire picture of what's happening. I suspect that somewhere, one of their servers has the wrong data, or some resolver is misbehaving, but based on the pattern/traffic/volume/randomization of hostnames, the resolver theory is less likely. I haven't analyzed the source IPs yet to see if they're in a particular set of countries. I've opened a ticket with DNS Made Easy and they replied very quickly suggesting the problem is not with them. I've opened a ticket with GoDaddy and...well, it's GoDaddy, so I don't expect much (no response yet). Any ideas? Can folks try resolving eriktest.uberflip.com and post here with details only if it resolves to an IP starting with 76.9 (old IPs)? Thanks Erik
Re: Intermittent incorrect DNS resolution?
On Wed, Jan 16, 2013 at 2:00 PM, Erik Levinson erik.levin...@uberflip.com wrote: Hi everyone, I'm having an unusual DNS problem and would appreciate feedback. For the zones in question, primary DNS is provided by GoDaddy and secondary DNS by DNS Made Easy. Over a week ago we made changes to several A records (including wildcards on two different zones), all already having a TTL no greater than one hour. The new IPs on those A records have taken many millions of requests since the changes. Occasionally, a small amount of traffic appears at the old IPs that those A records had. This is HTTP traffic. Packet captures of this traffic show various Host headers. Attempting to resolve those various Host headers from various networks in Canada against various random private and public resolvers and against the authoritative NSs all yield correct results (i.e. new IPs). However, both GoDaddy and DNS Made Easy use anycast, which makes it less likely that I can see the entire picture of what's happening. I suspect that somewhere, one of their servers has the wrong data, or some resolver is misbehaving, but based on the pattern/traffic/volume/randomization of hostnames, the resolver theory is less likely. I haven't analyzed the source IPs yet to see if they're in a particular set of countries. I've opened a ticket with DNS Made Easy and they replied very quickly suggesting the problem is not with them. I've opened a ticket with GoDaddy and...well, it's GoDaddy, so I don't expect much (no response yet). Any ideas? Can folks try resolving eriktest.uberflip.com and post here with details only if it resolves to an IP starting with 76.9 (old IPs)? Thanks Erik The other likely cause of this is local cacheing nameservers somewhere at some ISP or major site, that do not respect TTL values for some reason. This is sadly a common problem - not statistically, most nameservers do the right thing, but if you run big sites and flip things, there's always a long tail of people whose nameservers just didn't get it. -- -george william herbert george.herb...@gmail.com
Re: Intermittent incorrect DNS resolution?
On Wed, Jan 16, 2013 at 5:00 PM, Erik Levinson erik.levin...@uberflip.com wrote: Any ideas? Can folks try resolving eriktest.uberflip.com and post here with details only if it resolves to an IP starting with 76.9 (old IPs)? for d in $(seq 1 1000); do dig @pdns01.domaincontrol.com. eriktest.uberflip.com /tmp/tst ; dig @pdns02.domaincontrol.com. eriktest.uberflip.com /tmp/tst ; dig @ns5.dnsmadeeasy.com. eriktest.uberflip.com /tmp/tst ; dig @ns6.dnsmadeeasy.com. eriktest.uberflip.com /tmp/tst; dig @ns7.dnsmadeeasy.com. eriktest.uberflip.com /tmp/tst ; done you tried something like this already I assume?
Re: Intermittent incorrect DNS resolution?
Also client programs don't always honor TTLs either. For example, JAVA defaults to ignoring TTLs and holding IPs forever. *networkaddress.cache.ttl (default: -1)* Indicates the caching policy for successful name lookups from the name service. The value is specified as as integer to indicate the number of seconds to cache the successful lookup. A value of -1 indicates cache forever. Depending on who your clients are, your milage may vary. .r' On 16 January 2013 14:13, George Herbert george.herb...@gmail.com wrote: On Wed, Jan 16, 2013 at 2:00 PM, Erik Levinson erik.levin...@uberflip.com wrote: Hi everyone, I'm having an unusual DNS problem and would appreciate feedback. For the zones in question, primary DNS is provided by GoDaddy and secondary DNS by DNS Made Easy. Over a week ago we made changes to several A records (including wildcards on two different zones), all already having a TTL no greater than one hour. The new IPs on those A records have taken many millions of requests since the changes. Occasionally, a small amount of traffic appears at the old IPs that those A records had. This is HTTP traffic. Packet captures of this traffic show various Host headers. Attempting to resolve those various Host headers from various networks in Canada against various random private and public resolvers and against the authoritative NSs all yield correct results (i.e. new IPs). However, both GoDaddy and DNS Made Easy use anycast, which makes it less likely that I can see the entire picture of what's happening. I suspect that somewhere, one of their servers has the wrong data, or some resolver is misbehaving, but based on the pattern/traffic/volume/randomization of hostnames, the resolver theory is less likely. I haven't analyzed the source IPs yet to see if they're in a particular set of countries. I've opened a ticket with DNS Made Easy and they replied very quickly suggesting the problem is not with them. I've opened a ticket with GoDaddy and...well, it's GoDaddy, so I don't expect much (no response yet). Any ideas? Can folks try resolving eriktest.uberflip.com and post here with details only if it resolves to an IP starting with 76.9 (old IPs)? Thanks Erik The other likely cause of this is local cacheing nameservers somewhere at some ISP or major site, that do not respect TTL values for some reason. This is sadly a common problem - not statistically, most nameservers do the right thing, but if you run big sites and flip things, there's always a long tail of people whose nameservers just didn't get it. -- -george william herbert george.herb...@gmail.com
Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6
On Wed, Jan 16, 2013 at 2:53 PM, fredrik danerklint fredan-na...@fredan.se wrote: ARIN and IETF cooperated last year to allocate 100.64.0.0/10 for CGN use. See RFC 6598. This makes it possible to implement a CGN while conflicting with neither the user's RFC1918 activity nor the general Internet's use of assigned addresses. Hijacking a /8 somewhere instead is probably not a great move. If I have calculated the netmasks right that would mean to set aside: 2001:0DB8:6440::/42 for the use of 6rd service: 2001:0DB8:6440:::/64 = 100.64.0.0 2001:0DB8:647F:::/64 = 100.127.255.255 Sander already touched on this, but when implementing 6rd you'll want *at least* 4 bits on the subnetting side of the IPv6 block associated with each IPv4 address and you'll want that netmask to be evenly divisible by 4. A /60 or a /56, not a /64. In IPv4 your customer has a DSL router, potentially with distinct wired and wireless LANs running different RFC1918 address blocks. In IPv6 each of those LANs will consume a /64, so he'll need more than one. Selecting a netmask evenly divisible by 4 has two major benefits. First, it exactly matches one character in the written address. The customer doesn't have ...:ABC4:* through ...:ABC7:*, he has ...:ABC*::. Second, each delegable RDNS zone takes up the same 4 bits so the assignment will be right on an RNDS zone boundary. Even tough you have very good arguments, my suggestion would be to have a class A network (I got that right, right?) for all the users and only having 6rd as service on that network. I assume you meant this a little differently than what you wrote here. It wouldn't make any kind of sense to stand up a private IPv4 network with no IPv4 Internet connection in order to facilitate IPv6 via a 6rd deployment. For one thing it'd be a Rube Goldberg machine. For another, I suspect you'd find it very challenging to acquire a threshold number of paying customers for an IPv6-only network at the moment. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Intermittent incorrect DNS resolution?
On Wed, Jan 16, 2013 at 5:24 PM, Erik Levinson erik.levin...@uberflip.com wrote: Yes, though I tried way less than 1000 in the loop. :) given a large list of recursives you could even test resolution through a bunch of recursive servers...
Re: Intermittent incorrect DNS resolution?
Yes, though I tried way less than 1000 in the loop. On 16/01/13 05:13 PM, Christopher Morrow wrote: On Wed, Jan 16, 2013 at 5:00 PM, Erik Levinson erik.levin...@uberflip.com wrote: Any ideas? Can folks try resolving eriktest.uberflip.com and post here with details only if it resolves to an IP starting with 76.9 (old IPs)? for d in $(seq 1 1000); do dig @pdns01.domaincontrol.com. eriktest.uberflip.com /tmp/tst ; dig @pdns02.domaincontrol.com. eriktest.uberflip.com /tmp/tst ; dig @ns5.dnsmadeeasy.com. eriktest.uberflip.com /tmp/tst ; dig @ns6.dnsmadeeasy.com. eriktest.uberflip.com /tmp/tst; dig @ns7.dnsmadeeasy.com. eriktest.uberflip.com /tmp/tst ; done you tried something like this already I assume?
Re: Intermittent incorrect DNS resolution?
Good point. While I haven't checked the distribution of source IPs yet, I briefly grepped for the User-Agent headers in the tcpdump output, and there's a higher than expected bot presence, particularly Baidu. That said, there are also normal UAs (whatever that means, with every device/software pretending to be something else these days). On 16/01/13 05:20 PM, RijilV wrote: Also client programs don't always honor TTLs either. For example, JAVA defaults to ignoring TTLs and holding IPs forever. *networkaddress.cache.ttl (default: -1)* Indicates the caching policy for successful name lookups from the name service. The value is specified as as integer to indicate the number of seconds to cache the successful lookup. A value of -1 indicates cache forever. Depending on who your clients are, your milage may vary. .r'
Re: Intermittent incorrect DNS resolution?
True...I did try 4.2.2.2 / 8.8.8.8 and some local ones here. All looked fine. With anycast / DB and other backend clusters / load balancing / whatever else behind the scenes, it's hard to get a good idea of what's actually happening. Might be stuck with running this infra for a while longer and seeing if the traffic disappears eventually. On 16/01/13 05:25 PM, Christopher Morrow wrote: On Wed, Jan 16, 2013 at 5:24 PM, Erik Levinson erik.levin...@uberflip.com wrote: Yes, though I tried way less than 1000 in the loop. :) given a large list of recursives you could even test resolution through a bunch of recursive servers...
Re: Intermittent incorrect DNS resolution?
On Wed, Jan 16, 2013 at 5:00 PM, Erik Levinson erik.levin...@uberflip.com wrote: I suspect that somewhere, one of their servers has the wrong data, or some resolver is misbehaving, but based on the pattern/traffic/volume/randomization of hostnames, the resolver theory is less likely. I haven't analyzed the source IPs yet to see if they're in a particular set of countries. Hi Erik, Look up DNS pinning. I can't rule out the possibility of a faulty DNS server but it's far more likely your customers' web browsers are simply ignoring the DNS TTL. Malfunctioning as designed. If you keep it live, you'll notice a falling trickle of traffic to the old address for the next year or so. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Anyone from google networking on this list?
If there is anyone from Google Networking here on the list can you contact me offlist please. I want to talk about 60 Hudson. Todd Glassey -- Regards TSG Ex-Cruce-Leo //Confidential Mailing - Please destroy this if you are not the intended recipient.
Re: Intermittent incorrect DNS resolution?
Consider the possibility that some end users (or even corp networks) may have hardcoded your hosts' translation into their hosts files or perhaps corporate proxy firewalls that allow access onto to whitelisted web sites. They will continue to point to the old IP addresses until you shutdown the service and they call you to inquire why *you* broke your system :-) If this HTTP service has a GUI (aka: web page versus credit card transactions), you should put up a warning on the web page whenever it is being accessed via the old IP address.
Netflow Nfsen Server Hardware
We are looking to purchase a new server for Netflow exports. This will mainly be used to evaluate our transit bandwidth for potential peering opportunities. A long data retention is not a high priority. Our combined transit bandwidth is around 6 Gbps and increasing all the time. Looking to get a sanity check on the server hardware required. We will be using Nfsen as the collector. Would one of the below configurations be okay to handle such as task? If not, does anyone have any other recommendations. Thanks in advance. Tim PowerEdge R610 - 2x Intel E5540, 2.53GHz Quad Core Processor 32GB RAM 2x 300gb 10k 2.5 SAS HDD PERC6i RAID Controller iDRAC6 Enterprise Redundant Power Supply ReadyRails PowerEdge R610 - 2x Intel E5540, 2.53GHz Quad Core Processor 64GB RAM 6x 300gb 10k 2.5 SAS HDD PERC6i RAID Controller iDRAC6 Enterprise Redundant Power Supply ReadyRails
Symantec / Message Labs contact?
Hello, We are having a really hard time getting a hold of Symantec / Message Labs regarding one of our mail servers getting a Connection Refused when trying to send to any domains hosted with Symantec / Message Labs. Can someone please contact me? Sincerely, Bobby Glover Director of Information Services SVI Incorporated
DNS resolver addresses for Sprint PCS/3G/4G
I've noticed, for quite some time, that there seems to be a specific category of slow that I see in using apps on my HTC Supersonic/Sprint EVO, on both their 3G and 4G networks, and I wonder if it isn't because the defined resolvers are 8.8.4.4 and 8.8.8.8, which aren't *on* Sprint's networks. Does anyone have, in their magic bag of tricks, IP addresses for resolvers that *are* native to that network, that they wouldn't mind whispering in my ear? I don't suppose Android's smart enough to swap that file around when the IP core notices the uplink has changed? (Yes, I know, that's properly a question for XDA-Devel...) Offlist is fine. Yes, I owe the list summaries on a couple earlier questions; I still have the details to write from. :-} Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
Re: Intermittent incorrect DNS resolution?
- Original Message - From: Erik Levinson erik.levin...@uberflip.com I'm having an unusual DNS problem and would appreciate feedback. For the zones in question, primary DNS is provided by GoDaddy and secondary DNS by DNS Made Easy. Over a week ago we made changes to several A records (including wildcards on two different zones), all already having a TTL no greater than one hour. The new IPs on those A records have taken many millions of requests since the changes. Occasionally, a small amount of traffic appears at the old IPs that those A records had. This is HTTP traffic. Packet captures of this traffic show various Host headers. I'm a touch surprised to find that no one has mentioned the facet of Windows OSs that requires ipconfig /flushdns in some such circumstances... Not only may *browsers* be caching DNS lookups without regard to TTLs, the *OS* might be doing it to you too, in circumstances I was never quite able to get a handle on. XP was known to do this, as late as SP3; I'm not sure about V or 7. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6
On 16/01/2013 08:31, Justin M. Streiner wrote: On Wed, 16 Jan 2013, fredrik danerklint wrote: From the article: Faced with the shortage of IPv4 addresses and the failure of IPv6 to take off, British ISP PlusNet is testing carrier-grade network address translation CG-NAT, where potentially all the ISP's customers could be sharing one IP address, through a gateway. The move is controversial as it could make some Internet services fail, but PlusNet says it is inevitable, and only a test at this stage. I would hope that PlusNet has valid, well-thought-out reasons for deploying CGN instead of IPv6. Not knowing those, I can only jugde their position on its face: foolish and short-sighted. Apparently they aren't _totally_ blind to v6, but it sounds like it's been put in the mystery when we have a spare moment! bin: http://community.plus.net/forum/index.php/topic,106125.0.html S.
How are operators using IRR?
How are operators using the data available in the various IRRs? Using an example: AS1 is your customer AS1 has AS2, AS3 and AS4 described as customers in an IRR Also assume AS2 has IRR data describing AS1000 and AS2000 as it's customers. Are operators building AS path regexes such as the following automatically from IRR and applying that to your BGP sessions? AS1{1,} AS1{1,} AS2{1,} AS1{1,} AS3{1,} AS1{1,} AS2{1,} AS1000{1,} AS1{1,} AS2{1,} AS2000{1,} I would imagine most operators that are building policy from IRR are building prefix lists to limit what they are accepting. Is this being paired with some AS path filtering? Are operators just traversing an AS-SET as far as it will go and building prefix lists to represent all intended prefixes to be heard on a session regardless of who originates them? Is the possibility of AS1000 hijacking AS2000 prefixes towards AS2 a problem you as the upstream to AS1 need to consider? (Last question assumes AS2 made a mistake and wasn't filtering properly on it's own customers and AS1 is just accepting all prefixes under the cone of AS2) Thanks
GPS attack vector
Do you use GPS to provide any mission critical services (like time of day) in your network? Have you already see this? (I hadn't) http://arstechnica.com/security/2012/12/how-to-bring-down-mission-critical-gps-networks-with-2500/ Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
Re: Intermittent incorrect DNS resolution?
From nanog-bounces+bonomi=mail.r-bonomi@nanog.org Wed Jan 16 18:21:21 2013 Date: Wed, 16 Jan 2013 19:16:57 -0500 (EST) From: Jay Ashworth j...@baylink.com To: NANOG nanog@nanog.org Subject: Re: Intermittent incorrect DNS resolution? I'm a touch surprised to find that no one has mentioned the facet of Windows OSs that requires ipconfig /flushdns in some such circumstances... Winbloze has to be rebooted frequently enough that this is rarely an issue. wry grin
Re: Intermittent incorrect DNS resolution?
On 2013-01-16, at 14:33, Erik Levinson erik.levin...@uberflip.com wrote: True...I did try 4.2.2.2 / 8.8.8.8 and some local ones here. All looked fine. I sent queries from 270+ different locations for the domains you mentioned off-list and I didn't see any inconsistencies. The persistent host-caching/browser-caching theories seem like your best bet (or my 270+ locations weren't sufficiently diverse to catch a stale zone being served by an anycast authority server). Joe
Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6
In message 50f70524.4020...@fredan.se, fredrik danerklint writes: Even tough you have very good arguments, my suggestion would be to have a class A network (I got that right, right?) for all the users and only havi ng 6rd as service on that network. ARIN and IETF cooperated last year to allocate 100.64.0.0/10 for CGN use. See RFC 6598. This makes it possible to implement a CGN while conflicting with neither the user's RFC1918 activity nor the general Internet's use of assigned addresses. Hijacking a /8 somewhere instead is probably not a great move. Ok. If I have calculated the netmasks right that would mean to set aside: 2001:0DB8:6440::/42 for the use of 6rd service: 2001:0DB8:6440:::/64 = 100.64.0.0 2001:0DB8:647F:::/64 = 100.127.255.255 No. With 6rd you DROP the top 10 bits and you give every customer a /56. And you can repeat the exercise 4 times within a /32. /etc/dhcpd.conf: subnet 100.64.0.0 netmask 255.240.0.0 { range 100.64.0.2 100.64.255.254; router 100.64.0.1; option 6rd 10 34 2001:DB8:: 2001:DB8::1; } subnet 100.64.0.0 netmask 255.240.0.0 { range 100.64.0.2 100.64.255.254; router 100.64.0.1; option 6rd 10 34 2001:DB8:4000: 2001:DB8:4000:1; } subnet 100.64.0.0 netmask 255.240.0.0 { range 100.64.0.2 100.64.255.254; router 100.64.0.1; option 6rd 10 34 2001:DB8:8000: 2001:DB8:8000:1; } subnet 100.64.0.0 netmask 255.240.0.0 { range 100.64.0.2 100.64.255.254; router 100.64.0.1; option 6rd 10 34 2001:DB8:c000: 2001:DB8:C000:1; } -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: DNS resolver addresses for Sprint PCS/3G/4G
On Wed, Jan 16, 2013 at 7:13 PM, Jay Ashworth j...@baylink.com wrote: I've noticed, for quite some time, that there seems to be a specific category of slow that I see in using apps on my HTC Supersonic/Sprint EVO, on both their 3G and 4G networks, and I wonder if it isn't because the defined resolvers are 8.8.4.4 and 8.8.8.8, which aren't *on* Sprint's networks. doesn't sprint intercept all udp/53 on their cellular network?
Re: Intermittent incorrect DNS resolution?
Thanks Joe and thanks everyone else for the on and off-list replies. Quite insightful. I think we've reached the consensus that the problem is the ignoring of TTLs as opposed to misbehaving/stale authoritative servers. So for now I shall wait. To give an idea of the scale of the problem right now, I'm getting thousands of requests per minute to a new IP vs. about two requests per minute on the equivalent old IP, with over 60% of the latter being Baidu, but also a bit of Googlebot and other random bot and non-bot UAs. Perhaps next week I'll unbind some old IPs for a few minutes to see what happens. -Original Message- From: Joe Abley jab...@hopcount.ca Sent: Wednesday, January 16, 2013 8:57pm To: Erik Levinson erik.levin...@uberflip.com Cc: Christopher Morrow morrowc.li...@gmail.com, nanog@nanog.org Subject: Re: Intermittent incorrect DNS resolution? On 2013-01-16, at 14:33, Erik Levinson erik.levin...@uberflip.com wrote: True...I did try 4.2.2.2 / 8.8.8.8 and some local ones here. All looked fine. I sent queries from 270+ different locations for the domains you mentioned off-list and I didn't see any inconsistencies. The persistent host-caching/browser-caching theories seem like your best bet (or my 270+ locations weren't sufficiently diverse to catch a stale zone being served by an anycast authority server). Joe
Re: GPS attack vector
This could also be a big show stopper for cellular and radio networks. Many use a 10.000 MHz timebase distributed from a GPS disciplined local oscillator for precise time and frequency synchronization. Without this tight frequency stabilization from a GPS receiver, major drama will occur on the borders between simulcasting repeater coverage areas, cell sites, etc. Can anyone say Spaghetti mess? Ow my brain hurts. Tom Morris, KG4CYX Chairman, South Florida Tropical Hamboree Mad Scientist, Miami Children's Museum This message sent from a mobile device. Silly typos provided free of charge. On Jan 16, 2013 8:08 PM, Jay Ashworth j...@baylink.com wrote: Do you use GPS to provide any mission critical services (like time of day) in your network? Have you already see this? (I hadn't) http://arstechnica.com/security/2012/12/how-to-bring-down-mission-critical-gps-networks-with-2500/ Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
Re: DNS resolver addresses for Sprint PCS/3G/4G
- Original Message - From: Christopher Morrow morrowc.li...@gmail.com On Wed, Jan 16, 2013 at 7:13 PM, Jay Ashworth j...@baylink.com wrote: I've noticed, for quite some time, that there seems to be a specific category of slow that I see in using apps on my HTC Supersonic/Sprint EVO, on both their 3G and 4G networks, and I wonder if it isn't because the defined resolvers are 8.8.4.4 and 8.8.8.8, which aren't *on* Sprint's networks. doesn't sprint intercept all udp/53 on their cellular network? I don't know. If they do, and said boxes are slow, that could explain it, too. On the gripping hand, I am running Cyanogen, which isn't Sprint specific, and that could explain it too. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
Re: How are operators using IRR?
Hi, On Wed, 16 Jan 2013 19:55:44 -0500 ML m...@kenweb.org wrote: Is this being paired with some AS path filtering? I am a huge fan of path filtering, but I have so very little paths to maintain that I can say so. I guess most operators to not filter paths, and building prefix lists is more or less current practice. Just from what I have seen so far. I asked about best practice about building filteers from IRR data a while ago on NANOG, but there were not really an answer. Cheers Dan