I'm testing a setup created by ISPConfig Migration Tool from my old setup. Testing the new multiserver setup with one main host with everything and two name servers, I saw the names servers do not receive zone transfers, and thus do not answer to any queries about my domains. The name service does work on the main host. I have checked logs, and enabled debug, stopped cron starting the server script and started it manually. I can not see any errors anywhere about why zone transfers do not happen. I did remember to change the "Allow zone transfers to these IPs" for the new name servers. I compared this setup to another ISPConfig multi server setup and can not see what is different in DNS settings. How to find out how to fix the zone transfers?
ISPConfig does not use BIND zone transfers for mirroring, the mirroring happens in ISPConfig itself and not BIND. Check if the zone files that you created on the master are created on the slave as well by ISPConfig, if not, then check if you selected the secondary dns to be a mirror of the primary dns in ISPConfig under System > Server services. If that's ok, then you can use the iSPConfig debug mode to get more log details on the dns mirror jobs.
The name servers are ns3 and ns4. Ns3 is primary. No zone files on neither. Is the dns mirror job run by the server.sh?
Yes. Use ISPConfig debug mode to find out why neither primary nor slave are able to write the zone files: https://www.faqforge.com/linux/debugging-ispconfig-3-server-actions-in-case-of-a-failure/
I did not see anything useful in the debug output. Seems 2 changes are transferred, but nothing about zones. When run again, seems nothing is to be done. The script prints an empty line and then Remove Lock. When I try to use host command to ns3 name server, answer is Host mydomain.fi not found: 5(REFUSED) The main server can answer queries about that domain. Also: Now I notice the migtool only set up some of the domains. Under 40 domains got copied to the new master, but there are two hundred on the old server. There was warnings but no errors during migtool run.
Theseare two different things, first, a zone that does not exist on the master cannot exist on a slave, so when a zone could not be migrated, then it can not exist on one of the dns slave nodes. The migration tool creates a log file, in that log you can see all errors e.g. when the new system rejected a zone. The other thing is that when you add or update a dns zone on the master and run server.sh on the slave, then you should see that action in the server.sh output. The log you posted does not contain any info about a dns zone add or change action, so I guess you did not add or change a dns zone right before you run that script as the output shows only the completed action of enabling debug log level.
Now I changed one of the zones that does exist on the new master, but still nothing in debug output of server.sh. Nothing that I can see in logs on master on ns3 seems to be related to zone transfers.
Then the base installation of ISPConfig has a problem which is not related to the migration. But when you don't post the exact output, I can't help you. Of course, as BIND zone transfers are not used on ISPConfig servers to sync primary and secondary DNS server. You can see the sync process in the server.sh output when the servers are connected to each other properly.
I setup these three new servers following the ISPConfig manual for the multiserver setup parts and the Perfect server guide for Debian Strecth, Apache etc. for the operating system installation. Maybe I have mixed up stuff, but the setup seems OK. Sadly I have not been able to test much, been stuck with this DNS problem. I have included ispconfig.log from when I changed one zone on master and in debug log mode run by hand server.sh on host ns3, the first name server. The log file had literal \n instead of newlines, I changed those to real newlines to make the mess readable.
The \n have to be there as these lines are sql queries, these should not be newlines in the log. The log does not show any DNS record added or changed, but it shows that the system is processing changes correctly when you edited the server config part, so the server interconnect is working fine. Please follow these exact steps to test the system: 1) Comment out the server.sh cronjob in the root crontab of the primary dns server. 2) Login to ISPConfig on the master server, go to the DNS module, open one of the existing dns zones, increment the TTL by 1 and click save. 3) Login to the primary dns server and run server.sh as root user and post the output that you got on the shell. If it still does not show any dns changes, then the dns record on the master must be on a different server. You should check then if the dns zone shows really the primary dns node as server and not another server like the master or the secondary dns server.
First try was before I realised I have to run the server.sh also on the master server since I had also there removed it from crontab. Looks like the master server does not even try to send the zones to the dns server. There are no zones on either ns3 or ns4. Have to think about this, something is wrong but I can not see what.
server.sh has to be run on the server that you debug only and not on the master. An ISPConfig master is not sending anything, the way the data is moved is the exact opposite way, slaves pull the data from master and that's why you can not see any action on the master and that's why server.sh does not has to be run on the master. Please follow my debug instructions that I posted above, I explained in detail on which server you have to do which step.
I did run the server.sh on both hosts, because the changed TTL was stuck in job queue until I ran it on master. The posted text was cut and pasted from ns3 command window. If ns3 needs to pull the data, how does it know which zones it should pull? I have set NS records for the domain I test now to point to ns3 and ns4. And allow trasfer to IP-numbers lists ns3 and ns4 IP-addresses.
Then your DNS zones are set to be added to the master and not your dns server which explains why you don't see them on the dns server. See my post above:
I understand finally, or at least I hope I understood. In System | Main Config | DNS -tab the "Default DNS server" is ns3.mydomain.fi. When I go to DNS | Zones, all the zones do indeed show the master as Server. So, I must change that to be ns3.mydomain.fi. I compared to my other OK ISPConfig multiserver setup, and there this setting is different. The migtool did this setting, even though I believe I answered ns3 as the name server during migration. Now the problem is I can not change that field. I tried a few domains, I can not write to the Server setting. The drop-down menu is greened out, so menu does not work either. I can change other fields, for example I previously set NS to be ns3.mydomain.fi. Why does ISPConfig in this field not know there are other possibilities for the name server? In System | Main Config | DNS there are both the master and ns3. Server Services has all three of my servers with Yes in the DNS column.
ISPConfig is not able to move a dns zone from one server to another server and that's why it shows only the server where the zone has been created on in the select field and not other (primary) dns servers that might be available in your cluster. Secondary dns servers will never show up there as they are mirrors only and receive the same zones than the master automatically.
I see. I had hopes I found what was wrong and could get this working. Am I just not getting something or is it still unknown how to repair my setup?
When in Migration Tool, I answered for "On which server you want the DNS ENTRIES to be imported? " the master server. Should I have answered the ns3 name server which I want to be primary name server?
dns record consist of aconfig file anly and no data, so the following steps might work: Login to the dbispconfig master database with phpmyadmin and change the value of the 'server_id' column in the tables dns_soa and dns_rr for all records that shall be on the primary dns server to the server_id of the primary dns server. Then run Tools > resync in ISPConfig for the dns records. This should create the records on the primary dns server. You might have to clean u the bind files on the master server manually though as the zones that you 'moved' to the other server will not get removed in BIND on the master. Yes.
Good show. The pri.* files are now on ns3 and I deleted them from master. Now ns3 answers queries for those zones properly and not REFUSED. Also ns4 gives good answer now. Thanks a lot. Have to remember on next Migration Tool use to pay attention where DNS Entries go.
