web-dev-qa-db-fra.com

Pourquoi la résolution DNS ne fonctionne-t-elle pas au premier essai?

Depuis la mise à niveau vers 16.04, la résolution DNS échoue (renvoie un hôte introuvable) à la première tentative d'un site Web. Je peux alors immédiatement essayer une seconde fois et cela fonctionne très bien.

Un peu de fond:

  • J'ai sur mon réseau un serveur exécutant une ancienne version d'Ubuntu et un PC Windows. Les deux ne sont pas affectés (en utilisant les mêmes serveurs DNS que l'ordinateur posant problème).
  • Après avoir un peu fouillé sur le Web, j’ai suivi les conseils de quelqu'un et
    a supprimé et purgé resolvconf. Cela a résolu le problème ... jusqu'à ce que je
    redémarré. Ensuite, la résolution DNS ne fonctionnait pas du tout (j'ai corrigé cela mais je suis revenu à la case départ maintenant).

Dans ma compréhension limitée, ce qui semble se produire est que lorsqu'une requête pour un nouveau site Web arrive dans le cache DNS local (resolvconf?), Il ne se trouve pas dans le cache, la réponse est donc vide. Ensuite, lorsque la même requête revient, un processus a entre-temps résolu l'adresse et mis à jour le cache, de sorte que le cache répond avec l'adresse.

Ce que je veux, c'est que si l'adresse demandée ne se trouve pas dans le cache, elle ira la chercher avant de répondre le en premier fois. Quelqu'un peut-il me dire comment y arriver?

Voici la sortie de Dig (première fois):

~$ Dig www.foo.com

; <<>> Dig 9.10.3-P4-Ubuntu <<>> www.foo.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 6505
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.foo.com.              IN      A

;; Query time: 23 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)
;; WHEN: Thu Jun 02 13:44:49 JST 2016
;; MSG SIZE  rcvd: 34

Et quelques secondes plus tard, voici la sortie de Dig (deuxième fois):

~$ Dig www.foo.com

; <<>> Dig 9.10.3-P4-Ubuntu <<>> www.foo.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53490
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.foo.com.              IN      A

;; ANSWER SECTION:
www.foo.com.       14310   IN      CNAME   foo.com.
foo.com.           210     IN      A       192.0.79.33
foo.com.           210     IN      A       192.0.79.32

;; Query time: 0 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)
;; WHEN: Thu Jun 02 13:46:19 JST 2016
;; MSG SIZE  rcvd: 92
16.04dns
5
Weilong Wang

Je suis confronté au même problème. La solution que j'utilise pour l'instant est la suivante:

  • Ouvrez le fichier de configuration Network Manager:

    Sudo nano /etc/NetworkManager/NetworkManager.conf

  • Modifier la ligne suivante:

    #dns=dnsmasq

  • Enregistrez et redémarrez le gestionnaire:

    Sudo service NetworkManager restart
5
rootd

Je suis confronté au même problème. La solution que j'utilise pour le moment est d'ajouter un serveur DNS secondaire à mon /etc/resolv.conf:

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.0.1
nameserver 192.168.1.1
search lan

De plus, j'ai installé Dnsmasq qui met en cache toutes les requêtes DNS. Ainsi, toutes les demandes vont d’abord à dnsmasq (127.0.0.1) et si le domaine n’est pas mis en cache, la demande passe à 192.168.1.1 (mon routeur qui exécute également un serveur DNS, vous pouvez bien sûr utiliser 8.8.8.8).

Cette solution de contournement n’est pas idéale, je le sais, mais elle fonctionne pour le moment. J'utilise d'ailleurs aussi une nouvelle installation d'Ubuntu 16.04

2
Steve