OPNsense Forum
English Forums => Development and Code Review => Topic started by: Maurice on August 11, 2022, 02:23:45 pm
-
Hello devs,
There are currently two ways to configure domain overrides in Unbound: The 'Domain Overrides' tab on the 'Overrides' page (/ui/unbound/overrides/) as well as the dedicated 'Query Forwarding' page (/ui/unbound/forward).
Both create identical 'forward-zone' entries. 'Domain Overrides' adds them to domainoverrides.conf, 'Query Forwarding' adds them to dot.conf.
'Domain Overrides' also adds entries to private_domains.conf: 'domain-insecure' for all zones, 'private-domain' for forward lookup zones, 'local-zone' (typetransparent) for reverse lookup zones. 'Query Forwarding' does none of this, which makes it unsuitable for zones with private addresses and may break DNSSEC validation.
'Query Forwarding' allows specifying a custom port, 'Domain Overrides' doesn't.
I wasn't actively following the development when 'Query Forwarding' was added. Could someone bring me up to speed what the intention behind creating this page was? It seems 'Domain Overrides' is primarily meant for forwarding private zones to internal DNS servers, while 'Query Forwarding' is only suitable for forwarding queries to public DNS servers. Is this assumption correct?
Thanks
Maurice
-
They do 2 different things. Domain overrides tells unbound to locally resolve the domain to whatever you set there. Query forwarding forwards the query to an upstream dns server or internal dns server that can be administered and have record values change by someone else or you without intervention on the unbound side. There could be many reasons for this eg: someone runs an AD install and needs unbound to be able to resolve dynamically created records that appear via DHCP registration internally etc or any number of reasons like that.
-
Domain overrides tells unbound to locally resolve the domain to whatever you set there.
Host overrides do that. Domain overrides specify an upstream DNS server responsible for that domain.
-
Domain overrides tells unbound to locally resolve the domain to whatever you set there.
That's not correct. 'Host Overrides' do that, but 'Domain Overrides' forward the query to the configured server just like 'Query Forwarding' does. I've been using 'Domain Overrides' for years to forward queries for my internal zones to my own authoritative server.
[Edit] @pmhausen was faster. :)
-
I guess you are right, then I dont know. I did notice you can also specify a port on the domain overrides by using <ip>@<port> so you can change the port there also.
-
I did notice you can also specify a port on the domain overrides by using <ip>@<port> so you can change the port there also.
Oh, right, I forgot about this syntax. Thanks for checking. This makes the 'Query Forwarding' page even more mysterious. It omits adding entries to private_domains.conf. Other than that, there seems to be no difference to 'Domain Overrides'.
-
The idea was to allow for manual servers to be configured that are not part of system: settings: general but it may have gone a little overboard with the domain configuration option.
We will discuss this for 23.1 roadmap as there is more work to do on Unbound pages.
Cheers,
Franco
-
Thanks Franco, you are as always, a gentleman, a legend and a force against all chaos in this world.
-
Since the 'Domain Overrides', 'Query Forwarding' and 'DNS over TLS' pages do essentially the same (create 'forward-zone' entries), let me make a proposal for discussion:
Let's get rid of 'Domain Overrides' and 'DNS over TLS' and merge them into 'Query Forwarding'. Add two checkboxes to the edit dialogue:
[ ] Private domain
Disables DNSSEC validation, rebinding prevention and AS112 checks like 'Domain Overrides' currently does.
[ ] DNS over TLS
Enables DoT like 'DNS over TLS' currently does.
Then we would have everything on a single page and could specify (and change!) these settings for individual entries.
Thoughts?
Cheers
Maurice
-
Could be a plan, although a bit sad that work got wasted here having 3 separate components and now merging it back.
For historic context DoT was coming from Unbound-plus plugin so it needed a separate file and the query forward came from a ticket https://github.com/opnsense/core/issues/5138 latching onto previous "forwarder" mode setting which has been in there forever.
Cheers,
Franco
-
Oh, right, I forgot about this syntax. Thanks for checking. This makes the 'Query Forwarding' page even more mysterious. It omits adding entries to private_domains.conf. Other than that, there seems to be no difference to 'Domain Overrides'.
The only other difference is that you're able to omit a domain in Query Forwarding, allowing you to forward all requests to custom servers - which, granted, is basically the same functionality as using the system nameservers. Also: API support :)
My opinion is that 'Query Forwarding', its help sections and accompanying documentation is a lot clearer than a 'Domain Overrides', as it doesn't really have anything to do with overriding as interpreted in host overrides.
Since the 'Domain Overrides', 'Query Forwarding' and 'DNS over TLS' pages do essentially the same (create 'forward-zone' entries), let me make a proposal for discussion:
Let's get rid of 'Domain Overrides' and 'DNS over TLS' and merge them into 'Query Forwarding'. Add two checkboxes to the edit dialogue:
[ ] Private domain
Disables DNSSEC validation, rebinding prevention and AS112 checks like 'Domain Overrides' currently does.
[ ] DNS over TLS
Enables DoT like 'DNS over TLS' currently does.
Then we would have everything on a single page and could specify (and change!) these settings for individual entries.
Thoughts?
Cheers
Maurice
I like this approach.
Cheers,
Stephan
-
The only other difference is that you're able to omit a domain in Query Forwarding, allowing you to forward all requests to custom servers
Oh, right. I assumed (I know, big mistake) you can also do this with 'Domain Overrides' by using the "." domain, but apparently you can't. #5138 could probably have been solved by allowing "." and adding an option to omit private_domains.conf entries, but hindsight is 20/20.
which, granted, is basically the same functionality as using the system nameservers.
Not exactly. As mentioned in #5138, you might want Unbound to forward all queries to servers which are different from the system nameservers. I do get that point.
Also: API support :)
Another good reason to retire 'Domain Overrides'. :) Of course the code which (optionally) adds entries to private_domains.conf could be reused.
My opinion is that 'Query Forwarding', its help sections and accompanying documentation is a lot clearer than a 'Domain Overrides', as it doesn't really have anything to do with overriding as interpreted in host overrides.
Agreed.
Cheers
Maurice
-
Not exactly. As mentioned in #5138, you might want Unbound to forward all queries to servers which are different from the system nameservers. I do get that point.
Which is my confusion about domain setting in there. Obviously we could have omitted that but taking it away now isn't a good idea.
We talked about this issue in today's core meeting about 23.1 roadmap and at this point we see there were valid reasons and historic context which led to the situation and for now our duty is to document and explain this properly.
We will be working quite a bit on Unbound for 23.1 but don't want to change established behaviour before having added higher value targets. I know I'm teasing but for now a POC needs to be made to verify the plan(s) here before more can be shared.
Cheers,
Franco
-
I'll just add here that -- as a user who doesn't fully grasp the DNS nitty gritties without reading 5-7 articles before fixing the DNS related issues that I have AND then promptly forgetting within a day or so -- it is definitely confusing to have 3 different places that can do similar things. Sometimes, users like me read something on the web, and put those settings in which might turn out to be in conflict with previous settings we might have done on the different pages and it's hard to relate those unless you know what's going on.
I would definitely recommend reducing the footprint of doing stuff to a single page and would also like to ask if there is further progress on this issue since it was last discussed?
-
Domain Overrides are now considered deprecated, you should only use Query Forwarding / DNS over TLS for new setups. That's actually documented, but I agree that a hint in the UI wouldn't hurt. Changing the name to "Domain Overrides (legacy)" might be sufficient. Thoughts?
Cheers
Maurice
-
Domain Overrides are now considered deprecated, you should only use Query Forwarding / DNS over TLS for new setups. That's actually documented, but I agree that a hint in the UI wouldn't hurt. Changing the name to "Domain Overrides (legacy)" might be sufficient. Thoughts?
Cheers
Maurice
I think it is always a good idea to imagine your future self at 3AM, tired and maybe a bit drunk and some years down the line, trying to figure out what the config is trying to achieve - write help that would be so obvious to you in that state it would be entirely self evident...or maybe just assume the person reading it is a complete novice.
That is: to someone who has never designed, or even configured, a DNS system and who ONLY knows that DNS maps names to addresses (and knows nothing else) - what does "Domain Override" mean to that person?
-
That term was invented probably a over a decade ago by the poor soul working on the first Unbound GUI integration back when it wasn't even cool. ;)
Cheers,
Franco
-
I strongly recommend sobriety when working on critical infrastructure. ;)
Does the UI and documentation leave room for improvements? Sure. But should it replace "My first illustrated book on basic networking concepts for novices"? Definitely not. Keep in mind that this is not primarily a consumer product and the target audience are mostly professionals.
-
I strongly recommend sobriety when working on critical infrastructure. ;)
Does the UI and documentation leave room for improvements? Sure. But should it replace "My first illustrated book on basic networking concepts for novices"? Definitely not. Keep in mind that this is not primarily a consumer product and the target audience are mostly professionals.
:D
Haha, yes, I agree sobriety should be a requirement at all times on the job...but...you know as well as I there are always exceptions to every rule ;)
Even professionals in one discipline can be novices in another related discipline. I am amazed at how many network engineers AND software engineers do not know DNS very well, at least not well enough to build a DNS server if they had to. I am of the opinion that terminology should always be as obvious to the uninitiated as possible, whatever the field.