Hi,
it would be great to have an authoritative name server as plugin in opnsense to be able to manage zones comprehensively. Unbound's local-data is great, but limited and hard to scale up.
Although NSD would nicely align with Unbound (config, terminology), AFAIK it does not support dynamic DHCP updates. PowerDNS would be a great alternative and is already in ports.
Maybe someone is able and willing to implement this?
@tokred might be hard as a good implementation may depend on other plugins as well which do not exist (for example PostgreSQL) at the moment.
That's a valid concern. Maybe it would be feasible to skip database backends altogether and use only Bind file backend to cut dependencies? It would be hard to satisfy all backend expectations anyway.
Best regards
The problem is that this would also loose the big advantage of pdns over bind...
Bringing this up again, some kind of DNS implementation would be aweseome! I personally think BIND would do the job, one could have a look at the pfSense package to get this quickly to work. After all, there should be a fully packed authoritative DNS server in OPNsense to complete the whole package :)
I'd also love to see an authoritative DNS server on OPNsense, like PowerDNS, NSD, Knot DNS, MaraDNS or... BIND ;)
So per a reddit thread, I'm going to post on this issue.
I'd love to see Bind added to opnSense. Here's the list of functionality I use / able to configure in pfSense. I'll divide it out per "screens" or tabs that would be nice to mirror from pfSense to opnSense.
Settings
ACLs
Views
Zones
Domain Zone Configuration
DNSSEC
Slave Zone Configuration
Forward Zone Configuration
Master Zone Configuration
Import Zone Records
So yeah, those are what I currently use. I have multiple subnets across different VLan interfaces, and some subnets are grouped to have the same DNS zone/view while others get their own DNS zone/view. Example is my Guest Wifi network. It gets a few DNS entries such as the default router, ntp server, and a few other things, while the DMZ lan gets a zone file that contains the same as above but all the other servers in this subnet.
Anyways, I am planning on trying to do some of this myself, when I have time to learn the plugin system, but if anyone wants to help tackle this I'd love it. It's the only thing stopping me from switching from pfSense to opnSense, that is from a month ago when I was looking to swap..
I can provide screenshots etc for example layouts from pfSense if needed etc.
Thank you for this comprehensive list. I concur that a Bind plugin would be the best way forward at this point. I heard @mimugmail is interested too. I will gladly offer review and help in tests and code bits missing in the core if necessary.
@fichtner Great, yeah @mimugmail had said he talked with you in one of the Reddit post that I linked to in my earlier comment.
I'm roughly a beginner to intermediate level programmer of several languages, with a heavy lean towards beginner since I rarely have a chance to keep those skills sharp. I've gone through the Hello World example some time back but certain things never lined up 100% for me, so I just put things away and decided I'd come back at some point in time. I'll see about doing that sooner than later, now that there are other people interested.
Ok, I walked through the list, all sane, but we don't use custom boxes with newer plugins.
It's better to just integrate the features the ppl are using. More work for us, less error prone for all :)
I'll start with a general setup and when it comes to xml / templating @fboyd can start his journey in opnsense programming :)
do you need a dev branch? dont forget about dnssec btw.
@mimugmail I've removed the "custom boxes" from my above comment. I totally understand and follow. I am thinking in addition to all this, maybe another tab that has an import function. For example, just importing the individual records from maybe a CSV file. Would definitely come in handy for people that don't want to retype all of their zone info. Also added this tidbit to my above "requirements"
@fabianfrz I personally don't have DNSSEC enabled for my needs, but you have a good point. I've added it to my previous comment in line with how pfSense has it listed.
As for branch, where I come from, I'd say yes to that. Here I have no idea :-P LoL
@mimugmail @fboyd I created a feature branch for you:
https://github.com/opnsense/plugins/tree/bind
If you select this one as your base, you can work together without touching master and using complex git repository networks. Keep in mind that you still need pull requests.
Is BIND really the most security-oriented choice for OPNsense...? :/
It's just a plugin and wont come with default install. I think this is perfectly fine and only a feature enhancement. And since this is new code there's also a chance to build some PI hole functionality in it
Is BIND really the most security-oriented choice for OPNsense...? :/
The answer is obviously no, but people have asked for a package ever since 2015 which we have optionally provided and they keep using it so that tells you something about its overall operational value in today's networking world.
Also note that we removed the bind dependency from the core repository when we moved RCF 2136 to the plugins and the dependency is definitely not coming back.
FWIW, we offer timely updates and a vulnerability scanner so everybody can do the risk assessment and sensible administration on their own terms.
Just started with basic folder structure and saw that only 9.13 is available but with 9.13 ISC started to use odd number as dev versions.
Perhaps this plugin will takes so long that we start when 9.14 is out but we should only add version with even numbering scheme in future :)
We can switch back to 9.12 then. I did not anticipate such an archaic numbering scheme...
Me too, I was informed by the release notes that it's unstable :)
Settings
[x] Forwarder Configuration (semi colon separated list of DNS servers to forward request to if we don't know)
[x] ACLs
[x] Able to create Specific ACL groups. Each group can have multiple subnets assigned to it.
[ ] Views
[ ] Allow recursion (which networks are able to use this view)
[ ] Zones
[ ] Domain Zone Configuration
[ ] Disable this zone (able to disable without deleting the configuration)
[ ] Reverse Zone (checkbox if this is a reverse zone)
[ ] Slave Zone Configuration
[ ] Master Zone IP (box for ip address of master server to pull this zone from)
[ ] Forward Zone Configuration
[ ] Forwarders (Semi colon separated list of IP's to forward request to for this zone)
[ ] Master Zone Configuration
@fboyd Do you also want to join contributing to this plugin, possible as a first step for diving into plugin development? E.g. you can take over the views part:
copy Acl files to View files in controllers / Api and forms
replace Acl with View in above files
xml values should be the same as with Acl
copy Acl files to View files in model / php and xml
replace Acl with View in above files
xml values should be the same as with Acl
in generalcontroller.php add view part
in views / general.volt add view part (copy acl and replace with view)
in service go to the named.conf and under the acl for loop add view.
Thats all. :)
When this is finished we can start with new fields in General tab for recursions and ACL
include is missing.
This one can finally be closed, bind plugin offers zone management
Most helpful comment
The answer is obviously no, but people have asked for a package ever since 2015 which we have optionally provided and they keep using it so that tells you something about its overall operational value in today's networking world.
Also note that we removed the bind dependency from the core repository when we moved RCF 2136 to the plugins and the dependency is definitely not coming back.
FWIW, we offer timely updates and a vulnerability scanner so everybody can do the risk assessment and sensible administration on their own terms.