Page MenuHomeVyOS Platform
Create Task
Maniphest T9489

powerdns won't resolve both entries from system static-host-mapping and dhcp-server static-mapping
Open, LowPublicBUG
Actions

Description

For a single host with dual IPv4/v6, it get's it's IPv4 address from the vyos dhcp server, and it's IPv6 address from slaac.

show service dhcp-server shared-network-name LAN subnet 192.168.10.0/24 static-mapping myhost
 ip-address 192.168.10.4
 mac xx:xx:xx:xx:xx:xx
show system static-host-mapping host-name myhost.mydomain
 inet yyyy:yyyy:yyyy:10:xxxx:xxxx:xxxx:xxxx

I can then resolve the IPv4 address from the powerdns server, but given vyos doesn't know about it's IPv6 address, I add a manual DNS entry with set system static-host-mapping.
Whilst the IPv6 address does make it into the /etc/hosts file, it still will not resolve with powerdns.
This appears to be because the host entries from the dhcp server and /etc/hosts are not merged into a single line within /run/pdns-recursor/recursor.vyos-hostsd.conf.lua

grep myhost /run/pdns-recursor/recursor.vyos-hostsd.conf.lua
addNTA("myhost.mydomain.", "dhcp-server-192.168.10.4")
addNTA("myhost.mydomain.", "system")

Details

Version
-
Is it a breaking change?
Unspecified (possibly destroys the router)
Issue type
Unspecified (please specify)

Related Objects

Event Timeline

woodsb02 created this task.Mon, Oct 19, 4:28 PM
woodsb02 created this object in space S1 VyOS Public.
pasik subscribed.Mon, Oct 19, 5:17 PM
rherold subscribed.Mon, Oct 19, 8:46 PM

I reproduced this on a VM with rolling (PowerDNS Recursor 4.8.8, pdns-recursor 4.8.8-1+deb12u1) and the cause is in the recursor, not in vyos-hostsd or the addNTA lines. The addNTA lines only set DNSSEC negative trust anchors, they do not take part in resolving names.

Setup: system static-host-mapping host-name myhost.mydomain inet 2001:db8:10::4, plus a DHCP-sourced entry added the way sync-dhcp-lease-to-hosts.py does it (tag dhcp-server-192.168.10.4, myhost.mydomain with 192.168.10.4). /etc/hosts has both lines.

  • system tag first, dhcp-server tag second: only AAAA is answered.
  • dhcp-server tag first, system tag second: only A is answered, as in this report.
  • It does not depend on the tags: two plain lines in /etc/hosts for another name (one IPv4, one IPv6) give only the A record.

So the recursor keeps only the first line per name. In rec-4.8.8 makeNameToIPZone() in reczones-helpers.cc creates a zone per line and addToDomainMap() does not overwrite an already loaded zone ("Will not overwrite already loaded zone"). From rec-4.9.0 on, the function adds the record to the existing zone, so A and AAAA of the same name are
both served. VyOS ships 4.8.8 from Debian 12.

What I see as options: a newer pdns-recursor package (4.9 or later) in the image, or a workaround in vyos-hostsd that does not rely on /etc/hosts for names with more than one address family. Until then the name can only resolve to the address of the first entry. I did not test a newer recursor.

woodsb02 added a comment.Mon, Oct 19, 11:23 PM

Thanks for doing the work to replicate the issue.

I note that Debian 13 trixie ships with pdns-precursor 5.2.13-0+deb13u1
https://packages.debian.org/search?keywords=pdns-recursor&searchon=names&suite=stable&section=all

Also, powerdns maintain upstream repositories for various different Debian releases and pdns-recursor releases. They provide a repo for the stable version 5.4.x of the precursor for Debian 12 bookworm.
http://repo.powerdns.com/

Viacheslav subscribed.Tue, Oct 20, 6:45 AM

I think we are OK to use even pdns-recursor-5.4.6
Be sure that it fixes the issue, and feel free to add a PR with package build, you can find an example of build HAProxy

Viacheslav changed the subtype of this task from "Task" to "Bug".Tue, Oct 20, 6:45 AM
rherold added a comment.Tue, Oct 20, 7:50 AM

@Viacheslaw I will take care. Can you assign it to me?

Viacheslav assigned this task to rherold.Tue, Oct 20, 8:03 AM
rherold added a comment.Tue, Oct 20, 10:26 AM

Summary of what I found, and a question on the direction.

Cause and fix. The recursor in rolling is 4.8.8, which serves only the first /etc/hosts line per name (see my first comment). Upstream fixed it in 4.9.0 (PowerDNS PR 12203, 15 lines in reczones-helpers.cc). With the upstream package pdns-recursor 5.4.7-1pdns.debian12 on a VM, a static host mapping (IPv6) and a DHCP-sourced entry (IPv4) for the same name both resolve.

End of life and security. According to https://docs.powerdns.com/recursor/appendices/EOL.html 4.x and 5.2 are end of life and get no updates at all, 5.3 gets critical updates only, and 5.4 is the supported release train. In bookworm Debian only backported CVE-2024-25590 (4.8.8-1+deb12u1). The Debian security tracker (https://security-tracker.debian.org/tracker/source-package/pdns-recursor) lists 26 open issues for bookworm, CVE-2025-30192 up to CVE-2026-52690, among them two DNSSEC validation bypasses (CVE-2026-52688, CVE-2026-52686), cache poisoning through crafted delegations (CVE-2025-59023, CVE-2025-59024) and spoofed ECS answers (CVE-2025-30192), and DoS by a crafted packet (CVE-2026-52682). Trixie (5.2.13) has all of them fixed except CVE-2026-52684, forky and sid (5.4.6-2) as well. I did not check which of these are reachable with a VyOS configuration, several need the web server, ZoneToCache or RPZ.

Option 1: Debian's 4.8.8 plus the upstream fix. I built Debian's debian/bookworm branch (4.8.8-1+deb12u1, commit c24eb42e) with the upstream commit added as a patch in the vyos-build container. The build dependencies contain no Rust and the build succeeds. On a VM the patched recursor answers A and AAAA for the same name, from the VyOS DHCP and static host mappings and from plain /etc/hosts lines, in both orders, and the VyOS configuration works unchanged. There is no tag for that Debian version, only the branch, so the recipe would have to name the commit. It fixes this bug but leaves the 26 open issues above, so I would only use it as a very short bridge.

Option 2: 5.4.x. The supported branch, but there are two problems:

  • Packaging: Debian's 5.4.6-2 build-depends on 25 librust-*-dev packages that bookworm does not have, and the vyos-build image has no Rust toolchain. A package for bookworm needs a different way to get the crates.
  • Configuration: 5.x refuses the old key=value recursor.conf that VyOS generates ("Old-style settings syntax not supported by default anymore"). --enable-old-settings is only a stopgap, so the configuration has to move to YAML. Debian's NEWS for 5.2.0-4 says the same. In addition /usr/share/pdns-recursor/lua-config/rootkeys.lua (Debian-specific, one line DeadTrustAnchorsFromFile("/usr/share/dns/root.key")) is not shipped any more; the recursor has the root key built in, and dnssec.trustanchorfile can replace the Lua line.

On the VM, 5.4.7 ran with --enable-old-settings and an empty rootkeys.lua, and rec_control show-yaml converts the generated configuration to YAML without errors.

Which direction do the maintainers prefer? My suggestion is 5.4.x as the plan, with the YAML configuration prepared in vyos-1x (rendering YAML for 5.x) and tested
against 5.4.7, and option 1 only if 5.4 takes long. I can prepare the vyos-build PR for option 1 and the vyos-1x PR for the YAML configuration.

I also opened a bug for Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1151376

rherold added a comment.Tue, Oct 20, 11:06 AM

I implemented option one with PR https://github.com/vyos/vyos-build/pull/1329

rherold mentioned this in T9492: DNS forwarding: render the pdns-recursor configuration as YAML (needed for 5.x and Debian trixie).Tue, Oct 20, 11:19 AM
rherold added a subscriber: sarthurdev.Tue, Oct 20, 11:57 AM

Two additions: how serious the open CVEs are, and a simpler way to get to 5.x through T7557.

How serious are the open CVEs? I went through the 26 open entries of the Debian security tracker for bookworm (4.8.8-1+deb12u1) against the PowerDNS advisories. Notes first: the advisories only name 5.x versions, 4.x is end of life and not assessed, so the tracker's "vulnerable" for bookworm is not a code check. I checked only one CVE in the 4.8.8 source: CVE-2025-59030 (TCP NOTIFY) is not in 4.8.8, the bug came with a later refactoring into handleNotify(); in 4.8.8 the checks still return directly.

For the default VyOS configuration (DNSSEC process-no-validate, no webserver, no ZoneToCache, no outgoing ECS) I see five candidates that need no special setting, and I did not check whether 4.8.8 has the bugs:

  • CVE-2025-59023, High 8.2: cache poisoning by crafted delegations
  • CVE-2025-59024, Medium 6.5: cache poisoning by UDP IP fragments
  • CVE-2026-52682, High 7.5: a crafted packet raises memory and CPU use
  • CVE-2026-24027 and CVE-2026-0398, Medium 5.3: crafted zones raise traffic or memory use

One more, CVE-2026-52684, I could not find in the advisories. The other 19 need a feature that is off by default (DNSSEC validation, ZoneToCache, ECS), or one that VyOS does not expose (internal webserver, RPZ, catalog zones, cookies).

None of the advisories mentions remote code execution; the effects are cache poisoning and denial of service, and the advisories say there is no risk of system compromise. With name-server configured VyOS writes +.=<server> to the forward zones, which PowerDNS documents as forwarding with recursion desired to a resolver, without iterating from the root, so I expect the delegation cases (59023, 59024) to matter less there; without a forwarder they apply fully. That is my reading of the documentation, not checked in the advisories or the code. A client in the allowed networks asking for a name of an attacker is enough for the DoS cases. So: no emergency, but the fixes for the high ones will never come for 4.x. The full table is in my notes and I can paste it here.

T7557 (Debian trixie as the build base). Trixie ships pdns-recursor 5.2.13-0+deb13u1. It has the /etc/hosts fix (in all releases since 4.9.0), and the Debian tracker lists 25 of the 26 CVEs as fixed there; only CVE-2026-52684 is open (no DSA). It builds in trixie from Debian's own Rust crates, so there is no package to build in vyos-build and no Rust toolchain problem. 5.2 is end of life upstream, but Debian's security team keeps that package patched.

It does need the same changes in vyos-1x as 5.4: Debian's NEWS for 5.2.0-4 says the configuration must be YAML, and the trixie package no longer ships /usr/share/pdns-recursor/lua-config/rootkeys.lua, which our recursor.conf.lua loads (the root key is built in, dnssec.trustanchorfile can replace it).

Updated suggestion.

  1. Keep https://github.com/vyos/vyos-build/pull/1329 (Debian's 4.8.8 plus the upstream fix) as a bridge until the trixie base lands.
  2. I prepare the YAML configuration for the recursor in vyos-1x and test it against 5.4.7 on a VM. It can only be merged together with the trixie base.
  3. Question to the maintainers and @sarthurdev: is there a rough date for trixie on rolling, and should the YAML configuration be a subtask of T7557?