DNSSEC seems broken when using custom forwarding

[damajor]

Hi,

My setup is the following:
unbound <-> hnsd <-> pi-hole <- queries

Sample of unbound.conf used in HNSD:

server:
  trust-anchor-file: "/usr/share/dnssec-root/trusted-key.key"
  harden-dnssec-stripped: yes
  harden-short-bufsize: yes
  harden-below-nxdomain: yes
  harden-referral-path: yes
  hide-version: yes
  prefetch-key: yes
  use-caps-for-id: no
forward-zone:
  name: "COM."
  forward-addr: unbound@xxxx

Using "cloudflare.com" as example.

When Pi-hole validate the DNSSEC answer it tries to resolve cloudflare.com then com then .
Everything is going fine until Pi-hole reaches .

Here is dig answer from Pi-hole querying HNSD:

# dig @x.x.x.x +dnssec . -p xxxx

; <<>> DiG 9.11.5-P4-5.1+deb10u2-Debian <<>> @x.x.x.x +dnssec . -p xxxx
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5348
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;.                              IN      A

;; AUTHORITY SECTION:
.                       84068   IN      NSEC    . NS SOA RRSIG NSEC DNSKEY
.                       8468    IN      RRSIG   NSEC 13 0 86400 20210227010230 20210130010230 60944 . 70/mMGxapZuWAsA80+iWYwrtWTv7O6Y4DRSP5CySZbsIJ11mKR95XaMj c/+GGJHVWx4DxKQXraq7wQiDe/7AcQ==
.                       1268    IN      SOA     . . 2021021301 1800 900 604800 86400
.                       8468    IN      RRSIG   SOA 13 0 86400 20210227010230 20210130010230 60944 . oAwRaQGfb6K7Tcp5M76QsCJaZY7HjOUTFIqrgmjRkD2Qy3QCLJ5LO5KH x+60BFpJhdW+QbpwaPufLZ+DXqNOuA==

;; Query time: 0 msec
;; WHEN: Sat Feb 13 02:41:22 CET 2021
;; MSG SIZE  rcvd: 270

Here is the dig answer from Pi-hole when querying unbound;

# dig @x.x.x.x +dnssec . -p xxxx

; <<>> DiG 9.11.5-P4-5.1+deb10u2-Debian <<>> @x.x.x.x +dnssec . -p xxxx
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45590
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1472
;; QUESTION SECTION:
;.                              IN      A

;; AUTHORITY SECTION:
.                       3600    IN      SOA     a.root-servers.net. nstld.verisign-grs.com. 2021021201 1800 900 604800 86400
.                       86400   IN      RRSIG   SOA 8 0 86400 20210225170000 20210212160000 42351 . kSNTcz4yre3DZ3Vs85f5sKD7ZkwCfak1bqazvRTpWuaYYyKDiJLKwrRO HqNfWFzTpAMMCHdovaLaOVCg6z4XrIMM0/+lSsA88DMwjp+cL+XJlusy Ga83MurWb66fkIErC41cIuU1NJysCfxEozTid+WeuXvkw/WARdWzwHBA Z9oCxoSWWEgbEExMUqKxjff24M0D3422G6jCXEckkdNm7iMXKmBJQFVe o2bhlUy9El76nhAE4WQ91c+biyvQa7ge499eva5a2uGa9Ssl/HISBhZ5 pDIlTgL/oyPHRF5nGAFEqDOZCKjasCv8bHyh+Hp8fluO2sHyzlNEhueC 2e8Iaw==
.                       79300   IN      NSEC    aaa. NS SOA RRSIG NSEC DNSKEY
.                       79300   IN      RRSIG   NSEC 8 0 86400 20210225170000 20210212160000 42351 . PHM3hQ4kOUiscAfg7OBXBpgYQyLf/Waq6F1gSt33sy/n1V+gcgoneaP4 68Rsf0nFna2JH5EXMYfMoCnkIZsMVX21eOioVs5U7pwrjEim1Zuc7gQ3 bFWy80k+kY9PbPYRMxzNC6+fW2oXNsOXPmMxSrQgCcEXi4udX3hYNemg TRCNreEvkArKIVAgFzj8sD4pEmIrgWHVWIs9VZv3U8Gz0c6VJPrFHRcX lqXIZHyODlAW2AqS6B7X0EH0rGl6lVhrb6GVChgpbqSikPR33Hga6wbC OoePXHWh4QQvqGX2WDPEqfIBzA7tl1IgMWlZ1v/nfkIY91Emb7+BLLcH 0clyVA==

;; Query time: 10 msec
;; WHEN: Sat Feb 13 02:41:36 CET 2021
;; MSG SIZE  rcvd: 700

Hope that'll help.

[pinheadmz]

hm... so hnsd's recursive resolver (from libunbound) is forwarding com to your other unbound resolver, but when your recursive goes to check the DNSSEC, it asks hnsd for "." which is not forwarded. hnsd is a root authoritative server that can serve records from the ICANN root zone file (it's hard coded) and it normally signs those records with its own ZSK. Is there any reason why you don't just let hnsd resolve "com" for you?

[damajor]

The fact is I want to keep Pihole as first DNS in the chain for blocking and statistics purposes.

If I do the following unbound <- pihole <- hnsd it is working but I miss all statistics from HNS domains in Pihole.

[pinheadmz]

What are you trying to accomplish by forwarding the com zone? It's already passed pi-hole at this point, why not just let hnsd be the ultimate recursive? Just trying to understand your setup. May be related to #53

[damajor]

In fact I want to dedicate HSND to Handshake domains only.

Ideally I want HSND behind Pihole because Pihole give statistics per client, putting HSND in front of Pihole cause the lose of this feature, and also cause the lose of being able to block Handshake domains.

[pinheadmz]

Ok cool so this is the same issue as #53 and I tried fixing with #62 but its a doozy, I'll have to come back to this. The goal of having an alternate resolver when a name is not found in HNS is harder than it sounds. Handshake tries to act like there's really only one root zone, so splitting it into two roots is not clean.