DNS
Monitoring DNS
Qu'il résout, et que la réponse est exactement ce que tu attends.
Essaie-le maintenant
Un test, depuis un endroit, tout de suite, et rien n'est sauvegardé. Un monitor vérifie depuis chaque emplacement où on est présent et confirme une panne depuis deux autres continents avant de réveiller quelqu'un, ce qu'un simple test ne peut pas te montrer.
À quoi ça sert
Tous les autres tests de cette liste dépendent de DNS, et DNS est la seule chose qui peut échouer alors que tout ce qu'il pointe est parfaitement sain. Un transfert de zone qui a mal tourné, un panneau de registrar que quelqu'un a modifié, une délégation expirée : le site est en ligne et inaccessible.
La panne qui vaut la peine d'être surveillée est plus précise que ça. Un enregistrement peut se résoudre rapidement, depuis chaque resolver, et pointer vers l'adresse de quelqu'un d'autre. Rien qui vérifie si DNS répond verra jamais ça. Donne-nous la réponse que tu attends et on vérifie ça à la place.
Comme chaque vérification ici, elle s'exécute depuis Amsterdam, New York, Sydney and Singapore, et un échec est confirmé depuis deux autres continents avant que quelqu'un soit réveillé. Comment ça marche.
Ce que tu peux configurer
Tout ce qui suit est dans le formulaire quand tu en ajoutes un, sur chaque forfait.
- Enregistrement
- A, AAAA, MX, TXT, NS, CNAME ou SOA.
- Réponse attendue
- Vide, vérifie que le nom se résout tout court. Rempli, il vérifie que la réponse est toujours correcte, ce qui est la panne que rien d'autre ne détecte.
- Correspondance
- N'importe lesquels, ou exactement ceux-là. Choisir exactement ceux-là est le seul moyen de détecter l'ajout d'un enregistrement plutôt qu'un changement.
- Demander à ce resolver
- Indique ton propre serveur autoritaire et tu verras un changement dès qu'il est effectué, plutôt qu'attendre que le resolver que nous utilisons expire son cache.
Questions
Quels types d'enregistrements peux-tu surveiller ?
A, AAAA, CNAME, MX, TXT, NS et SOA sont sur le formulaire, et CAA, PTR et SRV sont également acceptés. La liste est volontairement plus courte que tout ce que le DNS peut contenir : chaque type ici est un enregistrement dont le changement serait remarqué par un client, ce qui est le seul type qui mérite une alerte.
Quelle est la différence entre NXDOMAIN et SERVFAIL ?
NXDOMAIN signifie que le nom n'existe pas : une faute de frappe, un enregistrement supprimé ou une délégation expirée. SERVFAIL signifie que les serveurs de noms ont été interrogés et qu'aucun n'a donné de réponse exploitable, ce qui indique une zone défaillante ou des serveurs hors ligne. Un troisième cas, où le nom existe mais sans enregistrement de ce type, est signalé séparément, car les trois cas ont des solutions différentes.
Peux-tu me dire si un changement s'est propagé ?
En partie, et il vaut la peine d'être précis sur ce qu'est la propagation : rien ne se propage, les caches expirent simplement à leur propre rythme. Les vérifications sont effectuées depuis trois continents, donc un changement visible sur l'un mais pas sur l'autre apparaîtra comme un désaccord. Indique ton propre serveur autoritaire et tu verras le changement dès qu'il est effectué.
Cela détecterait-il un détournement DNS ?
C'est pour ce type d'échec que cela existe. Un enregistrement peut se résoudre rapidement, depuis chaque resolver, avec un TTL correct, et pointer vers l'adresse de quelqu'un d'autre ; rien qui se contente de demander si le DNS a répondu ne le verra. Indique la réponse que tu attends, et un enregistrement pointant ailleurs échouera en un intervalle.
Est-ce que tu vérifies le TTL ou valides le DNSSEC ?
Non, et nous le disons plutôt que de laisser entendre le contraire. Le TTL est celui défini par ta zone et cela ne le vérifie pas, et les signatures DNSSEC ne sont pas validées. Ce qui est vérifié, c'est la réponse reçue et si elle est toujours celle que tu attends, ce qui est l'échec que le reste de ta surveillance ne peut pas détecter.
Qu'est-ce que correspondre exactement fait que correspondre à n'importe lequel ne fait pas ?
N'importe lequel passe quand la valeur attendue est quelque part dans la réponse, ce qui est ce que tu veux pour un nom derrière un pool d'adresses. Exactement ceux-là échoue si quoi que ce soit a été ajouté, et c'est ainsi que les dégâts arrivent généralement : un enregistrement A supplémentaire ou un MX en plus du tien est une détection de changement d'enregistrement que rien d'autre ne capte.
Pourquoi ne pas utiliser dig dans un script ?
Tu peux, et pour vérifier un enregistrement une fois, c'est l'outil qu'il te faut. Le problème, c'est qu'il n'y a pas de réponse unique : ce que ton resolver renvoie et ce qu'un resolver à Sydney renvoie peuvent différer pendant toute la durée d'un TTL, et un script sur une machine demandant à un seul resolver ne verra qu'une de ces réponses. Celui-ci interroge depuis quatre continents et peut être dirigé vers un resolver spécifique, ce qui transforme une recherche en comparaison.
Mon registrar m'envoie un email quand un enregistrement change. Ce n'est pas suffisant ?
Garde-le, c'est une vraie vérification et c'est le moyen le plus rapide de savoir que quelqu'un de ton équipe a changé quelque chose. Cela couvre le cas où le changement est passé par ton registrar, ce qui est celui qui t'inquiétait le moins. Cela ne dit rien lorsqu'un enregistrement est modifié chez un fournisseur que tu utilises aussi, lorsqu'un transfert de zone échoue, ou lorsqu'un resolver quelque part renvoie quelque chose que ton registrar n'a jamais publié. Ce sont les échecs qui donnent l'impression que tout va bien.