I had troubles configuring Secondary DNS server. I installed ISPConfig on new machine in expert mode with all services (web, mail, dns, db), no panel, etc. All went well, server2 was visible on server1 webui. I already had mydomain.com DNS zone created, with A records ns1 and ns2 pointing to IP1 which is server1, also NS records for both. Now I added server2, updated that ns2 record with IP2. I also changed records for ns2 on my domain registrar with IP2. In Zone settings for mydomain.com I added: Allow zone transfers to these IPs (comma separated list): IP2 Also Notify: IP2 I created Secondary zone: Server: server2.mydomain.com DNS-Zone: mydomain.com. NS (IP-address): IP1 And it didn't work. When I was doing dig for each IP I got: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, Then I found solution to manually edit /etc/bind/named.conf.options, and add these lines: server1: allow-transfer {IP2;}; allow-query { any; }; recursion no; server2: allow-transfer {none;}; allow-query { any; }; recursion no; It works now. But something feels wrong I have to ask you guys Is it how it is supposed to be? Should this be doable only from gui? Will this config stay persistent, or it will be overwritten in some future updates/changes? ------- One more questionl when I go to Tools -> Resync I only see server1 in drop-down menu for services (Web, Mail, DNS,...). Should server2 also be in drop-down list?
No you only see the primary dns server and not secundary dns servers. Because secondary dns servers should get notified by the primary dns server to resync if everything is configured correctly in your zones.
You shouldn't have to alter bind config file to make it work. It should work out of the box. Your zone config in ispc seems correct to me. Though since it didn't work I'm guessing it's ip address related.
I know, that's why I was surprised with this manual config edits. It's not clear to me, what do you mean with "I'm guessing it's ip address related."? What should I check for this?
Do your servers have public ip-addresses or private ip-addresses and you're using nat in your firewall? If private you need to set those in ispconfig for transfer and notify and not the public addresses.
The allow-transfer {IP2;}; is exactly what entering an IP into the xfer field of the zone does, just on a per-zone level and not globally. That#s why it is not needed to edit any config file. I've no idea why this does not work on your system. But adding a global allow transfer should be fine, so you can leave it as it is.
Yes, but only up to the point where allow-transfer (xfer) and also-notify have the same values for all zones. @bldx Did you have bind installed prior to installing ispconfig? That could have messed things up in configuring bind by the ispconfig installer. Is allow-transfer and also-notify set in /etc/bind/named.conf.local for every zone as how you set it in ispconfig? The file should contain: Code: zone "domain.tld" { type master; allow-transfer {IP2;}; also-notify {IP2;}; file "/etc/bind/pri.domain.tld(.signed)"; };
I installed ISPConfig on vanilla Debian 12, I didn't check before installing ISPConfig, but internet say it doesn't comes with the bind. Yes, /etc/bind/named.conf.local have zones for each domain: Code: zone "mydomain.com" { type master; allow-transfer {IP2;}; also-notify {IP;}; file "/etc/bind/pri.mydomain.com"; }; Also /etc/bind/named.conf should properly load .local file: Code: include "/etc/bind/named.conf.options"; include "/etc/bind/named.conf.local"; include "/etc/bind/named.conf.default-zones"; I'll try to play more these days, to retest. Maybe I was doing changes too fast, and something wasn't picked up... BTW, can I do multiple changes in ISPConfig one after another right away, or should I do one setting change and wait for that red circle do disappear before I do next change? I got under impression that some settings don't get applied if I do things too fast
Yes you can. Config files are rewritten in whole based on info in ispc's database at the time ispc's update script runs. So multiple updates are merged together on the next run of the update script.