DNSSEC not validated for private name servers

mfeller2000 commented 7 months ago

Prerequisites

[X] I have checked the Wiki and Discussions and found no answer
[X] I have searched other issues and found no duplicates
[X] I want to report a bug and not ask a question or ask for help
[X] I have set up AdGuard Home correctly and configured clients to use it. (Use the Discussions for help with installing and configuring clients.)

Platform (OS and CPU architecture)

Linux, AMD64 (aka x86_64)

Installation

GitHub releases or script from README

Setup

On one machine

AdGuard Home version

0.107.44

Action

Execute a dig command:

root@jupyter:~# dig @10.0.30.2 jupyter.int.XXXXXX.re +dnssec.

While the IP address 10.0.30.2 is the AdGuardHome DNS server

Expected result

jupyter.int.XXXXXX.re should have the ad (authenticated data) flag set and should show in AdGuardHome that it has been validated.

Actual result

Missing AD (Authenticated Data) flag

root@jupyter:~# dig @10.0.30.2 jupyter.int.XXXXXX.re +dnssec
; <<>> DiG 9.18.18-0ubuntu0.22.04.2-Ubuntu <<>> @10.0.30.2 jupyter.int.XXXXXX.re +dnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53337
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;jupyter.int.XXXXXX.re.         IN      A

;; ANSWER SECTION:
jupyter.int.XXXXXX.re.  581     IN      A       10.0.30.10
jupyter.int.XXXXXX.re.  581     IN      RRSIG   A 14 4 900 20240313173238 20240303163238 54541 int.XXXXXX.re. holhqxWHHYvBETWQUTeQaBmt0YKR2sBCiHi8QEYoFAwT1qAquvchUNAL KNi0Q2Yd7x+V7YO6SY5wAmib7w4gd7NXNGXB1oyKy/YU9U9fvABkFR1o LfcbjGsb/wiFZ475

;; Query time: 4 msec
;; SERVER: 10.0.30.2#53(10.0.30.2) (UDP)
;; WHEN: Mon Mar 04 19:05:23 CET 2024
;; MSG SIZE  rcvd: 207

DNSSEC not validated in AdGuardHome

response

Running delv for jupyter.int.XXXXXX.re works and validates fine:

root@agh01:~# delv jupyter.int.XXXXXX.re +vtrace
;; fetch: jupyter.int.XXXXXX.re/A
;; validating jupyter.int.XXXXXX.re/A: starting
;; validating jupyter.int.XXXXXX.re/A: attempting positive response validation
;; fetch: int.XXXXXX.re/DNSKEY
;; validating int.XXXXXX.re/DNSKEY: starting
;; validating int.XXXXXX.re/DNSKEY: attempting positive response validation
;; fetch: int.XXXXXX.re/DS
;; validating int.XXXXXX.re/DS: starting
;; validating int.XXXXXX.re/DS: attempting positive response validation
;; fetch: XXXXXX.re/DNSKEY
;; validating XXXXXX.re/DNSKEY: starting
;; validating XXXXXX.re/DNSKEY: attempting positive response validation
;; fetch: XXXXXX.re/DS
;; validating XXXXXX.re/DS: starting
;; validating XXXXXX.re/DS: attempting positive response validation
;; fetch: re/DNSKEY
;; validating re/DNSKEY: starting
;; validating re/DNSKEY: attempting positive response validation
;; fetch: re/DS
;; validating re/DS: starting
;; validating re/DS: attempting positive response validation
;; fetch: ./DNSKEY
;; validating ./DNSKEY: starting
;; validating ./DNSKEY: attempting positive response validation
;; validating ./DNSKEY: verify rdataset (keyid=20326): success
;; validating ./DNSKEY: marking as secure (DS)
;; validating re/DS: in fetch_callback_dnskey
;; validating re/DS: keyset with trust secure
;; validating re/DS: resuming validate
;; validating re/DS: verify rdataset (keyid=30903): success
;; validating re/DS: marking as secure, noqname proof not needed
;; validating re/DNSKEY: in fetch_callback_ds
;; validating re/DNSKEY: dsset with trust secure
;; validating re/DNSKEY: verify rdataset (keyid=49754): success
;; validating re/DNSKEY: marking as secure (DS)
;; validating XXXXXX.re/DS: in fetch_callback_dnskey
;; validating XXXXXX.re/DS: keyset with trust secure
;; validating XXXXXX.re/DS: resuming validate
;; validating XXXXXX.re/DS: verify rdataset (keyid=13177): success
;; validating XXXXXX.re/DS: marking as secure, noqname proof not needed
;; validating XXXXXX.re/DNSKEY: in fetch_callback_ds
;; validating XXXXXX.re/DNSKEY: dsset with trust secure
;; validating XXXXXX.re/DNSKEY: verify rdataset (keyid=2371): success
;; validating XXXXXX.re/DNSKEY: marking as secure (DS)
;; validating int.XXXXXX.re/DS: in fetch_callback_dnskey
;; validating int.XXXXXX.re/DS: keyset with trust secure
;; validating int.XXXXXX.re/DS: resuming validate
;; validating int.XXXXXX.re/DS: verify rdataset (keyid=34505): success
;; validating int.XXXXXX.re/DS: marking as secure, noqname proof not needed
;; validating int.XXXXXX.re/DNSKEY: in fetch_callback_ds
;; validating int.XXXXXX.re/DNSKEY: dsset with trust secure
;; validating int.XXXXXX.re/DNSKEY: verify rdataset (keyid=4744): success
;; validating int.XXXXXX.re/DNSKEY: marking as secure (DS)
;; validating jupyter.int.XXXXXX.re/A: in fetch_callback_dnskey
;; validating jupyter.int.XXXXXX.re/A: keyset with trust secure
;; validating jupyter.int.XXXXXX.re/A: resuming validate
;; validating jupyter.int.XXXXXX.re/A: verify rdataset (keyid=54541): success
;; validating jupyter.int.XXXXXX.re/A: marking as secure, noqname proof not needed
; fully validated
jupyter.int.XXXXXX.re.  900     IN      A       10.0.30.10
jupyter.int.XXXXXX.re.  900     IN      RRSIG   A 14 4 900 20240313173238 20240303163238 54541 int.XXXXXX.re. holhqxWHHYvBETWQUTeQaBmt0YKR2sBCiHi8QEYoFAwT1qAquvchUNAL KNi0Q2Yd7x+V7YO6SY5wAmib7w4gd7NXNGXB1oyKy/YU9U9fvABkFR1o LfcbjGsb/wiFZ475

Additional information and/or screenshots

The upstream DNS servers are configured as follows:

tls://1.1.1.1
tls://1.0.0.1
[/int.XXXXXX.re/]10.0.50.2 10.0.50.4

The nameservers 10.0.50.2 and 10.0.50.4 are internally accessible only.

DNSSEC validation is enabled under DNS Settings in AdGuardHome

ainar-g commented 6 months ago

What do you mean by “private” here? This doesn't seem to be about the Private rDNS upstream feature.

What are 10.0.50.2 and 10.0.50.4? AdGuard Home doesn't validate DNSSEC itself, but merely sends the AD flag to the upstream, as documented in the UI.

Do you see incoming queries on these servers and if so, do they have AD flag set?

mfeller2000 commented 6 months ago

By "private" I mean that these DNS servers are only accessible within the network where AdGuard is located. So no outside recursive DNS server can query them. 10.0.50.2 and 10.0.50.4 are the DNS servers for int.XXXXXX.re.

If AdGuard doesn't do the validation itself. I guess this issue can be closed then.

Also as a workaround, I just put a unbound resolver in front of AdGuard, where the unbound takes care of redirecting the int.XXXXXX.re to 10.0.50.2 and 10.0.50.4. In this setup, AdGuard correctly shows that DNSSEC is validated and the AD flag is set.

AdguardTeam / AdGuardHome