RE: DNS Based Load Balancers
Title: RE: DNS Based Load Balancers What would be a better solution then? -Original Message- From: Lincoln Dale [mailto:[EMAIL PROTECTED]] Sent: Tue Jul 04 18:30:00 2006 To: 'Rodrick Brown'; 'Sam Stickland' Cc: 'Matt Ghali'; 'Patrick W. Gilmore'; nanog@merit.edu Subject: RE: DNS Based Load Balancers As someone who has also deployed GSLB's with hardware applicances I would also like to know real world problems and issues people are running into today on modern GSLB implementations and not theoretical ones, as far as I can tell our GSLB deployment was very straight forward and works flawlessly. GSLB based on DNS have one significant shortcoming that moone here has yet mentioned: they are performing their magic on the location of the _nameserver_ that issued the query. this can be VERY different to that of the ACTUAL location of the client. for example, Akamai always sends to off to a serverfarm in Northern California, because that's where my DNS query is originating from. that is almost the exact opposite side of the planet from where I'm coming from... irony is that there is an akamai cluster about 10 feet away from where my [subsequent] http requests originate from... sure - perhaps this isn't the norm - split-tunnel VPNs being what they are - but it's a perfect example of why GSLB based on DNS ain't perfect. cheers, lincoln.
RE: DNS Based Load Balancers
but it's a perfect example of why GSLB based on DNS ain't perfect. What would be a better solution then? utopia would be for DNS to be enhanced in some manner such that the 'end user ip-address' became visible in the DNS request. utopia would have NAT devices which actually updated that in-place so an authoritive nameserver always authoritively _knew_ the public ip-address of where the request was coming from. alas, we don't live in utopia and have to settle for alternate solutions. one such approach is rely on protocol-specific mechanisms. e.g. if its HTTP, then something at HTTP. oh wait - that won't deal with HTTP proxies either - but at least there is some standardization on HTTP headers that proxies insert giving a hint of the original client ip-address. there are other approaches also. a few years back when i spent a fair bit of time in this area, my experience is that a hybrid system based on specific protocol and generic solution (dns) worked best. this simply isn't an area where one solution fits all cases. there are public companies whose business model depends on this being 'hard' to do right. them being capable of doing something 'better' than not all all is the reason they are still in business. i did a fair bit of research in this area as part of work i used to do a few years back. much of that research belongs to my employer - i thought it was documented publicly in the form of a patent i am a co-inventor of - but alas, i can't seem to find it on uspto.gov .. perhaps it hasn't been issued yet .. i haven't tracked these things for years. in either case, i guess its an example of where even commercial entities whose business model depends on 'getting it right' most of the time do indeed 'get it wrong' also. cheers, lincoln.
RE: DNS Based Load Balancers (redux)
Stepping back for a moment...Many (most) popular services end up in multiple data centers first because they want to get diversity (of data centers, of ISPs, maybe of pricing). All mission critical sites will be designed such a subset of these data centers can take their entire load if need be.Once spread out this way - you may need to run some or all of them in an active/active configuration so you need to balance load between them in some fashion between them.If you are going to split the load - a natural desire is to split it such that it actually increases performance for users. You figure network proximity (of the end user to the serving destination) ought to be a criteria -but the load on your cluster may be more important for personalization intensive sites.You start with round robin DNS but it leaves you unsatisfied along the way. You play around with souped up DNS servers that are fed with monitoring tools that measure reachability as well as some measure of load. You also discover that the most popular browser will gladly ignore your TTL settings and insist on sending your traffic to the data center that is down. You are frustrated when you find out that users of ISP A are being served out of your Data Center at ISP B, even though you have a data center connected to ISP A. You think Anycast might be the answer but not everyone is set up to do Anycast. You find some clever people have been aggregating data that will offer to geolocate your callers IP addresses and maybe there is a way to use that information to find the nearest server. You realize the accuracy of this list is dubious, the exchange points for several countries may actually be on the coasts of the United States, and how would you integrate this into your DNS or HTTP redirector, while still doing 2 shift day job.You turn to alternatives, and find the shiny boxes and/or services called the GLBS. They perform 2 main services.First, they hand out answers, which may vary in time and space, to your clients as to where to find the service they are looking for.Second, they decide what this "right" answer is.You post to NANOG and you get admonished about their efficacy on both counts. This is initially wrapped in appeals to love of God and country and general harm that might befall mankind but no one says what or why.On reflection, objections to the first part of this are usually along the "strict constructionist" point of view. No real harm comes from returning changing answers but when the Man who wrote the book jumps in with both feet you take pause. He chides people for using stupid tricks. You wonder if they are stupid in the same way as the "For Dummies" series of books is not really for dummies.Objections to the determination of what the "right" answer is are more vociferous. Some immediately take the view that since the question was about DNS based load balancers, the inference was that the GLBS must be using DNS logistics to decide what the right answer is, even though DNS may simply be used to "right communicate the right answer ( the first part) , but not calculated ( the second part).The GLBS may indeed be using some measure of server load, or even BGP derived network maps, or some other knowledge of topology or proximity but that gets drowned in the "the proximity of the DNS resolver to the GLBS is not a proxy for the actual end user". The latter is actually strictly true, and it is difficult to argue given the specific examples of where it fails, but no one is able to say how many times in normal use this technique actually returns a bad answer.You even hear from a man with one leg in US and one in Europe using a split tunnel VPN who wonders why when he orders Pizza using his tunnel to the HQ back in Europe, he doesn't get greasy satisfaction back in the US. You wonder what happens when he calls 911 on his VOIP phone, without having manually configured his PSAP in that configuration, but you have other problems to worry about at the moment. You also hear about the "AOL Proxy" effect masking all users behind it. Well actually you don't hear that, but someone should have chimed in about that.You hear some mumbling about the use of AS path lengths or a geo-location database of end user IPs not being a true measure. Yet you wonder if the Internet is actually not getting more stable everyday and that the nominal topology and the AS Paths for the more heavily trafficked routes may actually not change that rapidly in normal course.You also hear from others who have been using variations of GLBS for several years, and have even created large businesses by serving their customers this way. Their web sites are full of gleaming testimonials from these customers. Some one says no one got fired for using the GLBS... You wonder if those customers just bought insurance. You scratch your head some more. You want to order that pizza on line but you decide against it.You
Re: IP Delegations for Forum Spammers and Invalid Whois info
On Monday 03 Jul 2006 16:26, Phil Rosenthal wrote: We are very much anti-spam and I will look into Mark's issue - I'm looking through the tickets for abuse@ and there is no email sent in from [EMAIL PROTECTED] ... I suspect he tried [EMAIL PROTECTED] which seems to be in rfc-ignorant. Looks like the server; 195.225.177.31 Has been spewing guest book spam (and wiki spam) out, as a quick google of 195.225.177.31 nice site will show hundreds of links, although quite a lot of it just looks bizarre, and Dshield shows 80,000 odd reports port 80 probes in the last month from this address. We've just cleaned up a lot of address book spam promoted sites, so I know it is relentless and tedious thing to squash.
Re: IP failover/migration question.
It's actually a rather frustrating situation for people who aren't big enough to justify a /19 and an AS#, but require geographically dispersed locations answering on the same IP(s). If the number of IPs you require is small, then you can probably solve the problem with IPv4 anycasting. Several people have built out distributed anycast networks but the problem is that they think IPv4 anycast is a DNS thing. Therefore they don't sell anycast hosting services to people like you who need it. Of course, if you made them more aware of market demand, this could change. --Michael Dillon
Re: DNS Based Load Balancers
On Jul 5, 2006, at 5:18 AM, Lincoln Dale wrote: but it's a perfect example of why GSLB based on DNS ain't perfect. What would be a better solution then? utopia would be for DNS to be enhanced in some manner such that the 'end user ip-address' became visible in the DNS request. utopia would have NAT devices which actually updated that in-place so an authoritive nameserver always authoritively _knew_ the public ip- address of where the request was coming from. That would kill all cacheability of DNS. Split tunnel VPNs do somewhat break the DNS GSLB model, but I don't think that's as bad as anti-DNS GSLB people claim it is. If you were on a full- tunnel VPN, you would expect to be sent to nocal, right? This could also be fixed in split tunnel VPNs with a local DNS proxy that only used the DNS cache on the other side of the VPN for the internal domains, and your ISP's DNS cache for everything else. That proxy could even be built into your VPN client. With wide open recursive nameservers getting such bad press lately, I would expect to see client - caching nameserver proximity getting a lot closer.
RE: DNS Based Load Balancers
GSLB based on DNS have one significant shortcoming that moone here has yet mentioned: they are performing their magic on the location of the _nameserver_ that issued the query. this can be VERY different to that of the ACTUAL location of the client. Systems that infer stuff make errors, at least DNS GSLB fails working I've seen problems with DRM that assumed the IP requesting http would be the same as that requesting rtsp, neither of which were the actual client after some ISP caching. for example, Akamai always sends to off to a serverfarm in Northern California, because that's where my DNS query is originating from. that is almost the exact opposite side of the planet from where I'm coming from... That's more a failure of your systems than Akamai, depending on something the other side of the planet for something best done locally irony is that there is an akamai cluster about 10 feet away from where my [subsequent] http requests originate from... yes, like a free ride when you've already paid I don't see any point arguing over DNS GSLB. It exists, it can work, and no surprise some products aren't well designed. We've used a DNS GSLB system since 1997, it does the job we designed it to, it has the edge cases we expected, we're happy with it. Don't try using one without adult supervision The hardware SLB products we've tried have caused more down time than our DNS LB brandon
Re: Fanless x86 Server Recommendations
We're looking to acquire a couple small servers that can act as routers for us at remote locations. You may want to check out soekris. (www.soekris.com) This type of server is far more common nowadays than it was when Soekris launched their business. A Google search will lead you to dozens of fanless servers built around a VIA EPIA mini-itx board or one of AMD's GEODE chips. --Michael Dillon
Re: Fanless x86 Server Recommendations
...but the fanless chips are not always as fanless as you might like. I've seen a number of them come back well fried. Fanless doesn't just mean no fans to break down. It also means well-ventilated installation required. Maybe you can find a datacenter with so many hot bladeservers that they can't fill their racks. Then you could ask them to give you 8U cheap at the bottom of a rack and mount your servers vertically for maximal airflow. ;-) --Michael Dillon P.S. on the other hand, if there is enough demand for fanless server installations, maybe some datacenters will begin to offer vertically vented space at the bottom of their racks...
RE: DNS Based Load Balancers
John Payne wrote: On Jul 5, 2006, at 5:18 AM, Lincoln Dale wrote: utopia would be for DNS to be enhanced in some manner such that the 'end user ip-address' became visible in the DNS request. utopia would have NAT devices which actually updated that in-place so an authoritive nameserver always authoritively _knew_ the public ip- address of where the request was coming from. That would kill all cacheability of DNS. Only if you envision an extension that adds an 'end user IP address' to the query and doesn't add a 'scope of cacheability' to the reply. I admit it's possible that an extension could be bungled that badly, but not likely. DS
NANOG Spam?
Am I the only one to get this email? Headers say merit.edu sent it. I have NANOG whitelisted, though, so it came to my mailbox. HEADERS: Microsoft Mail Internet Headers Version 2.0 Received: from mx1.exchange.riversidecg.com ([10.10.1.20]) by be01.windows.riversidecg.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Jul 2006 12:43:14 -0500 Received: from mail1.hosting.riversidecg.com ([172.31.0.1]) by mx1.exchange.riversidecg.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Jul 2006 12:43:14 -0500 Received: from localhost (localhost [127.0.0.1]) by mail1.hosting.riversidecg.com (Postfix) with ESMTP id C656541A5BD for [EMAIL PROTECTED]; Wed, 5 Jul 2006 12:41:19 -0500 (CDT) Received: from mail1.hosting.riversidecg.com ([217.160.254.38]) by localhost (viruscheck1.hosting.riversidecg.com [217.160.254.38]) (amavisd-new, port 10024) with ESMTP id 32017-09 for [EMAIL PROTECTED]; Wed, 5 Jul 2006 12:41:15 -0500 (CDT) Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by mail1.hosting.riversidecg.com (Postfix) with ESMTP id 6A32C41F358 for [EMAIL PROTECTED]; Wed, 5 Jul 2006 12:41:15 -0500 (CDT) Received: by trapdoor.merit.edu (Postfix) id 7D1CA91265; Wed, 5 Jul 2006 13:39:22 -0400 (EDT) Delivered-To: [EMAIL PROTECTED] Received: by trapdoor.merit.edu (Postfix, from userid 56) id DF52991264; Wed, 5 Jul 2006 13:39:20 -0400 (EDT) Delivered-To: [EMAIL PROTECTED] Received: from trapdoor.merit.edu (unknown [84.232.124.32]) by trapdoor.merit.edu (Postfix) with SMTP id AD0CF91265 for [EMAIL PROTECTED]; Wed, 5 Jul 2006 13:39:15 -0400 (EDT) From: [EMAIL PROTECTED] [EMAIL PROTECTED] To: [EMAIL PROTECTED] Content-type: text/html; Charset=Windows-1251 Subject: ***SPAM*** Wanna hold a brick on your dick? Try our Soft Cialis Tabs. (Warning: =?iso-8859-1?Q?don=92t?= try it). Message-Id: [EMAIL PROTECTED] Date: Wed, 5 Jul 2006 13:39:15 -0400 (EDT) Sender: [EMAIL PROTECTED] Precedence: bulk Errors-To: [EMAIL PROTECTED] X-Loop: nanog X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at viruscheck1.hosting.riversidecg.com X-Amavis-Alert: BAD HEADER Non-encoded 8-bit data (char 92 hex) in message header 'Subject' Subject: ...r Soft Cialis Tabs. (Warning: don\222t try it). \n ^ X-Spam-Status: Yes, hits=20.6 tagged_above=6.0 required=8.0 tests=BAYES_50, DRUGS_ERECTILE, FB_CIALIS_LEO3, FB_Y0U, FR_3TAG_3TAG, HTML_30_40, HTML_MESSAGE, HTML_MIME_NO_HTML_TAG, HTML_NONELEMENT_60_70, MIME_8BIT_HEADER, MIME_HEADER_CTYPE_ONLY, MIME_HTML_ONLY, RAZOR2_CF_RANGE_51_100, RAZOR2_CHECK, SARE_HTML_MANY_BR05, SARE_HTML_MANY_BR10, SUBJECT_DRUG_GAP_C, URIBL_AB_SURBL, URIBL_OB_SURBL, URIBL_SBL, URIBL_SC_SURBL, URI_END_IS_SHORT X-Spam-Level: X-Spam-Flag: YES Return-Path: [EMAIL PROTECTED] X-OriginalArrivalTime: 05 Jul 2006 17:43:14.0506 (UTC) FILETIME=[7DD21AA0:01C6A05A] BODY: From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, July 05, 2006 12:39 PM To: [EMAIL PROTECTED] Subject: ***SPAM*** Wanna hold a brick on your dick? Try our Soft Cialis Tabs. (Warning: don't try it). With our Soft Cial1s Tabs y0u can have $ex: Anytime. Anywhere. W1th anyone you want. @s l0ng as you want. As often as you want. http://oarwind.info/ct/? http://oarwind.info/ct/ Be a man of her dreams with Cialis Soft Tabs! =640504C41456EBDBB49B2B4A1ABAC6AAFAF95978A509E9A8= he felt worse, as he now had a sharp pain in his toe to deal with in addition
Re: DNS Based Load Balancers
As someone who has also deployed GSLB's with hardware applicances I would also like to know real world problems and issues people are running into today on modern GSLB implementations and not theoretical ones, as far as I can tell our GSLB deployment was very straight forward and works flawlessly. since works flawlessly could just mean that you don't have any reported problems with the technology -- no complaints from your users, no bugs logged with your vendor, etc, i have two bracketing questions. first, have you measured the improvement you got -- in terms of min/max/avg/stddev of TTFB/TTLB (time to first byte / last byte) with the appliances turned on vs. turned off? second, have you measured the dns damage your gslb might cause or contribute to, due to things not responding to unhandled QTYPES ( comes to mind) or use of abnormally low DNS TTL? i'm not as much interested in whether a technology causes no problems for its operator as whether its cost:benefit is worthwhile to the internet community. -- Paul Vixie
Re: DNS Based Load Balancers
What would be a better solution then? multiple A RR's for your web service, each leading to an independent web server (which might be leased capacity rather than your own hardware), each having excellent (high bandwidth, low latency, etc) connectivity to a significant part of the internet. the law of averages is a good friend to those who can adequately provision, so the likely outcome is that you won't need anything fancy. but if you need something fancy, use session level redirects to tell a web browser or sip client that there's a better and closer place for them to get their service. pundits please note that the fancy thing i'm recommending sit perfectly on top of the non-fancy thing i'm recommending. -- Paul Vixie
re: NANOG Spam?
Joe Johnson wrote: Am I the only one to get this email? Headers say merit.edu sent it. I have NANOG whitelisted, though, so it came to my mailbox. You do realize that by including the whole email, that anyone who had it blocked, will not have seen your message either. I have multiple spam filtering, and that message was trapped at my first line of defense. Only because I have the habit of grepping From headers, did I see your message... What was funny is that you got a higher score with spamassassin than the original spam did;-) -- No matter how much you want to try and spin it, MySpace is the Paris Hilton of the internet. (http://www.digg.com/users/ArcaneDevice)
Re: NANOG Spam?
Subject: NANOG Spam? Date: Wed, 5 Jul 2006 12:56:19 -0500 From: Joe Johnson [EMAIL PROTECTED] To: nanog@merit.edu Am I the only one to get this email? Headers say merit.edu sent it. I have NANOG whitelisted, though, so it came to my mailbox. [...snip spam...] No, I got it as well but Postini caught it for me. So I hadn't seen it... Just a joe-job though. The headers are forged. See the IP address in thi FIRST Received-by: header. Came from Spain. [...snip later headers...] Received: from trapdoor.merit.edu (unknown [84.232.124.32]) by trapdoor.merit.edu (Postfix) with SMTP id AD0CF91265 for [EMAIL PROTECTED]; Wed, 5 Jul 2006 13:39:15 -0400 (EDT) From: [EMAIL PROTECTED] [EMAIL PROTECTED] To: [EMAIL PROTECTED] Content-type: text/html; Charset=Windows-1251 --- % Rights restricted by copyright. % See http://www.ripe.net/db/copyright.html % Information related to '84.232.124.0 - 84.232.125.255' inetnum:84.232.124.0 - 84.232.125.255 netname:TELELEPE-NET descr: Television Por Cable descr: Hermanos Ponce Garcia S.L. descr: Local TV and ISP Provider country:es admin-c:GPP18-RIPE tech-c: GPP18-RIPE status: ASSIGNED PA mnt-by: SERVIHOSTING-MNT source: RIPE changed:[EMAIL PROTECTED] 20060126 person: Gregorio Ponce Pozuelo address:C/Niña, 31 address:21440 Lepe (Huelva) SPAIN phone: +34 959645086 fax-no: +34 959158409 e-mail: [EMAIL PROTECTED] nic-hdl:GPP18-RIPE notify: [EMAIL PROTECTED] mnt-by: SERVIHOSTING-MNT changed:[EMAIL PROTECTED] 20060126 source: RIPE % Information related to '84.232.0.0/17AS29119' route: 84.232.0.0/17 descr: ServiHosting Networks S.L. descr: First Allocation remarks:** remarks:|For ABUSE/SPAM/SCANS issues | remarks:|send mail to [EMAIL PROTECTED] | remarks:|or Fax at number +34.966982510 | remarks:** origin: AS29119 mnt-by: SERVIHOSTING-MNT notify: [EMAIL PROTECTED] changed:[EMAIL PROTECTED] 20060113 source: RIPE Regards, Gregory Hicks - Gregory Hicks | Principal Systems Engineer Cadence Design Systems | Direct: 408.576.3609 555 River Oaks Pkwy M/S 9B1 San Jose, CA 95134 I am perfectly capable of learning from my mistakes. I will surely learn a great deal today. A democracy is a sheep and two wolves deciding on what to have for lunch. Freedom is a well armed sheep contesting the results of the decision. - Benjamin Franklin The best we can hope for concerning the people at large is that they be properly armed. --Alexander Hamilton
Re: NANOG Spam?
On 7/5/06, Gregory Hicks [EMAIL PROTECTED] wrote: Subject: NANOG Spam? Date: Wed, 5 Jul 2006 12:56:19 -0500 From: Joe Johnson [EMAIL PROTECTED] To: nanog@merit.edu snip Just my .02, emails to [EMAIL PROTECTED] (HA! like i'll get a response!) and [EMAIL PROTECTED] (not expecting a response from this one either) have been sent. Anybody else feel like telling these folks that they've got spammers on their networks? Allen Parker
Re: NANOG Spam?
Gregory Hicks wrote: Just a joe-job though. The headers are forged. See the IP address in thi FIRST Received-by: header. Came from Spain. [...snip later headers...] Received: from trapdoor.merit.edu (unknown [84.232.124.32]) by trapdoor.merit.edu (Postfix) with SMTP id AD0CF91265 for [EMAIL PROTECTED]; Wed, 5 Jul 2006 13:39:15 -0400 (EDT) From: [EMAIL PROTECTED] [EMAIL PROTECTED] To: [EMAIL PROTECTED] Yes, we all got it, and Google spam filters let it through, as it matches a valid mailing list. No, the received headers are not forged. The From and To are forged. The spammers have figured out how to bypass the NANOG members-only posting, in this case by pretending to be John Fraizer and sending directly to trapdoor. They're using old lists. He hasn't sent anything to NANOG from that address since 15 Feb 2005 14:30:47 -0500. Anyway, it's probably a good thing to nip this in the bud. It should hurt (a lot) to send spam to network operators themselves. AS | IP | AS Name 29119 | 84.232.124.32| SERVIHOSTING-AS ServiHosting N PEER_AS | IP | AS Name 6739| 84.232.124.32| ONO-AS Cableuropa - ONO
Re: NANOG Spam?
William Allen Simpson wrote: The spammers have figured out how to bypass the NANOG members-only posting, in this case by pretending to be John Fraizer and sending directly to trapdoor. On our public list servers we now require admin approval of all new subscriptions as well as email verification. It takes time, but it is worth it. Additionally, the admins occassionally reply to new subscribers with questionable addresses and ask them for a bit more info (who/what/why/etc). Finally all new subscribers are automatically moderated until their first post proves them to in fact be legit and on topic. Finally, we crawled the archives of the big lists and have come up with a list of subscribers who haven't posted in over 9 months, we plan to set the mod bit on them too very soon. These are necessary steps simply because we see at least 30 requests each week for what amounts to invalid subscriptions, if those subscriptions went through unfettered then users would be upset. Even if one bogus subscription slips through, the auto-mod provides a second chance to stop them. Perhaps these are some ideas for the NANOG mailinglist admins to implement. -Jim P.
Re: NANOG Spam?
Allen Parker wrote: Just my .02, emails to [EMAIL PROTECTED] (HA! like i'll get a response!) and [EMAIL PROTECTED] (not expecting a response from this one either) have been sent. Anybody else feel like telling these folks that they've got spammers on their networks? I sent to [EMAIL PROTECTED] about the spam source. And also to [EMAIL PROTECTED] Also tried [EMAIL PROTECTED] The spam beneficiary was, of course, a US entity pretending to be from Germany, with a throwaway obscured Yahoo address: Domain Name:OARWIND.INFO ... Tech Name:Audrey Pokela Tech Organization:Audrey Pokela Tech Street1:2940 115 Ave NW Tech Street2: Tech Street3: Tech City:COON RAPIDS Tech State/Province:MN Tech Postal Code:55433 Tech Country:US Tech Phone:+1.7634272392 Tech Phone Ext.: Tech FAX: Tech FAX Ext.: Tech Email:[EMAIL PROTECTED] Name Server:NS1.RENTSHELL.INFO Name Server:NS2.FORTWALK.INFO Name Server:NS1.BUSITEEN.INFO Name Server:NS2.SPOLF.INFO oarwind.info. AS | IP | Registry | AS Name 6724| 81.169.143.178 | ripencc | STRATO Strato AG PEER_AS | IP | Registry | AS Name 1273| 81.169.143.178 | ripencc | CW Cable _ Wireless 5430| 81.169.143.178 | ripencc | FREENETDE freenet Cityline Gmb inetnum: 81.169.128.0 - 81.169.143.255 netname: STRATO-RZG-DED descr:Strato Rechenzentrum, Berlin country: DE admin-c: CM265-RIPE tech-c: XX1-RIPE tech-c: WB14-RIPE remarks: ** remarks: * please report spam/abuse/attaks mailto:[EMAIL PROTECTED] * remarks: * reports to other addresses will not be processed * remarks: * please do not report simple portscans * remarks: ** status: ASSIGNED PA mnt-by: STRATO-RZG-MNT mnt-lower:STRATO-RZG-MNT mnt-routes: STRATO-RZG-MNT
