auth: poor handling of absent signers for present keys

[Habbie]

• 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.
• I have read and understood the 'out in the open' support policy
• I have read and understood the PowerDNS AI policy

• Program: Authoritative
• Issue type: Bug report

Short description

When I have DNSSEC keys for an algorithm not supported in my current build, "almost nothing works".

Environment

• Operating system: Debian 13
• Software version: master (114b76c)
• Software source: git

Steps to reproduce

1. import/generate a dnssec key with some algorithm (I used 253, probably from my sillysigners branch)
2. build a pdnsutil/pdns_server without the algo (it might be easier to add an MLDSA key and then build without, than the steps I did by accident)
3. try pdnsutil zone show, pdnsutil zone edit, or dig +dnssec against pdns_server for your zone

Expected behaviour

Some graceful degradation.

Actual behaviour

$ EDITOR=true ppdnsutil --config-dir=. --config-name=lmdb zone edit example.com
Error: Request to create key object for unknown algorithm number 253

$ ppdnsutil --config-dir=. --config-name=lmdb zone show example.comThis is a Master zone
Last SOA serial number we notified: 2025042701 == 2025042701 (serial in the database)
Error: Request to create key object for unknown algorithm number 253

and for dig +dnssec against pdns_server:

Aug 27 20:47:56 Exception building answer packet for example.com/SOA (Request to create key object for unknown algorithm number 253) sending out servfail

Other information

The pdnsutil failure is because dk.isSecuredZone calls getKeys (which seems wasteful but, due to caching, is fine in pdns_server), which attempts to construct all keys for the zone. Making dk.isSecuredZone more robust is easy, I bet, but I also bet we'll find even more failure modes if we dig.

I did not investigate the failure in pdns_server at all.