BOGUS (NSEC(3) missing) since Fritzbox update

Help Community Help
1

Yesterday I updated my Fritzbox to FRITZ!OS:7.56 - since then I can't reach any websites via pihole.
In pihole I get a "BOGUS (NSEC(3) missing)" error in the QueryLog for every request.
Before the update everything worked fine.
Neither restarting the Fritzbox nor restarting the Pihole (Proxmox-LXC) nor the Proxmox server helped.

I have checked all IP addresses - they are entered correctly as described here:
https://docs.pi-hole.net/routers/fritzbox-de/
after "Distribute Pi-hole as DNS server via DHCP to clients (LAN side)".
Both IPv4 and IPv6

Also I tried to activate only IPv4 or only IPv6 on the computer -> no difference
The connection to the Pihole seems to be OK.
In the Pihole itself only the IPv4 of the Fritzbox is entered as upstream (no IPv6).

I do not know what else to test.
Currently I have entered as Local DNS server in the Fritzbox again the FB itself and thus levered out the Pihole, so that we can surf again for now.

Does anyone have an idea what is going wrong here?

2

another try:
when I put "8.8.8.8" in the pihole-upstream and use pihole as DNS for my computer - everything is working.
So the error must definitely be in the connection from Fritzbox to pihole

normal setup:
PC -> pihole -> Fritzbox as DNS-upstream -> Internet
~ERROR~

test-setup:
PC -> pihole -> google-DNS-upstream -> Internet
~WORKS~

PC -> Fritzbox-DNS -> Internet
~WORKS~

I have no idea what's wrong :frowning:

Edit:
Disabling "Use DNSSEC" also works...but why?
Is FRITZ!OS:7.56 buggy? - but why there are not thousends of requests at the moment?

3

I can confirm this is happening with my router running FritzOS 7.56 when using the FritzBox as Pi-hole's only upstream and DNSSEC validation enabled.
I can't make any statements whether this worked with previous versions, though, as I am usually using unbound as Pi-hole's upstream.

$ dig heise.de

; <<>> DiG 9.11.5-P4-5.1+deb10u8-Raspbian <<>> heise.de
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 43661
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; OPT=15: 00 0c ("..")
;; QUESTION SECTION:
;heise.de.                      IN      A

;; Query time: 6 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Jul 06 09:09:11 CEST 2023
;; MSG SIZE  rcvd: 43

EDE response code 0c (or 12 decimal) translates to NSEC(3) missing .

Using BIND9's delv to verify DNSSEC validation via the Fritzbox at 192.168.178.1 reveals the reason for that:

 $ delv heise.de @192.168.178.1
;; DNS format error from 192.168.178.1#53 resolving de/DS: unrelated SOA fritz.box in de authority section
;; DNS format error from 192.168.178.1#53 resolving box/DS: unrelated SOA fritz.box in box authority section
;; no valid RRSIG resolving 'box/DS/IN': 192.168.178.1#53
;; no valid RRSIG resolving 'de/DS/IN': 192.168.178.1#53
;; no valid DS resolving 'heise.de/A/IN': 192.168.178.1#53
;; resolution failed: no valid DS

Obviously, the FritzBox is wrongly inserting its own SOA information into DNSSEC replies, causing DNSSEC validation to fail.

To verify, a public upstream would return:

$ delv heise.de @9.9.9.9
; unsigned answer
heise.de.               3200171710 IN   A       193.99.144.80

This has to be fixed by Fritzbox manufacturer AVM.

You should try to reproduce similar output on your installation and file a support request with that information at FRITZ!Box Supportanfrage | AVM Deutschland.

In the meantime, you could switch to a public DNS resolver with DNSSEC support as Pi-hole's upstream in combination with Conditional Forwarding to your FB enabled in Pi-hole. Note that DNSSEC validation is skipped for CF.

Alternatively, you could consider to disable DNSSEC validation in Pi-hole, but that would obviously mean that you would not know whether your DNS replies are authentic and can be trusted.

1 Like
4

Thanks for your answer and the confirmation-test.

I guess I'll contact Fritz!/AVM support and get them to fix their stuff :slight_smile:
Until then I just use another upstream in Pihole

5

Did you already get a response from AVM? I also updated my 7590 AX to 7.56 yesterday and I am having the same problem now. Would be interesting to know if they have a rough idea when they wanna fix it.

6

To be honest:
I first selected the 4 Cloudflare DNS in Pihole and had to find out that they are significantly faster than what Telekom assigns me, so I didn't even write to AVM anymore.
Shame on me.

7

Could be worth if any or all of you would file a support request with AVM.
The higher the number of reports, the better the chances they can reproduce and acknowledge this as an issue, and in turn the likelihood of a fix.

8

Hello, I've just sent them a support request. Will keep you posted!

2 Likes
9

I just received the standard support reply from AVM - Fritzbox, they need proof that this happens as so far no one complaint apparently. I just replied and I gave them the link to this forum. It looks like they totally neglected the output of the commands I pasted initially and that the issue is related to DNSSEC on Fritzbox with firmware 7.56

I had 7.55 installed on my 7590 and it worked fine with DNSSEC enable in pihole, as soon as I updated it, I could not access any webpage. I disable DNSSEC as a workaround for the time being, but I have low hope that they will understand what is going on...

10

OK, it looks this is now arranged and a fix will be out!

I got a reply:

Yes you are right, I just had found some time to discuss this DNSSEC validation issue with our experts who had then actually confirmed that we indeed are already investigating the situation that only occurs when using a local DNS server in the home network.

I have been told that we will fix this problem with a forthcoming FRITZ!OS update.

Until the update is released and as a workaround, you can either enter public DNS servers or deactivate DNSSEC in the local DNS server in the affected devices.

4 Likes
11

AVM's analysis is incorrect in that regard - the observation isn't tied to a local DNS server.

Any client OS resolver or any software package that is validating DNSSEC will run into that issue if the Fritzbox is used for DNS (as already demonstrated by using delv <somedomain> <fritz.box.ip> ).

Anyway, it's good to know they are working on a fix.

Thank you for filing that report and sharing AVM's reply. :slight_smile:

12

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.