Website unavailable

For several months I have been unable to access the main freebsd.org website, by either FQDN or IP address. Tried with Vivaldi, Firefox, Lynx, Safari and a couple of Android browsers. Changed DNS providers.

On a Slackware machine dig freebsd.org resolves the IP address for the A name record. traceroute doesn't get beyond my ISP.

I can obviously connect to https://forums.freebsd.org

Any idea what the problem might be? IP address blocked, for some reason? Problem in Ireland only?

It's most perplexing and it reflects badly on freebsd.
 
For several months I have been unable to access the main freebsd.org website, by either FQDN or IP address.
We can not debug if we don't know what the problem is. What exactly happens when you try to connect? Blank screen, waits forever, browser error message?

By the way, I just noticed: There is no real web server running on http://freebsd.org. If you try to connect to it, it immediately forwards to https://www.freebsd.org (note the "s" at the end of http). So when you say "the main freebsd.org web site", what site do you really go to?

Tried with Vivaldi, Firefox, Lynx, Safari and a couple of Android browsers.
On what OS? Safari must have been on MacOS or iOS, and Android browsers run on Android. But the first 3 could be on pretty much any OS.

On a Slackware machine dig freebsd.org resolves the IP address for the A name record.
To what? Something sensible? Here is what I get on my machine (I'm using host, not dig, just because the output is shorter, and I omitted the MX records to save space):

> host www.freebsd.org
www.freebsd.org is an alias for wfe0.nyi.freebsd.org.
wfe0.nyi.freebsd.org has address 96.47.72.84
> host freebsd.org
freebsd.org has address 96.47.72.84


traceroute doesn't get beyond my ISP.
That's not uncommon, many ISPs block trace route. You should use ping to test connectivity.

What happens when you do "telnet www.freebsd.org 80", and speak a few lines of http protocol to it?
Any idea what the problem might be? IP address blocked, for some reason?
Could be. Strange ISPs have been known to do lots of strange things. Have you tried going to an internet cafe? Or taking your cell phone somewhere away from home?

Problem in Ireland only?
That seems highly unlikely. There are lots of tech-savvy people on that island, and I bet quite a few of them run FreeBSD and visit the web site.

It's most perplexing and it reflects badly on freebsd.
Perplexing: Sure, but only until we actually start debugging it. Reflects badly? It is very likely user error or local configuration problem, nothing to do with FreeBSD itself.
 
That behavior from multiple sites is indeed very perplexing. OTOH, the same site works great for a lot of other people.
 
For me *.freebsd.org simply doesn't resolve right now (lookups time out) while me resolver has no problems resolving other names. It's been like that for at least a couple of days and it's not the first time this happens also. The last time it happened it kept timing out for a couple of weeks and then just magically fixed itself. By now i have added most FreeBSD domains to my host files though so it does not bother me much.
 
ekvz Who is your DNS point?

It's a private unbound resolver. I've been running this setup for years and *.freebsd.org are the only domains which are giving me problems. I admit i haven't looked into packet dumps yet but it seems kinda strange. It don't see a reason why it would fail for those only. From the top of my head there is nothing can think of besides bad routing, traffic from my IP being dropped somewhere (for whatever reason) or the target DNS servers somehow belonging to one of that handful of ranges that are blocked on my end (basically the second option in reverse).
 
On a Slackware machine dig freebsd.org resolves the IP address for the A name record. traceroute doesn't get beyond my ISP.
I’m aware this is an old thread, but this might be helpful for others nonetheless …

It’s not uncommon that traceroute doesn’t work, because it uses UDP packets in a port range that is often blocked by firewalls.
The FreeBSD implementation of traceroute(8) has several options to mitigate that situation. In particular, the -I option (uppercase “i”) often makes it work when it doesn’t work by default. If that still fails, -P TCP might be worth a try instead.

By the way, if you have IPv6 connectivity, and the target server also has it (this is the case for *.freebsd.org), you can try traceroute6(8) instead. It also supports the -I option.
 
ekvz If this was Stack Overflow, I would close your question for lack of debugging information. If you have a new question, start your own thread.

This isn't Stack Overflow though and i obviously don't expect any answer to a rhetorical question...If that somehow escaped you it's not my problem. I am not going to explain this.
 
ekvz You shouldn't be bringing up problems you are having on this forum if you aren't looking for help solving them. It gives the false impression everyone is having them when they're not.
 
Operator error - I doubt that reflects on FreeBSD at all. Try a different DNS source.
Agreed. The DNS servers hosted by (national) ISPs in my small town tend to be orphans. They don't seem to be a priority. Do yourself a favor and use anything except your ISP's DNS servers. If you run your own DNS, use anything except your ISP's DNS servers as a forwarder.
 
do you enforce dnssec? maybe that is the problem because download.freebsd.org is dnssec signed, and geo.freebsd.org which download refers to is not signed.
 
do you enforce dnssec? maybe that is the problem because download.freebsd.org is dnssec signed, and geo.freebsd.org which download refers to is not signed.

While i know pretty much nothing about dnssec i think you might be on to something there. I can actually resolve geo.freebsd.org (seemingly also *.geo.freebsd.org) while download.freebsd.org, pkg.freebsd.org, distfiles.freebsd.org, ... yield the usual timeout.
 
OT: Why I don't accept website-related job offers anymore:

Cause: 3rd-party payment system doesn't work.
Client: Site doesn't work.
Blame on: admin

Cause: Somebody is trying to connect to the website with a fringe VPN.
Client: Site doesn't work.
Blame on: admin

Cause: Internet is down.
Client: Site doesn't work.
Blame on: admin

Cause: Somebody is trying to connect to the website with his powered-off phone.
Client: Site doesn't work.
Blame on: admin

Cause: Blackout.
Client: Site doesn't work.
Blame on: admin

...
 
downforeveryoneorjustme.com shows that wfe0.nyi.freebsd.org is down.

But I have tried it on two machines, one in Europe and one in Asia, and the both redirect to www.freebsd.org .

pkg0.nyi.freebsd.org comes up quickly.
 
Back
Top