systemd-resolve hides DS records in explicit queries

[Nicos Gollan]

When querying for DS resource records on a DNSSEC signed domain using dig, the DS records are not shown when the system is using systemd-resolve.

Run: dig +short DS ripe.net

Expected: something like
40991 8 2 D8D3C88263D58930A8B5FE16427130AB84CA73A4988385B2F4B121A7 2E5299A6

Actual result: no output.

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: systemd 237-3ubuntu10.15
ProcVersionSignature: Ubuntu 4.15.0-46.49-generic 4.15.18
Uname: Linux 4.15.0-46-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.6
Architecture: amd64
CurrentDesktop: KDE
Date: Thu Apr 4 14:14:06 2019
MachineType: MSI MS-7A70
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-46-generic root=/dev/mapper/system-slash ro
SourcePackage: systemd
SystemdDelta:
 [EXTENDED] /lib/systemd/system/rc-local.service → /lib/systemd/system/rc-local.service.d/debian.conf
 [EXTENDED] /lib/systemd/system/user@.service → /lib/systemd/system/user@.service.d/timeout.conf

 2 overridden configuration files found.
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 07/03/2018
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: A.80
dmi.board.asset.tag: Default string
dmi.board.name: B250M PRO-VDH (MS-7A70)
dmi.board.vendor: MSI
dmi.board.version: 2.0
dmi.chassis.asset.tag: Default string
dmi.chassis.type: 3
dmi.chassis.vendor: MSI
dmi.chassis.version: 2.0
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrA.80:bd07/03/2018:svnMSI:pnMS-7A70:pvr2.0:rvnMSI:rnB250MPRO-VDH(MS-7A70):rvr2.0:cvnMSI:ct3:cvr2.0:
dmi.product.family: Default string
dmi.product.name: MS-7A70
dmi.product.version: 2.0
dmi.sys.vendor: MSI

[Dominic (triatic)]

Still a problem in 23.10 (mantic). Using resolved's passthrough address 127.0.0.54 results in success.
After it's cached, the default 127.0.0.53 address is happy to return it.

ubuntu@server:~$ dig arin.net ds @127.0.0.53 +short

ubuntu@server:~$ dig arin.net ds @127.0.0.54 +short
50716 8 2 EB708BF25CC3F568B017DA1BFFBD6B31FE4B94B4D89D1C27C1603133 5CE50526

ubuntu@server:~$ dig arin.net ds @127.0.0.53 +short
50716 8 2 EB708BF25CC3F568B017DA1BFFBD6B31FE4B94B4D89D1C27C1603133 5CE50526

[Nick Rosbrook (enr0n)]

It sounds like you don't have DNSSEC=yes anywwhere. I can do the following.
root@mantic:~# resolvectl dnssec
Global: no
Link 41 (eth0): no
root@mantic:~# dig +short DS ripe.net
root@mantic:~# resolvectl dnssec eth0 yes
root@mantic:~# resolvectl dnssec
Global: no
Link 41 (eth0): yes
root@mantic:~# dig +short DS ripe.net
10186 13 2 BC15C85E16FE7C651EAAFCEE3B1F1C956217A5B70A536BFEF38C24A9 AB7B9A3F

[Dominic (triatic)]

DNSSEC isn't required to query a DS record. The reason your query succeeded after you enabled DNSSEC is because systemd-resolved caches it internally as a result of the DNSSEC lookup.

Once the DS query is cached, the bug will not manifest. Another way to cache it is:

ubuntu@server:~$ dig ripe.net ds @127.0.0.53 +short

ubuntu@server:~$ dig ripe.net ds @127.0.0.54 +short
10186 13 2 BC15C85E16FE7C651EAAFCEE3B1F1C956217A5B70A536BFEF38C24A9 AB7B9A3F

ubuntu@server:~$ dig ripe.net ds @127.0.0.53 +short
10186 13 2 BC15C85E16FE7C651EAAFCEE3B1F1C956217A5B70A536BFEF38C24A9 AB7B9A3F