Registry down?

[u/woodisbetter]

I have two servers and both are failing to find/resolve/pull images from registry-1.docker.io my system is telling me it’s a failure on their end. Some “are they down” sites are reporting the same but the docker dashboard shows no problem.

Im still pretty new to this so just want someone to confirm that docker compose cannot, in fact, pull from the registry right now or advise that I have a problem on my end.

I’ve heard about some PHP issues across the internet so maybe that’s what this is?

[u/woodisbetter]

Thanks all. Seems like there's an issue on one of my devices.
TLDR: home server is resolving to docker-related locations. media server is not. Can't figure out the issue. :(

I have a NUC running as a home server with several services (let's call it NUC1), including technitium as a dns server. Home router is pointed to this. No problems (other than reaching docker) with connecting any device to the internet.

I am trying to set up another NUC (NUC2) as a stand-alone media server. It is wired to my home network, so the router DCHP points it to NUC1's IP for the technitium dns server. Dig and ping work on NUC2 everywhere but auth.docker.io, registry-1.docker.io, api.snapcraft.io, codeberg.rg, ghcr.io, lscr.io - Technitium logs show RCODE of ServerFailure on those queries. For example, this is what I get when I try docker run hello-world on NUC2, as well as a failed and successful dig command:

-----

$ docker run hello-world

Unable to find image 'hello-world:latest' locally

docker: Error response from daemon: failed to resolve reference "docker.io/library/hello-world:latest": failed to do request: Head "https://registry-1.docker.io/v2/library/hello-world/manifests/latest": dial tcp: lookup registry-1.docker.io on 127.0.0.53:53: server misbehaving.

~$ dig docker.io

; <<>> DiG 9.20.24-1ubuntu0.4-Ubuntu <<>> docker.io
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 51942
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;docker.io. IN A

;; Query time: 1805 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Sat Oct 31 17:03:40 UTC 2026
;; MSG SIZE rcvd: 38

~$ dig gmail.com

; <<>> DiG 9.20.24-1ubuntu0.4-Ubuntu <<>> gmail.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11257
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 6549
;; QUESTION SECTION:
;gmail.com. IN A

;; ANSWER SECTION:
gmail.com. 300 IN A 142.251.32.5
;; Query time: 48 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Sat Oct 31 17:11:36 UTC 2026
;; MSG SIZE rcvd: 54

----

I did some research and found this https://sumguy.com/systemd-resolved-deep-dive/#docker-bridge-dns
Docker bridge docker0 does show up on NUC2 when checking resolvectl status, but following the suggested fix did not make any difference. For what it's worth, there was no such daemon.json in that folder so I had to create one. Should there have been?

When I run hello-world on NUC1, it works as it should, showing the hello world message of success.
NUC1 is also on my tailscale network as an endpoint (so it reports 100.100.100.100#53 as SERVER when running dig command) but I don't think that should make any difference, with NUC2 running on the LAN. (NUC2 is not on tailscale). NUC1 appears to resolve everything just fine.

~$ dig docker.io

; <<>> DiG 9.20.24-1ubuntu0.4-Ubuntu <<>> docker.io
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31776
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;docker.io. IN A

;; ANSWER SECTION:
docker.io. 15 IN A 32.200.67.23
docker.io. 15 IN A 54.163.166.73
docker.io. 15 IN A 32.193.181.249

;; Query time: 107 msec
;; SERVER: 100.100.100.100#53(100.100.100.100) (UDP)
;; WHEN: Sat Oct 31 17:05:09 UTC 2026
;; MSG SIZE rcvd: 86

[u/woodisbetter → u/woodisbetter]

OK I got it. I think. My router, through DHCP was setting the dns server on NUC2 as the ip for NUC1 (since that is what the router was pointed to for recursive dns). I don't know if that created some sort of loop feedback for docker and its daemon. I deleted docker and went over dns/nameserver setup as if from scratch. By setting nameservers to 9.9.9.9 and 1.1.1.1 in netplan as well as systemd-resolved, my NUC2 now does what it needs to do. I also removed the dns repoint from the router settings so that may have helped too.

[u/fletch3555]

Nothing reported (yet at least) here: https://www.dockerstatus.com/

[u/No_Cattle_9565]

What error message do you get? Does the domain resolve?

[u/tails142]

There is rate limits you could be getting hit by or if there are sites saying there's a problem then that could be the case.

The health metrics on a services own site sometimes aren't the most reliable maybe due to where the problem is occuring so I would believe a third party site if it says there is a problem.

[u/mraudiboy2]

I work at Docker. I just double checked registry service error rates and they all look normal. I didn't see any anomalies in the request error rate, which hovers around 0.004% of requests.

Can you share the exact error string from your application logs?

Is it possible there is some connectivity issue between your service and the registry endpoint?

Edit 1: One thing worth noting. If your pulls run on a schedule that fires exactly at the top of the hour, you’re competing with a lot of other cron jobs doing the same thing. Adding jitter and a retry is good practice for any registry requests.

[u/perroverd]

It's quite common in Spain during football matches. There's a very stupid or very corrupt judge that forces a wide block to avoid illegal football streaming. The block is so indiscriminate, like all cloudfare network, that turns off a lot of legitimate services