Le serveur DNS lié / nommé sur ISPConfig fonctionne parfois [fermé]

0

J'ai installé le système préconfiguré avec le panneau ISPConfig sur le serveur VPS. Lorsque je crée et configure des zones DNS, le serveur fonctionne pendant un certain temps, puis pendant un certain temps, et les DNS globaux (tels que 8.8.8.8) perdent les enregistrements et le domaine inaccessibles (le serveur n'a pas été trouvé).

Les ports sont ouverts. Tant qu'il y a un délai d'attente sur le serveur DNS (qui est en cours d'exécution, j'ai vérifié), je peux sans problème me connecter sur le port 53 via Telnet.

Système d'exploitation: Centos 6, BIND 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6_4.4

Quand j'interroge le serveur avec dig ANY dekorate.pl @5.133.13.32un délai d'expiration. Et après un moment cela fonctionnera normalement.

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

Fichier de configuration généré par ISPConfig.

$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        5.133.13.32
dekorate.pl. 3600 A        5.133.13.32
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        5.133.13.32
ns1 86400 A        5.133.13.32
ns2 86400 A        5.133.13.32
www 3600 A        5.133.13.32

À noter: sur le panneau de mon registraire de domaine, j'ai délégué le domaine à ns1.dokrate.pl et ns2.dekorate.pl avec l'adresse IP de remplissage

MISE À JOUR

Il actuellement arrêté à nouveau pour travailler. J'ai fait (sur ma machine locale):

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

et:

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

et sur le serveur j'ai fait:

 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

;; QUESTION SECTION:
;dekorate.pl.                   IN      ANY

;; ANSWER SECTION:
dekorate.pl.            3600    IN      A       5.133.13.32
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

;; ADDITIONAL SECTION:
mail.dekorate.pl.       3600    IN      A       5.133.13.32
ns1.dekorate.pl.        86400   IN      A       5.133.13.32
ns2.dekorate.pl.        86400   IN      A       5.133.13.32

;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Apr  6 17:23:53 2015
;; MSG SIZE  rcvd: 192

Chaque fois que cela arrive. Les serveurs DNS Google ne sont plus en mesure de le résoudre.

dig ANY dekorate.pl @8.8.8.8

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

;; QUESTION SECTION:
;dekorate.pl.                   IN      ANY

;; Query time: 3081 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Apr  6 15:28:47 2015
;; MSG SIZE  rcvd: 29
domain-name-system bind dns-zone named-conf Gacek
la source

Réponses:

2

Tout d'abord, je suis actuellement incapable de reproduire le problème.

Je ne suis pas sûr que tout cela réponde réellement à la question (je ne suis pas sûr que la question soit vraiment claire), mais voici ce que je pense de ce qui a été présenté:

  • named-checkzoneest l'outil approprié pour tester un fichier de zone ( named-checkconfcorrespond au fichier de configuration nommé).

  • Vous devriez avoir plus d'un serveur de noms . Je suppose que votre registraire avait une règle pour ce que vous aviez en créant deux NSenregistrements ( ns{1,2}.dekorate.pl), mais comme ils se résument à la même adresse, vous avez vraiment trouvé un moyen de contourner leur application de la politique au lieu d'accepter la norme d'avoir plusieurs serveurs de noms. (le plus diversement possible) pour une fiabilité accrue.

  • Le DNS utilise principalement UDP , pas TCP. Votre test avec telnetutilise TCP , qui ne concerne que certains cas extrêmes. (Pour faire réellement un test DNS qui correspond avec telneten termes de connectivité que vous pourriez faire dig +tcp ....)

  • Après avoir essayé l'exemple de requête, j'ai remarqué que vous semblez autoriser les demandes de récursivité de tout le monde . C'est une très mauvaise idée qui invite pratiquement à des abus.


Dans l’ensemble, êtes-vous vraiment prêt à utiliser vos propres serveurs de noms?
Si votre objectif réel est autre chose, il peut être préférable de ne pas utiliser votre propre infrastructure supplémentaire, à moins que cela ne soit vraiment nécessaire.

Håkan Lindqvist
la source
En fait, je ne veux pas les exécuter du tout. Mais pour les serveurs VPS, ils ne fournissent pas de serveurs DNS comme pour un hébergement régulier. J'ai supposé que les zones DNS du serveur ISPConfig fonctionnent correctement et sont configurées correctement. En outre, comment configurer le domaine pour un serveur DNS? Je veux dire, est-ce que je l'ai fait correctement? Si le serveur est en panne, DNS est en panne. Le DNS est seulement pour ce serveur spécifique. Le DNS doit-il être plus réalisable pour ce serveur que le serveur lui-même?
Gacek
Mis à jour mon problème avec quelques informations supplémentaires.
Gacek
Votre DNS n'aura généralement pas d'effet négatif sur le site Web pendant très longtemps, mais cela affectera les courriels. Souvent, un domaine rebondit rapidement du côté http, même après un temps d'arrêt prolongé de DNS. mais l'email prend plus de temps. Lorsqu'ils disent jusqu'à 48 heures pour la propagation, ils désignent généralement les services de messagerie, mais cela peut également prendre pour http.
Chris
0

Après quelques recherches avec le fournisseur de services Internet, il s’est avéré que la réponse à cette énigme était la suivante: nous étions pris par la limite de connexion UDP définie sur IP. La limite a été enlevée et tout fonctionne.

Gacek
la source
0

Courez-y moi-même. L'enregistrement DNS ne serait pas mis à jour, peu importe le nombre de modifications effectuées sur ISPconfig. La solution était assez simple. Lorsque vous faites une erreur dans la configuration de la zone, bind crée un fichier .err dans le dossier / etc / bind. Cela contiendra vos "nouveaux" paramètres de zone, mais les anciens paramètres resteront tant que l'erreur restera dans votre configuration. Dans mon cas, il s'agissait d'un enregistrement SRV défectueux . Après sa suppression, ispconfig / bind a utilisé le fichier de configuration approprié à la place de l'ancien.

SamTzu
la source