DNS Lookup / inspecter les enregistrements DNS

Comment fonctionne le DNS ?

Le Domain Name System (DNS) est l'annuaire d'internet. Quand votre navigateur ouvre tools.kernelhost.com, le domaine est d'abord traduit en adresse IP. Le DNS n'est pas un seul serveur mais une chaîne hiérarchique : serveurs root (.), serveurs TLD (.com, .de, .at) et enfin le nameserver authoritative du domaine. Le resolver parcourt cette chaîne et met le résultat en cache localement.

Une requête DNS consiste en une question et une réponse : quels enregistrements de type X existent pour le domaine Y ? La réponse contient un ou plusieurs enregistrements plus un TTL (time to live) qui indique au resolver combien de temps il peut conserver l'entrée en cache. Les changements DNS ne sont donc pas visibles dans le monde entier instantanément, ils se propagent au fil de la hiérarchie de cache.

Notre outil lance un lookup UDP/TCP via le resolver système du conteneur à Frankfurt FRA01. Aucun tracking, aucun logging du domaine interrogé et aucune API tierce. La réponse revient en général en quelques millisecondes car le nœud Frankfurt est branché directement sur DE-CIX.

Quels types d'enregistrements existent ?

Chaque type d'enregistrement DNS a un rôle spécifique. Notre outil affiche les huit types les plus courants dont vous avez vraiment besoin pour exploiter un domaine.

• A : Mappe un domaine à une adresse IPv4. Un domaine peut avoir plusieurs enregistrements A (DNS round-robin, load balancing).
• AAAA : Mappe un domaine à une adresse IPv6. Obligatoire pour les setups web modernes, Google classe positivement la connectivité IPv6.
• MX : Mail exchanger. Quel serveur accepte le mail pour ce domaine. Porte une priorité (chiffre plus bas = préféré) pour le failover.
• TXT : Texte libre. En pratique presque exclusivement utilisé pour SPF, DKIM, DMARC, vérification de domaine (Google, Microsoft) et _acme-challenge (Let's Encrypt).
• CNAME : Alias vers un autre domaine. www.kernelhost.com peut être un CNAME pointant sur kernelhost.com. CNAME n'est pas autorisé sur le domaine apex lui-même.
• NS : Quels nameservers font autorité pour ce domaine. Les enregistrements NS sont posés à l'enregistrement du domaine et définissent où sont gérés les autres enregistrements.
• SOA : Start Of Authority. Définit le nameserver primaire, l'email d'admin et les valeurs refresh/retry/expire/minimum TTL pour les zone transfers.
• CAA : Certification Authority Authorization. Quelles CAs peuvent émettre des certificats TLS pour ce domaine. Protection contre l'émission non autorisée de certificats.

MX vs SPF vs DKIM vs DMARC : la configuration mail expliquée

Une configuration mail complète comporte quatre composants DNS. Si l'un manque, votre mail soit n'arrive pas, soit atterrit dans le dossier spam.

• MX (réception) : Indique au monde quel serveur accepte le mail entrant pour votre domaine. Sans MX, personne ne peut vous écrire. MX pointe en général vers un hostname comme mx.kernelhost.com qui est ensuite résolu via A/AAAA.
• SPF (authentification expéditeur) : Enregistrement TXT avec v=spf1 précisant quelles IP peuvent légitimement envoyer du mail pour votre domaine. -all à la fin est obligatoire (sinon n'importe qui peut usurper votre domaine).
• DKIM (signature cryptographique) : Chaque mail sortant est signé avec une clé privée, la clé publique se trouve dans le DNS à selector._domainkey.your-domain.com en TXT v=DKIM1. Les destinataires vérifient la signature et détectent les altérations.
• DMARC (politique + reporting) : TXT sous _dmarc.your-domain.com avec v=DMARC1; p=reject; rua=mailto:dmarc@... DMARC combine SPF et DKIM, dit au destinataire quoi faire des mails échoués et fournit des rapports.

Notre outil parse SPF, DKIM et DMARC inline et affiche un badge vert, jaune ou rouge pour que vous voyiez immédiatement si la configuration est saine ou si par exemple -all manque, la clé DKIM est trop courte ou DMARC est seulement en mode monitoring.

TTL et caching DNS

Le TTL (time to live) indique au resolver en secondes combien de temps il peut mettre un enregistrement DNS en cache. Avec TTL=3600, le resolver ne ré-interroge le serveur authoritative qu'après une heure. Cela économise de la bande passante mais rend les changements DNS non immédiatement visibles.

Le bon TTL dépend de l'objectif. Production stable : TTL élevé (1 heure à 1 jour). Déménagement de serveur prévu : abaisser le TTL à 60-300 secondes plusieurs jours à l'avance, déménager, puis remonter.

• TTL court (60-300 s) : Changements rapides mais plus de charge sur le serveur authoritative et latence de lookup légèrement supérieure.
• TTL long (3600-86400 s) : Moins de charge, réponses cache plus rapides, mais les changements prennent des heures à des jours pour être visibles partout.
• Pour les migrations : Abaisser le TTL à 60-300 secondes au moins 24 heures avant le déménagement, ainsi tous les caches resolver expirent juste avant le cutover.

Qu'est-ce que DNSSEC et en ai-je besoin ?

DNSSEC (DNS Security Extensions) signe les enregistrements DNS de manière cryptographique pour qu'un resolver puisse vérifier si la réponse a été altérée en route. Sans DNSSEC, un resolver malveillant chez un FAI ou en WiFi public peut renvoyer de fausses IP (DNS spoofing).

DNSSEC utilise deux clés : ZSK (zone signing key) signe les enregistrements, KSK (key signing key) signe la ZSK. Le hash KSK est publié comme enregistrement DS chez le registrar, fermant la chaîne de confiance jusqu'à la racine.

En avez-vous besoin ? Pour les banques, services publics, fournisseurs mail et toute personne utilisant des enregistrements SMIMEA, TLSA ou OPENPGPKEY (DANE) : oui. Pour une boutique normale, DNSSEC est un nice-to-have qui ne coûte rien si votre prestataire le supporte. Le DNS KernelHost supporte DNSSEC out of the box.

Cas de debug fréquents

Pourquoi vous avez vraiment besoin de cet outil au quotidien :

• Le mail n'arrive pas : Vérifier les enregistrements MX, puis SPF, DKIM, DMARC. Si l'un des quatre est cassé, le mail finit en spam ou est rejeté par le destinataire.
• Le domaine pointe sur la mauvaise IP : Vérifier les enregistrements A et AAAA. Souvent lors d'un déménagement de serveur, seuls les A ont été mis à jour et les anciens AAAA subsistent.
• Le sous-domaine ne répond pas : Vérifier le CNAME ou l'enregistrement A direct sur le sous-domaine. Erreur fréquente : le sous-domaine a été créé dans le panel mais le DNS pointe encore dans le vide.
• Vérifier la propagation DNS : Après un changement, lancer plusieurs lookups espacés dans le temps. Une fois le TTL expiré, tous les resolvers devraient voir les nouveaux enregistrements.
• Lets Encrypt refuse le certificat : Vérifier les enregistrements CAA. S'ils ne listent qu'une autre CA et que Lets Encrypt manque, Lets Encrypt refuse d'émettre.

Le DNS chez KernelHost

L'hébergement web KernelHost inclut un DNS managé complet : tous les enregistrements sont gérés via notre panneau de contrôle, DNSSEC est activé par défaut, et des nameservers anycast géographiquement redondants à Francfort et Vienne livrent des réponses rapides dans le monde entier.

Si vous n'avez besoin que d'un hébergement DNS sans webspace, nos packs domain service font le job. L'enregistrement, le transfert et la gestion DNS sont inclus dans chaque offre KernelHost. Pour des configurations plus complexes (split horizon, geo DNS, précision TTL élevée), un VPS plus votre propre serveur authoritative est une option, et vous pouvez utiliser cet outil à tout moment pour le diagnostic.

Questions fréquentes