I have Installed preconfigured system with ISPConfig panel on VPS server. When I create DNS zones and configure them, server work for some time then for some time timeouts and global dns (like lose records and domain in unreachable (couldn't find server).

Ports are Open. While there is timeout on DNS server (which is running, i checked) i can without problem connect on port 53 via telnet.

OS: Centos 6, BIND 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6_4.4

When I query server with dig ANY dekorate.pl @ i get timeout. And after a while it will work normally.

named-checkconf /var/named/pri.dekorate.pl

/var/named/pri.dekorate.pl:1: unknown option '$TTL'
/var/named/pri.dekorate.pl:3: unknown option 'serial,'
/var/named/pri.dekorate.pl:4: unknown option 'refresh,'
/var/named/pri.dekorate.pl:5: unknown option 'retry,'
/var/named/pri.dekorate.pl:6: unknown option 'expire,'
/var/named/pri.dekorate.pl:7: unknown option 'minimum,'
/var/named/pri.dekorate.pl:10: unknown option '*'
/var/named/pri.dekorate.pl:20: unexpected token near end of file

Configuration file that ISPConfig generated.

$TTL        3600
@       IN      SOA     ns1.dekorate.pl. admin.dekorate.pl. (
                        2015040604       ; serial, todays date + todays serial #
                        7200              ; refresh, seconds
                        540              ; retry, seconds
                        604800              ; expire, seconds
                        86400 )            ; minimum, seconds

* 86400 A
dekorate.pl. 3600 A
dekorate.pl. 3600      MX    10   mail.dekorate.pl.
dekorate.pl. 3600      NS        ns1.dekorate.pl.
dekorate.pl. 3600      NS        ns2.dekorate.pl.
mail 3600 A
ns1 86400 A
ns2 86400 A
www 3600 A

To note: on panel of my domain registrar i delegated domain to ns1.dokrate.pl and ns2.dekorate.pl with filling IP adress


It currently again stopped to work. I did (on on my local machine):

nc -u -z -v 53
Connection to 53 port [udp/domain] succeeded!


dig ANY dekorate.pl @
; <<>> DiG 9.3.6-P1-RedHat-9.3.6-20.P1.el5_8.4 <<>> ANY dekorate.pl @
;; global options:  printcmd
;; connection timed out; no servers could be reached

and on server i did:

 dig ANY dekorate.pl @localhost

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6_4.4 <<>> ANY dekorate.pl @localhos                                          t
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39
;; flags: qr aa rd; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 3
;; WARNING: recursion requested but not available

;dekorate.pl.                   IN      ANY

dekorate.pl.            3600    IN      A
dekorate.pl.            3600    IN      MX      10 mail.dekorate.pl.
dekorate.pl.            3600    IN      NS      ns2.dekorate.pl.
dekorate.pl.            3600    IN      NS      ns1.dekorate.pl.
dekorate.pl.            3600    IN      SOA     ns1.dekorate.pl. admin.dekorate.                                          pl. 2015040604 7200 540 604800 86400

mail.dekorate.pl.       3600    IN      A
ns1.dekorate.pl.        86400   IN      A
ns2.dekorate.pl.        86400   IN      A

;; Query time: 1 msec
;; WHEN: Mon Apr  6 17:23:53 2015
;; MSG SIZE  rcvd: 192

Whenever it happens. Google DNS servers lose ability to resolve it.

dig ANY dekorate.pl @

; <<>> DiG 9.3.6-P1-RedHat-9.3.6-20.P1.el5_8.4 <<>> ANY dekorate.pl @
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 29463
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;dekorate.pl.                   IN      ANY

;; Query time: 3081 msec
;; WHEN: Mon Apr  6 15:28:47 2015
;; MSG SIZE  rcvd: 29

closed as off-topic by womble Aug 5 at 0:59

This question appears to be off-topic. The users who voted to close gave this specific reason:

If this question can be reworded to fit the rules in the help center, please edit the question.


First of all, I'm currently unable to reproduce the problem.

I'm not sure if any of this actually answers the question (I'm not sure there even really is a clear question) but here is my take on what has been presented:

  • named-checkzone is the tool appropriate for testing a zone file (named-checkconf is for the named configuration file).

  • You should have more than one nameserver. I assume your registrar had a rule for that which you got around by making two NS records (ns{1,2}.dekorate.pl) but as these resolve to the same address you've really just found a way to get around their policy enforcement instead of accepting the norm of having multiple nameservers (as diversely situated as possible) for increased reliability.

  • DNS primarily uses UDP, not TCP. Your test with telnet uses TCP, which is only relevant for some edge cases. (To actually make a dns test that matches up with telnet in terms of connectivity you could do dig +tcp ....)

  • From having tried the example query I have noted that you appear to allow recursion requests from everyone. This is a very bad idea which practically invites abuse.

All in all, are you really up for running your own nameservers?
If your actual goal is something else it may be better not to run additional infrastructure of your own unless it's really necessary.

  • Acually, I don't want to run them at all. But for VPS server they don't provide DNS servers like for regular hosting. I assumed, that ISPConfig server DNS zones are working configured and are correctly. Also, how you configure domain for a dns server? I mean, did I do it correctly? If server i down, dns is down. DNS is only for this specific server. Does DNS need to be more realible for this server than server itself? – Gacek Apr 6 '15 at 11:04
  • Updated my problem with some more info. – Gacek Apr 6 '15 at 13:30
  • Your dns usually wont adversely affect the website for very long, but it will affect emails. Often a domain will bounce back quickly on the http side of things even after an extended downtime of dns. but email takes longer. When they say upto 48 hours for propagation they generally mean email services but it can take that for http too. – Chris May 27 '18 at 17:51

After some research with ISP it turned out that answer to this riddle is: We were being caught by UDP Connection limit set on IP. Limit got taken down and everything works.


Run in to this my self. DNS record would not update no matter how many edits on ISPconfig. Solution was fairly simple. When you make a mistake in the zone configuration bind will produce .err file in /etc/bind folder. That will contain your "new" zone settings but old settings will stay as long as the error remains in your configuration. In my case it was faulty SRV record. After deleting it ispconfig/bind used the proper configuration file instead of the old one.

Not the answer you're looking for? Browse other questions tagged or ask your own question.