-
-
Notifications
You must be signed in to change notification settings - Fork 362
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Priming the root key fails when RPZ is enabled in Unbound 1.20.0 or later #1152
Comments
It seems this is not really about trust anchor update, but about priming the root key? Because that is what the error says. But the issue talks about trust anchor update failure, where is that update happening, or was that a terminology mistake? Of course unbound needs a working trust anchor, and for the root that means for all domain names, that are not covered by other trust anchors or domain insecure points. The error says validation of the trust anchor fails, saying it could not fetch the root DNSKEY RRset. And the issue is that this fails when RPZ is enabled. Is RPZ blocking the lookup of the root DNSKEY? That could depend on the contents of the RPZ file. The contents of it with respect to the root DNSKEY lookup, what is that contents? It may be useful to enable verbosity at a level of 4 or 5, and then log to file, and then have unbound start with RPZ enabled, so that it can catch the error with debug output enabled. That could show in the debug logs, where the lookup of the root DNSKEY RRset is failing. Set |
There have been fixes in the unbound 1.20.0 release, and recent releases, for RPZ processing, in particular in the iterator. So it seems likely that the update causes the RPZ zone to be applied at a different point in the code. |
That was a terminological mistake.
After the above is repeated several times, the following log is recorded.
Also, when the unbound service was restarted and the root.key update failed, the following log was recorded.
What settings in the contents of the rpz file would cause this behavior? |
From the first line we see that Unbound is not allowed to resolve and a local-data reply is coming from the RPZ. I believe an entry in the RPZ zone matches and returns a local record to the Do you get a different behavior with the same RPZ file (with the exact same contents) and Unbound 1.19.1? |
Using the same RPZ file (with exactly the same contents), the root key priming was successful up to Unbound 1.19.3. |
Is it possible to share the RPZ file? You can find my email at https://nlnetlabs.nl/people/. |
@gthess |
I believe the problem lies with the TXT record you have at the apex. This means that there are local data for |
You can easily see if you block |
Describe the bug
After updating Unbound from 1.19.1 to 1.20.0, trust anchor auto-update fails.
The first time Unbound starts, it loads the trust anchor and resolves the domain name.
However, when the trust anchor expires after one day, it is not automatically renewed and domain resolution fails.
To reproduce
Steps to reproduce the behavior:
→Trust anchor is loaded.
→It is not automatically renewed and domain resolution fails.
At this time, the contents of the root.key file were also not updated.
Expected behavior
Trust anchor is automatically updated.
System:
Additional information
Execute dig(failure case)
Execute dig(dnnsec)
Error Log
If Unbound is restarted before the trust anchor expires, it will not be able to resolve domain.
The condition for this event to occur was when RPZ was enabled. The update was possible when RPZ was disabled.
In addition to RPZ, the following settings are in place where DNSSEC is concerned.
Also, I have verified that the root.key permissions are set appropriately.
The text was updated successfully, but these errors were encountered: