(Debian Bookworm) ISPConfig 3.3.1 Single Installation. Second DNS via named notification. The problem described here appeared after updating Debian to version 12 and simultaneously updating ISPConfig. I don't know if the problem is caused by ISPConfig or Debian. How to reproduce the problem: Create entries in any domain, e.g., example.com: lan.example.com. NS ns1.lan.example.com. So far, everything is fine, but after adding the Glue record, all changes to the domain take an extremely long time... ns1.lan A 192.168.1.1 or ns1.lan.exmaple.com. A 192.168.1.1 It doesn't matter which of these entries you use.
May you please explain what exact change takes how long, and how you determine that it takes long (does it takes long until the red dot stops blinking, or does something else takes long)? Also, ISPConfig typically does not influence DNS delegation times. It writes the config and reloads BIND. Have you checked if DNS delegation is delayed, or if writing the BIND DNS file is delayed?
Red dot stops blinking and manual execute command via ssh /usr/local/ispconfig/server/server.sh take long time. 2 changes in DNS take 1 or 2 min. if i have 50 changes, because i add domain or move domain from other server take 10 minuts or more. I diden't check with the time. However its problem with dns serial number because serial number start with high number and gow down. After that long time second dns have bigger number than master dns. The cron is not a problem because i run manual server.sh and watch how long time this take. I admit that I don't remember whether the problem concerns changes in other domains or only in this one. If you delete the glue record "a" everything back to normal.
the dns changes taking 1 or 2 minutes, with a red dot visible... the change is already made in the master ispconfig database by the time you can see the red dot. the red dot just remains there until all slave servers that need to have retrieved any relevant information. each slave server requests the data on any configuration changes via a mysql query to the master database every minute. this shouldn't be happening, dns serial numbers should only ever go up, being the date of the last change + a couple of incremental digits to account for multiple changes on the same date.
OMG? Realy i need record video and put here? I don't have any other servers! Is only one single instalation. Forget about Red Dot. Important is manual execute and long time to execute!
only single server installation? you mention that 5 posts in. are we supposed to be mind readers? kind of implies multiple servers.... is it the actual change of dns (the zonefiile itself) that takes a long time, or the end user being directed to the new server ip when browsing/pinging? if it's the latter.. as @till said earlier... we don't control dns propagation... it takes time.
I don't need connect all second dns to ISP because bind have something like notify. No, I don't need to be a mind reader. Just read it carefully and understand the problem with adding a glue record. A glue record is added when delegating a domain to an unknown NS. Best regards. Taka sama konfiguracja przed uaktualnieniem działa prawidłowo.
OK, and now i have big problem because i making copy 1:1 of my server into virtualization and problem don't exists. The only difference is that it logs in directly with the root account. This is a new virtual server with 48GB of memory and 12 cores from OVH.
Ok, so you know it's not a problem in ISPConfig or the ISPConfig version. The issue must be something in your server environment. You can use debug mode to find out in details which command causes the delay and then track why it's slow. Might be that some network requests are involved, which fail for some reason and wait until they time out or something similar
To avoid a lot of server issues, add the following entry to the /etc/bind/named.conf.options file: options { recursion yes; allow-recursion { localhost; }; # tylko dla lokalnego systemu forwarders { 8.8.8.8; 1.1.1.1; }; }; For example, Postfix is one of those entities that, even though the external DNS server is listed first in resolve.conf, still queries the local DNS. Please add this information to the documentation.
Recursion from localhost is allowed by default in BIND, there is no manual setting needed for that in named.conf.options. You must have disabled recursion on your system in some other config files if you had to add allow-recursion {localhosts;}; to make recursion work.
My Postfix often returns "unknown hostname." I searched for the cause, and dig -x .... @localhost provided quite long responses. This caused fail2ban to frequently block mail servers. After adding allow-recurse { localhost;}, I set the DNS to respond only to its own domains, which prevents spamming my DNS. By adding forward to fast servers that respond within 10 ns, I sped up the entire system. Slow DNS was one of the reasons for system lag. If we add rspam and, for example, spamhouse, slow DNS is the main cause of poor system performance. Now, when I run dig -x, I get very fast responses regardless of the speed of the root DNS. I think this post is worth including in the main documentation. I also compared Debian 12 and Debian 13 in a virtual environment, including bind9 and dig -x. It turns out that in Debian 12 entries in resolve.conf are probably not taken into account, but in Debian 13 they are, and changing the entry to e.g. 8.8.8.8 in resolve.conf for Debian 13 brings an immediate positive effect.
