# download.freebsd.org down



## rootbert (Dec 6, 2019)

download.freebsd.org is down now for days ... there is no news on the main site etc. I don't know if they even know that it is down ... does anyone have any information?


----------



## Beastie (Dec 6, 2019)

It's working fine here, right now.

```
Reply from 149.20.1.200: bytes=32 time=204ms TTL=46
```


----------



## rootbert (Dec 6, 2019)

no problem with ping here, but with http/s


----------



## rootbert (Dec 6, 2019)

to be exact: 213.138.116.78 has a problem with https


----------



## Alexander88207 (Dec 6, 2019)

Seems now to work again


----------



## SirDice (Dec 6, 2019)

If you're looking for the installation media to download there are a large number of mirrors for that, pick one that's closer to home.

C.4. Official Mirrors

Note that those mirrors are for the installation media only, they're not repository or update mirrors.


----------



## rootbert (Dec 6, 2019)

strange ... does not work for me neither in 3 mobile networks nor in 4 datacenters in Finland, Germany and Austria


----------



## rootbert (Dec 6, 2019)

fun part: most of their servers are not setup correctly, mirror germany does not work, finland does not work, ireland is non functional, latvia has a wrong certificate...


----------



## Deleted member 30996 (Dec 6, 2019)

I just downloaded a 12.1 memstick.img from the site without any problems.


----------



## rootbert (Dec 6, 2019)

to be honest, it's a shame for an operating system with the power to server that download.freebsd.org and at least 8 mirrors have problems resolving and/or with the tls handshake 

just for info: the same problems appear from 7 different networks in 3 countries, on 3 platforms: FreeBSD, Linux and Windows


----------



## rootbert (Dec 6, 2019)

Trihexagonal said:


> I just downloaded a 12.1 memstick.img from the site without any problems.


could you try again with putting the ip address from above for download.freebsd.org in your /etc/hosts (and opening a new private browser session)?


----------



## Deleted member 30996 (Dec 6, 2019)

Entering https://149.20.1.200 in my browser returns a bad cert warning.

https://213.138.116.78 returns "An error occurred during a connection to 213.138.116.78. PR_CONNECT_RESET_ERROR"

https://download.freebsd.org/ftp/releases/ISO-IMAGES/12.1/  was what I used. Mirrors are maintained by someone who is lending a hand and bandwidth. It's up to them to keep their certs right.


----------



## rootbert (Dec 6, 2019)

maybe the reason is that their dns setup is wrong ... see https://dnsviz.net/d/download.freebsd.org/dnssec/

... yeah from the list of freebsd mirrors, 8 out of the first 10 (or so) ipv4 mirrors did not work properly neither.


----------



## Emrion (Dec 6, 2019)

I have also a similar problem. A connection to download.freebsd.org results in: "Website unreachable: ERR_CONNECTION_RESET". The host is actually resolved and responds to ping. The mirrors redirect to download.freebsd.org at the end. So, no hope from that.


----------



## ShelLuser (Dec 6, 2019)

I can reproduce some of those issues here as well. 


```
;; ANSWER SECTION:
download.freebsd.org.   3121    IN      CNAME   download.geo.freebsd.org.
download.geo.freebsd.org. 150   IN      A       213.138.116.78
```
I connect to this from the main website and then things just stop working; 'can't connect'. Probably a TLS related issue indeed but I can't do further investigations rigth now because I only have a laptop to work with righ now and thats far from ideal.


----------



## rootbert (Dec 6, 2019)

got a fast reply from the admins, so gns0.freebsd.org is having issues and they removed it from the list of nameservers, should be propagated soon. the other nameservers:
NS    gns1.freebsd.org.
NS    gns2.freebsd.org.

problem solved ;-) thanks


----------



## peter@ (Dec 9, 2019)

The stale gns0 reference was actually not involved in this.  When the Yahoo cluster site was decommissioned in July this year, that gns0 reference was overlooked.  It's been like this for nearly 6 months.  It's fixed now, thanks!

This particular problem was caused by a partial hardware failure.  One drive in the volume had an imminent failure and was operating painfully slowly.  The system livelocked while ZFS was trying to rebuild onto a spare.  Among other things nginx was accepting connections and immediately dropping them, which caused the ssl handshake error.  The geo-dns rotation system was looking for accepting connections only.


----------

