> For the complete documentation index, see [llms.txt](https://docs.ipcheck.ing/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ipcheck.ing/knowledge-base/fr/lookup-privacy/dns-resolver.md). # DNS Resolver Résolvez un domaine via de nombreux fournisseurs DNS publics à la fois et comparez les réponses pour repérer le routage CDN, les caches obsolètes ou le filtrage en cours de route. ## Ce qu’il fait Chaque fois que vous ouvrez un site web, votre appareil demande à un résolveur DNS de convertir le nom de domaine en adresse IP. Des résolveurs différents peuvent donner des réponses différentes. La **Résolution DNS** L’outil pose la même question en même temps à une liste de résolveurs publics bien connus, puis affiche toutes les réponses côte à côte. Vous n’avez rien à modifier sur votre appareil. Les requêtes sont effectuées depuis le serveur IPCheck.ing, pas depuis votre ordinateur. C’est le moyen le plus rapide de voir si la réponse fournie par votre réseau correspond à ce que voit le reste du monde. ## Comment l’exécuter {% stepper %} {% step %} ### Ouvrez l’outil Accédez à **Outils avancés** et cliquez sur la **Résolution DNS** carte. Elle s’ouvre sur sa propre page, `/tools/dnsresolver`. {% endstep %} {% step %} ### Choisissez un type d’enregistrement Le type d’enregistrement est la liste déroulante à gauche du champ de saisie. `A` est sélectionné par défaut et constitue le bon choix pour « quelle adresse IP ce site web utilise-t-il ? » — les autres types sont expliqués en bas de cette page. {% endstep %} {% step %} ### Saisissez un domaine Tapez un nom de domaine ou collez une URL complète dans la zone. Une URL fonctionne très bien, car l’outil en extrait le nom d’hôte. Appuyez sur Entrée ou cliquez sur le bouton de lecture. {% endstep %} {% endstepper %} ## Lecture de vos résultats Les résultats apparaissent dans un tableau à deux colonnes — **Fournisseur DNS** et **Résultat de la résolution** — avec un drapeau à côté de chaque fournisseur indiquant le pays où il est basé. Au-dessus du tableau se trouve une rangée d’étiquettes régionales : **Toutes les régions**, plus une pour chaque pays présent dans les résultats. Appuyez sur l’une d’elles pour n’afficher que les résolveurs de ce pays. C’est le moyen le plus rapide de savoir si un désaccord concerne toute une région ou seulement un fournisseur. Le nom de chaque fournisseur comporte une étiquette : | Étiquette | Signification | | ---------- | ------------------------------------------------------------------------ | | `(DNS)` | Interrogé via le DNS classique, le protocole traditionnel non chiffré. | | `(DoH 🔒)` | Interrogé via le DNS sur HTTPS, une version chiffrée de la même requête. | Certains fournisseurs sont interrogés via les deux protocoles, si bien qu’un même nom peut apparaître deux fois avec des étiquettes différentes. Comparer ces deux lignes mérite à lui seul un instant : c’est la même question posée via un canal non chiffré et un canal chiffré. `N/D` signifie que ce fournisseur n’a rien renvoyé. Soit il n’existe aucun enregistrement de ce type, soit le fournisseur était injoignable depuis le serveur, soit la requête a expiré. Un seul `N/D` n’est pas un problème en soi. Interroger `SOA` sur un nom situé sous le sommet de la zone — `www.example.com` plutôt que `example.com` — est un cas utile à connaître : les lignes DoH reviennent à l’enregistrement propre de la zone, tandis que les lignes DNS classique peuvent afficher `N/D`. C’est une différence entre les deux protocoles, pas un défaut. Les réponses qui sont elles-mêmes des noms se terminent toujours par un point final, qui est la manière standard d’écrire un nom pleinement qualifié. Les deux lignes fournies par un fournisseur sont rédigées de la même façon, donc une différence visible dans le texte correspond à une réelle différence dans la réponse. ### Pourquoi les réponses peuvent différer, et pourquoi c’est souvent normal Des réponses différentes sont courantes et généralement sans conséquence : * **CDN.** Les grands sites sont servis depuis de nombreux centres de données. Un résolveur en Europe et un résolveur en Asie sont dirigés vers des serveurs de périphérie différents. * **Geo-DNS.** Certains services répondent avec une IP différente selon l’endroit d’où provient la question. * **Répartition de charge.** Un domaine peut avoir plusieurs IP et les distribuer en rotation, de sorte que deux requêtes espacées d’une seconde peuvent donner des résultats différents. * **Mise en cache.** Un résolveur peut encore renvoyer une réponse plus ancienne jusqu’à l’expiration de son cache. Voir [Comment fonctionne le DNS](/knowledge-base/fr/concepts/how-dns-works.md) pour le contexte. ### Quand une différence est suspecte {% hint style="warning" %} Toutes les divergences ne sont pas innocentes. Une réponse peut être filtrée ou réécrite n’importe où sur le trajet entre un résolveur et vous — par un opérateur réseau, par un équipement intermédiaire ou par le résolveur lui-même. Interroger des résolveurs dans de nombreux pays à la fois permet de rendre cela visible : une manipulation a tendance à se manifester comme une divergence limitée à une seule région, tandis qu’un routage CDN se traduit par de nombreuses petites différences plausibles. {% endhint %} Des schémas qui méritent un second regard : * La plupart des fournisseurs s’accordent sur un ensemble d’IP, et un ou deux renvoient quelque chose de complètement différent. * Un fournisseur renvoie une adresse privée ou réservée (quelque chose commençant par `10.`, `192.168.`, ou `127.`) pour un site web public. * Un fournisseur renvoie une adresse qui appartient à un réseau ou à un pays sans rapport. Si vous voyez l’un de ces schémas, vérifiez ce que fait votre propre appareil. Il reçoit peut-être la même mauvaise réponse.
Quel type d’enregistrement dois-je choisir ? * **A** — l’adresse IPv4 d’un site web. Commencez ici. * **AAAA** — l’adresse IPv6 d’un site web. * **CNAME** — un alias pointant vers un autre nom. Courant pour les sites derrière un CDN. * **MX** — les serveurs de messagerie qui reçoivent les e-mails pour le domaine. * **NS** — les serveurs de noms faisant autorité pour le domaine. * **TXT** — des enregistrements de texte libre, utilisés pour la vérification de domaine et les règles de messagerie comme SPF, DMARC et DKIM. * **SOA** — l’enregistrement « start of authority » : quel serveur de noms est la copie maîtresse de la zone, l’adresse de contact, et les temporisateurs que les autres serveurs utilisent pour se mettre à jour à partir de lui. * **CAA** — quelles autorités de certification sont autorisées à émettre des certificats pour le domaine.
Vérification des enregistrements e-mail : SPF, DMARC et DKIM Les trois sont `TXT` des enregistrements, et il vaut la peine de vérifier pour les trois que le monde entier voit la même valeur — une réponse obsolète ou filtrée est une cause courante des échecs soudains de la messagerie. * **SPF** — choisissez `TXT` et saisissez le domaine lui-même, par exemple `example.com`. Recherchez la valeur commençant par `v=spf1`. * **DMARC** — choisissez `TXT` et saisissez `_dmarc.example.com`. Recherchez `v=DMARC1`. * **DKIM** — choisissez `TXT` et saisissez `._domainkey.example.com`. Le sélecteur est choisi par l’expéditeur de votre courrier ; il apparaît dans le `s=` champ d’un `DKIM-Signature` de l’en-tête d’un message que vous avez déjà envoyé. Les noms commençant par un underscore sont des noms DNS ordinaires, et l’outil les accepte.
## Que faire ensuite * Vous soupçonnez que votre propre résolveur pose problème ? Suivez [Mon DNS est-il détourné ou pollué ?](/knowledge-base/fr/diagnose/is-my-dns-hijacked.md). * Vous voulez savoir quels résolveurs votre appareil utilise réellement ? Lancez le [Test de fuite DNS](/knowledge-base/fr/connection-tools/dns-leak-test.md). * Un site ne s’ouvre pas du tout ? Commencez par [Impossible d’ouvrir un site web ?](/knowledge-base/fr/diagnose/cant-open-a-website.md). * Vous voulez savoir à qui appartient une IP qui est revenue ? Recherchez-la avec [Recherche Whois](/knowledge-base/fr/lookup-privacy/whois-search.md). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.ipcheck.ing/knowledge-base/fr/lookup-privacy/dns-resolver.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.