Note: this problem is independent of wire/wireless, iPad (with Google DNS)/Linux/Windows
I can't access several sites including stackoverlow (cdn.sstatic.net), aws.amazon.com (d36cz9buwru1tt.cloudfront.net), heroku, github etc for 3 days from Turkey with ISP Superonline.
When I try to enter aws.amazon.com, browser downloads html and some images properly but can't download some of them, those hosted on d36cz9buwru1tt.cloudfront.net or subdomains like that.
Chrome says several images from this subdomain are pending. So the web page loading never finishes.
I can't access http://d36cz9buwru1tt.cloudfront.net, it keeps loading for a while (30 sec to minutes). But when I use proxy over Amsterdam, it loads immediately.
Without proxy, I can get its IP with ping:
64 bytes from server-54-240-162-83.fra6.r.cloudfront.net (54.240.162.83): icmp_req=1 ttl=53 time=58.2 ms
While writing these, the previous URL became available after several hours and now github.com can't be accessed due to css files on its CDN: https://github.global.ssl.fastly.net/assets/github2-f227c0e7c55002ba0645fc8d3761d00bce36e248.css
$ wget https://github.global.ssl.fastly.net/assets/github2-f227c0e7c55002ba0645fc8d3761d00bce36e248.css
--2013-11-19 21:39:32-- https://github.global.ssl.fastly.net/assets/github2-f227c0e7c55002ba0645fc8d3761d00bce36e248.css
Resolving github.global.ssl.fastly.net (github.global.ssl.fastly.net)... 185.31.17.184, 185.31.17.185
Connecting to github.global.ssl.fastly.net (github.global.ssl.fastly.net)|185.31.17.184|:443... connected.
...
...
waits but no response.
What could be the cause of this problem? My ISP did not help.
UPDATE: Changing my IP has solved the problem. Seems like someone using that IP before me got banned by Cloudfront.
I also had the exact same problem, Changing the DNS solved the issue. For me Coursera wasn't opening, neither 9GAG.
Changed my default DNS server provided by my ISP to the one given by google i.e.
8.8.8.8 and 8.8.4.4
I hope this solves your issue as well.
It seems there is a lot of problems with some ISPs and DNS resolution on CloudFront. See this https://forums.aws.amazon.com/thread.jspa?messageID=263168
Have you tried to change your DNS?
I also have the exactly same problem; same situation as you.
I think we really experience exactly the same. (but for me happen just today)
I first noticed problem on cloudfront then fastly then I can connect to cloudfront but fastly.
To answer your question I have a possible speculation about the root of the problem.
However, if this speculation is true the issue can't be solved on our end.
I think it's because of LSN (or NAT444, CGN) that installed in ISP network.
(ISP don't want customers to notice this change.)
To check if this speculation is plausible please check your modem/router
if the IP address received from ISP is in this block 100.64.0.0/10
then that should explain the phenomenon.
My ISP recently deploy LSN short before this problem arise.
I think IP address pool in LSN is too small (poorly deploy by ISP) so too many users share the same IP address.
this cause CDN networks to think they got DOS attack from particular IP address.
then CDN networks will temporary block (or null route) the LSN IP address.
some note: I'm sure this is not about the DNS because fastly deploy some trick called "round robin DNS" to use with "client retry" and I tried connect more than one IP address from fastly and also check that the values (All A records received) are correct.
To workaround the issue you can setup SOCKS proxy on a VPS and write PAC script to redirect some traffic thru the proxy.
Related
I Live in Estonia.
The second day I observe some kind of problem with the opening of some of my sites.
Example:
https://cp.nasdaq.ee - sometimes it works, sometimes it doesn't
https://185.252.232.227:8888/ - this is the same site cp.nasdaq.ee, but via IP - always opens properly
If the site is down and i enable the VPN, then it starts working.
In all other countries, the site opens without problems https://www.host-tracker.com/ru/ic/4/697585f4-486b-4c8e-b530-e3f0b6c96972/
This problem have all of my friends (5 men) who live in Estonia.
Perhaps the problem is somehow related to the fact that cp.nasdaq.ee has NS servers in the Cloudflare.com zone, but not all sites connected to Cloudflare have the problem.
I observe the problem only for those sites that are connected to Cloudflare and their A-record leads to ip 185.252.232.227.
If IP 109.205.176.239, 62.171.151.28, 62.171.151.28 are specified, then sites open without problems.
For your information,
all IPs listed are for VPS owned by Contabo.com hosting, the server is located in Germany.
The problematic IP 185.252.232.227 is from one VPS on Contabo, and all the other IPs I listed are from another VPS on Contabo.
And if i turn of status Proxied at CLoduflare.com and set DNS ONLY - then website works well!
Here is such an incomprehensible problem ...
I have tried to send a DNS packet to get an IP of some web-site.
In some cases, like google, the IP was right and when i typed it in the url line it sent me to google.
But in other cases (for example : stackoverflow.com) its gave me an IP that didin't linked to the web-site.
To be sure that my packet is right, i tried to do Nslookap in the command line, and the result was the same.
So i cant find the right IP adress of a web-site.
There is the message that appear when I'm trying to enter stakoverflow
Fastly error: unknown domain: 151.101.65.69.
Please check that this domain has been added to a service.
You (generally speaking) can not open the website just by entering the IP address in your browser's address bar because web servers (and possibly many other network components that are between you and the web server) often do not host only one web site on that IP address so they rely on exact domain name typed in address bar to serve the right content.
I think, it's caused by yours internet restriction. Try to contact your ISP (your internet provider) about this problem. He will probably know more about cause of this problem.
Short answer: you need a host header.
Long answer: Since HTTP/1.1 introduced in 1997 (and then updated in 1999 and in 2014), the request needs a host header. That allows the web server to route a request to a corresponding server configuration, a virtual server in Apache speak. Some servers don't have this configured and is allowing requests to any host to be served from the same web server configuration.
HTTP/1.1 also allowed multi-tenant proxies, as Fastly, to exist in the Internet. Fastly is a CDN - content delivery network - that allows to cache websites content on closer to users and deliver it locally (faster than from a cloud or a colo, thus the name).
When you're not specifying the domain for the request, it looks like your client (or a library) is using the IP address as the host header. That's why the response from Fastly talks about domain: unknown domain: 151.101.65.69.
While Fastly do support service pinning to a dedicated IP address, which would have worked for your request - it doesn't look like stackoverflow is using the feature as they might not need it.
I'm running a nodejs webserver on azure using the express library for http handling. We've been attempting to enable cloudflare protection on the domains pointing to this box, but when we turn cloudflare proxying on, we see cycling periods of requests succeeding, and requests failing with a 524 error. I understand this error is returned when the server fails to respond to the connection with an HTTP response in time, but I'm having a hard time figuring out why it is
A. Only failing sometimes as opposed to all the time
B. Immediately fixed when we turn cloudflare proxying off.
I've been attempting to confirm the TCP connection using
tcpdump -i eth0 port 443 | grep cloudflare (the request come over https) and have seen curl requests fail seemingly without any traffic hitting the box, while others do arrive. For further reference, these requests should be and are quite quick when they succeed, so I'm having a hard time believe the issue is due to a long running process stalling the response.
I do not believe we have any sort of IP based throttling or firewall (at least not intentionally?)
Any ideas greatly appreciated, thanks
It seems that the issue was caused by DNS resolution.
On Azure, you can configure a custom domain name for your created webapp. And according to the CloudFlare usage, you need to switch the DNS resolution to CloudFlare DNS server, please see more infomation for configuring domain name https://azure.microsoft.com/en-us/documentation/articles/web-sites-custom-domain-name/.
You can try to refer to the faq doc of CloudFlare How do I enter Windows Azure DNS records in CloudFlare? to make sure the DNS settings is correct.
Try clearing your cookies.
Had a similar issue when I changed cloudflare settings to a new host but cloudflare cookies for the domain was doing something funky to the request (I am guessing it might be trying to contact the old host?)
I have a couple EC2 instances behind an Elastic Load Balancer. These instances serve HTTP requests for a single web site. I recently started looking at the HOST header of the traffic, because I am planning to split my app into virtual hosts.
With some regularity (dozens of times a day), I log a request for a host name that is totally unrelated to my servers. As a couple examples, today I saw requests with the host names ad.adserverplus.com and r1---sn-upfn-hp5e.c.youtube.com. I looked these up and the IP addresses are not the same as any of my servers, nor of the ELB, so I am trying to develop a theory as to how this happens.
I realize that someone could be spoofing the host header, but it happens often enough that I am pretty sure this is not what is going on. My other idea is that somehow there is stale DNS data that just happens to resolve one of those hosts to my IP address, but again this seems like it could happen once in a great while but not regularly. What are some other possibilities, and how might I verify / discredit them?
EDIT
I looked at some of the unexpected host names today, and it seems that they actually do resolve to an IP that is one of the possible IPs that my domain apex resolves to. I use Route 53 for DNS, and I have the zone apex pointed to the ELB, so when I query the IP address for my domain, I get different answers depending on when I ask. So this makes me very curious, how do these IP addresses get assigned to me and how does EC2 make sure they are not co-opting an IP address that someone else is already using.
There are any number of reasons for this. First you should understand that the public host name for your EC2 instances and load balancers have likely been used before. If you have an elastic IP associated with your load balancer, it has also probably been used before.
As such you can get traffic to your servers that is intended for a previous tenant of that hostname of IP address that you are currently using.
One thing you can do is to configure your web servers to reject traffic (respond with 403) to traffic that is not arriving with the proper hostname specified or that comes from a specific external host.
Your IP or your ELBs IP may have at one point in time been an open proxy. meaning that someone is hoping that you would forward the requests on to their intended destination.
but in general open port 80 to the internet and all kinds of bots and zombies will visit you with a pretty constant flow of dodgy requests. I would imagine though that the \ec2 IP ranges would be a particularly juicy range to search for poorly patched websites to exploit.
This is not a C# question. This has to do more with our servers. Basically we've been noticing that another DNS address is resolving to our server's address, example.
Our DNS: www.bob.com
The other mysterious DNS that resolves to our IP: thing.blah8.com
This is actually a rather serious issue because some how this random DNS is being picked up by google and people are reaching our website through this address. So anyone have any ideas where this second DNS address is coming from? Anyone seen this strange behavior before? I'm guessing it might be the name of the box of our webhost.
Any hints or tips of where to look would be great. As a note, we've already checked our DNS server and there is no obvious clue as to where that address is coming from.
You can try contacting their technical domain contact (get it through a WHOIS request) and let them know their DNS is wrong. There's nothing you could forcefully do to stop them, outside of catching this hostname request with your web server and serving those visitors a different page. Some might say traffic is traffic, but I assume you don't agree. :)
It doesn't have anything to do with your servers, it's the remote sites DNS zone that is configured with your IP address. You couldn't make that happen.