web-dev-qa-db-fra.com

Configuration de plusieurs serveurs de noms DNS sur le serveur 18.04

J'ai mis en place un réseau statique lors de l'installation d'Ubuntu 18.04, qui semble avoir généré un fichier sur /etc/netplan/50-cloud-init.yaml avec les détails que j'ai fournis.

enter image description here

Les choses semblaient fonctionner, mais Ubuntu oublie régulièrement les paramètres DNS que j'ai entrés. Par exemple, si j'essaie de nslookup another-server.lan.example.com, il ne le trouvera parfois pas.

Après avoir exécuté Sudo netplan apply, il fonctionne à nouveau. L'exécution de cette commande semble être nécessaire plusieurs fois par jour.

Server:         127.0.0.53
Address:        127.0.0.53#53

Non-authoritative answer:
Name:   another-server.lan.mydomain.com
Address: 10.10.1.1›

/etc/netplan/50-cloud-init.yaml 

# This file is generated from information provided by
# the datasource.  Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
    ethernets:
        ens160:
            addresses:
            - 10.10.1.10/16
            gateway4: 10.10.0.1
            nameservers:
                addresses:
                - 10.10.1.1
                - 8.8.8.8
                search:
                - lan.mydomain.com
            optional: true
    version: 2

Ce que je pense est en train de se passer, c'est qu'à un moment de la journée, une recherche échoue avec le serveur DNS interne principal (en premier lieu répertorié), de sorte que systemd bascule vers le serveur DNS Google secondaire (en deuxième lieu répertorié). Mais pour une raison quelconque, lorsque le serveur DNS secondaire ne parvient pas à résoudre une adresse locale, systemd ne réessaie pas le serveur DNS principal.

Un problème similaire est traité ici: https://github.com/systemd/systemd/issues/5755

networking18.04dns
2
waspinator

Je peux confirmer le problème avec 18.04.1 LTS et netplan car je le vis moi-même avec une solution de contournement différente.

La configuration: J'ai deux serveurs 18.04.1 LTS configurés de manière plus ou moins identique. Un serveur héberge des applications et est accessible sur Internet. L'autre est un serveur de données derrière le pare-feu auquel seul le serveur d'applications peut accéder.

Le réseau: J'ai un environnement statique avec deux serveurs DNS. (Windows OS). Pour plus de redondance, j'utilise 8.8.8.8 en cas de défaillance du DNS interne.

La situation: Certaines de mes applications sont résolues via un nom d'hôte et non une adresse IP. Plusieurs fois par jour, les applications se bloquent ou génèrent des erreurs car elles ne peuvent pas résoudre le nom d'hôte. Si je lance netplan apply cela fonctionne un peu.

Bien que je sois 8.8.8.8 troisième dans la liste, je pense que Netplan ignore finalement mes serveurs DNS locaux au profit de Google et ne vérifie jamais le DNS interne s’il ne parvient pas à résoudre un nom d’hôte par rapport au DNS principal.

La solution de contournement: Lorsque j'ai ajouté mon nom d'hôte local à mon enregistrement DNS public (je ne sais pas non plus) sans réappliquer netplan, j'ai pu résoudre mon serveur d'applications sans problème.

En fin de compte, je pense qu’il s’agit d’un problème de défaillance "permanente" de serveur de noms avec Netplan tel qu’il a été mis en œuvre dans Ubuntu 18.04.1 LTS

1
Joseph Sileo

Malheureusement, Google DNS ne connaît pas nos adresses internes :( Lorsque certains services internes ne sont pas accessibles de manière externe, je recommande de ne pas utiliser de DNS externe ni même de serveurs secondaires. J'ai implémenté un serveur DNS interne pour mon réseau universitaire (1800+ PC/50 + serveurs) et n’a pas configuré de serveur secondaire pour eux, mais simplement les PC continuent à essayer si de temps en temps il ya une certaine latence sur le réseau local.

Bien sûr, le fait de n'avoir qu'un seul serveur DNS est un point de défaillance, mais il est facile d'implémenter la haute disponibilité à l'aide d'un moniteur de service et de certains conteneurs.

0
Fjor