Closed mbillen-cimt closed 2 months ago
It works with the latest published image, but there may be some issues in the contributing steps.
> docker pull klutchell/unbound:latest
> docker exec unbound drill @127.0.0.1 dnssec.works
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 56592
;; flags: qr rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; dnssec.works. IN A
;; ANSWER SECTION:
dnssec.works. 3600 IN A 5.45.107.88
;; AUTHORITY SECTION:
;; ADDITIONAL SECTION:
;; Query time: 360 msec
;; SERVER: 127.0.0.1
;; WHEN: Tue Jun 25 13:09:06 2024
;; MSG SIZE rcvd: 46
I'll try to reproduce following the build steps.
I actually get a different error on that step.
#16 [unbound 7/7] RUN wget -q https://www.internic.net/domain/named.root -O root.hints && { /opt/usr/sbin/unbound-anchor -v -r root.hints 2>&1 || true ; } | tee -a /dev/stderr | grep -q "success: the anchor is ok"
#16 0.817 /var/unbound/root.key does not exist
#16 0.933 success: the anchor is ok
Are you able to run this command locally and inspect the output?
wget https://www.internic.net/domain/named.root -O root.hints
Thank you for your message. I have downloaded the root.hints file manually and made a diff to the version in the git repository. Apart from a change to the B server, the files are identical:
$ diff <(curl -s https://www.internic.net/domain/named.root) ./rootfs_overlay/var/unbound/root.hints
12,13c12,13
< ; last update: May 28, 2024
< ; related version of root zone: 2024052801
---
> ; last update: October 24, 2023
> ; related version of root zone: 2023102402
24,25c24,25
< B.ROOT-SERVERS.NET. 3600000 A 170.247.170.2
< B.ROOT-SERVERS.NET. 3600000 AAAA 2801:1b8:10::b
---
> B.ROOT-SERVERS.NET. 3600000 A 199.9.14.201
> B.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:200::b
I have also attached the complete log of the build with the error: build.log
By any chance is outgoing traffic on your network to port 53 blocked or redirected? I've found the unbound-anchor requires access to the root servers on port 53, but it's common to redirect or block port 53 internally if you are running your own DNS.
As far as I can tell the build works for me, and the GitHub CI runners, so it might be isolated to where you are running the test?
Follow up question, do you have a use case to update the root hints manually? I might change the workflow to just grab the latest root hints at build time and not bother committing them to git.
Thank you very much, you were absolutely right. After I explicitly enabled port 53 to the outside in the firewall, the build runs correctly:
#18 10.37 /var/unbound/root.key does not exist
#18 10.56 success: the anchor is ok
Unfortunately, I was not aware that the unbound anchor needed access to port 53 of the root server during the build.
My use case is as follows: I had previously installed unbound directly on one of my servers and had a cronjob there that regularly downloaded the latest version of the root hints. Now that I have switched to the Docker version, I would like to automatically build and deploy a new container as soon as the root hints have changed.
I have just checked out and tested your new branch kyle/build-time-root-key. This is the perfect solution for my requirement.
As a suggestion, you could add a comment that port 53 must be open to the outside during the build in case someone also encounters the problem.
As a suggestion, you could add a comment that port 53 must be open to the outside during the build in case someone also encounters the problem.
Excellent idea. I added a note to the CONTRIBUTING steps. How does that look?
Perfect, that looks pretty good. With that hint, others shouldn't have the problem.
Thanks again for your support. I really appreciate that!
I'm trying to build the Docker image myself and have checked out the git repository and followed the instructions in the CONTRIBUTING.md file. Unfortunately, I get the following error during the Docker build:
This happens both on a Linux server and directly on a Raspberry Pi. Can anyone give me a tip on how to solve the problem?
Docker version 26.1.1, build 4cf5afa
Apparently there is also a problem with the trusted keys when using the official latest image: