TicketMaster / Live Nation admin on list?
If so, can you contact me offlist? I seem to have a subnet that you guys don't like. Thank You, Mike
GoDaddy abuse Contact
Could someone from GoDaddy please contact me off list? Running into issues where customers on our network are not able to reach their sites due to blackhole because of phishing sites that are on the shared IP. Thanks Joe Crowe Comcast
Go Daddy contact
Can someone from Go Daddy contact me off-list about a shared customer issue? Mark Comcast DNS
Re: BCP38 adoption "incentives"?
Even if the customers are unaware of the spoofed traffic, ISPs should be aware which leaves them open for "aiding and abetting". This doesn't require inspecting the payload of the packets. This is the IP header which they are expected to examine and for which there is a BCP saying to drop spoofed packets. Sources are used for policy routing so the source field is expected to be processed. I would expect a Judge to take into consideration the BCP in deciding whether a ISP should be aware of the issue when deciding if a ISP is aiding and abetting by allowing spoofed packets to enter their network. Mark In message , Alain Hebert writes: > Well there is money to be made in DDoS protection... See our > "friends" still hosting "those" pay sites. > > Do not expect the vendors to cut themself of that market. > > - > Alain Hebertaheb...@pubnix.net > PubNIX Inc. > 50 boul. St-Charles > P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 > Tel: 514-990-5911 http://www.pubnix.netFax: 514-990-9443 > > On 09/29/16 11:31, Leo Bicknell wrote: > > In a message written on Tue, Sep 27, 2016 at 08:44:35PM +, White, > > Andrew wrote: > >> This assumes the ISP manages the customer's CPE or home router, which is > >> often not the case. Adding such ACLs > to the upstream device, operated by the ISP, is not always easy or feasible. > > Unicast RFP should be a feature every ISP requires of all edge > > devices for at least 15 years now. It should be on by default for > > virtually all connections, and disabled only by request or when > > there are circumstances to suggest it would break things (e.g. a > > request for BGP with full tables over the link). > > > > At this point there's no excuse, anyone who has gear who can't do > > that has been asleep at the switch. It's been a standard feature > > in too much gear for too long. > > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: bogon identified? how to track down bogus IPs/ASN's
As far as I can tell, AS394786 (Avetria Wireless) made up both AS135022 and the associated bogon IP ranges that AS announces (103.206.16.0/22 & 182.161.32.0/22) for its own use. Avetria's sole upstream provider appears to be AS54889 (Bluwest Inc). Probably an issue to discuss with both of these organizations. --Blake Filip Hruska wrote on 9/29/2016 3:06 PM: According to HE's BGP tool, the IP range is actually 103.206.16.0/22 and it looks like it's a bogon. http://bgp.he.net/net/103.206.16.0/22#_bogon Regards, Filip On 29.9.2016 21:46, Ken Chase wrote: My turn for the newb question: I've got a traceroute with this IP in it thats close to the end of the trace. 103.206.16.46 Chasing down this IP to see who the ISP a friend is using, figured out the diff between ARIN and APNIC whois for IPs (..bit of a learning curve, not sure why there's not just one whois interface syntax). whois -h whois.apnic.net -m 103.206.16.0/21 shows only the upper /22 being registered with APNIC (if you do -m on .16.0/22, there's no entry). So it seems to me these Ips arent registered properly with APNIC (could it be cross-registered with another RIR? Well it's not with ARIN who'd be the local.) But I do see this block in global bgp tables so it wasnt like someone decided to use 10.10.10/24 or 1.2.3/24 in their routing infrastructure. They're actually announcing; sh ip bg 103.206.16.0 ends in a path with 394786 135022 looking up 394786 I see avetria networks. looking up 135022 I see nothing at ARIN. At APNIC I get as-block: AS134557 - AS135580 descr: APNIC ASN block remarks:These AS numbers are further assigned by APNIC remarks:to APNIC members and end-users in the APNIC region but nothing more specific. However, this does show up in radb as avetria networks as well. (and various geolocate DBs put it in Melbourn.au though i know it's in use in Kitchener ontario). So what's not matching up here? /kc -- Ken Chase - m...@sizone.org Guelph Ontario
Re: bogon identified? how to track down bogus IPs/ASN's
According to HE's BGP tool, the IP range is actually 103.206.16.0/22 and it looks like it's a bogon. http://bgp.he.net/net/103.206.16.0/22#_bogon Regards, Filip On 29.9.2016 21:46, Ken Chase wrote: My turn for the newb question: I've got a traceroute with this IP in it thats close to the end of the trace. 103.206.16.46 Chasing down this IP to see who the ISP a friend is using, figured out the diff between ARIN and APNIC whois for IPs (..bit of a learning curve, not sure why there's not just one whois interface syntax). whois -h whois.apnic.net -m 103.206.16.0/21 shows only the upper /22 being registered with APNIC (if you do -m on .16.0/22, there's no entry). So it seems to me these Ips arent registered properly with APNIC (could it be cross-registered with another RIR? Well it's not with ARIN who'd be the local.) But I do see this block in global bgp tables so it wasnt like someone decided to use 10.10.10/24 or 1.2.3/24 in their routing infrastructure. They're actually announcing; sh ip bg 103.206.16.0 ends in a path with 394786 135022 looking up 394786 I see avetria networks. looking up 135022 I see nothing at ARIN. At APNIC I get as-block: AS134557 - AS135580 descr: APNIC ASN block remarks:These AS numbers are further assigned by APNIC remarks:to APNIC members and end-users in the APNIC region but nothing more specific. However, this does show up in radb as avetria networks as well. (and various geolocate DBs put it in Melbourn.au though i know it's in use in Kitchener ontario). So what's not matching up here? /kc -- Ken Chase - m...@sizone.org Guelph Ontario
PeeringDB Product Committee Charter Survey / NANOG
Hello PeeringDB users / hello NANOG, the PeeringDB Product Committee (PC, [0]) is charged with steering the future product development and running the market outreach efforts to continuously improve the value that PeeringDB delivers to the networks registered with PeeringDB, and the broader community. We're looking for feedback and input from the community on our charter proposal. Please take this short survey [1]. Your input and comments are appreciated! [0] http://docs.peeringdb.com/gov/ [1] https://www.surveymonkey.com/r/JN36DT2 Greetings Arnold -- Arnold Nipper email: arn...@nipper.de phone: +49 6224 5593407 2 mobile: +49 172 2650958 fax: +49 6224 5593407 9 signature.asc Description: OpenPGP digital signature
bogon identified? how to track down bogus IPs/ASN's
My turn for the newb question: I've got a traceroute with this IP in it thats close to the end of the trace. 103.206.16.46 Chasing down this IP to see who the ISP a friend is using, figured out the diff between ARIN and APNIC whois for IPs (..bit of a learning curve, not sure why there's not just one whois interface syntax). whois -h whois.apnic.net -m 103.206.16.0/21 shows only the upper /22 being registered with APNIC (if you do -m on .16.0/22, there's no entry). So it seems to me these Ips arent registered properly with APNIC (could it be cross-registered with another RIR? Well it's not with ARIN who'd be the local.) But I do see this block in global bgp tables so it wasnt like someone decided to use 10.10.10/24 or 1.2.3/24 in their routing infrastructure. They're actually announcing; sh ip bg 103.206.16.0 ends in a path with 394786 135022 looking up 394786 I see avetria networks. looking up 135022 I see nothing at ARIN. At APNIC I get as-block: AS134557 - AS135580 descr: APNIC ASN block remarks:These AS numbers are further assigned by APNIC remarks:to APNIC members and end-users in the APNIC region but nothing more specific. However, this does show up in radb as avetria networks as well. (and various geolocate DBs put it in Melbourn.au though i know it's in use in Kitchener ontario). So what's not matching up here? /kc -- Ken Chase - m...@sizone.org Guelph Ontario
contact @ detroit pistons IT/network org?
by chance - anyone have a clueful contact at the detroit pistons who can help resolve an https MITM proxy problem? (likely a misconfigured watchguard.) trying to diagnose a proxy level certificate problem through a management level proxy is less than fun.
Re: Root Zone DNSSEC Operational Update -- ZSK length change
A quick update on this change: A 2048-bit ZSK has been pre-published in the root zone as of September 20. We are not aware of any issues related to the appearance of the larger key. In less than 48 hours we will being publishing root zones signed with the 2048-bit ZSK. I will send another note once that has happened. If you observe any problems related to this change, please contact Verisign's customer service at i...@verisign-grs.com. Duane W. > On Jul 28, 2016, at 3:37 PM, Wessels, Duane wrote: > > As you may know, Verisign, in its role as the Root Zone Maintainer > is also the operator of the root zone Zone Signing Key (ZSK). Later > this year, we will increase the size of the ZSK from 1024-bits to > 2048-bits. > > The root zone ZSK is normally rolled every calendar quarter, as per > our “DNSSEC Practice Statement for the Root Zone ZSK operator.”[1] > The ZSK public keys are signed at quarterly key signing ceremonies > by ICANN in its role as the IANA Functions Operator. > > On September 20, 2016 the 2048-bit ZSK will be pre-published in the > root zone, following the standard ZSK rollover procedure. We intend > to begin publishing root zones signed with the first 2048-bit ZSK > on October 1, 2016. > > Some details of the ZSK size transition have recently been presented > at the DNS-OARC, NANOG, RIPE, ICANN, and IETF meetings.[2] If you > have any questions or concerns, please feel free to contact us at > z...@verisign.com. > > Please feel free to forward this message to anyone who might not have > seen it here. > > [1] https://www.verisign.com/assets/dps-zsk-operator-1532.pdf > [2] > https://ripe72.ripe.net/wp-content/uploads/presentations/168-verisign-zsk-change.pdf > signature.asc Description: Message signed with OpenPGP using GPGMail
Re: BCP38 adoption "incentives"?
Well there is money to be made in DDoS protection... See our "friends" still hosting "those" pay sites. Do not expect the vendors to cut themself of that market. - Alain Hebertaheb...@pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.netFax: 514-990-9443 On 09/29/16 11:31, Leo Bicknell wrote: > In a message written on Tue, Sep 27, 2016 at 08:44:35PM +, White, Andrew > wrote: >> This assumes the ISP manages the customer's CPE or home router, which is >> often not the case. Adding such ACLs to the upstream device, operated by the >> ISP, is not always easy or feasible. > Unicast RFP should be a feature every ISP requires of all edge > devices for at least 15 years now. It should be on by default for > virtually all connections, and disabled only by request or when > there are circumstances to suggest it would break things (e.g. a > request for BGP with full tables over the link). > > At this point there's no excuse, anyone who has gear who can't do > that has been asleep at the switch. It's been a standard feature > in too much gear for too long. >
Re: BCP38 adoption "incentives"?
In a message written on Tue, Sep 27, 2016 at 08:44:35PM +, White, Andrew wrote: > This assumes the ISP manages the customer's CPE or home router, which is > often not the case. Adding such ACLs to the upstream device, operated by the > ISP, is not always easy or feasible. Unicast RFP should be a feature every ISP requires of all edge devices for at least 15 years now. It should be on by default for virtually all connections, and disabled only by request or when there are circumstances to suggest it would break things (e.g. a request for BGP with full tables over the link). At this point there's no excuse, anyone who has gear who can't do that has been asleep at the switch. It's been a standard feature in too much gear for too long. -- Leo Bicknell - bickn...@ufp.org PGP keys at http://www.ufp.org/~bicknell/ pgpsnqYUh9bKQ.pgp Description: PGP signature