-
Notifications
You must be signed in to change notification settings - Fork 757
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
Unbound host overrides breaks when adding a wildcard entry #8051
Comments
I have just recently experienced the same issue. I cannot pinpoint when it started, however, as I have backup DNS that my system reverted to without me knowing. The outcome (Unbound shutting down) is the same if one were to use a different IP address in step #3 listed above. |
most likely cause is an overlapping entry (e.g. *.my.org and host.my.org assigned), these are difficult to detect upfront and if I remember correctly will break startup. |
Isn't "*" the reason why domain overrides exist? |
Confirmed, I just tested, and this seems to be the pre-requisite for this issue. I updated the reproducing steps. |
I dislike being on an island when it comes to error reporting. In almost every case it means I'm doing something wrong and/or stupid. My wildcard entry on Host Domains is the only entry on my list; no overlapping entries. I just have the one wildcard entry directed to my reverse proxy for keep-it-inside-LAN DNS overrides. (I think this is one application of this Opnsense functionality, yes?) As soon as I hit apply, it thinks for a bit and then Unbound turns off. When I disable it Unbound immediately turns back on. |
check the logs?? |
Important notices
Before you add a new report, we ask you kindly to acknowledge the following:
Describe the bug
Adding a DNS entry named * (wildcard) on a domain with an existing host override will be allowed by UI but will break Unbound initialization, thus making it immediately offline after applying the change.
According to the manual, wildcards should be accepted as host names for host overrides.
To Reproduce
Steps to reproduce the behavior:
drill @routerip abc.opnsense.com
to see that it returns an entry to 127.0.0.1Expected behavior
Unbound should stay up, and a subsequent
drill xyz.opnsense.com
should return an entry to '127.0.0.1'.Environment
I don't think it's relevant.
The text was updated successfully, but these errors were encountered: