5 votes

TTL lors d'une requête pour tout enregistrement avec dig

Cette question provient de ce sujet . Lorsque je fais cela, j'obtiens les secondes restantes jusqu'à l'expiration de l'enregistrement A dans le serveur de noms interrogé :

dig stackexchange.com

Cependant, si je fais cela, j'obtiens les valeurs de TTL autoritaires :

dig any stackexchange.com 

Donc, je ne comprends pas pourquoi quand je fais dig any stackexchange.com J'obtiens toutes les valeurs TTL comme si je posais une question autoritaire, alors que j'ai en fait effectué une requête récursive.

8voto

Kannan Mohan Points 428

Pour être bref, les deux requêtes que vous avez mentionnées dans la question sont des requêtes non-autoritaires.

Les enregistrements DNS d'un domaine peuvent être interrogés à partir d'un serveur DNS en cache ou d'un serveur DNS faisant autorité. Ainsi, lorsque vous souhaitez interroger un serveur DNS de mise en cache, vous pouvez soit spécifier l'adresse IP du DNS, soit, s'il n'est pas spécifié, le serveur DNS par défaut qui a été configuré dans le fichier /etc/resolv.conf seront prises.

Requête ne faisant pas autorité

$ dig stackexchange.com

ou

$ dig stackexchange.com @8.8.8.8

Dans les deux cas ci-dessus, la requête renvoie une réponse non-autoritaire car le DNS de votre FAI ou le DNS public de Google (8.8.8.8) ne font pas autorité pour stackexchange.com domaine. Au fur et à mesure que vous interrogez un serveur de noms non-autoritaire, la valeur TTL qu'il fournit diminue à chaque fois que vous l'interrogez. Une fois la valeur TTL expirée, le serveur de noms en cache demandera à nouveau le serveur DNS faisant autorité.

Requête faisant autorité

Ainsi, pour obtenir une réponse faisant autorité, vous devez interroger l'enregistrement à partir d'un serveur DNS faisant autorité, ce qui peut être trouvé avec la méthode ci-dessous.

$ dig ns stackexchange.com
       ...
;; ANSWER SECTION:
stackexchange.com.  84894   IN  NS  cf-dns02.stackexchange.com.
stackexchange.com.  84894   IN  NS  cf-dns01.stackexchange.com.
       ...

En SECTION REPONSE fournit les serveurs de noms faisant autorité pour le domaine stackexchange.com et donc si nous avons besoin d'obtenir la réponse officielle alors

$ dig stackexchange.com @cf-dns01.stackexchange.com.

Lorsque nous interrogeons le serveur DNS faisant autorité, les valeurs TTL ne changent pas car ces serveurs de noms sont la source primaire d'information et n'expirent pas tant que l'administrateur ne les modifie pas.

Comment fonctionne TOUT enregistrement

ANY record est comme un joker, vous pouvez l'utiliser pour obtenir tous les enregistrements qui sont mis en cache/stockés dans un serveur DNS. Par exemple, j'ai interrogé stackexchange.com pour un enregistrement ANY et mon serveur DNS par défaut répond comme ci-dessous.

$ dig any stackexchange.com
    ....
;; ANSWER SECTION:
stackexchange.com.  86350   IN  SOA cf-dns01.stackexchange.com. dns.cloudflare.com. 2017456480 10000 2400 604800 3600
stackexchange.com.  176 IN  A   198.252.206.140
stackexchange.com.  84338   IN  NS  cf-dns01.stackexchange.com.
stackexchange.com.  84338   IN  NS  cf-dns02.stackexchange.com.
    ....

Ici, vous pouvez voir que la réponse ne contient que des informations sur SOA , A y NS enregistrement. Mais il y a en fait plus de records pour stackexchange.com qui ne sont pas mis en cache dans mon serveur DNS par défaut car je ne les ai pas demandés.

Maintenant, je fais une demande pour MX à mon serveur DNS par défaut et la réponse est la suivante

$ dig MX stackexchange.com
    ....
;; ANSWER SECTION:
stackexchange.com.  300 IN  MX  10 aspmx3.googlemail.com.
stackexchange.com.  300 IN  MX  5 alt2.aspmx.l.google.com.
stackexchange.com.  300 IN  MX  5 alt1.aspmx.l.google.com.
stackexchange.com.  300 IN  MX  10 aspmx2.googlemail.com.
stackexchange.com.  300 IN  MX  1 aspmx.l.google.com.
    ....

Maintenant, je demande à nouveau ANY et maintenant vous pouvez voir que la requête de ANY est revenu MX aussi. Et donc ANY ne fournira que les enregistrements qui ne sont mis en cache que sur votre serveur de noms par défaut.

$ dig any stackexchange.com
     ....
;; ANSWER SECTION:
stackexchange.com.  298 IN  MX  5 alt1.aspmx.l.google.com.
stackexchange.com.  298 IN  MX  10 aspmx2.googlemail.com.
stackexchange.com.  86084   IN  NS  cf-dns01.stackexchange.com.
stackexchange.com.  298 IN  MX  10 aspmx3.googlemail.com.
stackexchange.com.  298 IN  MX  1 aspmx.l.google.com.
stackexchange.com.  298 IN  MX  5 alt2.aspmx.l.google.com.
stackexchange.com.  86084   IN  NS  cf-dns02.stackexchange.com.
stackexchange.com.  243 IN  A   198.252.206.140
stackexchange.com.  86343   IN  SOA cf-dns01.stackexchange.com. dns.cloudflare.com. 2017456480 10000 2400 604800 3600
     ....

Et comme vous pouvez le voir, les valeurs TTL changent pour les réponses non-autoritaires.

1voto

TheCompWiz Points 10142

Vous ne comprenez pas le champ TTL des requêtes DNS. Le TTL indique au client combien de temps il doit mettre les résultats en cache avant de réinterroger le serveur de noms. À moins que vous ne mettiez à jour votre serveur DNS avec une valeur différente pour le TTL, la réponse sera toujours la même. C'est une très mauvaise pratique que de réinterroger les serveurs de noms chaque fois que vous devez résoudre un nom d'hôte en une adresse IP.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X