La version DNS est visible pour ns1.canonical.com avec l'IP 185.125.190.65 : 9.18.18-0ubuntu0.22.04.2-Ubuntu.
La version DNS est visible pour ns2.canonical.com avec l'IP 185.125.190.66 : 9.18.18-0ubuntu0.22.04.2-Ubuntu.
La version DNS est visible pour ns3.canonical.com avec l'IP 91.189.91.139 : 9.9.5-3ubuntu0.19+esm11-Ubuntu.
archive.ubuntu.com a été détecté comme étant un hôte
La version DNS est visible pour ns1.canonical.com avec l'IP 185.125.190.65 : 9.18.18-0ubuntu0.22.04.2-Ubuntu.
La version DNS est visible pour ns2.canonical.com avec l'IP 185.125.190.66 : 9.18.18-0ubuntu0.22.04.2-Ubuntu.
La version DNS est visible pour ns3.canonical.com avec l'IP 91.189.91.139 : 9.9.5-3ubuntu0.19+esm11-Ubuntu.
La version Bind ne doit pas être visible car il y a un risque qu'une personne malveillante fasse une recherche sur des éventuelles failles de sécurité propre à la version trouvée.
0.134s
Réussi
Dans le but d'obtenir une très haute disponibilité, il est fortement recommandé par la RFC d'avoir au moins 2 serveurs pour les DNS.
RFC0.000s
Réussi
Tous les serveurs DNS doivent être accessible et accepter une requête publique.
0.019s
Réussi
Il est important que tous les serveurs retournent un code de succès.
0.017s
Réussi
Réussi
Les IPs des serveurs DNS doivent être différentes dans le but d'augmenter le taux de disponibilité afin que celui-ci soit au plus haut.
0.000s
Réussi
La classe C de chaque IP doit être différente pour que les serveurs ne se trouvent pas dans la même baie et qu'il y ait un risque d'indisponibilité.
RFC0.000s
Réussi
Le SOA répondu par les serveurs DNS doit être identique pour chaque serveur. Les informations les plus importantes sont le serveur maître, l'adresse e-mail du contact et le serial.
0.000s
Réussi
Une adresse e-mail doit respecter certaines conditions pour être valide, conformément à la RFC 5322.
RFC0.000s
Réussi
Réussi
La valeur de Retry doit être inférieur à celle de Refresh qui elle même doit être inférieur à Expire (retry <refresh <expire).
RFC0.000s
Réussi
Les résolveurs DNS qui autorisent les requêtes provenant de toutes les adresses IP et qui sont exposés à Internet peuvent être attaqués et utilisés pour mener des attaques par déni de service (DoS) par des personnes malveillantes.
0.105s
Réussi
Un attaquant peut utiliser un transfert de zone contenant un code malveillant ou un format inapproprié qui bloque un serveur DNS vulnérable à ce type d'attaque, ce qui entraîne un DoS qui déstabilise les services DNS. Cela permet la récupération de l'ensemble des informations de la zone DNS. Le test peut être effectué à l'aide de la commande : #host -T axfr ou #dig axfr.
documentation0.332s
Réussi
Avoir un serveur DNS qui autorise les requêtes récursives est un risque de sécurité, une attaque DDOS peut être effectuée.
RFC documentation documentation0.105s
Réussi
Réussi
Il est extrêmement important que chaque DNS renvoie les mêmes enregistrements MX afin d'éviter de contacter un serveur SMTP qui n'existe plus.
0.104s
Ignoré
La synchronisation des serveurs DNS se doit d'être parfaite pour éviter tout problème de résolution dns. Les serveurs doivent donc donner la même réponse lorsqu'on leur demande "quels sont les serveurs DNS du domaine?".
0.000s
Réussi
Il est primordial que les DNS trouvés dans le WHOIS soient identiques à ceux retournés par une requête de résolution DNS.
0.000s
Réussi
Un domaine ne doit pas être blacklisté sinon celui-ci il sera pénalisé pour le référencement et la délivrabilité des emails.
0.000s
Réussi
Google Safe Browsing catégorise un domaine comme étant mauvais si un élément suspect est détecté.
0.000s
Réussi
Virus Total analyse votre domaine ou votre adresse IP avec 66 antivirus.
0.000s
Réussi
Web Of Trust évalue des milliers de sites Web et trouve des menaces si elles existent.
0.000s
L'autodiscover n'est pas configuré