Dnsmasq warning: Insecure DS reply received for _dns.resolver.arpa

firewire · May 6, 2026, 8:40pm

Expected Behaviour:

No Message in Pi-hole diagnosis section

Actual Behaviour:

Debug Token:

Docker compose file:

services:
  unbound:
    image: alpinelinux/unbound:latest
    container_name: unbound_container
    cpu_shares: 100000     # Priozahl zwischen 2 und 262.144; Standard 1024
    restart: unless-stopped
    expose:
      - "5335/tcp"
      - "5335/udp"
    volumes:
      - /home/pi/docker_volumes/unbound:/etc/unbound

  pihole:
    image: pihole/pihole:latest
    container_name: pihole_container
    cpu_shares: 100000     
    restart: unless-stopped

    environment:
      FTLCONF_webserver_api_password: 'werbeblocker'
      TZ: Europe/Berlin
      FTLCONF_dns_revServers: 'true,192.168.188.0/24,192.168.188.1,fritz.box'
      FTLCONF_dns_listeningMode: 'ALL'
      FTLCONF_dns_dnssec: 'true'
      FTLCONF_dns_upstreams: unbound#5335
      FTLCONF_dns_cache_size: '4100' 
    ports:
      - "53:53/tcp"
      - "53:53/udp"
      - "80:80/tcp"
      - "443:443/tcp"
    # Volumes store your data between container upgrades
    volumes:
      - '/home/pi/docker_volumes/pihole/etc-pihole:/etc/pihole'
      - '/home/pi/docker_volumes/pihole/etc-dnsmasq.d:/etc/dnsmasq.d'
    cap_add:
    # See https://github.com/pi-hole/docker-pi-hole#note-on-capabilities
    # Optional, if Pi-hole should get some more processing time
      - SYS_NICE
      - SYS_TIME
    depends_on:
      - unbound

DanSchaper · May 7, 2026, 6:28pm

It's just a warning that the Domain Signature reply was insecure, which is true as resolver.arpa is not signed nor public, it's a service record.

You are using unbound for your upstream so you might have a better time letting unbound handle DNSSEC and not use Pi-hole in DNSSEC mode.

firewire · May 8, 2026, 2:44pm

Thanks for your reply. I am aware that this is merely a warning. However, I do not want to be warned if there is no valid reason for it.
I also understand that _dns.resolver.arpa is not signed. What I do not understand, however, is why a warning is triggered only for this specific address. cnn.com, for example, is also unsigned, yet no warning is issued in that case.
I would like to handle DNSSEC through Pi-hole because it offers a clear and user-friendly interface.

DanSchaper · May 8, 2026, 3:48pm

cnn.com is unsigned and there is no DS record for it. resolver.arpa is unsigned but there is a DS reply being sent, it's just not secure, likely because there is no root certificate to verify against. You'd need to see the unbound logs to find out exactly why there is a reply to the DS record query and how unbound is creating the reply.

deHakkelaar · May 8, 2026, 5:08pm

Whats bugging me is how is FTL able to receive a reply if that domain should instantly return NODATA without forwarding?

github.com/pi-hole/FTL

Add Discovery of Designated Resolvers special zone blocking (#2315)

development ← new/dns_resolver_arpa

opened 12:04PM - 01 Mar 25 UTC

DL6ER

+43 -1

# What does this implement/fix? Add Discovery of Designated Resolvers special… zone blocking to prevent a possible way to bypass Pi-hole depending on the configured upstream. For instance, if you are using Google DNS (`8.8.8.8`) a client locally querying ``` SVCB _dns.resolver.arpa ``` would get the reply ``` _dns.resolver.arpa. 86400 IN SVCB 1 dns.google. alpn="dot" _dns.resolver.arpa. 86400 IN SVCB 2 dns.google. alpn="h2,h3" key7="/dns-query{?dns}" ``` giving them a valid path to try to evade Pi-hole's blocking. This PR adds blocking for the new special zone `resolver.arpa` described in [RFC 9462](https://datatracker.ietf.org/doc/rfc9462/) and provides `NODATA` whenever this is enabled (default on). This behavior is recommended at the end of section 4: > If the recursive resolver that receives this query has no Designated > Resolvers, it SHOULD return NODATA for queries to the "resolver.arpa" > zone, to provide a consistent and accurate signal to clients that it > does not have a Designated Resolver. --- **Related issue or feature (if applicable):** https://discourse.pi-hole.net/t/are-svcb-queries-sent-through-pi-hole-of-blocking-concern/59983 **Pull request in [docs](https://github.com/pi-hole/docs) with documentation (if applicable):** N/A --- **By submitting this pull request, I confirm the following:** 1. I have read and understood the [contributors guide](https://docs.pi-hole.net/guides/github/contributing/), as well as this entire template. I understand which branch to base my commits and Pull Requests against. 2. I have commented my proposed changes within the code. 3. I am willing to help maintain this change if there are issues with it later. 4. It is compatible with the [EUPL 1.2 license](https://opensource.org/licenses/EUPL-1.1) 5. I have squashed any insignificant commits. ([`git rebase`](http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html)) ## Checklist: - [x] The code change is tested and works locally. - [x] I based my code and PRs against the repositories `developmental` branch. - [x] I [signed off](https://docs.pi-hole.net/guides/github/how-to-signoff/) all commits. Pi-hole enforces the [DCO](https://docs.pi-hole.net/guides/github/dco/) for all contributions - [x] I [signed](https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits) all my commits. Pi-hole requires signatures to verify authorship - [x] I have read the above and my PR is ready for review.

$ dig @localhost _dns.resolver.arpa

; <<>> DiG 9.18.33-1~deb12u2-Debian <<>> @localhost _dns.resolver.arpa
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48983
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; EDE: 15 (Blocked): (special)
;; QUESTION SECTION:
;_dns.resolver.arpa.            IN      A

;; Query time: 3 msec
;; SERVER: 127.0.0.1#53(localhost) (UDP)
;; WHEN: Fri May 08 18:59:28 CEST 2026
;; MSG SIZE  rcvd: 60

$ sudo pihole tail
[..]
May  8 18:59:28: query[A] _dns.resolver.arpa from 127.0.0.1
May  8 18:59:28: Designated Resolver domain _dns.resolver.arpa is NODATA

$ dig @localhost _dns.resolver.arpa svcb

; <<>> DiG 9.18.33-1~deb12u2-Debian <<>> @localhost _dns.resolver.arpa svcb
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9856
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; EDE: 15 (Blocked): (special)
;; QUESTION SECTION:
;_dns.resolver.arpa.            IN      SVCB

;; Query time: 3 msec
;; SERVER: 127.0.0.1#53(localhost) (UDP)
;; WHEN: Fri May 08 19:01:34 CEST 2026
;; MSG SIZE  rcvd: 60

$ sudo pihole tail
[..]
May  8 19:01:34: query[SVCB] _dns.resolver.arpa from 127.0.0.1
May  8 19:01:34: Designated Resolver domain _dns.resolver.arpa is NODATA

Am I missing something?

tomporter518 · May 8, 2026, 6:21pm

What's peculiar is that I am serving up a record for that, which digs fine from my Linux hosts with no error in Pi-hole:

; <<>> DiG 9.18.48 <<>> _dns.resolver.arpa SVCB
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45117
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1


;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;_dns.resolver.arpa. IN SVCB

;; ANSWER SECTION:
_dns.resolver.arpa. 0 IN SVCB 1 gyre.home.arpa. alpn="h2,doq,dot" port=443 ipv4hint=10.5.18.2 key7="/dns-query{?dns}"


;; Query time: 3 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Fri May 08 13:55:00 EDT 2026
;; MSG SIZE  rcvd: 126

Same dig from a Macbook, results in a SERVFAIL response and the error message in Pi-hole diagnosis.

Edit: Looking at my query log, it does not appear as though the dig from the Macbook is not observing the request for an SVCB record. It's getting ignored and seems to request an A, which my unbound certainly can't serve up.

DanSchaper · May 8, 2026, 7:13pm

It would be good to see the OP's dig output.

I see deHakkelaar's flags (flags: qr rd ra;) are different than tomporter518 (flags: qr aa rd ra;) with that additional Authoritative Answer making sense considering tom is acting authoritatively for that record/zone.

firewire · May 8, 2026, 9:46pm

A dig query without the Dnsmasq warning entry. Whenever I delete the entry and wait at most a day, it reappears.

 pi@mypi:\~ $ dig @pi.hole \_dns.resolver.arpa

 ; <<>> DiG 9.18.47-1\~deb12u1-Debian <<>> @pi.hole \_dns.resolver.arpa
 ; (1 server found)
 ;; global options: +cmd
 ;; Got answer:
 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43661
 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

 ;; OPT PSEUDOSECTION:
 ; EDNS: version: 0, flags:; udp: 1232
 ; EDE: 15 (Blocked): (special)
 ;; QUESTION SECTION:
 ;\_dns.resolver.arpa.		IN	A

 ;; Query time: 3 msec
 ;; SERVER: 172.19.0.3#53(pi.hole) (UDP)
 ;; WHEN: Fri May 08 23:36:01 CEST 2026
 ;; MSG SIZE  rcvd: 60

 pi@mypi:\~ $ dig @pi.hole \_dns.resolver.arpa svcb

 ; <<>> DiG 9.18.47-1\~deb12u1-Debian <<>> @pi.hole \_dns.resolver.arpa svcb
 ; (1 server found)
 ;; global options: +cmd
 ;; Got answer:
 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5347
 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

 ;; OPT PSEUDOSECTION:
 ; EDNS: version: 0, flags:; udp: 1232
 ; EDE: 15 (Blocked): (special)
 ;; QUESTION SECTION:
 ;\_dns.resolver.arpa.		IN	SVCB

 ;; Query time: 0 msec
 ;; SERVER: 172.19.0.3#53(pi.hole) (UDP)
 ;; WHEN: Fri May 08 23:45:17 CEST 2026
 ;; MSG SIZE  rcvd: 60

DanSchaper · May 9, 2026, 11:47pm

Are your digs for \_dns.resolver.arpa with that leading foreslash, or is that just a copy/paste artifact?

firewire · May 17, 2026, 4:53pm

As suspected, this is a copy-and-paste artifact.

The warning continues to appear every now and then.

DanSchaper · May 17, 2026, 11:52pm

Not sure where you are quoting from, I don't think I said what you are attributing to me.