Does anyone else find it sort of beautiful watching replays of events like this? It's amazing to watch how the routers organise themselves, making and breaking connections when needed.
There are at least two of us, dear friend!
Possible BGP hijack of 1.1.1.1
51–60 of 158 posts
Re: Possible BGP hijack of 1.1.1.1
#52I use 1.1.1.1 Do I need to do anything? Can I just continue using it or do I need to clear some cache etc?
Re: Possible BGP hijack of 1.1.1.1
#53Earlier quoted context omitted.
I wonder if it is a resolution issue or an access issue. What happens when you go to: http://62.129.133.242/ ? That should come up with a 'domain for sale' page, that's the same server.
Not loading for me from MA, USA. $ httpstat http://62.129.133.242/ 2018/05/29 10:54:04 unable to connect to host 62.129.133.242:80: dial tcp 62.129.133.242:80: connect: connection timed out
Loads for me in Texas on a cable connection. Fixed IP.
Re: Possible BGP hijack of 1.1.1.1
#54Earlier quoted context omitted.
As a data point - your site still isn't loading for me. IP : 79.69.113.214 Time: Tue May 29 15:28:30 BST 2018
I wonder if it is a resolution issue or an access issue. What happens when you go to: http://62.129.133.242/ ? That should come up with a 'domain for sale' page, that's the same server.
Connected to 62.129.133.242:80 from 10.44.54.246:54832
Resolves for me.
Re: Possible BGP hijack of 1.1.1.1
#55Earlier quoted context omitted.
As a data point - your site still isn't loading for me. IP : 79.69.113.214 Time: Tue May 29 15:28:30 BST 2018
I wonder if it is a resolution issue or an access issue. What happens when you go to: http://62.129.133.242/ ? That should come up with a 'domain for sale' page, that's the same server.
Not loading for me.
UK : 79.69.113.214 : Tue May 29 16:06:38 BST 2018
Re: Possible BGP hijack of 1.1.1.1
#56Network engineer here: I'm going to guess that this is a mistaken effort on the part of a Chinese ISP or the GFW to hijack traffic to 1.1.1.1 internally within China, but probably not intended to propagate beyond the major Chinese international-transit-ISP's connections to the global Internet. BCP38 is your friend.
It's been a while so I should re-read it, but I thought BCP38 was best applied at the terminal ISP/client network level. If you're a transit network, you can't do that kind of fitering because you have a legitimate chance of forwarding traffic to and from any network address.
Re: Possible BGP hijack of 1.1.1.1
#57I'm using AnchNet's services. And We've asked AnchNet when I recieved a e-mail from our BGPMon. They said their staff was configured a wrong config on router. Also they don't know 1.1.1.0/24 is used by CloudFlare&APNIC. So they used this prefix to test.
It shouldn't really matter who is currently using that net, it's not a private range :/
Re: Possible BGP hijack of 1.1.1.1
#58Ah! That may have been the reason why my site wasn't resolving earlier today. It was the weirdest situation with people from all over the planet complaining without any apparent pattern, a RIPE check of the site from 10 different locations showed no issues in connectivity. Thanks for posting this.
Also not loading from any SURFNet IP in The Netherlands
Re: Possible BGP hijack of 1.1.1.1
#59Network engineer here: I'm going to guess that this is a mistaken effort on the part of a Chinese ISP or the GFW to hijack traffic to 1.1.1.1 internally within China, but probably not intended to propagate beyond the major Chinese international-transit-ISP's connections to the global Internet. BCP38 is your friend.
It's been a while so I should re-read it, but I thought BCP38 was best applied at the terminal ISP/client network level. If you're a transit network, you can't do that kind of fitering because you have a legitimate chance of forwarding traffic to and from any network address.
More about the principles of not just ingress filtering, but the same as BCP38, but as an ISP with its own ASN, applied to your own egress:
a) don't announce shit you don't own
b) know how to set up ACLs and prefix-list filters on your own egress IP space announcements which face towards your peers and IP transit upstreams.
Conversely, as a big ISP which has many small ASNs downstream of it, be responsible and set up filters on your own ingress which prevent your customers from announcing mistaken shit to you.
Using an example of a clueful and attentive major ISP: For example if you are a small to medium sized regional ISP and buy IP transit from NTT, one of the world's top-ten global commercial transit providers, they actually do take the time to verify each and every prefix you announce to them and will require an interaction with their NOC if you want to announce a new /22.
Re: Possible BGP hijack of 1.1.1.1
#60Would this affect certificate-validating clients doing DNS-over-HTTPS to 1.1.1.1 — doesn’t it have an ipAddress certificate and demand HTTPS resolution only?
They use a named certificate, validated against the standard CAs. Unless the hijackers were able to get a certificate with the name 'cloudflare-dns.com.' then the TLS session would fail. https://developers.cloudflare.com/1.1.1.1/dns-over-tls/
[deleted]