Hello, In order to manage dns servers(publics and privates) with one master, I'm searching a dns web interface. I found ispconfig but i don't know how to use views(dns horizon). Is it possible? If not, future feature? Thanks Regards
Looking at this as it's a question I had, too, and using views should be quite straightforward. On Debian 8 it looks like ispconfig only writes to /etc/bind/named.conf.local and creates zone files (eg. pri.yourdomain.com). Normally named.conf.local is included by named.conf, which aside from comments is simply: Code: include "/etc/bind/named.conf.options"; include "/etc/bind/named.conf.local"; include "/etc/bind/named.conf.default-zones"; I believe all you would need to do is move/duplicate those last 2 lines into each view, eg. something like: Code: include "/etc/bind/named.conf.options"; acl internal_addrs { 172.16.0.0/12; // Our private addr subnet }; view "internal-view" { match-clients { internal_addrs; }; allow-query { internal_addrs; }; recursion yes; include "/etc/bind/named.conf.local"; include "/etc/bind/named.conf.default-zones"; }; view "external-view" { match-clients { !internal_addrs; any; }; allow-query { any; }; recursion no; include "/etc/bind/named.conf.local"; include "/etc/bind/named.conf.default-zones"; }; In minimal testing, that seems to work right for a simple example.
Thanks for your help; I know how to configure named.conf and named.conf.options for working with dns horizon but what i looking for is how to manage zones with ispconfig. Indeed, you can't have Two zones with same name on ispconfig(that seems normal) but you can't specify zone file for private and another for public neither specify views. Or maybe i did not understood how to.
I'm interested in that, too. That could be useful for all users with servers behind a NAT... But probably it's very hard to have a meaningful (and not too error-prone) interface for this use case.
As you found, ispconfig does not manage multiple versions of the same domain/zone, so a single installation cannot be used to accomplish that. The above example incorporates the zones that ispconfig does create into multiple views, but it is the same data in each view - a valid use case, but not what you're wanting. The first workaround that comes to mind using ispconfig would require 3 servers as a minimum - 2 ispconfig servers for managing the dns zones, in one you create the "internal" dns records, and in the other you create the "external" dns records, then have a 3rd (and 4th, etc.) dns server which handles your queries, and on which you define your views, but instead of including your zone files directly, you set forwarding to the ispconfig server (ie. in the "internal" view, forward to the first ispconfig server, in the "external" view, forward to the second). A second workaround would be to use different domain names in ispconfig, eg. "int--domain.com" and "ext--domain.com", then write a little script that strips the int-- and ext-- and puts the info into separate files, and rewrites named.conf.local equivalents that your view definitions read. This would break DNSSEC, which may be a showstopper, and require a little scripting, though pretty simple for what's needed. I also briefly did a recent survey of available DNS configuration web interfaces, and found the same thing - no viable options other than ispconfig, which isn't ideal (missing some features/capabilities), but might work....
Well, two ISPConfig instances could be enough: one for "internal" and the other for "external", as long as ISPConfig allows to create the same zone (w/ different records) on different servers. Then have internal (DHCP?) clients use the "internal" server while the external ones point to the other. Should be slave- and DNSSEC- friendly. But that's error-prone: everytime you add a record to one zone, you have to remember to add a matching one on the other. Even worse if you need different horizons.
There you go, only two ispconfig servers (no need for the third) - and I mean two standalone control panels, which you login to separately to setup dns (not part of the same ispconfig install/system). sever1 does "internal" with something like: Code: view "internal-view" { match-clients { internal_addrs; }; allow-query { internal_addrs; }; recursion yes; include "/etc/bind/named.conf.local"; include "/etc/bind/named.conf.default-zones"; }; view "external-view" { match-clients { !internal_addrs; any; }; allow-query { any; }; forward only; forwarders { 2.2.2.2; }; include "/etc/bind/named.conf.default-zones"; }; And server2 handles "external" with something like: Code: view "internal-view" { match-clients { internal_addrs; }; allow-query { internal_addrs; }; recursion yes; forward only; forwarders { 1.1.1.1; }; include "/etc/bind/named.conf.default-zones"; }; view "external-view" { match-clients { !internal_addrs; any; }; allow-query { any; }; include "/etc/bind/named.conf.local"; include "/etc/bind/named.conf.default-zones"; };
