Setting trustanchorfile will override trustanchors

[cmouse]

• [x] This is not a support question, I have read about opensource and will send support questions to the IRC channel, GitHub Discussions or the mailing list.

• [x] I have read and understood the 'out in the open' support policy

• Program: Recursor

• Issue type: Bug report

Short description

When trustanchorfile is set in the yaml config file, all trustanchors are ignored.

Environment

• Operating system: Ubuntu 24.04
• Software version: 5.1.3
• Software source: PowerDNS Repository

Steps to reproduce

1. Configure recursor with trustanchorfile and trustanchors
2. Run rec_control get-tas

Expected behaviour

See all configured trust anchors

Actual behaviour

You only see what it is in trustanchorfile

[rgacogne]

I'm not convinced the current behaviour is a bug, but at the very least the documentation is wrong: Reads all DS and DNSKEY records from fname (a BIND zone file) and adds these to the Trust Anchors while we actually replace any existing Trust Anchors.

[cmouse]

From admin point of view this is problematic behaviour, on the other hand you want to be able to use the system shipped trust anchor file, but the anchor file setting only accepts a file. So if you need to add some extra TAs, you either have to modify a system shipped file, you need to have automation that merges the system shipped file with your TAs, or you have to manually convert the system shipped TA into a trustanchor setting.

[omoerbeek]

I was worried this would be a regression introduced by the YAML setting code, but the present behavior (TA's read from file overriding all existing TA's, including root trust anchors) is already present since the introduction of this feature in 4.2.0.

I do follow your reasoning that merging the TA's defined an external file and the settings would be better, but it would introduce a behavior change, so extra care is needed. Anyway, not something for 5.2.0, lets revisit for the next release cycle.

[omoerbeek]

As mentioned on IRC: it does not seem possible to manage (negative) trustanchors using the API. This is especially relevant when DNSSEC validation is active and you want to define forwards.

[omoerbeek]

Another feature request: introduce automatic (if desired) NTA on forwards.

[omoerbeek]

Sketch of plans:

Current behaviour:

• NTA's override TA's (this is not going to change)
• TA file overrides all built-in and configged TA's (this is going to change)
• Runtime changes are always lost on TA file reload (default once per 24h) or restart. This will change as well, see below.

Several sources of TA/NTA's:

1. Built-in.
2. TA file (no NTA's)
3. YAML config (can consist of sections in multiple files, merged by domains, root entries override)
4. Runtime added/cleared

New behavior

Proposal is to build a merged set. Tow parts: config and runtime mods.

Take the built-in TA's. Merge in File, YAML config and runtime additions/removals. Current YAML config adds to existing TA's except for root TA's; those are replaced.

• On restart the merged set is rebuilt, previously runtime mods to TA's are lost.
• If the config files are reloaded or the TA file changes the merged set is rebuilt, and runtime additions/removals are are applied again. This requires that we remember the list of runtime mods separately, but no need to persist on disk.

New stuff:

• add/remove TA/NTA's using REST. Just another source of runtime mods
• add automatic NTA's for forwards (if flag is set) -> so if forwards change, potentially NTA list has to be rebuilt.

Changes compared to current behaviour:

• config is no longer overridden by TA file.
• runtime modifications are no longer lost on config or TA file reload. But consider the scenario:

1. runtime add TA for name X
2. add TA for X in config
3. reload config

After this, the runtime added TA for X is still in effect as we re-apply the runtime changes after the config is re-read. Proposal is to have an explicit "remove runtime override" of name X. Plus rec_control get-tas/get-ntas clearly marks the difference between TA from configs and runtime overrides.

So an TA entry from config can be overridden by add-ta meaning: use this extra TA, clear-TA (do not use TAs from config). An override is removed by clear-ta -override X, making the TA from config effective.