Trying to unblock api.met.no

PWD · November 11, 2024, 7:36pm

Please follow the below template, it will help us to help you!

If you are Experiencing issues with a Pi-hole install that has non-standard elements (e.g you are using `nginx` instead of `lighttpd`, or there is some other aspect of your install that is customised) - please use the Community Help category.

Expected Behaviour:

Unbound shouldn't be blocking traffic from api.met.no

Actual Behaviour:

I'm running Pi-Hole on a Raspberry Pi Zero 2W and it's running absolutely fine for the most part, but I can't get the weather in my Home Assistant to show up and tracing the problem, it's because Unbound is blocking the API call as BOGUS

Debug Token:

https://tricorder.pi-hole.net/etoxSfp6/

jfb · November 11, 2024, 10:29pm

See the warnings on this site. Your unbound instance may be configured in such a way as to not work with algorithm 10.

https://dnsviz.net/d/api.met.no/dnssec/

My local unbound install (Version 1.13.1) correctly resolves that domain name to an IP:

 dig api.met.no @127.0.0.1 -p5335

; <<>> DiG 9.16.50-Raspbian <<>> api.met.no @127.0.0.1 -p5335
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44549
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;api.met.no.			IN	A

;; ANSWER SECTION:
api.met.no.		300	IN	A	157.249.81.141

;; Query time: 939 msec
;; SERVER: 127.0.0.1#5335(127.0.0.1)
;; WHEN: Mon Nov 11 16:28:18 CST 2024
;; MSG SIZE  rcvd: 55

PWD · November 11, 2024, 11:57pm

Thanks for your response.

I'm getting yellow earnings in the last box.

How would I fix the algorithm 10 problem please?

I should also add that I can visit api.met.no just fine via a browser.

jfb · November 12, 2024, 12:06am

If a browser is on your network and you want Pi-hole to block ads for all network clients, the browser should also be using Pi-hole for DNS resolution. Pi-hole, in turn, uses unbound.

Take a look through the unbound documentation:

Bucking_Horn · November 12, 2024, 7:38am

Let's see how unbound answers a resolution request for api.met.no.
Please share the result of:

delv +rtrace api.met.no @127.0.0.1 -p 5335

Output should look like (click for more)

;; fetch: api.met.no/A
;; fetch: met.no/DNSKEY
;; fetch: met.no/DS
;; fetch: no/DNSKEY
;; fetch: no/DS
;; fetch: ./DNSKEY
; fully validated
api.met.no.		249	IN	A	157.249.81.141
api.met.no.		249	IN	RRSIG	A 10 3 300 20241211230004 20241111230004 488 met.no. LzoocKKOG8CiZ9MqjeBQNO9NOtP+eKlav/SJDL2dJ8hRTM2Lh+8GtsII MSaMFRubAANwp9bVQgP87j1Zlp1UbIOd4OvuzAnMRfsCyHP6XoPUQyC4 gxs4lQ2fipGk4FKollLsrYPuA2yogRlLWsTxBjDTdvyvZ8JzOkTVd1wK 13ARV0mFVLnnA4icQj6J6wbsQp/q1HYJXosbTMOCBaTceM3UeF8vKElg 65mJG5GgGbAys0SZEk73mIK0W5DXZG8m6cqibOYG/y7Tl/OfKsxAGUtv XAOS2ei5IsnZ9UHxS2oLPAugS9CMhk1PKX4xF71FseJ1l2tHg9aDDJTG I70d1g==

PWD · November 12, 2024, 7:39am

Sorry, that's just too much for me. The browser works properly and is blocking everything Pi-Hole tells it too. It's just when it comes to api.met.no there's an anomaly. I feel like we're going in the right direction with this algorithm 10 stuff. Can you explain it like I'm 5 how to whitelist algorithm 10? The link to the docs is going right over my head and I feel like I'm likely to create more issues than solve them if I try and blindly fumble around in them.

PWD · November 12, 2024, 7:41am

;; fetch: api.met.no/A
;; resolution failed: SERVFAIL

Mine doesn't look like yours

Bucking_Horn · November 12, 2024, 7:49am

So it fails on retrieving the A record already, i.e. before DNSSEC validation.
Also note that we have queried your unbound at 127.0.0.1#5335 directly, confirming this as an unbound issue rather than a Pi-hole one.

Please check and share your unbound configuration:

unbound-checkconf

sudo grep -v '#\|^$' -R /etc/unbound/unbound.conf.d

PWD · November 12, 2024, 9:44am

Sorry, I'm an actual idiot sandwich, so not only did I not get a notification because I never turned them on. I also don't know how to quote properly either.

unbound-checkconf: no errors in /etc/unbound/unbound.conf

sudo grep -v '#\|^$' -R /etc/unbound/unbound.conf.d
/etc/unbound/unbound.conf.d/root-auto-trust-anchor-file.conf:server:
/etc/unbound/unbound.conf.d/root-auto-trust-anchor-file.conf:    auto-trust-anchor-file: "/var/lib/unbound/root.key"
/etc/unbound/unbound.conf.d/remote-control.conf:remote-control:
/etc/unbound/unbound.conf.d/remote-control.conf:  control-enable: yes
/etc/unbound/unbound.conf.d/remote-control.conf:  control-interface: /run/unbound.ctl
/etc/unbound/unbound.conf.d/pi-hole.conf:server:
/etc/unbound/unbound.conf.d/pi-hole.conf:    verbosity: 0
/etc/unbound/unbound.conf.d/pi-hole.conf:    interface: 127.0.0.1
/etc/unbound/unbound.conf.d/pi-hole.conf:    port: 5335
/etc/unbound/unbound.conf.d/pi-hole.conf:    do-ip4: yes
/etc/unbound/unbound.conf.d/pi-hole.conf:    do-udp: yes
/etc/unbound/unbound.conf.d/pi-hole.conf:    do-tcp: yes
/etc/unbound/unbound.conf.d/pi-hole.conf:    do-ip6: no
/etc/unbound/unbound.conf.d/pi-hole.conf:    prefer-ip6: no
/etc/unbound/unbound.conf.d/pi-hole.conf:    harden-glue: yes
/etc/unbound/unbound.conf.d/pi-hole.conf:    harden-dnssec-stripped: yes
/etc/unbound/unbound.conf.d/pi-hole.conf:    use-caps-for-id: no
/etc/unbound/unbound.conf.d/pi-hole.conf:    edns-buffer-size: 1232
/etc/unbound/unbound.conf.d/pi-hole.conf:    prefetch: yes
/etc/unbound/unbound.conf.d/pi-hole.conf:    num-threads: 1
/etc/unbound/unbound.conf.d/pi-hole.conf:    so-rcvbuf: 1m
/etc/unbound/unbound.conf.d/pi-hole.conf:    private-address: 192.168.0.0/16
/etc/unbound/unbound.conf.d/pi-hole.conf:    private-address: 169.254.0.0/16
/etc/unbound/unbound.conf.d/pi-hole.conf:    private-address: 172.16.0.0/12
/etc/unbound/unbound.conf.d/pi-hole.conf:    private-address: 10.0.0.0/8
/etc/unbound/unbound.conf.d/pi-hole.conf:    private-address: fd00::/8
/etc/unbound/unbound.conf.d/pi-hole.conf:    private-address: fe80::/10

jfb · November 12, 2024, 3:45pm

This is unrelated to the issue you are having with your specific instance of unbound.

Unbound isn't blocking the domain, and neither is Pi-hole. Unbound is unable to authenticate the DNSSEC signature of the domain, and thus returns BOGUS.

The domain has a valid DNSSEC signature (as evidenced by the fact that others can resolve the domain using unbound). That leave us to figure out why your local instance of unbound cannot resolve it.

There are additional tools available, but will require some study of the various outputs.

You can raise the verbosity of your unbound install to 5, query unbound directly for resolution of the domain, and then compare your log output to the output of a separate install of unbound that is able to resolve the domain. This online tool uses unbound and will show you the details of the log for that domain:

https://unboundtest.com

Select the A query type, type in your domain and hit query. The output will look something like this (just the first bit shown here):

Query results for A api.met.no

Response:
;; opcode: QUERY, status: NOERROR, id: 28876
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version 0; flags: do; udp: 1232

;; QUESTION SECTION:
;api.met.no.	IN	 A

;; ANSWER SECTION:
api.met.no.	0	IN	A	157.249.81.141
api.met.no.	0	IN	RRSIG	A 10 3 300 20241212114207 20241112114207 488 met.no. mMuBn8XLCD9NBQEquN9xFFUL94tbjaKRfm1Ww52SnFrkwb9U1j30EJQhQziEesS2zQpy34g+PpndqAxZ6jUEN2aFAVsBmfXVBhUqx+1U3hsCuXsNaFCt1KtgzTXwdpt1wwu7XUEUYVojGHmYpEea1lXypuM1unM/I48CNRw9fYvE6adIPMC+HCrOPlF7KBxU3+NMb3tpviSZIlBR/JKAuNAyG3Hnnx/JTY9kix/NvQcdpV+3I/S2BIXU8FooLacZ1jHjdXWsy3M1MdDWd/6sqB65kPAor0w/tMkLj1QVtKCVgOoey6WXTga/M9nmoBhbBVbR/QXM9zDtPh6ULSGcJQ==

----- Unbound logs -----
Nov 12 15:41:09 unbound[9960:0] debug: creating udp6 socket ::1 1053
Nov 12 15:41:09 unbound[9960:0] debug: creating tcp6 socket ::1 1053
Nov 12 15:41:09 unbound[9960:0] debug: creating udp4 socket 127.0.0.1 1053
Nov 12 15:41:09 unbound[9960:0] debug: creating tcp4 socket 127.0.0.1 1053
Nov 12 15:41:09 unbound[9960:0] debug: chdir to .
Nov 12 15:41:09 unbound[9960:0] debug: switching log to stderr
Nov 12 15:41:09 unbound[9960:0] debug: module config: "validator iterator"
Nov 12 15:41:09 unbound[9960:0] notice: init module 0: validator
Nov 12 15:41:09 unbound[9960:0] debug: validator nsec3cfg keysz 1024 mxiter 150
Nov 12 15:41:09 unbound[9960:0] debug: validator nsec3cfg keysz 2048 mxiter 150
Nov 12 15:41:09 unbound[9960:0] debug: validator nsec3cfg keysz 4096 mxiter 150
Nov 12 15:41:09 unbound[9960:0] notice: init module 1: iterator
Nov 12 15:41:09 unbound[9960:0] debug: target fetch policy for level 0 is 3
Nov 12 15:41:09 unbound[9960:0] debug: target fetch policy for level 1 is 2
Nov 12 15:41:09 unbound[9960:0] debug: target fetch policy for level 2 is 1
Nov 12 15:41:09 unbound[9960:0] debug: target fetch policy for level 3 is 0
Nov 12 15:41:09 unbound[9960:0] debug: target fetch policy for level 4 is 0

Note also that we aren't unbound experts here. We have a guide for unbound and many of us use unbound, but that's generally where our expertise ends.

PWD · November 12, 2024, 3:57pm

Hi, I posted the output as requested, it was the two lines that said SERVFAIL

PWD · November 12, 2024, 4:20pm

The entirety of the output was

delv +rtrace api.met.no @127.0.0.1 -p 5335
;; fetch: api.met.no/A
;; resolution failed: SERVFAIL

PWD · November 12, 2024, 4:22pm

How would I go about this please?

jfb · November 12, 2024, 9:25pm

Edit your unbound configuration file that currently shows verbosity=0.

/etc/unbound/unbound.conf.d/pi-hole.conf: verbosity: 0

Change the 0 to 5. Save the file. Restart unbound with sudo service unbound restart

After you are done troubleshooting, return the verbosity to 0 or 1, or your log will grow very quickly.

PWD · November 12, 2024, 9:40pm

Do I just copy this and paste this into the Terminal and then change the 0 to 5?

And when you say troubleshoot, what do you mean exactly? Is there a specific command I should run?

jfb · November 12, 2024, 10:03pm

When you installed unbound, you created the configuration file using a terminal command. That command was likely nano.

sudo nano /etc/unbound/unbound.conf.d/pi-hole.conf

By troubleshooting, I mean you have run all your test commands, have the output you want to review, and are ready to return unbound back to its prior configuration.

PWD · November 12, 2024, 10:16pm

Yup, it was nano.

But, what are the test commands I'm supposed to be running?

Just changing the 0 to 5 and restarting or something more?

jfb · November 13, 2024, 3:10am

dig api.met.no @127.0.0.1 -p 5335

PWD · November 13, 2024, 6:55am

So what I did was

Open Terminal

Type:

sudo nano /etc/unbound/unbound.conf.d/pi-hole.conf

Change

verbosity: 0

To

verbosity: 5

Then save and exit via ctrl X +Y + Enter

Then type

delv +rtrace api.met.no @127.0.0.1 -p 5335

Which returned

;; fetch: api.met.no/A
;; resolution failed: timed out

I tried this a few times but it kept timing out.

PWD · November 13, 2024, 9:27am

Tried again with the correct command. Told you I'm an idiot!

dig api.met.no @127.0.0.1 -p 5335 ;; communications error to 127.0.0.1#5335: timed out
;; communications error to 127.0.0.1#5335: timed out    ;; communications error to 127.0.0.1#5335: timed out    
; <<>> DiG 9.18.28-1~deb12u2-Debian <<>> api.met.no @127.0.0.1 -p 5335
;; global options: +cmd                                 ;; no servers could be reached