Adding capabilities for views

[Apachez-]

Is there a way today to serve different zones (well content) based on the srcip of the DNS-client?

For example when 192.0.2.1 asks about www.example.com they will get one answer while if 192.0.2.2 asks the same DNS-query they will get a different result?

If not then I would like to file this as a feature request.

With views you define an ACL regarding which srcip will see the content of which view.

Preferly there should be a default view which if not matching any ACL this is where the query ends up at.

The workaround today is to use different technitium/dns-server installations.

Example:

Understanding views in BIND 9, with examples
https://kb.isc.org/docs/aa-00851

Views are also not only about which zones are presented to which client but will include the caching/recursive lookups and blocklists aswell.

This way you can use the same installation to serve both lab, staging and prod (perhaps not advisable but still) where for example you might have recursive for lab and staging but not prod and perhaps one set of blocklists for lab and another set for staging.

You can today add ACL for caching and blocklist but it will still be a single cache and blocklist being used.

To make life easier a single zone should be able to be tagged for 1 or more views.

Things to resolve:

1. Perhaps add a new tab for "Views" (between "Dashboard" and "Zones"?) where you define custom views except for "Default" that will always exist. Here you will also define the ACLs.

Things to figure out is if the ACL's should be top down or longest prefix match and if so how to deal if two views have the same ACL (lets say both have 192.0.2.0/24 as ACL)?

2. The webgui part of Zones. Perhaps add another column (in the list of "Zones") to show which views a particular zone belongs to. This includes to be able to have example.com as two (or more) different zones which belongs to different views.

3. How to deal with zonetransfers - how will the recepient know which zone belongs to which view?

4. Add view-capaiblities to cache, allowed and blocked. Along with if shared cache, blocklist or allowlist should be used or not (configurable).

5. Something else I forgot about which adding view-capabilities would need to alter/change?

[Hemsby]

If you want different responses based on the source ip of the client you can use the Split Horizon App

[Apachez-]

Where can I find some docs and screenshots and manual for that app?

Googling on it looks overcomplicated by adding some APP records and copy paste a JSON to each of them etc.

I would still prefer native support of views.

[ShreyasZare]

Thanks for the post. This requirement is solved using the Split Horizon app. It is quite simple to use and you should attempt to do that in an example zone once to get to know it.

To use it, you need to have the Split Horizon app installed in the Apps section. You can then add APP record and select the Split Horizon app and a relevant class path. There is a small default json config template that will up which you need to edit. The json allows you to map a network/IP address/custom-network-group to one or more IP addresses (or CNAME if you use the other class path).

The app's main config in the Apps section allows you to define custom network names so that you can use the custom name directly in multiple APP records. The other part of the config is for the address translation feature which may not be useful for your scenario and you can ignore it.

Let me know if you have any queries on this. Do give it a try, its quite simple once you try it and get to know.

[Apachez-]

Even if the APP/JSON + Split Horizon app is handy for small deployments where you need this for just a handful of records thats simply not an option for me.

Current workaround is to run multiple technitium/dns-server which would be resolved once view capabilities are added.

Using views would also be compatible when the other DNS-servers isnt necessary technitium-based.

[Hemsby]

Its much easier to configure than the Microsoft DNS Policies! Even when you have those working, they don't show in the GUI and you have to interrogate using PowerShell. I'm using the Split Horizon App, and once configured it literally takes seconds to add APP records for the records you want split. I agree with Shreyas, explore it first before responding with "well it does not suit me".

For common scenarios I have even scripted it, but i also use my Android App, as its form based and not JSON. Im currently updating my other TDNS-AdvAppConfig WebApp to be able to do this via a GUI. Currently it only supports the Advanced Blocking App, but within the next few days will cover all APP Store apps to remove the JSON aspect and make it easier to configure.

[Apachez-]

Well I did and I prefer to have it per view similar to how bind does this.

Having it as APP-records is a nice complement for a few entries but again I prefer to do this on zone level.

Current workaround is to have multiple technitium/dns-server to solve this issue and if/when proper zones are added it would become less admin-work since for these usecases there are no IT-SEC related reasons to use dedicated servers.

[Hemsby]

You've now shifted from "not an option for me" to "I prefer it similar to how BIND does it" to "no IT-SEC related reasons to use dedicated servers" across three replies in this thread alone. Split Horizon does what you're describing, at zone/APP-record granularity, and both Shreyas and I told you to actually try it before writing it off. If per-zone view tagging is genuinely still a gap for your use case after trying it, say specifically what it can't do rather than restating "I'd prefer BIND's approach."

Also worth noting: you've opened 12 issues on this repo and contributed 0 PRs. Filing feature requests is fine, but if you want a specific architecture built the way you're describing, a PR carries a lot more weight than a design spec in a comment thread.

[Hemsby]

One more thing worth flagging given the pattern here: your last big ask (#1989, interface/VRF-aware UDP binding) shipped in 15.3 as dynamic per-IP socket binding, and it broke UDP DNS resolution for several unrelated users — #2028 (Docker/macvlan, cross-subnet), #2035 (WireGuard/VPN clients, traced directly to SO_BINDTODEVICE on the dynamically-bound sockets), and #2023 (crashed outright on macOS, needed its own fix). It took a second patch in 15.4 to stabilize, and even now you've had to reopen it yourself as #2039 because it's still not fully working for your own original case.

That's the actual cost of building a "views" feature to your spec: it's a large architectural change (ACLs, per-view cache/blocklist isolation, zone transfer semantics you flagged yourself in point 3) requested by someone with a track record of the last major ask destabilizing DNS resolution for other users across two releases. That's a reason to be a lot more conservative about scope here, not less.

For context on the broader track record: of your 12 issues on this repo, only 2 have ever been closed. One (#1992, Dockerfile permissions) was declined outright and nothing was merged. The other is #1989 above, the one that shipped and broke resolution for other users. So the actual record is zero cleanly-implemented requests, one rejected, and one that caused a two-release regression. Worth keeping in mind before signing up for a change of this size on your say-so.

[Apachez-]

If you actually read #1989 (I doubt that you have) it wasnt my suggestion to try to "autodetect" egressing interface.

I suggested to have the feature being manually configured as with what version 15.4 eventually became.

You could also blame those who upgraded without first keeping a backup to revert back to in case there are regressions found?

And regressions are to be found - just read the changelog from the past few years. Its not all about adding new features who works flawlessly on the first attempt but also fixing what others have reported being broken or needs improvement.

So Im finding it hard to understand why you would blame on a customer asking for a feature request rather than the developer who made a bad choice of implementation (autodetect instead of manually configured) or didnt have enough of testing before releasing a new feature? Or for that matter first release a new version as a beta-release to be tested to detect any cornercases before it reaches a greater public?

We can also in the same timeperiod see issues regarding DNSSEC - does this mean that DNSSEC should be removed? Of course not but again dont blame it on the messenger?

When I file a feature request towards an open source project I dont expect it to be fixed right away (something you can expect if you got an "enterprise support contract") but a way to improve the product not only for myself but also for others.

That is the example of the information I filed regarding updated dockerfile. I dont care that it wasnt accepted - hopefully it will help next person sitting in the same situation as myself where you need to compile some custom change to technitium/dns-server but you simply dont have or dont want to have a complete Microsoft based build environment. The findings I did to create the custom workaround dockerfile might help others in future and thats why I choosed to share my findings publically - sharing is caring :-)

I understand that adding views wouldnt be a quickfix which I also posted at the bottom of my initial post in this thread (I am sure you can see the 5 bullet points at the end of that post?).

But when I started to invest my time in using technitium/dns-server the issues (bugs) and feature requests I have found is the way for me to contribute back to the project by reporting bugs detected and improvements to make the product even greater.

And quite frankly none of the bug reports or feature requests I have posted so far are that exotic.

[Hemsby]

On #1989: fair correction - you proposed moving from autodetect to manual per-interface binding (the %eth1:53 syntax), which is what shipped in 15.4. The autodetect approach in 15.3 was the implementation choice, not your ask. Retracting that part.

The track record point stands independent of that detail though: 12 issues filed, 2 closed - one declined outright (#1992), one that needed a second release to stabilize and is still reopened as #2039 - and 0 PRs. That's not a moral judgment, it's a reason to be conservative about signing up for a large architectural change (ACLs, per-view cache/blocklist isolation, zone transfer semantics you flagged yourself) on spec alone.

You still haven't answered the actual question: what specifically can Split Horizon's network/APP-record matching not express for your setup? Not "I prefer BIND's model," not "no IT-SEC reason for dedicated servers" - an actual case it can't handle. That's the only thing that moves this forward.

[Apachez-]

Im not too worried about your "stats" regarding issues filed.

First one was filed less than/about 3 weeks ago during a time when many are on vacation (and still are). There are currently about 126 still open issues in this project with the oldest being more than 6 years old (#133)... so no, Im not that worried or "offended" that bug reports and/or feature requests that I have created in this project isnt fixed within 3 weeks.

But for whatever reason that seems to consider you?

There will most likely never be any PR's from me in this project simply because Im not a dotnet developer (which again if you had read #1989 you would have seen that I typed that multiple times) so I leave the actual coding for the maintainer who seems to know what he is doing.

And speaking of PR's there are currently 9 of them pending in this project with the oldest being more than 6 months old (#1680).

I already answered why it isnt an option for me to manually add APP-records along with a JSON for the "ACL" for each and every record I want to be able to deliver through views.

If I would add a single entry as "split horizon" I would probably just use the app and call it a day. Another workaround (already mentioned several times in this thread) is to have multiple technitium/dns-server instances running.

But by adding views as a capability you would get the "split horizon" on zone level along with cache/recursor and allow/blocklists (who currently are global per technitium/dns-server instance) without having to run multiple technitium/dns-server instances. Views would also be compatible with doing zonetransfers to other DNS-software where I doubt APP-records with a JSON blob really are.

I have been doing DNS since the late 1990's (short after Bind8 was released) and IMHO technitium/dns-server since its now matured and shown to be "battleproofed" is the most exiting thing in the DNS world since the past +20 years (the others were basically PowerDNS (1999-2002 depending on what you count as startdate) and Unbound (about 2007 as startdate) but they are more or less same same but different while technitium/dns-server is a completely different solution).

Again my contribution to this project is my time and then to file bug reports and feature requests when I find them warranted.

[Hemsby]

Retracting "offers nothing in return" - the VRF patch in #1989, the Dockerfile writeup, and the DNAT workaround in #2035 are real contributions, even without a formal PR.

Still don't think a concrete case for where Split Horizon's record-level matching falls short has been given, just an architecture preference. Either way, let's leave it to Shreyas to decide if this is worth the scope and risk.

[ShreyasZare]

It looks like the discussion is getting heated for no reason. I would request you guys to let this go.

I personally have no problems with anyone creating multiple issues so do not want to discourage anyone. All issues and discussion helps shape the project in some way or other. Some times a feature request may not be feasible so I will say so. If something is feasible and not big enough of change then I try to get it added sooner. Anything that requires more time gets delayed for any amount of time.

I also do not wish to blame anyone for issues that come up with any release. Such things happen even with large companies with huge teams that include exclusive team for testing. So, a few things can get amiss with such a small project. I fact, the anycast scenario didn't come across by mind for some reason when thinking about the option for binding to interface.

Regarding the views feature request, I am not sure at the moment about it as I have only rough idea about BIND views and have no experience using it. So, will need to study this to see how feasible it is. It would take some time for sure since I do not want to delay the DHCP major refactoring (which includes DHCPv6 and clustered scopes) that is planned since a lot of people are waiting or it for a long time.