Re: Constant Abuse Reports / Borderline Spamming from RiskIQ

[Raymond Dijkxhoorn]

Ha!

The first warning sign would be where they discuss your AUP and 
exceptions / corner cases to it


Or

'we just need a /24, we are doing e-mail services and we can assure 
you its all good'


...

Bye, Raymond

Re: DOS for hire issues

[Raymond Dijkxhoorn]

Hai!

Many hosting providers and esp's experience that same issue.

After many discussions at maawg (www.maawg.org) a community efford was founded 
and supported by a few very big esp's helping to optimize their signup proces 
and implementing customer vetting. 

Much can be done on that end to bring down abuse issues. 

There is also a community database included where you can 'report' these bad 
actors. So other people wont run into the same miscreants over and over.

If you make effords to keep bad guys out by tightening up your signup proces 
things do tend to get better.

Posting on list since i hope, just like we tell people to implement bcp38, more 
people will look into cleaning things at the far beginning of the chain.

If you want to make the world a better place i think 

Thanks,
Raymond Dijkxhoorn

(You can find more about it on the e-hawk site (www.e-hawk.net). 

Just posting this single url, since i dont know any others that will help you 
out with that. If other people do know please post offlist to me do i can also 
recommend that wherever i can. 

> Op 14 dec. 2016 om 23:19 heeft ping murder  het 
> volgende geschreven:
> 
> Hello,
> One of the hosting brands we recently acquired is overrun with DOS for hire
> providers and individuals. We kill them as they alert however I'm curious
> if there's a discussion group or location, contacts, etc we might be able
> to coordinate in about the actors behind these accounts (assuming this
> isn't the right place for that, however has a lot of the right people).
> 
> If I'm out of my lane, forgive me.
> Thanks,
> pm

Re: East coast outage

[Raymond Dijkxhoorn]

Hello Ben,


Is anyone else seeing connectivity issues along the east coast?  Our pipe
through HE in NYC is showing loss to things behind most of Level3, and
Qwest below Washington.

*Ben Hatton*

Network Engineer

Haefele TV Inc.

d:(607)589-8000

bhat...@htva.net

www.htva.net


We see the same, traffic going from Amsterdam towards HE heading USA is 
experiencing big packetloss at the moment.


Traffic heading towards Ashburn seems affected from our point of view.

Bye,
Raymond.

Re: Request Spamhaus contact

[Raymond Dijkxhoorn]

Hi!


That's fine, but the listings don't even make sense. There is no
evidence in the listing and i'm still trying to figure out a) why they
think that these new listings have anything to do with the ones we
already cleaned and b) which customers actually need to be removed and
for specifically what reasons. Their entire mentality is "the site is
pharmacy which means its part of a criminal spammer gang," regardless
of whether or not that is true.



Please stop pretending that you're not hosting e-trash.  208.64.122.114
is still hosting an active SEO poisoning site (myspace-codes.com).  I
think, frankly, it would make your life a lot simpler if you just
accepted the fact that BlackLotus sells to e-trash, just like the rest
of the "ddos-protected hosting solutions" companies do.


viagra-shopping .com
potenzmittel-at .com
medicin-24 .com
apothekeohnerezept .at

[root@noc log]# whois 208.64.122.234
[Querying whois.arin.net]
[Redirected to rwhois.blacklotus.net:4321]
[Querying rwhois.blacklotus.net]
[rwhois.blacklotus.net]
%rwhois V-1.0,V-1.5:00090h:00 support.blacklotus.net (Ubersmith RWhois 
Server V-1.8.0)

autharea=208.64.120.0/21
xautharea=208.64.120.0/21
network:Class-Name:network
network:Auth-Area:208.64.120.0/21
network:ID:NET-481.208.64.122.232/30
network:Network-Name:Nameserver IP Addresses
network:IP-Network:208.64.122.232/30
network:IP-Network-Block:208.64.122.232 - 208.64.122.235
network:Org-Name:Aloli LTD
network:Street-Address:3321 Road Town, Drake Chambers
network:City:Tortola
network:State:-
network:Postal-Code:3321
network:Country-Code:
network:Tech-Contact:MAINT-481.208.64.122.232/30
network:Created:20101015124139000
network:Updated:20101015124139000
network:Updated-By:supp...@blacklotus.net
network:POC-Name:Network Operations Center
network:POC-Email:supp...@blacklotus.net
network:POC-Phone:(323) 657-5944
network:Tech-Name:Network Operations Center
network:Tech-Email:supp...@blacklotus.net
network:Tech-Phone:(323) 657-5944

This thread doesnt belong here. But hey, seems they are asking for it.
Oh and yes all these botnet landing pages are still up...

If i look back at November 2010 archives there is a whole bunch and its 
adding new domains daily.


brandviagra23 .com
brandviagra27 .com
brandcialis26 .com
brandviagra25 .com
...

Neh, clean as it can be cough ...

Bye,
Raymond.

Re: Request Spamhaus contact

[Raymond Dijkxhoorn]

Hi!


1) The sites were already null routed. The problem is with Spamhaus'
inability to contact me prior to impacting other legitimate customers.


Null routed?

Its up!

[root@master tmp]# host www.viagra-shopping.com
www.viagra-shopping.com has address 208.64.127.78


viagra-shopping .com
potenzmittel-at .com
medicin-24 .com
apothekeohnerezept .at


Please take more then 2 seconds to reply and clean up your act first!

Jan 17 15:20:08 CET potenzmittel-at.com: [208.64.127.87]

You didnt shut down what i put in this mail. Please act now, clean it. 
Clean more, there is zillions


You seriously need to check your network first before complaining.

Bye,
Raymond.

Re: Request Spamhaus contact

[Raymond Dijkxhoorn]

Hi!


That is not in our IP space. These are the only SBL's we have outstanding:

SBL101835
208.64.127.64/27blacklotus.net
17-Jan-2011 14:44 GMT
Drug spam domain hosting


SBL101662
208.64.123.176/28   blacklotus.net
14-Jan-2011 10:31 GMT
Drug spam domain hosting



208.64.120.186 canadian-rx-store.org

I connected to 208.64.120.186 on TCP port 80 and finger-boned an HTTP
request for http://canadian-rx-store.org/ and the server responded as
I would expect a server configured with that name to respond.

canadian-rx-store .org? Really?


So they need, and will add more.

NetRange:   208.64.120.0 - 208.64.127.255
CIDR:   208.64.120.0/21
OriginAS:   AS32421
NetName:NET-208-64-120-0-1
NetHandle:  NET-208-64-120-0-1
Parent: NET-208-0-0-0-0
NetType:Direct Allocation
NameServer: NS1.ENTERPRISE.BLACKLOTUS.NET
NameServer: NS2.ENTERPRISE.BLACKLOTUS.NET
RegDate:2005-12-22
Updated:2009-11-11
Ref:http://whois.arin.net/rest/net/NET-208-64-120-0-1

OrgName:Black Lotus Communications
OrgId:  BLC-92
Address:3419 Virginia Beach Blvd. #D5

Thats not your IP space? Really? How come.

apothekeosterreich .at -> 208.64.120.197
vertrouwdeapotheek .nl -> 208.64.120.197

viagra-shopping .com -> 208.64.127.78
medicin-24 .com -> 208.64.127.78

apothekeohnerezept .at -> 208.64.127.66

www.medicin-24 .com -> 208.64.127.78
www.viagra-shopping .com -> 208.64.127.78

This is just like 3 minutes digging in todays spamfolders.

Instead of typing here, i would be rather nervous and placing null routes 
wherever i could.


Bye,
Raymond.

Re: Request Spamhaus contact

[Raymond Dijkxhoorn]

Hi!


208.64.120.186 canadian-rx-store.org

That is not in our IP space.



http://whois.arin.net/rest/nets;q=208.64.120.186?showDetails=true&showARIN=false


If they claim its not theirs lets ask ARIN to revoke the space.

Bye,
Raymond.

Re: Re: Request Spamhaus contact

[Raymond Dijkxhoorn]

Hi!


Spam does not make me nervous, it's a practical matter that we will
address in due course. The null routes we have set are pretty recent
so you may have received some spam prior to that time but I absolutely
guarantee you that it did not come from our network, otherwise we
would have detected it and stopped it on the spot.



Thats not your IP space? Really? How come.

apothekeosterreich .at -> 208.64.120.197
vertrouwdeapotheek .nl -> 208.64.120.197

viagra-shopping .com -> 208.64.127.78
medicin-24 .com -> 208.64.127.78

apothekeohnerezept .at -> 208.64.127.66

www.medicin-24 .com -> 208.64.127.78
www.viagra-shopping .com -> 208.64.127.78

This is just like 3 minutes digging in todays spamfolders.


www.apothekeosterreich .at is still up at the mentioned ip. Instead of 
telling you are s good on terminating stuff. Can you walk over the 
list and act?


I have sended in many requests for termination. You or your network dont 
respond to this at all.


Its a waste of time even telling it seems.

I will stop posting here, spam-l is a much better place for this. But 
please dont act like you dont know anything whats going on. You have been 
warned. You have gotten many many reports. But we dont see stuff changing.


Good luck with your listing at SpamHaus.

Bye,
Raymond.

Re: {Spam?} Re: Request Spamhaus contact

[Raymond Dijkxhoorn]

Hi!


Actually, that was just a brain lapse. The domain didn't resolve at
all (misspelled?) and it returned the Cox default resolution.


Instead of looking at typo's or misspelled stuff, can you null route the 
rest of the abuse reports that came in? Or should we get it added on the 
SBL listing since it seems thats the only way to get your attention.



apothekeosterreich .at -> 208.64.120.197
vertrouwdeapotheek .nl -> 208.64.120.197

viagra-shopping .com -> 208.64.127.78
medicin-24 .com -> 208.64.127.78

apothekeohnerezept .at -> 208.64.127.66

www.medicin-24 .com -> 208.64.127.78
www.viagra-shopping .com -> 208.64.127.78

This is just like 3 minutes digging in todays spamfolders.

Instead of typing here, i would be rather nervous and placing null routes
wherever i could.


Bye,
Raymond.

Re: Re: Request Spamhaus contact

[Raymond Dijkxhoorn]

Hi!


We've acted on every report that we're aware of and instead you want
to play pharmacy domain scavenger hunt. This domain at 208.64.120.197
redirects to IP space we already null routed. It's the same customer.


Either you place strange nullroutes or you did not at all.

[root@mi10 tmp]# wget -S www.vertrouwdeapotheek.nl
--01:37:29--  http://www.vertrouwdeapotheek.nl/
   => `index.html'
Resolving www.vertrouwdeapotheek.nl... done.
Connecting to www.vertrouwdeapotheek.nl[208.64.120.197]:80... connected.
HTTP request sent, awaiting response...
 1 HTTP/1.1 301 Moved Permanently
 2 Cache-Control: private
 3 Content-Length: 0
 4 Location: http://www.vertrouwdeapotheek.nl/Home.aspx
 5 Server: Microsoft-IIS/7.0
 6 X-AspNet-Version: 4.0.30319
 7 X-Powered-By: ASP.NET
 8 Date: Tue, 18 Jan 2011 00:37:04 GMT
 9 Connection: close
Location: http://www.vertrouwdeapotheek.nl/Home.aspx [following]
--01:37:29--  http://www.vertrouwdeapotheek.nl/Home.aspx
   => `Home.aspx'
Connecting to www.vertrouwdeapotheek.nl[208.64.120.197]:80... connected.
HTTP request sent, awaiting response...

Does this look as its nullrouted?


P.S. Someone at Spamhaus PLEASE remove the /21 listing?


I highly doubt. There is much more to clean on your network before i hope 
they would even reconsider.


Bye,
Raymond.

Re: Re: Request Spamhaus contact

[Raymond Dijkxhoorn]

Hi!


I fat fingered the netmask, try now.



HTTP request sent, awaiting response...
 1 HTTP/1.1 301 Moved Permanently
 2 Cache-Control: private
 3 Content-Length: 0
 4 Location: http://www.vertrouwdeapotheek.nl/Home.aspx
 5 Server: Microsoft-IIS/7.0
 6 X-AspNet-Version: 4.0.30319
 7 X-Powered-By: ASP.NET
 8 Date: Tue, 18 Jan 2011 00:37:04 GMT
 9 Connection: close
Location: http://www.vertrouwdeapotheek.nl/Home.aspx [following]
--01:37:29--  http://www.vertrouwdeapotheek.nl/Home.aspx
          => `Home.aspx'
Connecting to www.vertrouwdeapotheek.nl[208.64.120.197]:80... connected.
HTTP request sent, awaiting response...

Does this look as its nullrouted?


P.S. Someone at Spamhaus PLEASE remove the /21 listing?


I highly doubt. There is much more to clean on your network before i hope
they would even reconsider.


Resolving www.vertrouwdeapotheek.nl... done.
Connecting to www.vertrouwdeapotheek.nl[208.64.120.197]:80... connected.
HTTP request sent, awaiting response...
 1 HTTP/1.1 301 Moved Permanently
 2 Cache-Control: private
 3 Content-Length: 0
 4 Location: http://www.vertrouwdeapotheek.nl/Home.aspx
 5 Server: Microsoft-IIS/7.0
 6 X-AspNet-Version: 4.0.30319
 7 X-Powered-By: ASP.NET
 8 Date: Tue, 18 Jan 2011 00:43:18 GMT
 9 Connection: close
Location: http://www.vertrouwdeapotheek.nl/Home.aspx [following]
--01:43:43--  http://www.vertrouwdeapotheek.nl/Home.aspx
   => `Home.aspx.1'
Connecting to www.vertrouwdeapotheek.nl[208.64.120.197]:80... connected.
HTTP request sent, awaiting response...
 1 HTTP/1.1 200 OK
 2 Cache-Control: private
 3 Content-Length: 126007
 4 Content-Type: text/html; charset=utf-8
 5 Server: Microsoft-IIS/7.0
 6 X-AspNet-Version: 4.0.30319
 7 WL-Version: 2475.0
 8 Set-Cookie: ASP.NET_SessionId=4o3uhvfkqw3uanvriystoe2d; path=/; 
HttpOnly

 9 X-Powered-By: ASP.NET
10 Date: Tue, 18 Jan 2011 00:43:19 GMT
11 Connection: close

Still there.

All the best Jeffrey ... you are playing games with the wrong people.

Bye,
Raymond.

Re: Request Spamhaus contact

[Raymond Dijkxhoorn]

Hi!


Unless you guys can help find some more related IP space I think the
issue has been solved.


You are not able to even shutdown one thats mentioned. You keep telling 
us its down and null routed. Its simply not. Its alive and kicking. Bullet 
proof hosting rocks doesnt it?


This is now:

[root@fallback ~]# wget -S www.vertrouwdeapotheek.nl
--2011-01-18 02:02:20--  http://www.vertrouwdeapotheek.nl/
Resolving www.vertrouwdeapotheek.nl... 208.64.120.197
Connecting to www.vertrouwdeapotheek.nl|208.64.120.197|:80... connected.
HTTP request sent, awaiting response...
  HTTP/1.1 301 Moved Permanently
  Cache-Control: private
  Content-Length: 0
  Location: http://www.vertrouwdeapotheek.nl/Home.aspx
  Server: Microsoft-IIS/7.0
  X-AspNet-Version: 4.0.30319
  X-Powered-By: ASP.NET
  Date: Tue, 18 Jan 2011 01:02:02 GMT
  Connection: close
Location: http://www.vertrouwdeapotheek.nl/Home.aspx [following]
--2011-01-18 02:02:21--  http://www.vertrouwdeapotheek.nl/Home.aspx
Connecting to www.vertrouwdeapotheek.nl|208.64.120.197|:80... connected.
HTTP request sent, awaiting response...
  HTTP/1.1 200 OK
  Cache-Control: private
  Content-Length: 126007
  Content-Type: text/html; charset=utf-8
  Server: Microsoft-IIS/7.0
  X-AspNet-Version: 4.0.30319
  WL-Version: 2475.0
  Set-Cookie: ASP.NET_SessionId=eknnhn43j4kcqxzqwk24ewjs; path=/; HttpOnly
  X-Powered-By: ASP.NET
  Date: Tue, 18 Jan 2011 01:02:03 GMT
  Connection: close
Length: 126007 (123K) [text/html]
Saving to: "Home.aspx.2"

100%[===>] 
126,007  162K/s   in 0.8s


2011-01-18 02:02:22 (162 KB/s) - "Home.aspx.2" saved [126007/126007]

[root@fallback ~]# more Home.aspx.2

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>

http://www.w3.org/1999/xhtml";>

Vertrouwde Apotheek - Viagra ...

You either have a funny way of nullrouting stuff. OR someone just stole 
your netspace and put the same content online ;)


Bye,
Raymond.

Re: Request Spamhaus contact

[Raymond Dijkxhoorn]

Hi!


I do not take you for a fool, the assignment is legitimately null
routed. My traceroutes are dropping at my home ISP.



I call bollocks.  It's alive and kicking via BGP here.

edge1.lax01# show ip bgp 208.64.120.197/32
BGP routing table entry for 208.64.120.0/24, version 2014041464
Paths: (6 available, best #3, table default)
[...]

And I can reach it from my house.

William



So it's dead on Cox Cable and the L3 Looking Glass but not at your
house? How is that possible?


Its your network isnt it. If you dont know whats happening. ...

Mail me your router logins and i'll make sure its peoperly null routed. 
And some more.


Bye,
Raymond.

RE: Broken Teredo relay AS1101?

[Raymond Dijkxhoorn]

Hello Jimmy,


I'm still seeing this behavior, which is causing a good amount of
Teredo-based connectivity to fail.  The relay appears to be
miredo.surfnet.nl - any chance someone on the list is from SURFNet and 
could take a look?


If you can send me offlist some traces i can check for you.


This path for 2001::/32 leads to a broken teredo relay:

  3257 1103 1101

http://ip6.me was using this path and not working from my client. When I
routing to prefer 6939's relays it started working.


We see ~ 180 mbps running over the relay so i doubt its a generic thing.

Bye,
Raymond.

RE: Broken Teredo relay AS1101?

[Raymond Dijkxhoorn]

Hi!


I'm still seeing this behavior, which is causing a good amount of
Teredo-based connectivity to fail.  The relay appears to be
miredo.surfnet.nl - any chance someone on the list is from SURFNet and 
could take a look?



If you can send me offlist some traces i can check for you.



This path for 2001::/32 leads to a broken teredo relay:

  3257 1103 1101

http://ip6.me was using this path and not working from my client. When I
routing to prefer 6939's relays it started working.



We see ~ 180 mbps running over the relay so i doubt its a generic thing.


This has been resolved.

Thanks,
Raymond.

Re: Saudi Telecom sending route with invalid attributes 212.118.142.0/24

[Raymond Dijkxhoorn]

Hi!


anyone else getting a route for 212.118.142.0/24 with invalid
attributes? Seems this is (again) causing problems with some (older)
routers/software.

  Announcement bits (4): 0-KRT 3-KRT 5-Resolve tree 1
6-Resolve tree 2
   AS path: 6453 39386 25019 I Unrecognized Attributes: 39
bytes
   AS path:  Attr flags e0 code 80: 00 00 fd 88 40 01 01 02
40 02 04 02 01 5b a0 c0 11 04 02 01 fc da 80 04 04 00 00 00 01 40 05 04
00 00 00 64
   Accepted Multipath


Exactly the same here.

Sep  8 20:24:04  BBD-RC02 rpd[1334]: Received BAD update from 
94.228.128.57 (External AS 41887), aspath_attr():3472 
PA4_TYPE_ATTRSET(128) => 1 times IGNORED, family inet-unicast(1), prefix 
212.118.142.0/24


Bye,
Raymond.

RE: IPv6 side of www.charter.com has been down since Friday, September 16 5:12 am Central

[Raymond Dijkxhoorn]

Hi!


Takes our HE tunnel to get out. Were also Native with Cogent (Not that it
gets us anything..)

No dice.


Native also no luck here (from .nl) :

[root@ipv6proxy ~]#  traceroute6 www.charter.com
traceroute to www.charter.com (2607:f428:3:1:80:80:80:1), 30 hops max, 80 
byte packets
 1  2a00:d00:ff:131::253 (2a00:d00:ff:131::253)  0.610 ms  0.708 ms  0.700 
ms

 2  2a00:d00:1:4::2 (2a00:d00:1:4::2)  0.644 ms  0.637 ms  0.745 ms
 3  hurricane-electric.nikhef.nlsix.net (2001:7f8:13::a500:6939:1)  0.549 
ms  0.547 ms  0.551 ms
 4  10gigabitethernet1-4.core1.lon1.he.net (2001:470:0:3f::1)  8.584 ms 
8.587 ms  8.609 ms
 5  10gigabitethernet7-4.core1.nyc4.he.net (2001:470:0:3e::1)  76.459 ms 
76.473 ms  76.453 ms
 6  10gigabitethernet8-3.core1.chi1.he.net (2001:470:0:1c6::2)  97.787 ms 
96.714 ms  93.772 ms

 7  2001:470:0:114::2 (2001:470:0:114::2)  93.941 ms  93.924 ms  93.968 ms
 8  bbr02chcgil-tge0-1-0-1.il.chcg.charter.com (2001:506:100:31d::1) 
104.974 ms bbr02chcgil-tge0-0-0-1.il.chcg.charter.com 
(2001:506:100:317::2)  99.650 ms 
bbr02chcgil-tge0-0-0-0.il.chcg.charter.com (2001:506:100:305::1)  99.767 
ms
 9  bbr01olvemo-tge0-5-0-4.mo.olve.charter.com (2001:506:100:5c::2) 
106.416 ms  101.397 ms  101.371 ms

10  * * *
11  2001:506:100:6c::2 (2001:506:100:6c::2)  101.667 ms  101.553 ms 
101.598 ms

12  * * *
13  * * *
14  * * *
15  * * *
16  *^C
[root@ipv6proxy ~]# ping6 www.charter.com
PING www.charter.com(2607:f428:3:1:80:80:80:1) 56 data bytes
^C
--- www.charter.com ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3700ms

[root@ipv6proxy ~]# wget -6 www.charter.com
--2011-09-19 20:47:13--  http://www.charter.com/
Resolving www.charter.com... 2607:f428:3:1:80:80:80:1
Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80...

Bye,
Raymond.

Re: BGP Peers as basis of available routes

[Raymond Dijkxhoorn]

Hi!

Dont mix up peering and transit connections!

That you dont see that route on a lookingglass doesnt mean much. Only Could 
tell you they dont transit there.

Its all depending what you definiëren with available routes.

If i peer with all ISP's in a specific area and your looking glass isnt licated 
there does that mean its bad? You need to know much more. If your customers are 
local there its even prefered.

Its never that black/white ...its depending on your needs!

Thanks,
Raymond Dijkxhoorn, Prolocation


Op 19 okt. 2011 om 08:46 heeft "Nathanael C. Cariaga"  
het volgende geschreven:

> Hi!
> 
> We're currently evaluating web hosting providers in the APAC region and one 
> of the criteria that we are currently considering is the availability of 
> routes going to the web hosting provider.
> 
> In this regard,  I would like to ask for your idea regarding this.  Is it 
> safe to conclude that the web hosting provider's available routes would would 
> depend on the peers who are advertising their AS / network?  (i.e if web 
> hosting provider claims that they are peering with telco a, b, c but as seen 
> from a third party looking glass, only C is seen advertising the web hosting 
> provider network that would mean web hosting provider is effectively 
> utilizing c as their upstream??)
> 
> Thanks.
> 
> 
> -- 
> -nathan

Re: BGP Peers as basis of available routes

[Raymond Dijkxhoorn]

Hi!

You wont see those local peerings unless all those providers have looking 
glasses. So thats not gonna work out in this case. You will only see who they 
transit with...

Thanks,
Raymond Dijkxhoorn, Prolocation


Op 19 okt. 2011 om 09:21 heeft "Nathanael C. Cariaga"  
het volgende geschreven:

> Hi.
> 
> Thanks for the prompt response.  Actually our requirement is to find a 
> webhosting provider whose routes are widely advertised locally and 
> regionally.  This is why I thought of using bgp as a basis studying the 
> availability of routes of the hosting provider.
> 
> 
> -nathan
> 
> On 10/19/2011 3:00 PM, Raymond Dijkxhoorn wrote:
>> Hi!
>> 
>> Dont mix up peering and transit connections!
>> 
>> That you dont see that route on a lookingglass doesnt mean much. Only Could 
>> tell you they dont transit there.
>> 
>> Its all depending what you definiëren with available routes.
>> 
>> If i peer with all ISP's in a specific area and your looking glass isnt 
>> licated there does that mean its bad? You need to know much more. If your 
>> customers are local there its even prefered.
>> 
>> Its never that black/white ...its depending on your needs!
>> 
>> Thanks,
>> Raymond Dijkxhoorn, Prolocation
>> 
>> 
>> Op 19 okt. 2011 om 08:46 heeft "Nathanael C. 
>> Cariaga"  het volgende geschreven:
>> 
>>> Hi!
>>> 
>>> We're currently evaluating web hosting providers in the APAC region and one 
>>> of the criteria that we are currently considering is the availability of 
>>> routes going to the web hosting provider.
>>> 
>>> In this regard,  I would like to ask for your idea regarding this.  Is it 
>>> safe to conclude that the web hosting provider's available routes would 
>>> would depend on the peers who are advertising their AS / network?  (i.e if 
>>> web hosting provider claims that they are peering with telco a, b, c but as 
>>> seen from a third party looking glass, only C is seen advertising the web 
>>> hosting provider network that would mean web hosting provider is 
>>> effectively utilizing c as their upstream??)
>>> 
>>> Thanks.
>>> 
>>> 
>>> --
>>> -nathan

Re: BGP Peers as basis of available routes

[Raymond Dijkxhoorn]

Hi!

Ok. Thanks for the information :)  So that would mean that to answer my 
question, I would need to determine the web hosting provider who has the most 
number of peers and most number of transit providers?


You wont see those local peerings unless all those providers have looking 
glasses. So thats not gonna work out in this case. You will only see who 
they transit with...


I cant answer that, only you can. If that hosting provider has many peers 
but your customers are not behind them its of no use.


But generally a hosting provider with many local peers, either public or 
private -might have- ok connections ;)


For example if they private peer with 10 mbps and the other one has 10 
gbps public peering...


There isnt a real answer to your question. Its based on your own buisiness 
needs and decisions on those.


Bye,
Raymond.

Re: Traceroute explanation

[Raymond Dijkxhoorn]

Hai!

Check with lft or mtr ... 

Thanks,
Raymond Dijkxhoorn, Prolocation


Op 7 dec. 2011 om 20:56 heeft "Meftah Tayeb"  het 
volgende geschreven:

> please tel me how to ?
> i don't know astraceroute:)
> 
> - Original Message - From: "Steven Bellovin" 
> To: "Meftah Tayeb" 
> Cc: "Fred Baker" ; 
> Sent: Thursday, December 08, 2011 11:33 PM
> Subject: Re: Traceroute explanation
> 
> 
> On Dec 7, 2011, at 2:51 08PM, Meftah Tayeb wrote:
> 
>> big thank for that
>> but, i am testing that for one day :)
> 
> 
> 
> Can you do an AStraceroute or manually translate those addresses into AS#s?
> That is, might level3 and tinet  be using multiple AS#s, in which case this
> isn't unreasonable?
> 
> 
> 
> 
> 
>> 
>> 
>> - Original Message - From: "Fred Baker" 
>> To: "Meftah Tayeb" 
>> Cc: 
>> Sent: Thursday, December 08, 2011 11:23 PM
>> Subject: Re: Traceroute explanation
>> 
>> 
>> This is just a guess, but I'll bet the route changed while you were 
>> measuring it.
>> 
>> Traceroute sends a request, awaits a response, sends a request, ... Suppose 
>> that the route was
>> 
>> 172.28.0.1 -> 10.16.0.2
>> -> 41.200.16.1
>> -> 172.17.2.25
>> -> 213.140.58.10
>> -> 195.22.195.125
>> -> 4.69.151.13
>> -> 213.200.68.61
>> -> somewhere else
>> 
>> and after the test got that far, two systems got inserted into the path 
>> before level3, resulting in the route entering level3 at a different point, 
>> 4.69.141.249. What you now have is
>> 
>> 172.28.0.1 -> 10.16.0.2
>> -> 41.200.16.1
>> -> 172.17.2.25
>> -> 213.140.58.10
>> -> 195.22.195.125
>> -> unknown
>> -> unknown
>> -> 4.69.141.249
>> -> 77.67.66.154
>> -> and so on
>> 
>> The effect would be to get a result like this.
>> 
>> Next time you see something like this, suggestion: repeat the traceroute and 
>> see what you get.
>> 
>> 
>> On Dec 7, 2011, at 12:12 PM, Meftah Tayeb wrote:
>> 
>>> Hey folks,
>>> i see a strange traceroute there
>>> 
>>> Détermination de l'itinéraire vers www.rri.ro [193.231.72.52]
>>> avec un maximum de 30 sauts :
>>> 
>>> 1 2 ms 1 ms 1 ms  172.28.0.1
>>> 2 1 ms 1 ms 1 ms  localhost [10.16.0.2]
>>> 310 ms10 ms13 ms  41.200.16.1
>>> 411 ms10 ms11 ms  172.17.2.25
>>> 521 ms21 ms21 ms  213.140.58.10
>>> 634 ms31 ms55 ms  pos14-0.palermo9.pal.seabone.net 
>>> [195.22.197.125
>>> ]
>>> 734 ms33 ms35 ms  ae-5-6.bar2.marseille1.level3.net 
>>> [4.69.151.13]
>>> 8   106 ms68 ms67 ms  xe-1-1-0.mil10.ip4.tinet.net [213.200.68.61]
>>> 974 ms73 ms74 ms  ae-1-12.bar1.budapest1.level3.net 
>>> [4.69.141.249]
>>> 1063 ms63 ms79 ms  euroweb-gw.ip4.tinet.net [77.67.66.154]
>>> 1185 ms84 ms84 ms  v15-core1.stsisp.ro [193.151.28.1]
>>> 12   100 ms   100 ms   102 ms  inet-crli1.qrli1.buh.ew.ro [81.24.28.226]
>>> 1381 ms81 ms81 ms  193.231.72.10
>>> 1492 ms92 ms93 ms  ip4-89-238-225-90.euroweb.ro [89.238.225.90]
>>> 1589 ms89 ms89 ms  webrri.rri.ro.72.231.193.in-addr.arpa 
>>> [193.231.7
>>> 2.52]
>>> Itinéraire déterminé.
>>> C:\Documents and Settings\TAYEB>
>>> Seabone, then level3, then Tinet, then level3, then tinet ?
>>> if is that a routing stufs that i don't know, please let me know :)
>>> i never saw that befaure
>>> 
>>>  Meftah Tayeb
>>> IT Consulting
>>> http://www.tmvoip.com/
>>> phone: +21321656139
>>> Mobile: +213660347746
>>> 
>>> 
>>> __ Information from ESET NOD32 Antivirus, version of virus 
>>> signature database 6695 (20111208) __
>>> 
>>> The message was checked by ESET NOD32 Antivirus.
>>> 
>>> http://www.eset.com
>>> 
>> 
>> 
>> 
>> __ Information from ESET NOD32 Antivirus, version of virus signature 
>> database 6695 (20111208) __
>> 
>> The message was checked by ESET NOD32 Antivirus.
>> 
>> http://www.eset.com
>> 
>> 
>> 
>> 
>> __ Information from ESET NOD32 Antivirus, version of virus signature 
>> database 6695 (20111208) __
>> 
>> The message was checked by ESET NOD32 Antivirus.
>> 
>> http://www.eset.com
>> 
>> 
>> 
>> 
>> 
> 
> 
> --Steve Bellovin, https://www.cs.columbia.edu/~smb
> 
> 
> 
> 
> 
> 
> 
> __ Information from ESET NOD32 Antivirus, version of virus signature 
> database 6695 (20111208) __
> 
> The message was checked by ESET NOD32 Antivirus.
> 
> http://www.eset.com
> 
> 
> 
> 
> __ Information from ESET NOD32 Antivirus, version of virus signature 
> database 6695 (20111208) __
> 
> The message was checked by ESET NOD32 Antivirus.
> 
> http://www.eset.com
> 
> 
> 

Re: {Spam?} Re: Traceroute explanation

[Raymond Dijkxhoorn]

Hi!


Using LFT:
root@debian:~# lft 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1  172.28.1.1 (172.28.1.1)  0.798 ms  0.711 ms
2  10.16.0.2 (10.16.0.2)  0.414 ms  0.331 ms
3  41.200.16.1 (41.200.16.1)  11.400 ms  11.474 ms
4  172.17.2.25 (172.17.2.25)  10.184 ms  11.322 ms
5  213.140.58.10 (213.140.58.10)  11.264 ms  10.623 ms
6  212.73.253.65 (212.73.253.65)  30.330 ms  32.391 ms
7  ae-4-5.bar1.Marseille1.Level3.net (4.69.151.9)  32.177 ms  32.219 ms
8  ae-7-7.ebr1.Paris1.Level3.net (4.69.143.238)  42.160 ms  42.318 ms



root@debian:~# lft www.rri.ro
traceroute to www.rri.ro (193.231.72.52), 30 hops max, 60 byte packets
1  172.28.1.1 (172.28.1.1)  0.819 ms  0.737 ms
2  10.16.0.2 (10.16.0.2)  0.402 ms  0.335 ms
3  41.200.16.1 (41.200.16.1)  10.592 ms  10.209 ms
4  172.17.2.25 (172.17.2.25)  10.146 ms  10.559 ms
5  213.140.58.10 (213.140.58.10)  11.258 ms  10.369 ms
6  pos14-0.palermo9.pal.seabone.net (195.22.197.125)  30.817 ms  31.439 ms
7  ae-5-6.bar2.Marseille1.Level3.net (4.69.151.13)  33.968 ms  31.395 ms
8  ge-0-0-0.mil19.ip4.tinet.net (213.200.68.145)  57.178 ms 
xe-1-1-0.mil10.ip4.

tinet.net (213.200.68.61)  57.749 ms
9  ae-1-12.bar1.Budapest1.Level3.net (4.69.141.249)  61.835 ms  62.317 ms
10  euroweb-gw.ip4.tinet.net (77.67.66.154)  61.361 ms  60.292 ms
11  v15-core1.stsisp.ro (193.151.28.1)  163.662 ms  144.245 ms
12  inet-crli1.qrli1.buh.ew.ro (81.24.28.226)  91.309 ms  89.880 ms
13  193.231.72.10 (193.231.72.10)  80.790 ms  79.354 ms
14  ip4-89-238-225-90.euroweb.ro (89.238.225.90)  91.067 ms  90.906 ms
15  webrri.rri.ro.72.231.193.in-addr.arpa (193.231.72.52)  79.196 ms  79.389 
ms

root@debian:~#


lft -A snows ASN also.

Example:

[root@lft ~]# lft -A www.rri.ro -d 80
Tracing .T
TTL LFT trace to webrri.rri.ro.72.231.193.in-addr.arpa 
(193.231.72.52):80/tcp

 1  [34108] vrrp-253.bbd.prolocation.net (95.128.88.253) 0.3/0.3ms
 2  [41887] breedband-delft-rc02-gige-1.prolocation.net (94.228.128.57) 
11.8/1.4ms

 3  [12871] gigabone10-3.prolocation.net (213.197.27.165) 1.3/1.4ms
 4  [1200] amx1.fra.ew.ro (195.69.144.121) 59.5/31.5ms
 5  [6663] inet-qrli1.crli1.buh.ew.ro (81.24.28.225) 38.1/38.1ms
 6  [6663] inet-crli1.qrli1.buh.ew.ro (81.24.28.226) 37.4/37.5ms
 7  [6663] qrli11.drli1.buh.ew.ro (81.24.28.242) 37.9/37.9ms
 8  [6663] ip4-89-238-225-90.euroweb.ro (89.238.225.90) 37.7/37.7ms
 9  [34808] 193.231.72.10 37.9/37.9ms
10  [34808] [target open] webrri.rri.ro.72.231.193.in-addr.arpa 
(193.231.72.52):80 37.8/38.0ms


Bye,
Raymond.

Re: Overall Netflix bandwidth usage numbers on a network?

[Raymond Dijkxhoorn]

Hi!


I believe Akamai,
LLNW, & L3 are the only companies that stream movies for Netflix.  Peer with
the CDNs to save your transit.



That would be good if more than one of those CDNs peered openly.


So what one doesnt?

Akamai will peer with you anywhere and i doubt LLNW will give you trouble.

L3, well, they run a superb network and even more superb pricing, so why 
would they peer with anyone ;)


I still think, old fashioned me, that a CDN doesnt do go without peering 
but some feel otherwise.


Bye,
Raymond.

Re: IPv6 resolvers

[Raymond Dijkxhoorn]

Hi!


But I was wondering if a more permanent solution for these resolvers exist.

74.82.42.42  2373 msec
2001:470:20::2   2592 msec

The google DNS server I'm using is doing swimmingly so far, OpenDNS seems ok 
too.
2001:4860:4860::8844 16 msec


[root@ipv6proxy ~]# ping 74.82.42.42
PING 74.82.42.42 (74.82.42.42) 56(84) bytes of data.
64 bytes from 74.82.42.42: icmp_seq=1 ttl=61 time=0.664 ms
64 bytes from 74.82.42.42: icmp_seq=2 ttl=61 time=0.640 ms
64 bytes from 74.82.42.42: icmp_seq=3 ttl=61 time=0.551 ms
64 bytes from 74.82.42.42: icmp_seq=4 ttl=61 time=0.614 ms

[root@ipv6proxy ~]# ping6 2001:470:20::2
PING 2001:470:20::2(2001:470:20::2) 56 data bytes
64 bytes from 2001:470:20::2: icmp_seq=1 ttl=61 time=0.488 ms
64 bytes from 2001:470:20::2: icmp_seq=2 ttl=61 time=0.478 ms
64 bytes from 2001:470:20::2: icmp_seq=3 ttl=61 time=0.739 ms
64 bytes from 2001:470:20::2: icmp_seq=4 ttl=61 time=0.515 ms

Looks pretty normal here.

Bye,
Raymond.

Re: IPv6 resolvers

[Raymond Dijkxhoorn]

Hi!


So please stop responding with ping response times already :-)

No, pfSense does not set these per default, they are in wide use 
because these are part of the Google DNS whitelist for V6 records.


And a similar mistake I see others respond too as well, this is another 
domain with just a IPv4 record. That was not really what I was 
complaining about but I was not specific enough in my email


When requesting the DNS for the hostname with a Quad A the story is 
entirely different!


Try www.pfsense.com or www.didi.nl


Tried those three for you and prolocation.net. All fine? This should not 
be on nanog i guess. Check with their support, or something :-)


[root@ipv6proxy ~]# time host www.prolocation.net 2001:470:20::2
Using domain server:
Name: 2001:470:20::2
Address: 2001:470:20::2#53
Aliases:

www.prolocation.net has address 94.228.129.19
www.prolocation.net has IPv6 address 2a00:d00:ff:131:94:228:131:131

real0m0.011s
user0m0.001s
sys 0m0.008s
[root@ipv6proxy ~]#

[root@ipv6proxy ~]# time host pfsense.com 2001:470:20::2
Using domain server:
Name: 2001:470:20::2
Address: 2001:470:20::2#53
Aliases:

pfsense.com is an alias for pfsense.org.
pfsense.org has address 69.64.6.21
pfsense.org has IPv6 address 2605:8000:d:1::167
pfsense.org mail is handled by 10 mail.pfsense.org.

real0m0.011s
user0m0.001s
sys 0m0.007s

[root@ipv6proxy ~]# time host www.didi.nl 2001:470:20::2
Using domain server:
Name: 2001:470:20::2
Address: 2001:470:20::2#53
Aliases:

www.didi.nl has address 82.94.161.132
www.didi.nl has IPv6 address 2001:888:2087:33::132

real0m0.523s
user0m0.001s
sys 0m0.006s

Bye,
Raymond.

Re: spammers trying to "lease" IP space?

[Raymond Dijkxhoorn]

Hi!

This was mailed to many ISP's the last days.

Bye,
Raymond.


I know this tactic isn't exactly new .. just thought I'd pass this along.

Text below is exact with exception of our ARIN information and ranges
(which any of you could figure out anyway).

Cheers,

Michael Holstein
Cleveland State University

--snip--

Description: ABC Widgets

*Greetings, NOC or IP Admin at (our ARIN NetName)*

**

We would like to Lease or even Purchase some of your IPv4 Ranges like
(our/16)

?Why do You want to lease our IPs??



Very Simply: Our Business is the delivery of Opted In Marketing Email. The key
to this business is good stewardship of IP assets to ensure deliverability, and
even more importantly; *Sustainability. *Many of our IP leases last years due to
our investment in our network before we ever even mail. As a result it takes
Several months before a subnet is profitable for us after recouping our initial
infrastructure expenses. So to Hit and Run simply does not make good business
sense, after all maybe if we are good to our word you will offer us additional 
IPs!

**

there are two core requirements in any Major League Mail Campaign ?



a. _Having a solid list_ with real recipients and records to prove their Sign up
is vital to delivery but also to settling any complaints registered with an ISP.

b. _Using Multiple IP addresses_. If having a good list is a good defense then
using Multiple Static IP addresses is a proactive measure. ISPs, Backbone
Carriers, Software Makers, and more all use (among other means) Algorithms to
shape traffic across their networks and to their clients. Using an MTA to spread
our traffic across thousands of IP addresses from then thousands of ?C-Blocks?
we mitigate the footprint of our traffic originating from any one network range.



?/It should be noted here that this email is a Request for Pricing (RFP) and its
recipients have in no way requested it, they have instead been identified
through research, and therefore this email should not be thought of as
characteristic of our normal mailings./



Precision Management of Texas (USA) offers on-demand solutions for brand
marketers and website promotion chiefly through email marketing. Currently PM is
seeking to expand its network capability both overseas and here in the US with
the addition of several points of presence (PoP) in geographically diverse
locations. Precision Management makes no attempt to conceal identity or
intentions as a show of good faith on our part that we will be good customers
with an eye on building a relationship beyond this installation. It should go
without saying that our use of your network will be totally AUP Compliant and
any complaints will be handled in 12 hours or less. We only mail to Top Level
Domain?s and do no General Internet mailing. Also i want you to be aware that we
are an American Company with verifiable references who can attest to how we
conduct our email business.

Description: C:\Users\BLEAUH~1\AppData\Local\Temp\~ed_sb_i\~files\3.gif

Description: Content Image InlinePM seeks to obtain as much diversity in the
allocated IP space as possible, however the most important thing is the Subnets
need to have no abuse history.

We can take the IPs via GRE or BGP or other such tunneling solution to where you
have them announced. Alternatively we can advertise them ourselves on our
network, saving you the back-haul. As a third solution we can take a server on
your network with the following specs



One Virtual (or Dedicated) Server ?



Dual Cores

1 GB RAM

100 GB HDD?

3 Mbps dedicated - burstable to 100

Term period minimum of 6-12 months



I hope you have read this far and will seriously consider this opportunity to
generate additional revenue for your company.

If this email has found you in error please fwd it to the right person and cc
me. Otherwise hit the un-sub at the bottom!



Thanks,


Edward Wootan
Chief Technical Officer
Precision Management LLC 
3030 LBJ Freeway
Dallas, TX 75234
If you are interested in working with a *Legitimate Marketer *
please reply to this email or call me Direct at *(704)286-6098* anytime.

The information contained within the referenced, linked, or directed email
communication is intended to be a confidential communication between the
original sender and recipient, and is to be treated as confidential. All works,
ideas, or copy within are copyrighted by precision management llc., and are not
to be used in any manner other by which they were intended by precision
management llc... If you believe you have received this or any other email in
error, please contact c...@precision-management.info

Re: Our first inbound email via IPv6 (was spam!)

[Raymond Dijkxhoorn]

Jason,


In preparation for the World IPv6 Launch, inbound (SMTP) email to the
comcast.net domain was IPv6-enabled today, June 5, 2012, at 9:34 UTC.
Roughly one minute later, at 9:35:30 UTC we received our first
inbound email over IPv6 from 2001:4ba0:fff4:1c::2. That first bit of mail
was spam, and was caught by our Cloudmark messaging anti-abuse platform
(the sender attempted a range of standard spam tactics in subsequent
connections).


You specificly tell 'inbound' ... by that you mean the MX record was 
added. But just to be sure. Comcast is also sending out over IPv6 now 
right? And if so, what protocol is preferred by default? Outgoing mail 
over IPv4 or over IPv6?



Since the Internet is of course more than just the web, we encourage
others to start making non-HTTP services available via IPv6 as well.


Watching logs here to see if things (at least mail for me now) will raise 
the next few days...


Bye,
Raymond.

Re: Our first inbound email via IPv6 (was spam!)

[Raymond Dijkxhoorn]

Hi!


In preparation for the World IPv6 Launch, inbound (SMTP) email to the
comcast.net domain was IPv6-enabled today, June 5, 2012, at 9:34 UTC.
Roughly one minute later, at 9:35:30 UTC we received our first
inbound email over IPv6 from 2001:4ba0:fff4:1c::2. That first bit of mail
was spam, and was caught by our Cloudmark messaging anti-abuse platform
(the sender attempted a range of standard spam tactics in subsequent
connections).

In the past several hours we have of course seen other messages from a
range of hosts, many of which were legitimate email ­ so it wasn't just
spam! ;-)

Since the Internet is of course more than just the web, we encourage
others to start making non-HTTP services available via IPv6 as well.


Looking more closely... Is this still work in progress?

;; ANSWER SECTION:
comcast.net.358 IN  MX  5 mx3.comcast.net.
comcast.net.358 IN  MX  10 mx1.comcast.net.
comcast.net.358 IN  MX  5 mx2.comcast.net.

;; ADDITIONAL SECTION:
mx2.comcast.net.6958IN  A   76.96.30.116
mx3.comcast.net.358 IN  A   68.87.26.147
mx1.comcast.net.358 IN  2001:558:fe14:70::22

You are now only accepting IPv6 if all IPv4 fails?
Or will  records for mx2 and mx3 added later?

Bye,
Raymond.

Re: Our first inbound email via IPv6 (was spam!)

[Raymond Dijkxhoorn]

Hi! Seth,


In the past several hours we have of course seen other messages from a
range of hosts, many of which were legitimate email ­ so it wasn't just
spam! ;-)

Since the Internet is of course more than just the web, we encourage
others to start making non-HTTP services available via IPv6 as well.


I always wondered why (ISPs) never started with rolling out IPv6 email 
servers first, the fallback from 6 to 4 is transparent and invisible to the 
end user at a delay of a maximum of 30 seconds.


I enabled v6 for my email before my website since the impact if it didn't 
work on the 1st try was almost nil.


Still waiting for the 1st Country to top Romania' 6% deployment. I'm sure we 
can do better then 0.21.


IMHO Asking users if they want IPv6 is the wrong way round, you enable IPv6 
and then allow for opt-out in the service portal.


That's basically what the Romanian ISP did. They have not gone bankrupt 
either, so maybe it's not all as bad as we think.


I think its pretty simple. Many do this, but protection is little. Abuse 
also but that may change. To get to the point. There are no widely 
available IPv6 blacklists. Like you are used to have on IPv4. Might be a 
legitimate reason ...


Lets see how Comcast does.

Bye,
Raymond.

Re: F-ckin Leap Seconds, how do they work?

[Raymond Dijkxhoorn]

Hi!


Drive Slow
Paul


Not very well if you have a modern box (RHES/CentOS 6) and Java apps running 
on them.  RHES/CentOS 5 merrily ignored it.  Worse, just bouncing the Java 
stack didn't fix it, it required the box to be rebooted.  A sizeable number 
of annoyed sysadmins tweeting about it this afternoon.


Anything with java running seems hit.
We just finished up a firm round of reboots... :(

Recent Ubuntu boxes and RHES 6... all the same ...

Bye,
Raymond.

Re: DNS caches that support partitioning ?

[Raymond Dijkxhoorn]

Hi!


The cache needs to be big enough that it has a thrashy bit that is
getting changed all the time.  Those are the records that go into the
cache and then die without being queried again.  If the problem is
that there's some other record in there that might be queried again,
but that doesn't get queried often enough to keep it alive, then the
additional cost of the recursive lookup is just not that big a deal.



A big part of the problem is that TTLs reflect the server's estimate
of how long it might be until the data changes, but not the client's
likelihood of reusing the data.  I publish a BL of hosts in Korea.
The data changes maybe once a month so from my point of view a large
TTL would make sense, but most of the hits are for bots spraying spam
at random, so the client's not likely to reuse the data even if it
sticks around for many hours.

A plausible alternative to a partitioned cache might be TTL capping,
some way to say to your cache that no matter what the TTL is on
data from a range of names, don't keep it for more than a few seconds.

Another thing that would be useful to me for figuring out the BL cache
stuff would be traces of incoming IP addresses and timestamps for mail
servers larger than my tiny system, so I could try out some cache models.


About any caching nameserver supports forwarding. So if you REALLY are 
afraid this will bite you. Fire up another instance. Forward all the 
reverse DNS to that and you are set. That other instance will handle your 
reverse DNS with a cache that you will specify. The other ones are not 
impacted at all. When you use forwarding it doesnt cache the entry. 
('forward only' option in bind for example).


So:

Caching resolver -> Caching resolver dedicated for reverse DNS.

Your first resolver does not cache reverse DNS and you are safe there. On 
the second you do the reverse DNS.


I talked with Paul Vixie about doing this internal inside bind but that 
was not something they would be delighted to do (at least not now). If you 
could define how large your cache pool was for certain objects that would 
fix it also.


Reverse DNS isnt the only issue here. There are many sites that give each 
user a subdomain. And if i look at my top talkers on some busy resolvers i 
do see that thats doing about 25-30% of the lookups currently.


akamai.net, amazonaws.com and so on. All make nice use of DNS for this.
Those have litterly millions of entry's in DNS also. And thats what 
currently is doing the load on resolvers...


Oh and dont forget DNSSEC. Traffic went up allready by a factor 7 due to 
that. Those objects are also much larger to store.


Bye,
Raymond.

Re: Facebook invisible in Italy

[Raymond Dijkxhoorn]

Hai Marco,

Same in NL so most likely bigger then Italy alone. 

Thanks,
Raymond Dijkxhoorn, Prolocation

> Op 28 sep. 2015 om 22:35 heeft Marco Paesani  het volgende 
> geschreven:
> 
> Hi,
> some issues from FB network ??
> Do you have some info ?
> Regards,
> 
> -- 
> 
> Marco Paesani
> MPAE Srl
> 
> Skype: mpaesani
> Mobile: +39 348 6019349
> Success depends on the right choice !
> Email: ma...@paesani.it

Re: finding whois servers, was .pro whois registry down?

[Raymond Dijkxhoorn]

Hai!


whois.conf-compatible format



What uses whois.conf?   Not the whois on my FreeBSD or Mac.

Or you can just use this shell script:

#!/bin/bash
WHOISHOST=${1##*.}.ws.sp.am
exec whois -h $WHOISHOST $*


I just a slightly different one but still my fav one... jwhois

Has a whois.conf style list.

Bye,
Raymond.

Re: Huge Level 3 ipv4 issues?

[Raymond Dijkxhoorn]

Hai David,

> Op 12 jun. 2015 om 10:51 heeft David Hubbard  
> het volgende geschreven:
> 
> Experiencing packetloss all over the place (chicago, tampa, atlanta) on
> Level 3's network; can't even reach them from Brighthouse residential.
> IPv6 seems to still be working fine, but of course Brighthouse doesn't
> offer that lol.
> 
> Anyone seeing the same?
> 
> David

Yes. See also another thread here:

http://mailman.nanog.org/pipermail/nanog/2015-June/076189.html

Thanks,
Raymond Dijkxhoorn - Prolication

Re: AS4788 Telecom Malaysia major route leak?

[Raymond Dijkxhoorn]

Hai!

Wouw! This is what they came up with?! 

Hopefully Level3 will take appropriate measures. Its amazing. Really. 

'Some internationally routes' 

Have they any idea what they did at all?

Its amazing that with parties like that the internet still works as is  ... 

Thanks,
Raymond Dijkxhoorn

> Op 14 jun. 2015 om 20:27 heeft Job Snijders  het volgende 
> geschreven:
> 
>> On Fri, Jun 12, 2015 at 08:25:40PM +, Jürgen Jaritsch wrote:
>> This is the official [level3] feedback:
>> 
>> [ ... ]
> 
> For completeness sake: here is what Telekom Malaysia published about the
> issue:
> 
>Telekom Malaysia Berhad (TM) wishes to update on the service related
>issue detected yesterday, 12 June 2015 affecting a number of our
>Internet services customers that caused a deterioration in
>connection performance.
> 
>We identified the root cause and our network team immediately took
>steps to optimise traffic flows, while we worked to restore
>connectivity to its expected level of performance. The services were
>restored at 6.30pm on the same day.
> 
>We would like to clarify that during a network reconfiguration
>exercise, we had unintentionally updated traffic routing information
>which caused congestion and packet loss to our international
>connectivity. This had affected the internet traffic flow for some
>of our customers and some international traffic routes.
> 
>We apologise for any inconvenience caused by the service disruption
>and would like to assure customers that we are undertaking all the
>necessary measures to ensure customers continue to experience
>uninterrupted services.
> 
>Meanwhile, customers who have any enquiry or require further
>assistance can email us at h...@tm.com.my or tweet to us via
>@tmconnects on Twitter.
> 
>source: 
> https://www.tm.com.my/OnlineHelp/Announcement/Pages/INTERNET-SERVICES-DISRUPTION-12-June-2015.aspx
> 
> Kind regards,
> 
> Job

Re: AS4788 Telecom Malaysia major route leak?

[Raymond Dijkxhoorn]

Hai!

Mark, mistakes and oopses happen. No problem at all. I understand that 
completely. There is human faillure and this happenes. 

A simple 'sorry' would have done. Yet their whole message tells 'they did ok' 
In my very limited view they did NOT ok. Did i misread?

I am also very much looking how level3 is going to prevent things like this. 
But out of own experience they will not. We have seen before that they 
implemented filtering based on customer lists. But not a per customer filter. 
They did this globally. So any l3 customer can announce routes of another l3 
customer. While this can be changed this outage tells there is certainly room 
for improvements. 

I hope people will learn from what happened and implement proper filtering. 
Thats even more important then a message from a operator that didnt even 
understand fully what they caused to the internet globally. 

Thanks,
Raymond Dijkxhoorn

> Op 14 jun. 2015 om 23:04 heeft Mark Tinka  het volgende 
> geschreven:
> 
> 
> 
>> On 14/Jun/15 22:55, Raymond Dijkxhoorn wrote:
>> Hai!
>> 
>> Wouw! This is what they came up with?! 
>> 
>> Hopefully Level3 will take appropriate measures. Its amazing. Really. 
>> 
>> 'Some internationally routes' 
>> 
>> Have they any idea what they did at all?
>> 
>> Its amazing that with parties like that the internet still works as is  
>> ...
> 
> I wouldn't be as hard. Stuff happens - and as they said, during a
> maintenance activity, they boo-boo'ed.
> 
> Are Level(3) going to own up and say they should have had filters in
> place? I certainly hope they do.
> 
> But more importantly, are Level(3) going to implement the filters
> against TM's circuit? Are they going to run around the network looking
> for any additional customer circuits that need plugging? That's my
> concern...
> 
> Mark.

Re: AS4788 Telecom Malaysia major route leak?

[Raymond Dijkxhoorn]

Hello Mel,

Must just be me then. 

I was most likely expecting a more in depth report. Strange things happened. 
Perhaps they could post a 'what exactly happened' since this wasnt a average 
route leak. 

Thanks,
Raymond Dijkxhoorn

> Op 14 jun. 2015 om 23:27 heeft Mel Beckman  het volgende 
> geschreven:
> 
> Raymond,
> 
> They provided a "simple sorry":
> 
>"We apologise for any inconvenience caused by the service disruption."
> 
> It doesn't get much more simple than that.
> 
> -mel beckman
> 
>> On Jun 14, 2015, at 2:21 PM, Raymond Dijkxhoorn  
>> wrote:
>> 
>> Hai!
>> 
>> Mark, mistakes and oopses happen. No problem at all. I understand that 
>> completely. There is human faillure and this happenes. 
>> 
>> A simple 'sorry' would have done. Yet their whole message tells 'they did 
>> ok' In my very limited view they did NOT ok. Did i misread?
>> 
>> I am also very much looking how level3 is going to prevent things like this. 
>> But out of own experience they will not. We have seen before that they 
>> implemented filtering based on customer lists. But not a per customer 
>> filter. They did this globally. So any l3 customer can announce routes of 
>> another l3 customer. While this can be changed this outage tells there is 
>> certainly room for improvements. 
>> 
>> I hope people will learn from what happened and implement proper filtering. 
>> Thats even more important then a message from a operator that didnt even 
>> understand fully what they caused to the internet globally. 
>> 
>> Thanks,
>> Raymond Dijkxhoorn
>> 
>>> Op 14 jun. 2015 om 23:04 heeft Mark Tinka  het 
>>> volgende geschreven:
>>> 
>>> 
>>> 
>>>> On 14/Jun/15 22:55, Raymond Dijkxhoorn wrote:
>>>> Hai!
>>>> 
>>>> Wouw! This is what they came up with?! 
>>>> 
>>>> Hopefully Level3 will take appropriate measures. Its amazing. Really. 
>>>> 
>>>> 'Some internationally routes' 
>>>> 
>>>> Have they any idea what they did at all?
>>>> 
>>>> Its amazing that with parties like that the internet still works as is 
>>>>  ...
>>> 
>>> I wouldn't be as hard. Stuff happens - and as they said, during a
>>> maintenance activity, they boo-boo'ed.
>>> 
>>> Are Level(3) going to own up and say they should have had filters in
>>> place? I certainly hope they do.
>>> 
>>> But more importantly, are Level(3) going to implement the filters
>>> against TM's circuit? Are they going to run around the network looking
>>> for any additional customer circuits that need plugging? That's my
>>> concern...
>>> 
>>> Mark.

Re: /25's prefixes announced into global routing table?

[Raymond Dijkxhoorn]

Hai!

Extreme supports route compression since several years. I hope other vendors 
will also start doing this. 

Thanks,
Raymond Dijkxhoorn, Prolocation

Op 22 jun. 2013 om 15:11 heeft Daniel Suchy  het volgende 
geschreven:

> On 06/22/2013 12:27 AM, Jakob Heitz wrote:
>>> Date: Fri, 21 Jun 2013 16:14:07 -0400
>>> From: "Majdi S. Abbas" 
>>>The forwarding hardware is generally going to be the limit, and
>>> that's going to be painful enough as we approach a half million
>>> prefixes.
>> 
>> There are techniques to fix that. For example, Simple Virtual Aggregation
>> http://tools.ietf.org/html/rfc6769
> 
> I'm not sure, if hardware vendors will implement something like this. I
> expect they'll sell you router with larger hardware FIB instead.
> 
> - Daniel

Re: BGP hijack from 23724 -> 4134 China?

[Raymond Dijkxhoorn]

Hi!


We just got Cyclops alerts showing several of our prefixes sourced from
AS23474 propagating through AS4134.  Anyone else?

aut-num:  AS23724
as-name:  CHINANET-IDC-BJ-AP
descr:IDC, China Telecommunications Corporation
country:  CN

aut-num:  AS4134
as-name:  CHINANET-BACKBONE
descr:No.31,Jin-rong Street
descr:Beijing
descr:100032
country:  CN


More alerts from :

88.159.0.0/16 being advertised with aspath 286 4134 23724 23724.

route:  88.159.0.0/16
descr:  Edutel Network
origin: AS39309
mnt-by: MNT-EDUTEL
source: RIPE # Filtered

Cant someone properlyu filter the crap inside Chinanet? This is silly.

Bye,
Raymond.

Re: Emulating ADSL bandwidth shaping

[Raymond Dijkxhoorn]

Hi!


- do ISPs typically use token bucket filters with large bursts to shape traffic?
- what kind of burst sizes and latencies/limits are typically used for
the filter?



You will definitely have to account for latency.

For emulating cable traffic, latencies (in the USA) will be about
60-80ms to typical sites.  Burst mode in my experience occurs only for
about the first 15 seconds, then is throttled back (though not always;
seems to depend on time of day).

For DSL, I seem to recall latency being about 90-110ms (note, I haven't
used DSL in many years).  Burst mode was generally not noticeable or
available, that is, you got the same speed regardless of downloading a
1MB jpeg or a 640MB .iso  file.


The latency i have here on my DSL is ~ 16-22 ms. So its much lower, factor 
4...


Bye,
Raymond.

Re: Emulating ADSL bandwidth shaping

[Raymond Dijkxhoorn]

Hi!


Either you're looking only at the loop contribution, or you're in the
SF bay area and nearly every "typical site" is available locally.
Here in the relatively backwater Seattle suburbs, unless it's served
by Microsoft or a content distribution network, there are substantial
latencies to typical sites.

To make it concrete I used Windows ICMP tracert against a few sites
from both cable and DSL in the Seattle suburbs.  First from a
consumer-grade cable offering:

http://pastebin.com/TGc6xsHk

Then from a business-class telco DSL (complete with more than 1 static
IP, someone tie me down lest my soul escape my body from sheer joy!):


I am in the Netherlands, and its pretty common there to have low latency 
on DSL ;)


Bye,
Raymond.

Re: Google wants your Internet to be faster

[Raymond Dijkxhoorn]

Hi!


Cringely has a theory and it involves Google and Verizon,
but it doesn't involve net neutrality:

 http://www.nytimes.com/2010/08/08/opinion/08cringeley.html?_r=2


Woow this is fantactic news. Oh wait. Didnt Akamai invent this years ago?

Bye,
Raymond.

Re: net-neutrality

[Raymond Dijkxhoorn]

Hi!

btw, considering that you appearantly run a larger network than the 3 
networks we own and operate, willing to sell? :P


That would be rarther funny Sven, you buying IBM. Sweet dreams.

Bye,
Raymond.

Re: Did your BGP crash today?

[Raymond Dijkxhoorn]

Hi!


I think you blame the wrong people. The vendor should make sure that
their implementation does not violate the very basics of the BGP
protocol.



The curious thing here is that the peer that resets the session, as
required by the spec, causes the actual damage (the session reset),
and not the peer producing the wrong update.

This whole thread is quite schizophrenic because the consensus appears
to be that (a) a *researcher is not to blame* for sending out a BGP
message which eventually leads to session resets, and (b) an
*implementor is to blame* for sending out a BGP messages which
eventually leads to session resets.  You really can't have it both
ways.

I'm fed up with this situation, and we will fix it this time.  My take
is that if you reset the session, you're part of the problem, and
consequently deserve part of the blame.  So if you receive a
properly-framed BGP update message you cannot parse, you should just
log it, but not take down the session.


Not sure if the link was posted allready ...

http://www.cisco.com/en/US/products/products_security_advisory09186a0080b4411f.shtml

'The vulnerability manifests itself when a BGP peer announces a prefix 
with a specific, valid but unrecognized transitive attribute. On receipt 
of this prefix, the Cisco IOS XR device will corrupt the attribute before 
sending it to the neighboring devices. Neighboring devices that receive 
this corrupted update may reset the BGP peering session.'


Bye,
Raymond.

Re: Did your BGP crash today?

[Raymond Dijkxhoorn]

Hi!


Cisco posts their advisories to the NANOG list.



'The vulnerability manifests itself when a BGP peer announces a prefix
with a specific, valid but unrecognized transitive attribute. On
receipt of this prefix, the Cisco IOS XR device will corrupt the
attribute before sending it to the neighboring devices. Neighboring
devices that receive this corrupted update may reset the BGP peering
session.'



I'm not sure what you intend to say by quoting this part of the
advisory.  If you think that it's an IOS XR bug which only needs
fixing in IOS XR, you're showing the very attitude which has stopped
us from making the network more resilient to these types of events.


Its more a workaround then a bugfix ...

Dont try to write down what I might think. I am perfectly capable of 
explaining this myselve. The narrow minded response you just did tells 
more about you then about me. So far for the rant.


I think i am around long enough that you would not even consider thinking 
that i would say 'hey this is a IOS XR BUG. Its not.' I didnt say this at 
all. Did I?


If it affects a large part of traffic on the internet and it obviously 
did. It took down a couple of the larger networks.


http://www.ams-ix.net/cgi-bin/stats/16all?log=totalall;png=daily

You can clearly see the drop there also.

I think a 'fix' 'bugfix' 'workaround' whatever you want to call it, 
i still think its good they released it and fast. A more structural 
approach is nice but wont help a lot of networks right now.


I am sorry i tried to add something to the thread. Think about this 
Florian. We are not the bad guys.


Bye,
Raymond.

Re: Local Peering and Transit - BGP multihoming

[Raymond Dijkxhoorn]

Hi!


Yes, i can get sample of configuration via Google search.
but i am looking for best practices and from experience people.


Then post your suggested config and ask for comments.

Bye,
Raymond.

Re: Local Peering and Transit - BGP multihoming

[Raymond Dijkxhoorn]

Hi!


Yes, i can get sample of configuration via Google search.
but i am looking for best practices and from experience people.



Then post your suggested config and ask for comments.



...on a suitable list, dedicated to Cisco gear..


Sorry, yes. :-) Plenty of Cisco lists there to answer 'questions' :-)

Bye,
Raymond.

Re: Cogent input

[Raymond Dijkxhoorn]

Hi!


Should have said "And, they have no plans to deploy IPv6 in the immediate
future."

:)



"Cogent's official stance on IPv6 is that we will deploy IPv6 when it
becomes a commercial necessity. We have tested IPv6 and we have our plan
for rolling it out, but there are no commercial drivers to spend money
to upgrade a network to IPv6 for no real return on investment."


Thats strange they are running pilots with customers on v6 in 
Amsterdam.


Bye,
Raymond.

Re: Cogent input

[Raymond Dijkxhoorn]

Hi!


"Cogent's official stance on IPv6 is that we will deploy IPv6 when it
becomes a commercial necessity. We have tested IPv6 and we have our
plan
for rolling it out, but there are no commercial drivers to spend money
to upgrade a network to IPv6 for no real return on investment."



Thats strange they are running pilots with customers on v6 in Amsterdam.



Not really so strange.  ISPs often pilot features (v6, multicast, etc)
that they have no immediate intention of deploying, so that they have
experience if and when it becomes profitable/sensible to deploy them.


Not from what i have been told, but hey i am not working there. We got a 
v6 transit offer as pilot from them so perhaps they are moving towards 
live service  Would not be strange in this current stage...


Bye,
Raymond.

RE: spamhaus drop list

[Raymond Dijkxhoorn]

Hi!


Both containing prefixes that should not be announced on the internet,
but often used by spammers trying to deliver their content.


When did you experience this last time, this is not what we see on 
various antispam projects.


So if you have new information, please share, we didnt see bogons used a 
lot at least the last 12 months.


Drop list is a completely different thing, and effective, but also 
effective to loos legitimate mails, the blocks inside there are too wide. 
I would not recommend people putting that inside iptables or something ;)


Bogon filtering is something that should be considered common practice. So 
your borders or upstreams should take care of that ;)


Bye,
Raymond.

Re: Dutch ISPs to collaborate and take responsibility for bottedclients

[Raymond Dijkxhoorn]

Hi!


Sounds great but who cover the costs?



 If done right, such a treaty here in the US and elsewhere thing would be a
 major win for the Internet.


The ISP's will pick up the costs. A cleaner customer base is also a win 
for them.


First implementations wont be next week however but the start is beeing 
made.


Bye,
Raymond.

Re: Dutch ISPs to collaborate and take responsibility for botted clients

[Raymond Dijkxhoorn]

Hi!

A major reason ISPs are hesitant to take deliberate measures against such 
systems is that they are afraid that disconnecting users and making them 
spend time and money cleaning up their systems will only drive them into the 
hands of competitors. And the support process itself is expensive, probably 
wiping out the profit from that user. But with such high coverage of the 
market users may not have permissive alternatives.


This will be an interesting phenomenon to watch. If it is successful perhaps 
it could work here too."

---

I couldn't find the story in English in a version that did not link to my 
original post, I waited a few days to see if anyone else picks it up, as I 
don't want yet another self-promotion fight. No one I found in under 2 
minutes on Google did, so this second-hand link should do.


http://blogs.pcmag.com/securitywatch/2009/09/dutch_isps_sign_anti-botnet_tr.php


This is rather old news btw, the convernant was signed < 14 Aug.

The ISP's that signed are :

Alice, Het Net, InterNLnet, KPN, Luna NL, Concepts ICT, Online, Solcon, 
Tele2, Telfort, UPC, Xenosite, XS4ALL en Ziggo


This is certainly not 98% of the NL marked as they claim. But who cares 
its a nice initiative.


Bye,
Raymond.

Re: Cisco interface - GB of transfer software

[Raymond Dijkxhoorn]

Hi!

I like to use ntop (from ntop.org) for this, along with MRTG. Others prefer 
cacti. I found MRTG easier to setup. It comes down to personal preference.


MRTG provides graphs of usage, but I'm not aware of it providing a monthly 
total usage (or 95% or other) in report form (though would be happy to learn 
otherwise).


Does ntop provide a way to generate a monthly report?


Check RTG.

http://rtg.sourceforge.net/

Bye,
Raymond.

Re: peeringdb admin contact?

[Raymond Dijkxhoorn]

Hi!

Been trying to get someone from [EMAIL PROTECTED] to get back to me but haven't 
had any luck.  Anyone?


If you have someone responding. we have created accounts there for a 
couple of our customers, but still are read only level. Not really handu 
if you ask people on peeringforum.eu to join and not handle their request 
accordingly.


Bye,
Raymond.

Re: Potential Prefix Hijack

[Raymond Dijkxhoorn]

Hi!

That's not true, as not all our prefixes were hijacked nor leaked, 
since they were originating them.  If they were leaking them you might 
be able to see further AS's on the AS-PATH, incluiding the legitimate 
AS for originating those prefixes.


We have seen issues like this also when a customer was leaking full 
routes, and his router ws not able to coop with the BGP tables. This gave 
really really strange things, simmilar like here, some prefixes were 
there and some not. Completely random.


Am i seeing things in a blur way ?  or this is supposed to happen as 
wind flows ?


Upstreams should filter things properly. Thats a sure thing. OR max prefix 
limit customers like that


Bye,
Raymond.

Re: Potential Prefix Hijack

[Raymond Dijkxhoorn]

Hi!


94.46.0.0/16
194.88.142.0/23
194.11.23.0/24
82.102.0.0/18
195.246.238.0/23
194.107.127.0/24
81.92.192.0/19
193.227.238.0/23




We are trying to contact them in order to get some feedback, and some good 
explanation for this.



The obviously were leaking full routing, are we all gonna annnounce 'my
prefix was in there also?'



ACTUALLY They didn't hijack ALL my netblocks... I have 3. 
One was completely
untouched, 1 was only hijacked by 1 site, and the last was hijacked by 2 
different sites. :)


So their router had most likely a hard time and stuff was flapping, i see 
something like that in the BGPLay output also.


Bye,
Raymond.

Re: Potential Prefix Hijack

[Raymond Dijkxhoorn]

Hi!


We were hijacked aswell, by 27664 16735

Our affected prefixes were:

94.46.0.0/16
194.88.142.0/23
194.11.23.0/24
82.102.0.0/18
195.246.238.0/23
194.107.127.0/24
81.92.192.0/19
193.227.238.0/23

We are trying to contact them in order to get some feedback, and some good 
explanation for this.


The obviously were leaking full routing, are we all gonna annnounce 'my 
prefix was in there also?'


Bye,
Raymond.

Re: IPv6 Confusion

[Raymond Dijkxhoorn]

Hi!


networks with visitors have shown a serious problem with rouge RAs



Does that get better with RAs from the good routers turned off?

Aria Stewart
aredri...@nbtsc.org


Is there something like RA filtering on switches yet, so end users can be 
filtered? Just like the dhcp stuff thats available on most switches 
nowdays... ?


Its as annoying as fake DHCP servers...

Bye,
Raymond.

Re: BGP more specific prefixes

[Raymond Dijkxhoorn]

Hi!


Some days ago, a BGP issue was announced about "IP hijacking".
OK, we understand that this is some "new" because the traffic is also sent
back to the "real owner" of the block.


Traffic will walk the shotest path, so you can never tell its the 'real' 
owner that will receive this traffic.



What kind of security can we have (and all internet providers) about that
there is nobody announcing a subset of their prefix or a subset of their
customer prefixes (i.e. x.y.0.0/24) disturbing the "normal" traffic flow?
Of course, we know about prefix monitoring tools (from RIPE and others)
but... it is the best solution?

Or simply anyone can announce the /24 prefix that he want "capturing" that
/24 prefix (of course if the "normal" prefix is smaller than that (i.e.
/16))?
In other words... can anybody "capture" the /24 prefix that he want?


If i start announing your /24, and my upstreams dont do proper filtering, 
i steal your prefix, easy as that. As little this may be, my most direct 
peerings will accept the routes and off you go.


And prefix filtering is within some providers not even per customer, we 
personally had for example issues with a big carrier, somethhing with a 3 
inside their name, who only had a large prefix filter with *ALL* their 
customers, so if another customer of that same 3 would announce our 
prefixes, it would be ok for them, and that happened. So we were 
blackholed, since that other customer had many peerings with '3' on 
various locations.


So even with 'some' filtering in place bad things can and will happen.


The question is very simply, It is very very difficult for me to believe
that anybody can "shutdown" the /24 network that he wants in the world.
I am right?


No? Its dead simple in fact. Totally shut down, no, since you most likely 
have direct peers who have a shorter path.



Or may be that simply internet works like this and the providers are very
careful about what accepts from their customers and what announces to other
providers?


Ghe ... you think route leaking and stealing dont happen on a daily base? 
Go look and see where a major part of your spam is comming from, yes, 
stolen prefixes.



In other words... There is anybody in internet that can be sure that their
traffic (traffic destined to their prefix)  is not going to be "stoled"?
If yes... how?

Keep in mind that announcing the same prefixes than the attacker will not
solve totally the problem because it is only a partial solution.

If announcing a more specific /24 network is so easy... why does this not
happen every day (for example for shutting down competitors sites)?


It does happen daily, wake up!

Bye,
Raymond.

Re: YAY! Re: Atrivo/Intercage: NO Upstream depeer

[Raymond Dijkxhoorn]

Hi!


Thanks to the efforts of the people on this list, you've known
Estdomains/Esthost was bad news for several weeks or more.


[EMAIL PROTECTED] ~]# dig estdomains.com

; <<>> DiG 9.5.0-P2 <<>> estdomains.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2970
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0

;; QUESTION SECTION:
;estdomains.com.IN  A

;; ANSWER SECTION:
estdomains.com. 86400   IN  A   94.102.49.3

inetnum:94.102.48.0 - 94.102.63.255
netname:NL-ECATEL-20080829
descr:  Ecatel LTD
country:NL
org:ORG-EL38-RIPE
admin-c:RvE16-RIPE
tech-c: RvE16-RIPE
status: ALLOCATED PA
mnt-by: RIPE-NCC-HM-MNT
mnt-lower:  ECATEL-MNT
mnt-routes: ECATEL-MNT
source: RIPE # Filtered

person: Reinier van Eeden
address:Archangelkade 1-3
address:1013 BE  Amsterdam
mnt-by: IQARUS-MNT
e-mail: [EMAIL PROTECTED]
phone:  +31 64 607 11 12
nic-hdl:RvE16-RIPE
source: RIPE # Filtered

The same guys were hosting several ROKSO spammers in 2006 allready. This 
smells badly!


Earlier this year they had also this one (also ROKSO)

http://www.spamhaus.org/sbl/sbl.lasso?query=SBL65783

The company that Reinier was with was called Icarus earlier, does that 
ring a bell? 3 of the top 10 ROKSO spammers were hosted there. This is 
more then just a normal shining.


bye,
Raymond.

RE: DNS query analyzer

[Raymond Dijkxhoorn]

Hi!


Anyone know of a tool that can take a pcap file from wireshark that was
used to collect dns queries and then spit out statistics about the
queries such as RTT and timeouts?



It just so happens there is a tool aptly named DNS Analyzer by NLnet Labs.
I used it a while back but if I recall you could feed it a pcap and it could
spit out all kinds of useful statistical data.

I don't think it's being actively maintained at the moment but you should be
able to find it on the NLnet Labs site -
http://www.nlnetlabs.nl/projects/dns-analyzer/


I very recently asked the maintainers of that package if its still under 
development but i heard if was unfortunately dropped.


Bye,
Raymond.

Re: Arrogant RBL list maintainers

[Raymond Dijkxhoorn]

Hi!


RBLs are neither authorised (EU privacy laws anyone?), nor the appointed
authority to keep databases on "whats static or not". RIRs -are-, if
anyone should maintain a database on such things, i'd be the rirs
(which they have, it's called "whois", it just lacks a field that
indicates the type of assignment method used.


Who cares!?

This is something between the ISP using them and YOU. If people want to 
make use of ANY datasource thats their own thing. They are not forced to 
use it at all.


There is no EU law or anything involved here.

There are blacklists that block .CN, so what, up to you to use it it not.

Same with iptables, you can also filter anything you like there, 
yourselve. No EU law telling anything about that.


Stick to the point, solve your issue with the party receiving your mails.
they dediced to use the list, and most likely were not forced to do so.

If you want to mail with them, fix your reverses. If not, no problem 
either. But stop whining :)


Byem,
Raymond.

Re: Arrogant RBL list maintainers

[Raymond Dijkxhoorn]

Hi!


thing is that it's illegal to maintain a database with "personal details"
which ip addresses according to various german courts are (don't ask..
mmk? ;) ofcourse we all know ip addresses identify nodes on a network, not
persons, but the germans seem to mainain a different view on this,
despite us isps being the owners of the internet and not the german
government ;).

therefore we are not even -allowed- to cooperate with trend micro *grin*

sometimes laws really come in handy you know ;)


I am not a german neither do i live there. This is nanog, not denog ;)

Ok and how many german blacklists are in use? There are reasons most of 
the blacklists are not based there. Its a silly story and you should 
focus on the ISP using the list and not some legal thing. Thats 
irrelevant here.


Technically i dont see any new points and stick to the old story.

Contact that ISP and negotiate with them.
Good luck.

bye,
Raymond.

Re: Are the Servers of Spamhaus.rg and blackholes.us down?

[Raymond Dijkxhoorn]

Hi!


Are this Blacklistservers since x-mas down. We receive in the last days many
errors from this servers...



Exemple enclosed Anonymsed.
Greeting
Xaver

Dec 31 10:12:37 linux-1ij2 named[14306]: too many timeouts resolving
'XXX.cn-kr.blackholes.us/A' (in 'cn-kr.blackholes.us'?): disabling EDNS
Dec 31 10:12:37 linux-1ij2 named[14306]: too many timeouts resolving
'XXX.korea.blackholes.us/A' (in 'korea.blackholes.us'?): disabling EDNS
Dec 31 10:12:37 linux-1ij2 named[14306]: too many timeouts resolving
'XXX.china.blackholes.us/A' (in 'china.blackholes.us'?): disabling EDNS
Dec 31 10:12:38 linux-1ij2 named[14306]: too many timeouts resolving


Is your queuery volume not too high so they simply blocked your servers?

Bye,
Raymond.

Re: trying to analyze vispa isp outage

[Raymond Dijkxhoorn]

Hi!


I have try to check BGP traffic behaviors related to recent VISPA ISP DDOS.
For this task I have using BGplay and I need feedback about my analysis. If
you are interested check
http://extraexploit.blogspot.com/2010/01/trying-to-analyze-vispa-isp-outage_08.html

Thank you for your attention.


Thats not too strange, UK ISP, small uplink line(s?), line full, router 
unable to send BGP updates. Gone!


They dont have any direct peerings just a transit. I mean, any student in 
europe could map them off the card. With a gigabit @ home.


I'll check with James (Vispa) if he has more info for you but the above 
applies i am afraid.


Bye,
Raymond.

Re: ISC DHCP server failover

[Raymond Dijkxhoorn]

Hi!

I am wondering if anyone has implemented the failover features of ISC 
DHCP? And if so, how successful has failover been in your environment?


We run it on various locations and this works pretty well.
Student dormitory's, and so on.

Bye,
Raymond.

Re: SIXXS contact

[Raymond Dijkxhoorn]

Hi!


would someone at SIXXS please contact me off-list regarding an account
issue?


Contact
The main contact address for SixXS is i...@sixxs.net, which is the sole 
email address one should use to contact SixXS. Non-English, impolite, 
clueless, UCE and HTML email gets discarded automatically. The official 
language used is English, due to archiving issues and the international 
effort put into SixXS.


And you naturally trued that one before sending here, right?

Bye,
Raymond.

Re: Announcement of Experiments

[Raymond Dijkxhoorn via NANOG]

Hi!

If, for any reason, you want to opt out from us using your ASN 
for our experiments, you can do so in the following form before May 9:


  https://forms.gle/ZvZaodndPhCqMvR89


If I am interpreting this correctly that you are just going to yolo a 
bunch of random ASNs to poison paths with, perhaps you should consider 
getting explicit permission for the ASNs you want to use instead. 


A lot of operators monitor the DFZ for prefixes with their ASN in the 
path, and wouldn't appreciate random support tickets because their NOC 
got some alert. :) 


Exatly that. How about you ask people to OPT-IN instead of you wanting 
people to OPT-OUT of whatever experiment you feel you need to do with 
other people's resources.


Bye, Raymond.

Re: Announcement of Experiments

[Raymond Dijkxhoorn via NANOG]

Hi!


> If I am interpreting this correctly that you are just going to yolo a
> bunch of random ASNs to poison paths with, perhaps you should consider
> getting explicit permission for the ASNs you want to use instead. 
>
> A lot of operators monitor the DFZ for prefixes with their ASN in the
> path, and wouldn't appreciate random support tickets because their NOC
> got some alert. :) 



Exatly that. How about you ask people to OPT-IN instead of you wanting
people to OPT-OUT of whatever experiment you feel you need to do with
other people's resources.



When you the last time you asked the entire internet?s  permission to announce 
routes ?


I dont exactly understand what you try to say its not about the route its 
about the path.


If the insert 'my ASN' i certainly will complain wherever i can and no i 
will not opt out from that. I will assume they just do use my ASN. Weird 
thought?


Bye, Raymond