Qui exploite 1.1.1.1 ? Vérifier une adresse DNS avant de lui faire confiance

Vous avez collé 1.1.1.1 dans le champ DNS du VPN, la page s’est chargée, et le tutoriel semble désormais confirmé. Cette observation est plus étroite qu’il n’y paraît : l’application s’est comportée différemment, et le changement ne dit encore rien sur qui a répondu à la requête ni pourquoi l’ancienne configuration a échoué. Un tutoriel recopié appelle souvent « le DNS du VPN » une adresse publique familière, ce qui est une affirmation sur la propriété et non sur l’accessibilité. Vérifier ce que l’adresse représente prend cinq minutes et évite un changement permanent fait pour la mauvaise raison.

Un réglage qui fonctionne n’est pas une identité

L’adresse d’un champ de réglage est un point de terminaison, et un point de terminaison a un exploitant. Ces deux faits sont distincts, et c’est le second que l’on saute. Pour la paire la plus souvent copiée, la réponse est publique : Cloudflare publie 1.1.1.1 et 1.0.0.1 comme adresses de son résolveur, et les répertorie dans sa référence officielle d’adresses. C’est pourquoi le nom de l’exploitant va à côté de l’adresse, et non dans un tutoriel séparé.

Saisir cette paire alors qu’un tunnel est actif ne fait pas de l’entreprise du VPN son exploitant, et ne rend pas le trafic anonyme. La requête quitte votre machine vers une entreprise qui publie la plage d’adresses, et cette entreprise peut être respectable sans être pour autant la partie que le tutoriel laissait entendre. L’étiquette dans les instructions et l’exploitant réel sont deux affirmations différentes. Ni l’une ni l’autre ne dit qui exploite le chemin réseau intermédiaire.

Utilisez la référence publiée du résolveur lui-même pour confirmer une paire d’adresses ou un point de terminaison chiffré. Une recommandation d’un autre fournisseur peut être légitime, et « recommandé par », « atteint via » et « exploité par » décrivent toujours trois relations différentes.

Comparez les trois éléments dont un enregistrement a besoin

Un enregistrement prêt pour la revue sépare trois questions : qui doit recevoir la requête, si l’échange est en clair ou chiffré, et quel chemin doit le porter. Un nom de fournisseur ne peut remplir ni la deuxième ni la troisième, et une étiquette de pays ne peut remplir aucune des trois. Notez les trois entrées avant le changement et comparez-les ensuite. Ces entrées ne sont pas interchangeables, et les traiter comme une seule est la façon dont une supposition devient de la documentation.

C’est la comparaison qui transforme un réglage qui fonctionne en décision documentée. Sans elle, la personne suivante hérite d’une adresse sans aucune raison attachée. Lisez d’abord la troisième colonne du tableau ci-dessous, car c’est là que la plupart des explications assurées s’arrêtent en réalité.

Le tableau est volontairement court. Son point est que chaque entrée répond à une question différente, et qu’aucun champ unique ne remplit les trois.

Un redirecteur local masque la véritable source

Un appareil configuré pour utiliser son routeur comme DNS pointe vers un redirecteur. Cette adresse identifie le prochain destinataire de la requête, pas le résolveur qui y répond finalement. Un résolveur stub local ajoute la même étape supplémentaire, et il est facile de le confondre avec la vraie chose parce qu’il apparaît dans chaque sortie d’état.

Le stub redirige vers des sources que la même sortie répertorie aussi, généralement plus bas. Lisez toute la chaîne avant de conclure quoi que ce soit sur l’exploitant, car la première ligne n’est pas toute la réponse. Sinon, vous nommez l’accueil comme l’entreprise.

resolvectl status | grep -A4 'Current DNS Server'
dig +short CH TXT whoami.cloudflare @1.1.1.1
dig example.com | grep -E '^;; SERVER'

La deuxième commande utilise le nom d’écho d’un résolveur, lorsque l’exploitant en publie un, pour signaler l’adresse source qu’il voit. La troisième nomme le serveur qui a répondu, qui n’est souvent pas l’adresse que vous avez configurée. Comparez les trois sorties avant de noter un exploitant.

Le DNS chiffré change ce qui est visible, pas qui le voit

DNS over HTTPS et DNS over TLS protègent l’échange entre le client et le résolveur. Le résolveur lit toujours chaque nom qu’on lui demande, car répondre est son métier. Ce qui change, c’est qui peut observer l’échange : le réseau local voit une connexion vers un seul point de terminaison plutôt qu’un flux de requêtes en clair.

Ce qui ne change pas, c’est la relation de confiance, qui pointe toujours vers l’organisation qui exploite ce point de terminaison. Un navigateur doté de son propre réglage DNS sécurisé peut contourner entièrement le résolveur du système d’exploitation. Traitez-les comme deux configurations qui peuvent diverger, et non comme un réglage appliqué deux fois.

Les noms privés ont de nouveau besoin de leur propre décision. Un tunnel professionnel peut acheminer certains domaines vers des résolveurs de l’organisation, et le remplacer par un service public peut casser les recherches internes ou divulguer des noms internes à la mauvaise partie. Vérifiez la politique de domaines avant de remplacer les réglages de tout un adaptateur.

Gardez l’observation étroite

Quand vous comparez, conservez l’ancienne configuration et ne changez qu’un réglage à la fois. Notez l’application, l’opération, la politique du résolveur, et si les noms publics et les noms privés autorisés se résolvent encore après une reconnexion. Une comparaison comportant deux changements n’en prouve aucun. Écrivez le résultat là où la personne suivante le trouvera, à côté du réglage lui-même.

resolvectl query intranet.corp.example
resolvectl domain
dig +short @1.1.1.1 example.com

Si l’application se met à fonctionner, gardez l’affirmation aussi petite que les preuves le permettent. Ce changement a aidé un test, et il ne dit rien sur le fait de savoir si le résolveur précédent a agi de mauvaise foi, si le tunnel était cassé, ou si un autre appareil a besoin du même remplacement. Le résultat durable est une configuration dont vous pouvez expliquer l’exploitant et l’objectif.