Re: junos config commit question
that's what the "commit confirm xxx" command is for. :) Andrew On 2/16/22 3:23 PM, Jay Hennigan wrote: On 2/16/22 09:56, Owen DeLong via NANOG wrote: You can also do: config commit rollback 1 commit Unless you're remote and breaks your ability to reach the box. Then you're hosed after the first "commit". -- Andrew Fried andrew.fr...@gmail.com
Re: Dyn DDoS this AM?
The brutal reality in todays world is that anyone that relies on the Internet is just asking for stuff like this. No service is safe. Andrew Andrew Fried andrew.fr...@gmail.com On 10/21/16 5:58 PM, Randy Bush wrote: > anyone who relies on a single dns provider is just asking for stuff such > as this. > > randy >
Re: Cogent - ATT issue?
My connectivity between Fios and Cogent in Washington DC has been mostly down for the past hour. Andrew Andrew Fried andrew.fr...@gmail.com On 4/2/14, 3:03 PM, Eric wrote: > Anyone know if there is a connectivity issue between Cogent and ATT in the > northeast? We're seeing random timeouts to some systems we have in an ATT > data center but only from sources on Cogent's network. > > Thanks... > > - Eric :) >
Re: spamassassin hole again?
Any chance you could provide a *clue* as to what you're seeing, eg message subject, from, etc??? Andrew Fried andrew.fr...@gmail.com On 4/13/14, 1:00 AM, Babak Farrokhi wrote: > We are not using spamasassin and only major RBLs in place and seeing the same > wave of spam. Seems like a new botnot has just appeared. > > -- Babak >
Re: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality
++1 Andrew Fried andrew.fr...@gmail.com On 5/10/14, 2:42 PM, Patrick W. Gilmore wrote: > Nice discussion about history & motivations. Not completely correct, but it's > always fun to argue over history, and over motivations, since both are open > to intepretation. > > Personally, I am interested in the future, and specifically in market-driven > solutions to our problems. Call me a capitalist if you like, but I believe in > a functioning market, we can get a very good approximation of "fair". > > If Company A and Company B have a mutual customer, and that customer needs > both companies to perform a task, the market will find a way to make those > two companies work together. Either that, or the customer will replace A or > B, whichever the customer feels is underperforming, with Company C. > > We have that situation today. Streaming Company wants to send End User of > Broadband Company some content. If Streaming Company sucks - not enough > titles, lousy customer service, high price, poor performance, etc., etc. - > End User is free to select Streaming Company 2. And contrary to popular > belief, there are plenty of "Streaming Company 2s" available. Besides NF, > there is Hulu, Amazon, iTunes, iPlayer, etc. They might have different > models, but they all allow you to access streaming content, so choice is > available. > > And here is where we get into the problem. Should End User believe Broadband > Company sucks, they frequently cannot choose Broadband Company 2. I know I > cannot, my choices are Comcast @ 100 Mbps or Verizon at 1.1 (yes, > one-point-one) Mbps. So when Streaming Company sucks, but they suck because > Broadband company is doing something I do not like, I cannot "vote with my > wallet" and pick Broadband Company 2. I have no choice but to pick Streaming > Company 2, even if I think the problem is Broadband Company's fault. (To be > clear, I am not a NF subscriber - any more - and so this is not a NF/CC > thing, I'm just talking generalities.) > > Put more succinctly, there is no functioning market. therefore there cannot > be a market-based solution. > > Personally, I view that as about the most Un-American, Un-Capitalistic thing > there is. > > Lots of people have suggested a simple, if very difficult, fix to this > problem. Make the underlying physical infrastructure a regulated monopoly, > i.e. a Utility. Then allow anyone to run services over that physical > infrastructure. > > This is not pipe dream. The UK does it today. People there pick ISPs based > on service, price, features, etc., not on "who paid off my local PUC". > > And before anyone brings up the whole "the UK is more dense than the US", I > preemptively call BS. There is more choice, faster speeds, and lower prices > in the middle of no-where UK than downtown manhattan. Please just leave that > argument where it belongs, in the dung heap. > > Why can we not do something similar in the US? because the companies who own > the lines have enough money to pay enough lobbyists to avoid even the > promises they do make. (If anyone on this list is un-aware of things like the > telcos promising ubiquitous high-speed BB years ago and never delivering, but > never giving back their tax breaks or monopoly positions, you should be > ashamed of yourselves.) > > But hey, a guy can dream, right? > > In the mean time, let's stop pretending that 'oh, L3 paid CC so they must be > best friends'. L3 paid because They Had No Choice, and maybe because they see > some long-term strategic benefit (e.g. they can charge others more later). > > This is not a functioning market. This is a few players with Market Power > charging Rents, which any first year econ major will explain is a > _very_very_very_ bad place for the market to be. >
Re: Ars Technica on IPv4 exhaustion
IPv6 will never become the defacto standard until the vast majority of users have access to IPv6 connectivity. Everything I have at the colo is dual stacked, but I can't reach my own systems via IPv6 because my business class Verizon Fios connection is IPv4 *only*. Yes, Comcast is in the process of rolling out IPv6, but my Comcast circuit in Washington DC is IPv4 only. And I'd suspect that everyone with Time Warner, AT&T, Cox, etc are all in the same boat. Whether the reason for the lack of IPv6 deployment is laziness or an intentional omission on the part of large ISPs to protect their income from leasing IPv4 addresses doesn't matter to the vast majority of the end users; they simply can't access IPv6 via IPv4 only networks, without using some kludgy, complicated tunneling protocols. Andy -- Andrew Fried andrew.fr...@gmail.com On 6/17/14, 5:48 PM, Jared Mauch wrote: > > On Jun 17, 2014, at 5:41 PM, Lee Howard wrote: > >> >> >> On 6/17/14 4:20 PM, "Jay Ashworth" wrote: >> >>> Here's what the general public is hearing: >> >> But only while they still have IPv4 addresses: >> ~$ dig arstechnica.com +short >> ~$ >> >> >> >>> >>> >>> http://arstechnica.com/information-technology/2014/06/with-the-americas-ru >>> nning-out-of-ipv4-its-official-the-internet-is-full/ >> >> >> Can't tech news sites *please* run dual stack while they're spouting >> end-of-IPv4 stories? > > > > I would love to see a few more properties do IPv6 by default, such as ARS, > Twitter and a few others. After posting some links and being a log stalker > last night the first 3 hits from non-bots were from users on IPv6 enabled > networks. > > It does ring a bit hollow that these sites haven't gotten there when others > (Google, Facebook) have already shown you can publish records with no > adverse public impact. Making IPv6 available by default for users would be > an excellent step. People like AT&T who control the 'attwifi' ssid could do > NAT66 at their sites and provide similar service to the masses. With chains > like Hilton, McDonalds, etc.. all having this available, it would push IPv6 > very far almost immediately with no adverse impact compared to users IPv4 > experience. > > - Jared >
Re: Time Warner Cable YouTube throttling
I know only too well that Verizon's peering with Cogent in the DC/IAD area is beyond saturated. Looking at the traceroute you have below it would appear to be the same problem: >> 5 0.xe-10-0-0.BR2.IAD8.ALTER.NET (152.63.38.165) 15.007 ms 15.109 ms >> 14.975 ms >> 6 144.232.8.209 (144.232.8.209) 187.038 ms 115.363 ms 117.669 ms A handoff between Verizon and Sprint shouldn't incude a 100ms delay. Andy Andrew Fried andrew.fr...@gmail.com On 3/6/13 9:25 PM, Min wrote: > 3 traces all indicated the last hub are 80~100ms faster than the > second last hub. Interesting. > > Min > > On Wed, Mar 6, 2013 at 9:07 PM, Derek Ivey wrote: >> I just got home and tested with quite a few 1080p videos. No issues over my >> Hurricane Electric IPv6 tunnel. I did notice frequent stops to buffer on my >> FiOS IPv4 connection. I have a 50 Mbps down connection and don't even come >> close to maxing it when watching Youtube videos. >> >> Here are a few traceroutes: >> >> [2.1-BETA0][root@pfsense]/root(1): traceroute >> r19---sn-p5qlsm7d.c.youtube.com >> traceroute to r19.sn-p5qlsm7d.c.youtube.com (208.117.251.184), 64 hops max, >> 40 byte packets >> 1 L100.HRBGPA-VFTTP-12.verizon-gni.net (98.117.0.1) 1.222 ms 1.348 ms >> 0.834 ms >> 2 G10-0-8-112.HRBGPA-LCR-01.verizon-gni.net (130.81.184.148) 2.839 ms >> 2.589 ms 2.443 ms >> 3 P12-0-0.HRBGPA-LCR-02.verizon-gni.net (130.81.27.185) 14.880 ms 14.614 >> ms 14.698 ms >> 4 so-12-1-0-0.RES-BB-RTR1.verizon-gni.net (130.81.28.254) 14.647 ms >> 14.696 ms 14.552 ms >> 5 0.xe-3-1-1.BR1.IAD8.ALTER.NET (152.63.37.141) 15.027 ms 15.004 ms >> 15.064 ms >> 6 te9-2-0d0.cir1.ashburn-va.us.xo.net (206.111.0.201) 38.517 ms 36.033 >> ms 34.816 ms >> 7 216.156.8.189.ptr.us.xo.net (216.156.8.189) 31.958 ms 30.994 ms >> 29.194 ms >> 8 209.48.42.86 (209.48.42.86) 124.931 ms 126.117 ms 124.303 ms >> 9 208.117.251.184 (208.117.251.184) 26.483 ms 27.792 ms 27.974 ms >> >> [2.1-BETA0][root@pfsense]/root(2): traceroute >> r15---sn-p5qlsm76.c.youtube.com >> traceroute to r15.sn-p5qlsm76.c.youtube.com (208.117.251.148), 64 hops max, >> 40 byte packets >> 1 L100.HRBGPA-VFTTP-12.verizon-gni.net (98.117.0.1) 1.077 ms 0.863 ms >> 0.968 ms >> 2 G10-0-8-112.HRBGPA-LCR-01.verizon-gni.net (130.81.184.148) 2.429 ms >> 2.265 ms 2.456 ms >> 3 P12-0-0.HRBGPA-LCR-02.verizon-gni.net (130.81.27.185) 14.788 ms 14.666 >> ms 14.643 ms >> 4 so-12-1-0-0.RES-BB-RTR1.verizon-gni.net (130.81.28.254) 14.591 ms >> 14.479 ms 16.041 ms >> 5 0.xe-10-0-0.BR2.IAD8.ALTER.NET (152.63.38.165) 15.007 ms 15.109 ms >> 14.975 ms >> 6 144.232.8.209 (144.232.8.209) 187.038 ms 115.363 ms 117.669 ms >> 7 sl-st31-ash-0-4-0-0.sprintlink.net (144.232.28.6) 116.263 ms >> sl-st31-ash-0-8-0-2.sprintlink.net (144.232.1.19) 116.491 ms >> sl-st31-ash-0-4-0-0.sprintlink.net (144.232.28.6) 116.934 ms >> 8 sl-googl10-584821-0.sprintlink.net (144.228.205.34) 122.521 ms 122.780 >> ms 121.535 ms >> 9 208.117.251.148 (208.117.251.148) 33.669 ms 37.652 ms 38.478 ms >> >> [2.1-BETA0][root@pfsense]/root(6): traceroute >> r10---sn-p5qlsm7l.c.youtube.com >> traceroute to r10.sn-p5qlsm7l.c.youtube.com (208.117.251.47), 64 hops max, >> 40 byte packets >> 1 L100.HRBGPA-VFTTP-12.verizon-gni.net (98.117.0.1) 1.159 ms 0.831 ms >> 0.806 ms >> 2 G9-0-4-212.HRBGPA-LCR-02.verizon-gni.net (130.81.139.126) 2.396 ms >> 2.435 ms 2.167 ms >> 3 so-12-1-0-0.RES-BB-RTR1.verizon-gni.net (130.81.28.254) 14.497 ms >> 14.767 ms 14.695 ms >> 4 0.xe-11-0-0.BR2.IAD8.ALTER.NET (152.63.38.169) 15.001 ms 15.074 ms >> 15.024 ms >> 5 144.232.8.209 (144.232.8.209) 118.582 ms 116.717 ms 113.669 ms >> 6 sl-st31-ash-0-4-0-3.sprintlink.net (144.232.3.169) 114.433 ms 117.698 >> ms >> sl-st31-ash-0-4-0-0.sprintlink.net (144.232.28.6) 115.981 ms >> 7 sl-googl10-584821-0.sprintlink.net (144.228.205.34) 123.912 ms 124.402 >> ms 125.384 ms >> 8 208.117.251.47 (208.117.251.47) 30.591 ms 30.676 ms 29.528 ms >> >> Derek >> >> On 3/6/2013 8:31 PM, Grant Ridder wrote: >>> >>> Can any one provide traceroutes to youtube to see if there is any >>> correlation between last mile providers? >>> >>> -Grant >>> >>> On Wed, Mar 6, 2013 at 6:37 PM, Derek Ivey >> <mailto:de...@derekivey.com>> wrote: >>> >>> I don't think it's just Time Warner. Definitely looks like XO. I have >>> Veri
Re: Google Public DNS Problems?
Your IPs may have been rate limited... Andy Andrew Fried andrew.fr...@gmail.com On 5/1/13 12:38 PM, Blair Trosper wrote: > That's all well and good, but I certainly wouldn't expect "nslookup > gmail.com" or for "nslookup google.com" to return SERVFAIL > > > On Wed, May 1, 2013 at 9:34 AM, Joe Abley wrote: > >> >> On 2013-05-01, at 12:09, Blair Trosper wrote: >> >>> Is anyone else seeing this? From Santa Clara, CA, on Comcast >>> Business...I'm getting SERVFAIL for any query I throw at 8.8.8.8 and >>> 8.8.4.4... >>> >>> Level 3's own public resolvers are fine for me, as are OpenDNS's >> resolvers. >> >> Google just turned on validation across the whole of 8.8.8.8 and 8.8.4.4. >> The expected behaviour in the case where a response does not validate is to >> return SERVFAIL to the client. >> >> You could check that the queries you are sending are not suffering from >> poor signing hygiene (e.g. use the handy-dandy dnsviz.net visualisation). >> >> If this is a repeatable, consistent problem even for unsigned zones (or >> for zones that you've verified are signed correctly) and especially if it's >> widespread you might want to call google on the nanog courtesy phone and >> have them look for collateral damage from their recent foray into 8.8.8.8 >> validation. >> >> Raw output from dig/drill and traceroutes to 8.8.8.8/8.8.4.4 are highly >> recommended if you need to take this further. >> >> >> Joe
Re: Hijacked Network Ranges
The interesting thing is that I'm not seeing any new "hosts" from those subnets in passive dns. It almost seems that their purpose for hijacking the space was to direct traffic to themselves, possibly for collecting login attempts. Andrew Fried andrew.fr...@gmail.com On 1/31/12 1:00 PM, Kelvin Williams wrote: > Greetings all. > > We've been in a 12+ hour ordeal requesting that AS19181 (Cavecreek Internet > Exchange) immediately filter out network blocks that are being advertised > by ASAS33611 (SBJ Media, LLC) who provided to them a forged LOA. > > The routes for networks: 208.110.48.0/20, 63.246.112.0/20, and > 68.66.112.0/20 are registered in various IRRs all as having an origin AS > 11325 (ours), and are directly allocated to us. > > The malicious hijacking is being announced as /24s therefore making route > selection pick them. > > Our customers and services have been impaired. Does anyone have any > contacts for anyone at Cavecreek that would actually take a look at ARINs > WHOIS, and IRRs so the networks can be restored and our services back in > operation? > > Additionally, does anyone have any suggestion for mitigating in the > interim? Since we can't announce as /25s and IRRs are apparently a pipe > dream. >
Re: Operation Ghost Click
I suggest you reach out to Shadowserver or Team Cymru if you're a netblock owner. They can provide daily reports of infected IPs. Andy Andrew Fried andrew.fr...@gmail.com On 4/26/12 5:50 PM, Leigh Porter wrote: > > On 26 Apr 2012, at 22:47, "Andrew Latham" > mailto:lath...@gmail.com>> wrote: > > On Thu, Apr 26, 2012 at 5:38 PM, Jeroen van Aart > mailto:jer...@mompl.net>> wrote: > > Yes its a major problem for the users unknowingly infected. To them > it will look like their Internet connection is down. Expect ISPs to > field lots of support s > > Is there a list of these temporary servers so I can see what customers are > using them (indicating infection) and head off a support call with some > contact? > > -- > Leigh > > > __ > This email has been scanned by the Symantec Email Security.cloud service. > For more information please visit http://www.symanteccloud.com > __
Domain changer statistics by ASN
As many of you probably know, the replacement nameservers operated on behalf of the FBI for the Domain Changer Working Group (DCWG) are scheduled to go down Sunday morning (GMT). Yesterday, July 4th, was a holiday in the US, and as such the US based activity hitting the DCWG nameservers was uncharacteristically low. The numbers seen in the rest of the world were normal. I'm attaching a report that shows the number of unique ip addresses that were seen hitting the DCWG nameservers from the 4th based on ASN. If you control one of the ASNs seen in the list please remind your folks that these numbers need to come down by Sunday. if you find this of use, I can regenerate new reports later this afternoon with data from the 5th. Andy -- Andrew Fried andrew.fr...@gmail.com dcwg-asns-20120704.txt.bz2 Description: BZip2 compressed data
Re: Domain changer statistics by ASN
We have data going back to November 8, 2011. Generating a report of over 2,000 ASNs, by day, would be too large an attachment for NANOG. I'll produce a follow up report in less than 3 hours with data from July 5th. Would that help? Andy Andrew Fried andrew.fr...@gmail.com On 7/5/12 5:42 PM, Eric Wieling wrote: > A report for a day other than the 4th of July would be very helpful. > > -Original Message- > From: Andrew Fried [mailto:andrew.fr...@gmail.com] > Sent: Thursday, July 05, 2012 5:26 PM > To: nanog@nanog.org > Subject: Domain changer statistics by ASN > > As many of you probably know, the replacement nameservers operated on behalf > of the FBI for the Domain Changer Working Group (DCWG) are scheduled to go > down Sunday morning (GMT). > > Yesterday, July 4th, was a holiday in the US, and as such the US based > activity hitting the DCWG nameservers was uncharacteristically low. The > numbers seen in the rest of the world were normal. > > I'm attaching a report that shows the number of unique ip addresses that were > seen hitting the DCWG nameservers from the 4th based on ASN. If you control > one of the ASNs seen in the list please remind your folks that these numbers > need to come down by Sunday. > > if you find this of use, I can regenerate new reports later this afternoon > with data from the 5th. > > Andy > > -- > Andrew Fried > andrew.fr...@gmail.com > >
Re: DNS Changer items
The dns-ok.us site is getting crushed from all the sudden media interest. We're trying to tweak it to handle the 50,000 or so simultaneous connections. Andy Andrew Fried andrew.fr...@gmail.com On 7/6/12 12:34 PM, Eric J Esslinger wrote: > A) The DNS changer working group site http://www.dns-ok.us seems to be down > for the clean people anyway. (Down for everyone agrees with me). > B) Fox, CNN, and MSNBC have apparantly all run stories in the last couple of > hours that essentially ended with 'Call your ISP if you have any questions' > (gee thanks). And I'm told the ABC/CBS/NBC are running the same basic thing > tonight, with the same basic ending. > > The more you know... > > __ > Eric Esslinger > Information Services Manager - Fayetteville Public Utilities > http://www.fpu-tn.com/ > (931)433-1522 ext 165 > > This message may contain confidential and/or proprietary information and is > intended for the person/entity to whom it was originally addressed. Any use > by others is strictly prohibited. >
Re: DNS Changer items
The DNS redirection began on November 8, 2011. The servers were instrumented to capture a very small portion of the dns data (source ip and port only) so that reports of infected users could be sent to the ISPs via reporting organizations like Shadowserver. Some ISPs did create walled gardens. Some merely redirected affected customers to their own internal DNS servers. Some ISPs did aggressive notifications to their users. And some ISPs did nothing. Sites were set up to allow users to check their systems (dns-ok.us, etc). The DCWG set up an information site to provide information on how to detect the DNSchanger infection and how to fix it. AV companies provided tools to help clean up systems, and the tools were published on the DCWG.org website. The FBI went to great lengths to get press coverage to get the word out. This operation has been ongoing for 7 months, 27 days and 14 hours. How much more of a graceful ramp down could there have been? Andy Andrew Fried andrew.fr...@gmail.com On 7/6/12 1:52 PM, Cameron Byrne wrote: > So insteading of turning the servers off, would it not have been helpful to > have the servers return a "captive portal" type of reponse saying "hey, > since you use this server, you are broken, go here to get fixed" > > Seems that would have been a more graceful ramp down. > > CB >
Re: DNS Changer items
Cameron, That idea had been brought up. Also discussed was short durations of random blackouts of dns resolution to impress upon the infected users that they needed to take action. Unfortunately, taking either of those actions would have exceeded the authorization of the court order. We're coming up with a pretty detailed list of "lesson's learned" from this operation and being able to implement ideas like yours will hopefully be considered in advance "next time". Andy Andrew Fried andrew.fr...@gmail.com On 7/6/12 3:58 PM, Tomas L. Byrnes wrote: > I think having the ISC DNS changer sinkhole servers return the DCWG > check page IP for all queries would be a good final act. > >> -----Original Message- >> From: Andrew Fried [mailto:andrew.fr...@gmail.com] >> Sent: Friday, July 06, 2012 11:16 AM >> To: Cameron Byrne >> Cc: nanog@nanog.org >> Subject: Re: DNS Changer items >> >> The DNS redirection began on November 8, 2011. The servers were >> instrumented to capture a very small portion of the dns data (source > ip and >> port only) so that reports of infected users could be sent to the ISPs > via >> reporting organizations like Shadowserver. >> >> Some ISPs did create walled gardens. Some merely redirected affected >> customers to their own internal DNS servers. Some ISPs did aggressive >> notifications to their users. And some ISPs did nothing. >> >> Sites were set up to allow users to check their systems (dns-ok.us, > etc). The >> DCWG set up an information site to provide information on how to > detect >> the DNSchanger infection and how to fix it. AV companies provided > tools to >> help clean up systems, and the tools were published on the DCWG.org >> website. >> >> The FBI went to great lengths to get press coverage to get the word > out. >> >> This operation has been ongoing for 7 months, 27 days and 14 hours. >> >> How much more of a graceful ramp down could there have been? >> >> Andy >> >> Andrew Fried >> andrew.fr...@gmail.com >> >> >> On 7/6/12 1:52 PM, Cameron Byrne wrote: >>> So insteading of turning the servers off, would it not have been >>> helpful to have the servers return a "captive portal" type of > reponse >>> saying "hey, since you use this server, you are broken, go here to > get fixed" >>> >>> Seems that would have been a more graceful ramp down. >>> >>> CB >>> >> >
Re: DNS Changer items
The subnets will probably be held until the conclusion of the criminal trials. After that, the addresses may be held back from assignment for a while (e.g. a year), but eventually they'll get reassigned. Andrew Fried andrew.fr...@gmail.com On 7/6/12 4:45 PM, Roy wrote: > On 7/6/2012 1:15 PM, Andrew Fried wrote: >> Cameron, >> >> That idea had been brought up. Also discussed was short durations of >> random blackouts of dns resolution to impress upon the infected users >> that they needed to take action. Unfortunately, taking either of those >> actions would have exceeded the authorization of the court order. >> >> We're coming up with a pretty detailed list of "lesson's learned" from >> this operation and being able to implement ideas like yours will >> hopefully be considered in advance "next time". >> >> Andy >> >> Andrew Fried >> andrew.fr...@gmail.com >> >> > > > Doesn't the court order expire as of Monday? What happens to those IP > ranges then? > > >
Re: [outages] www.dns-ok.us down
Some ISPs are performing internal redirection. Some, in fact, have been doing it since the takedown last November. The redirection has to stop at some point. And keep in mind, most of the systems infected with DNSchanger have other malware running on their boxes, so keeping those systems up indefinitely is actually not a good thing. Andy Andrew Fried andrew.fr...@gmail.com On 7/6/12 5:40 PM, Jay Ashworth wrote: > So... might large and medium ISPs not redirect DNS to those known addresses > to a resolver in house, which would log the client IPs and let them > know whom to address? > > Cheers, > -- jra
Re: load balancer product for dns content switching
While still in pre-production state, you might want to look at: http://dnsdist.org/ Andrew Andrew Fried andrew.fr...@gmail.com On 8/27/15 3:13 PM, Brooks Bridges wrote: > Spent quite a bit of time researching products out there looking for one > that will do content switching based on the domain being queried, and > I'm coming up empty. Can anyone point me in a decent direction? > > For example: > > all requests are sent to one (HA) VIP, and then: > > host.bob.domain.com gets routed to dns server group 1 > host.bill.domain.com gets routed to dns server group 2 > and so on... > > Thanks for any advice >
Re: remote serial console (IP to Serial)
The Lantronix Spiders work well and aren't a "do-it-yourself" option: http://www.lantronix.com/products/lantronix-spider/ Andrew Andrew Fried andrew.fr...@gmail.com On 3/8/16 10:30 AM, greg whynott wrote: > Recently I have taking over the responsibility of managing about 18 remote > routers and firewalls. None of these have a console port for 'out of > band' access accessible today. > > Most sites has available IPs between the ISP and us (typically a /29) or a > backup DSL connection available for use. I'd like to purchase a IP to > Serial port device I can use for each location in the event I lock myself > out. The requirement would be an Ethernet port, a serial port, and SSH. > > > Anyone have any recommendations on something like this? > > thanks much, > greg >
Re: This is a coordinated hacking. (Was Re: Need help in flushing DNS)
Not so easy and straightforward to do. You'll find that a lot of the big names out there frequently tweak DNS, which will result in a non-stop stream of "alerts". Andy Andrew Fried andrew.fr...@gmail.com On 6/20/13 3:57 PM, Jared Mauch wrote: > It seems there may be a need for some sort of 'dns-health' check out there > that can be done in semi-realtime. > > I ran a report for someone earlier today on a domain doing an xref against > open resolver data searching for valid responses vs invalid ones. > > Is this of value? Does it need to be automated? > > - Jared > > On Jun 20, 2013, at 3:53 PM, jamie rishaw wrote: > >> This is most definitely a coordinated and planned attack. >> >> And by 'attack' I mean hijacking of domain names. >> >> I show as of this morning nearly fifty thousand domain names that appear >> suspicious. >> >> I'm tempted to call uscentcom and/or related agencies (which agencies, who >> the hell knows, as ICE seems to have some sort of authority over domains >> (nearly two hundred fifty of them as I type this in COM alone and another >> thirty-some in NET). >> >> Anyone credentialed (credentialed /n/., "I know you or know of you,") >> wanting data, e-mail me off-list for some TLD goodness. >> >> >> >> >> >> >> On Thu, Jun 20, 2013 at 12:29 PM, Phil Fagan wrote: >> >>> Agree'd in these "smaller" scenario's I just wonder if in a larger scale >>> scenario, whatever that might look like, if its necessary. Whereby many >>> organizations who provide "services" are effected. Perhaps the result of a >>> State led campaign topic for another day. >>> >>> >>> >>> >>> On Thu, Jun 20, 2013 at 11:25 AM, Paul Ferguson >>> wrote: >>> >>>> I am betting that Netsol doesn't need any more "coordination" at the >>>> moment -- their phones are probably ringing off-the-hook. There are >>>> still ~400 domains still pointing to the ztomy NS: >>>> >>>> >>>> ; <<>> DiG 9.7.3 <<>> @foohost parsonstech.com NS >>>> ; (1 server found) >>>> ;; global options: +cmd >>>> ;; Got answer: >>>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49064 >>>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 >>>> >>>> ;; QUESTION SECTION: >>>> ;parsonstech.com.INNS >>>> >>>> ;; ANSWER SECTION: >>>> parsonstech.com.172800INNSns2617.ztomy.com. >>>> parsonstech.com.172800INNSns1617.ztomy.com. >>>> >>>> ;; Query time: 286 msec >>>> ;; SERVER: 127.0.0.1#53(127.0.0.1) >>>> ;; WHEN: Thu Jun 20 19:16:25 2013 >>>> ;; MSG SIZE rcvd: 81 >>>> >>>> - ferg >>>> >>>> On Thu, Jun 20, 2013 at 10:13 AM, Phil Fagan >>> wrote: >>>> >>>>> I should caveat.coordinate the "recovery" of. >>>>> >>>>> >>>>> On Thu, Jun 20, 2013 at 11:10 AM, Brandon Butterworth >>>>> wrote: >>>>> >>>>>>> Is there an organization that coordinates outages like this amongst >>>> the >>>>>>> industry? >>>>>> >>>>>> No, usually they are surprise outages though Anonymous have tried >>>>>> coordinating a few >>>>>> >>>>>> brandon >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Phil Fagan >>>>> Denver, CO >>>>> 970-480-7618 >>>> >>>> >>>> >>>> -- >>>> "Fergie", a.k.a. Paul Ferguson >>>> fergdawgster(at)gmail.com >>>> >>> >>> >>> >>> -- >>> Phil Fagan >>> Denver, CO >>> 970-480-7618 >>> >> >> >> >> -- >> Jamie Rishaw // .com.arpa@j <- reverse it. ish. >> [Impressive C-level Title Here], arpa / arpa labs > >
Re: Cogent IPV6 connectivity to fireball.acr.fi
>From AS54054 in Ashburn, VA I can ping your address but traceroute's aren't making it through. Andrew Andrew Fried andrew.fr...@gmail.com On 11/3/13, 1:30 PM, Clinton Work wrote: > IPV6 connectivity to fireball.acr.fi is failing inside Cogent AS174. I > have already contacted the Cogent NOC, but I haven't heard anything back > yet. I'm wondering if somebody else with Cogent IPV6 connectivity can > run some tests. IPV4 connectivity is working fine. >
Re: List of CDNs?
Actually, a list of CDNs would be very handy. I harvest botnets and fast flux hosts out of passive dns, and some of the heuristics used to identify them are similar to what CDNs look like. Having a decent list of CDN effective top level domains alone would be useful for redacting those hosts. Andy Andrew Fried andrew.fr...@gmail.com On 11/14/13, 5:11 PM, Patrick W. Gilmore wrote: > List of CDNs would be difficult, but not impossible. Although they do > different things, so a simple list is unlikely to be as useful as it looks. > > A lost of CDN "DC nodes" is not possible. Why do you care about such a thing > anyway? >
Re: Verizon FIOS IPv6?
You fared better than I did. I also am a Verizon Business customer, and when I called and inquired about ipv6 I was told that they didn't carry that channel. :) Andrew Fried andrew.fr...@gmail.com On 1/7/14, 11:28 PM, Stephen Frost wrote: > * Christopher Morrow (morrowc.li...@gmail.com) wrote: >> On Tue, Jan 7, 2014 at 10:56 PM, Adam Rothschild >> wrote: >>> I've heard of folk in and around the NYC metro getting set up >>> for v6 by escalating through their commercial account teams, or >>> the field >> >> 'commercial account teams' == business customers? > > As a FIOS business customer, I can say that I've had no progress on > that front, though I've bugged them about it often enough... > Perhaps I shall try again though. I would truely love to hear from > one of these folks in NYC who managed to get it... > >>> implementation is shameful, and should be called out wherever >>> possible. >> >> yes :( it's nice that the Networx contract didn't require any >> ipv6 readiness... > > There's a US government mandate for government public websites to > support IPv6 and quite a few of those do- in some cases through > Networx. I don't recall agencies complaining about the inability to > get IPv6 for public websites via Networx either. Additionally, > most of the services under the Networx contract are more > traditional telecom services which don't particularly care what you > run over them. > > As for having Networx require IPv6 support for all services- some > of us tried, and while a nice idea, I doubt it would have lasted > terribly long post-award even if it had been included for the few > IP-based services which were part of the original contract. Sadly, > having been involved in government contracting, it's amazing what > happens when the vendor says "we want to provide $awesome, but we > need you to waive this *one* little thing" and there isn't a > mandate (afair...) for agencies to run IPv6 internally (tho they're > supposed to be buying devices which *support* it). > > I will say that the more the agencies complain to GSA the highest > the chance of something being done about it. > > Thanks, > > Stephen >
Re: POP3 DoS attacks and mailanyone.net?
Hummm. Looking through some of my data I found that the domain NORTHROANOKE.COM resolves to 98.190.204.2 (the first attack vector). That box is running Microsoft Business Server 2003. NORTHROANOKE.COM appears to be some kind of assisted living facility in Roanoke, Virginia (based on whois). Doesn't look gmail related from that perspective... Andrew Andrew Fried andrew.fr...@gmail.com Winn Johnston wrote: > Issues with gmail.com > > here in DC > > Winn Johnston > > From: u...@3.am [...@3.am] > Sent: Tuesday, September 01, 2009 3:28 PM > To: nanog@nanog.org > Subject: POP3 DoS attacks and mailanyone.net? > > For the first time since I can remember, my POP3 server was effectively > shut down by too many simultaneous connections today. The first fix I > tried was to raise the number of connections from the default 40 to 100, > but the problem soon returned. > > I finally ipfw'd off the offending IP (98.190.204.2 for anyone > interested), then went to look for other possible offenders in the log. I > noticed several thousand connections today to a few dozen former users > from 4 IPs from 208.70.128.0/21. One of the users was actually > legitimate. > > These IPs belong to mailanyone.net. The tech contact in their ARIN record > is listed as: > > OrgTechHandle: BHE57-ARIN > OrgTechName: Heitman, Bryan > OrgTechPhone: +1-816-587-4700 > OrgTechEmail: hostmas...@mailanyone.net > > However, that phone number goes to a UPS store that has no idea what I'm > talking about. I then dialed their suppseod NOC number: > > Comment:FuseMail, LLC Network Operations Center contact > Comment:877.888.3873 x3 > > I am on hold with that number right now with some very loud and annoying > music. > > Can anyone offer any insight as to these people and how/who to deal with > there? > > Would a provider be amiss to just block their entire /21? > > TIA, > > James Smallacombe PlantageNet, Inc. CEO and Janitor > u...@3.am http://3.am > = > > > __ > This inbound email was scanned by MessageLabs > _ > > __ > This email was scanned by MessageLabs > _ >
Re: godaddy spam / abuse suspensions?
Chances are if the domain has been sandboxed, it was because it was involved in some kind of phishing scheme, not spam. This is the typicaly way of mitigating fast flux botnets. So I don't agree with the assessment that this is bad behavior on the part of GoDaddy - to the contrary, they are acting quite responsibly. AF James Hess wrote: > I don't think he wants the domain. The problem is Godaddy listing NS > records for some domains (for any reason) to only DNS servers that > were all down or didn't exist. The entry of only lame DNS servers is > an inconclusive situation and doesn't let a message be permanently > rejected as spam; it's indistinguishable from a temporary failure of > all that domain's DNS servers. > > It also causes (hopefully non-fatal) problems for hosts looking up the > contacting host's ip, > like wasteful repeated queries. > > This is not good behavior on the registrar's part; Godaddy would > almost be better seving > the internet community by ignoring spam and doing nothing, or > forwarding reports to ISPs rather than introducing lame DNS zones. > > > Registrars aren't really in a place to be able to stop spam; the > spammer can simply use any domain or have their reverse zone changed > accordingly, if they have custom reverse. > > But for a registrar to do their best.. by pulling domains where they > have proof the owner has performed or authorized spam, they should > pull the domain from the TLD zone entirely and let the response be > NXDOMAIN. > > A NXDOMAIN response allows the mail server to definitively reject the > message > and move on. > > > -- > -J > > On Sun, Nov 16, 2008 at 12:19 PM, Rohan Sheth <[EMAIL PROTECTED]> wrote: > >> Name has been suspended for "supposed" abuse by the godaddy abuse team. >> >> I believe the only recourse is to email [EMAIL PROTECTED] (cc >> [EMAIL PROTECTED]) asking what they want to release the domain to >> you. I believe the usual charge is like $75 or so. >> >> --Rohan >> >> > > > -- Andrew Fried [EMAIL PROTECTED]
Re: isprime DOS in progress
p named[32762]: client 208.78.169.235#46265: > view ext: query (cache) './NS/IN' denied > Jan 24 08:52:45 imhotep last message repeated 2 times > Jan 24 08:55:54 imhotep named[32762]: client 149.20.58.131#59151: view > ext: query (cache) 'localhost/A/IN' denied > Jan 24 09:36:38 imhotep named[32762]: client 208.37.177.62#46265: view > ext: query (cache) './NS/IN' denied > Jan 24 09:36:38 imhotep last message repeated 2 times > Jan 24 09:43:53 imhotep named[32762]: client 204.11.51.61#43330: view > ext: query (cache) './NS/IN' denied > Jan 24 09:43:54 imhotep last message repeated 2 times > Jan 24 09:53:56 imhotep named[32762]: client 63.217.28.226#53: view > ext: query (cache) './NS/IN' denied > Jan 24 10:05:28 imhotep named[32762]: client 208.78.169.234#42517: > view ext: query (cache) './NS/IN' denied > Jan 24 10:05:28 imhotep last message repeated 2 times > Jan 24 10:26:09 imhotep named[32762]: client 206.71.158.30#18971: view > ext: query (cache) './NS/IN' denied > Jan 24 10:26:11 imhotep named[32762]: client 206.71.158.30#47622: view > ext: query (cache) './NS/IN' denied > Jan 24 10:26:13 imhotep named[32762]: client 206.71.158.30#16077: view > ext: query (cache) './NS/IN' denied > > > -- Andrew Fried andrew.fr...@gmail.com
Re: isprime DOS in progress
I just took a snapshot of my bind logs from the past two hours (on 01/25/209 at 14:40 EST). Based on what I'm seeing, four DNS servers are still under attack at varying levels. 206.71.158.30 is bearing the brunt of the attacks. And as you indicated, 76.9.16.171 is still being targeted, although to a lesser degree than before. +---+-+ | host | count(host) | +---+-+ | 10.168.69.6 | 3 | | 206.71.158.30 |6513 | | 63.217.28.226 | 182 | | 66.230.160.1 | 266 | | 76.9.16.171 | 92 | +---+-+ -- Andrew Fried andrew.fr...@gmail.com David Andersen wrote: > I'm not sure you're entirely out of the water yet: > > 17:13:45.680944 76.9.16.171.53868 > .53: 58451+ NS? . (17) > 17:13:45.681251 .53 > 76.9.16.171.53868: 58451 Refused- 0/0/0 > (17) > > CIDR: 76.9.0.0/19 > NetName:ISPRIME-ARIN-3 > > In addition to the one that Brian Keefer mentioned a few days ago > (206.71.158.30). > > But on that subject, I figured I'd toss in a (sad) anecdote about > security and upgrades. I'd upgraded this nameserver to bind-9 some > time ago, during a bit of a security panic. And in the process, I > screwed it up - I'd updated the machine itself, but had failed to > propagate the changes to the master that sends updates to all of the > servers. The obvious thing happened: after a while, this nameserver > pulled its updates from the master, and downgraded to bind-8 again, > which we didn't notice until I saw it spitting full cached NS > responses to isprime hosts. Human error strikes again. Apologies for > letting my host be an amplifier. > > -Dave > > > On Jan 23, 2009, at 1:11 PM, Phil Rosenthal wrote: > >> Just a friendly notice, the attack against 66.230.128.15/66.230.160.1 >> seems to have stopped for now. >> >> -Phil >> On Jan 22, 2009, at 6:01 AM, Bjørn Mork wrote: >> >>> Graeme Fowler writes: >>> >>>> I've been seeing a lot of noise from the latter two addresses after >>>> switching on query logging (and finishing an application of Team >>>> Cymru's >>>> excellent template) so I decided to DROP traffic from the addresses >>>> (with source port != 53) at the hosts in question. >>>> >>>> Well, blow me down if they didn't completely stop talking to me. Four >>>> dropped packets each, and they've gone away. >>>> >>>> Something smells "not quite right" here - if the traffic is >>>> spoofed, and >>>> my "Refused" responses have been flying right back to the *real* IP >>>> addresses, how are the spoofing hosts to know that I'm dropping the >>>> traffic? >>> >>> Did you filter *only* 66.230.128.15/66.230.160.1, or are you dropping >>> traffic from other sources too? Looks like some of the other source >>> addresses are controlled by the DOSers. Possibly used to detect >>> filters? >>> >>> These clients may look similar to the DOS attack, but there are subtle >>> differences: >>> >>> Jan 18 05:08:33 canardo named[32046]: client 211.72.249.201#29656: >>> view external: query (cache) './NS/IN' denied >>> Jan 18 05:08:33 canardo named[32046]: client 211.72.249.201#29656: >>> view external: query (cache) './NS/IN' denied >>> Jan 18 05:08:34 canardo named[32046]: client 211.72.249.201#29656: >>> view external: query (cache) './NS/IN' denied >>> Jan 18 05:47:00 canardo named[32046]: client 211.72.249.201#29662: >>> view external: query (cache) './NS/IN' denied >>> Jan 18 05:47:01 canardo named[32046]: client 211.72.249.201#29662: >>> view external: query (cache) './NS/IN' denied >>> Jan 18 05:47:01 canardo named[32046]: client 211.72.249.201#29662: >>> view external: query (cache) './NS/IN' denied >>> Jan 18 06:25:22 canardo named[32046]: client 211.72.249.201#29664: >>> view external: query (cache) './NS/IN' denied >>> Jan 18 06:25:22 canardo named[32046]: client 211.72.249.201#29664: >>> view external: query (cache) './NS/IN' denied >>> Jan 18 06:25:23 canardo named[32046]: client 211.72.249.201#29664: >>> view external: query (cache) './NS/IN' denied >>> Jan 18 07:03:41 canardo named[32046]: client 211.72.249.201#29667: >>> view external: query (cache) './NS/IN' denied >>> Jan 18 07:03:41 canardo named[32046]: client 211
DNS DDoS Host list
Based on the logs from the past 48 hours, here are the hosts that appear to be under attack. The count field reflects the individual number of "'./NS/IN' denied" log entries that appeared in my logs. Note that the stats for 206.71.158.30 are under-reported due to the fact that I blackholed that address last night, however packet captures reveal that I'm no longer seeing spoofed packets targeting that address. ++-+ | host | count(host) | ++-+ | 10.168.69.6| 18 | | 202.104.106.49 | 84 | | 206.71.158.30 | 34327 | | 210.21.218.138 | 84 | | 63.217.28.226 |2696 | | 66.230.160.1 |3541 | | 76.9.16.171|1355 | ++-----+ -- Andrew Fried andrew.fr...@gmail.com
DNS DDoS - New Hosts
As of 10:10am (EST) new hosts are now being targeted in the DDoS. Interestingly enough two of the ip addresses are in China. Attached is a file containing the geoip/whois and peering information for the targeted systems. ++-+ | host | count(host) | ++-+ | 202.104.106.49 | 45 | | 210.21.218.138 | 48 | | 63.217.28.226 |1153 | | 64.57.246.146 |1559 | | 67.192.144.0 | 11765 | | 76.9.16.171| 582 | ++-+ -- Andrew Fried andrew.fr...@gmail.com GeoIP Location Information for IP: 202.104.106.49 Located in: Boshi, 26 (CN) Latitude: 34.7667 Longitude: 110.0500 Area Code: Postal Code: ARIN information for: 202.104.106.49 DNS PTR Record: Registrar: apnic ASN Number:AS4134 Country: CN Ip Starting Block: 202.104.0.0 IP Ending Block: 202.105.255.255 IP Block Size: 131072 Date Registered: 19980817 Block Status: allocated BGP Peering Information for ASN4134: PEER_AS | IP | BGP Prefix | CC | Registry | Allocated | AS Name 174 | 202.104.106.49 | 202.104.0.0/17 | CN | apnic| 1998-08-17 | COGENT Cogent/PSI 1239| 202.104.106.49 | 202.104.0.0/17 | CN | apnic| 1998-08-17 | SPRINTLINK - Sprint 1299| 202.104.106.49 | 202.104.0.0/17 | CN | apnic| 1998-08-17 | TELIANET TeliaNet Global Network 2516| 202.104.106.49 | 202.104.0.0/17 | CN | apnic| 1998-08-17 | KDDI KDDI CORPORATION 2828| 202.104.106.49 | 202.104.0.0/17 | CN | apnic| 1998-08-17 | XO-AS15 - XO Communications 2914| 202.104.106.49 | 202.104.0.0/17 | CN | apnic| 1998-08-17 | NTT-COMMUNICATIONS-2914 - NTT America, Inc. 3257| 202.104.106.49 | 202.104.0.0/17 | CN | apnic| 1998-08-17 | TISCALI-BACKBONE Tiscali Intl Network BV 3320| 202.104.106.49 | 202.104.0.0/17 | CN | apnic| 1998-08-17 | DTAG Deutsche Telekom AG 3491| 202.104.106.49 | 202.104.0.0/17 | CN | apnic| 1998-08-17 | BTN-ASN - Beyond The Network America, Inc. 3549| 202.104.106.49 | 202.104.0.0/17 | CN | apnic| 1998-08-17 | GBLX Global Crossing Ltd. 7132| 202.104.106.49 | 202.104.0.0/17 | CN | apnic| 1998-08-17 | SBIS-AS - AT&T Internet Services 7473| 202.104.106.49 | 202.104.0.0/17 | CN | apnic| 1998-08-17 | SINGTEL-AS-AP Singapore Telecommunications Ltd 11164 | 202.104.106.49 | 202.104.0.0/17 | CN | apnic| 1998-08-17 | TRANSITRAIL - National LambdaRail, LLC GeoIP Location Information for IP: 210.21.218.138 Located in: Shenzhen, 30 (CN) Latitude: 22.5333 Longitude: 114.1333 Area Code: Postal Code: ARIN information for: 210.21.218.138 DNS PTR Record:sym.gdsz.cncnet.net. Registrar: apnic ASN Number:AS17623 Country: CN Ip Starting Block: 210.21.128.0 IP Ending Block: 210.21.255.255 IP Block Size: 32768 Date Registered: 20001017 Block Status: allocated BGP Peering Information for ASN17623: PEER_AS | IP | BGP Prefix | CC | Registry | Allocated | AS Name 4837| 210.21.218.138 | 210.21.192.0/18 | CN | apnic| 2000-10-17 | CHINA169-BACKBONE CNCGROUP China169 Backbone GeoIP Location Information for IP: 63.217.28.226 Located in: Herndon, VA (US) Latitude: 38.9841 Longitude: -77.3827 Area Code: 703 Postal Code: 20170 ARIN information for: 63.217.28.226 DNS PTR Record:63-217-28-226.static.pccwglobal.net. Registrar: arin ASN Number:AS3491 Country: US Ip Starting Block: 63.216.0.0 IP Ending Block: 63.223.255.255 IP Block Size: 524288 Date Registered: 19991209 Block Status: allocated BGP Peering Information for ASN3491: PEER_AS | IP | BGP Prefix | CC | Registry | Allocated | AS Name 174 | 63.217.28.226| 63.216.0.0/13 | US | arin | 1999-12-09 | COGENT Cogent/PSI 701 | 63.217.28.226| 63.216.0.0/13 | US | arin | 1999-12-09 | UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 1299| 63.217.28.226| 63.216.0.0/13 | US | arin | 1999-12-09 | TELIANET TeliaNet Global Network 2516| 63.217.28.226| 63.216.0.0/13 | US | arin | 1999-12-09 | KDDI KDDI CORPORATION 2828| 63.217.28.226| 63.216.0.0/13 | US | arin | 1999-12-09 | XO-AS15 - XO Communications 3549| 63.217.28.226| 63.216.0.0/13 | US | arin | 1999-12-09 | GBLX Global Crossing Ltd. 4565| 63.217.28.226| 63.216.0.0/13 | US |
DNS DDoS
Targeted victims, beginning 28-Jan-2009, as seen from my DNS server. GeoIP data for top two sites also below: ++-++ | host | count(host) | Percentage | ++-++ | 202.104.106.49 | 51 | 0.1109 | | 210.21.218.138 | 51 | 0.1109 | | 64.57.246.123 |3561 | 7.7421 | | 64.57.246.146 | 29530 |64.2026 | | 67.192.144.0 | 991 | 2.1546 | | 70.86.80.98| 11276 |24.5157 | | 76.9.16.171| 535 | 1.1632 | ++-++ GeoIP Location Information for IP: 64.57.246.146 Located in: Suwanee, GA (US) Latitude: 34.0535 Longitude: -84.0659 Area Code: 770 Postal Code: 30024 ARIN information for: 64.57.246.146 DNS PTR Record: Registrar: arin ASN Number:AS20141 Country: US Ip Starting Block: 64.57.240.0 IP Ending Block: 64.57.255.255 IP Block Size: 4096 Date Registered: 20051012 Block Status: allocated BGP Peering Information for ASN20141: PEER_AS | IP | BGP Prefix | CC | Registry | Allocated | AS Name 6983| 64.57.246.146| 64.57.240.0/20 | US | arin | 2005-10-12 | ITCDELTA - ITC^Deltacom 14745 | 64.57.246.146| 64.57.240.0/20 | US | arin | 2005-10-12 | INTERNAP-BLOCK-4 - Internap Network Services Corporation GeoIP Location Information for IP: 70.86.80.98 Located in: Houston, TX (US) Latitude: 29.7523 Longitude: -95.3670 Area Code: 713 Postal Code: 77002 ARIN information for: 70.86.80.98 DNS PTR Record:62.50.5646.static.theplanet.com. Registrar: arin ASN Number:AS21844 Country: US Ip Starting Block: 70.84.0.0 IP Ending Block: 70.87.255.255 IP Block Size: 262144 Date Registered: 20040729 Block Status: allocated BGP Peering Information for ASN21844: PEER_AS | IP | BGP Prefix | CC | Registry | Allocated | AS Name 2914| 70.86.80.98 | 70.84.0.0/14| US | arin | 2004-07-29 | NTT-COMMUNICATIONS-2914 - NTT America, Inc. 3356| 70.86.80.98 | 70.84.0.0/14| US | arin | 2004-07-29 | LEVEL3 Level 3 Communications 3549| 70.86.80.98 | 70.84.0.0/14| US | arin | 2004-07-29 | GBLX Global Crossing Ltd. 4565| 70.86.80.98 | 70.84.0.0/14| US | arin | 2004-07-29 | MEGAPATH2-US - MegaPath Networks Inc. 6461| 70.86.80.98 | 70.84.0.0/14| US | arin | 2004-07-29 | MFNX MFN - Metromedia Fiber Network -- Andrew Fried andrew.fr...@gmail.com
Re: community real-time BGP hijack notification service
Mail being what it is today, testing message delivery is an excellent idea. I'll implement that feature this weekend. Andy Skywing wrote: > It might be useful to have an option to generate an example alert mail for > purposes of setting up necessary mail processing rules and that sort. Just a > thought. > > - S > > -Original Message- > From: Gadi Evron [mailto:[EMAIL PROTECTED] > Sent: Friday, September 12, 2008 3:13 PM > To: Kevin Oberman > Cc: [EMAIL PROTECTED] > Subject: Re: community real-time BGP hijack notification service > > On Fri, 12 Sep 2008, Kevin Oberman wrote: > >> Looks interesting, but it only takes a fairly short list of ASNs for a >> prefix. For our big CIDR blocks, we have WAY too many ASNs to enter them >> all, so it's pretty useless for me. I need to be able to enter at very >> least a dozen ASes and I suspect may folks have a LOT more then that. >> > > I am sure we can fix that, Thanks for the comment! > > >> For now, I'll enter some shorter pieces from the block, but I'm most >> concerned with the pieces that are not currently assigned, so are >> available for hijack. I have added the larger, unassigned blocks. I'll >> start adding assigned bits and pieces as well as unassigned pieces, but >> being able to put all valid origin ASes in the list for the full blocks >> would be a lot nicer. >> > > Please let us know if you encounter any issues. > > > >> -- >> R. Kevin Oberman, Network Engineer >> Energy Sciences Network (ESnet) >> Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) >> E-mail: [EMAIL PROTECTED]Phone: +1 510 486-8634 >> Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 >> >> > > >
