Unbound: failed to prime trust anchor -- could not fetch DNSKEY rrset . DNSKEY IN

[ray123]

Hi

Suddenly I could not contact pfSense's DNS resolver (unbound) anymore. Restarting pfSense and/or restarting the unbound service did not help.

I then ran clog -f /var/log/resolver.log and could see the following lines repeating over and over again:

Apr  9 14:59:59 firewall unbound: [57899:0] info: generate keytag query _ta-4f66. NULL IN
Apr  9 14:59:59 firewall unbound: [57899:0] info: failed to prime trust anchor -- could not fetch DNSKEY rrset . DNSKEY IN

I then remembered that I had DNSSec support enabled in the DNS resolver. I turned it off and voilà, DNS lookups were again possible.

Of course this should be a temporary solution, since I would like to enable DNSSec support again.
What can I do to solve this issue?

[johnpoz]

Your actually "resolving" - or did you setup dot or forwarding mode in unbound?

[ray123]

Well, that was it I guess. I just realized that forwarding mode was enabled, which, according to the docs (https://docs.netgate.com/pfsense/en/latest/dns/unbound-dns-resolver.html) is recommended to be disabled when using DNSSEC.
Turning off the forwarding mode and enabling DNSSEC seems to reply dns queries again.

I probably would have wished a less cryptic error message and/or disabling the forwarding mode in the UI when DNSSEC was enabled.

Thank you for pointing me in the right direction.

=> Solved

[Gertjan]

@ray123 said in Unbound: failed to prime trust anchor -- could not fetch DNSKEY rrset . DNSKEY IN:

failed to prime trust anchor -- could not fetch DNSKEY rrset

pfSense version ?

Is the pfSense system time and zone ok ??

[johnpoz]

Not sure how pfsense is suppose to make an applications errors easier to read for the user? Unbound is a just a application that pfsense is using and has created a gui to manage it with.. Other than the user having to edit the conf files directly, etc.

Its still the application, and understanding how it works and what it does would be up to the user..

What the user should prob do is not touch shit they are not clear on how or what its doing ;) Out of the box pfsense would resolve and user really has zero to do for fully functional dns with dnssec out of the box.

What should happen is when you switch to forwarder mode - the gui should auto disable dnssec, since its utterly pointless to have those dnssec settings when your forwarding.. It never makes sense to do such a thing.

But keeping the user from shooting themselves is a never ending battle ;) You can put the gun on safe, you can have it locked up in a safe, with a trigger lock even. And the bullets in another safe - and still the user manages to blow off their little toe, which clearly is the guns fault ;) heheheh

[Gertjan]

@johnpoz said in Unbound: failed to prime trust anchor -- could not fetch DNSKEY rrset . DNSKEY IN:

the gui should auto disable dnssec, since its utterly pointless to have those dnssec settings when your forwarding.

Ah !!!
A @johnpoz pull request is coming up ?!!

[johnpoz]

Are you writing one? I have no issues with how everything currently setup.. I don't really care for user proofing to be honest ;) It always a never ending battle that the user will still find a way to shoot themselves - heheh

But sure if your going to try and user proof it, disabling dnssec when forwarding mode is selected would be a good choice..

[ray123]

@Gertjan
pfSense 2.4.5 and time + timezone is correct.

@johnpoz
I mostly agree with what you say. I especially agree that it is up to the user to get informed how the stuff works. If one wants to enable DNSSEC one should clearly disable the forwarding mode. The mistake here is on my side and not on pfSense. I must have enabled forwarding mode by mistake, since that was not my intention at all.

So much to that.

However:
I still believe the wording in the options is improvable. The option to enable DNSSEC mentions the word "support" ("Enable DNSSEC Support" to be precise). It does not mention that enabling that support disables support for regular queries (If that's even correct?) as a fallback when dnssec is unavailable (due to misconfiguration like in my case). Probably it is a translation error on my side, since english isn't my first language and I have a different understanding what "support" means. My understanding was that pfSense/unbound will use DNSSEC if available and not use it when it is not available (due to whatever reasons).
Of course, one can always consult the documentations to read how it works (but even there, it says that it is "recommended" to disable forwarding mode and not that it is mandatory :-)).

But as you said yourself, this is a neverending story and users (like me) always find a way to shoot themselves :-) So, all good on my side.

[johnpoz]

@ray123 said in Unbound: failed to prime trust anchor -- could not fetch DNSKEY rrset . DNSKEY IN:

nabling that support disables support for regular queries (If that's even correct?

No enabling dnssec does not disable normal non dnssec - the vast majority of the internet is not dnssec signed.. Is a sad state of affairs to be honest..

While the % of signed tlds is pretty good.. The percent of total domains is not...

edit: Here is the site I was looking for!!!
https://rick.eng.br/dnssecstat/