Pourquoi le DNS reste-t-il difficile à apprendre ?

• Le DNS est utilisé depuis les années 1980, depuis plus de 35 ans, et son architecture est stable, mais il faut souvent beaucoup de temps à de nombreux programmeurs pour déboguer avec assurance des problèmes de base
• La difficulté tient moins à la complexité du DNS lui-même qu’au grand nombre de composants invisibles, comme les caches des résolveurs, les bibliothèques DNS locales et les échanges avec les serveurs de noms faisant autorité
• dig est puissant, mais la structure de sa sortie et sa terminologie sont peu familières ; des fonctions comme +norecurse sont utiles, mais l’interprétation des résultats n’est pas intuitive
• Des pièges courants comme le negative caching, l’historique de l’absence de prise en charge du DNS sur TCP par musl, les résolveurs qui ignorent les TTL, la mise en cache permanente par nginx ou ndots dans Kubernetes sont difficiles à découvrir tant que quelqu’un ne vous les a pas expliqués
• Pour les personnes qui manipulent rarement le DNS, les aide-mémoire peuvent être utiles, et les problèmes sur lesquels il est intimidant d’expérimenter peuvent être abordés dans des environnements de test sûrs comme Mess With DNS

---

Le DNS, une technologie ancienne mais toujours difficile

• Le DNS est utilisé depuis plus de 35 ans, depuis l’époque de la RFC 1034 ; il est présent sur tous les sites web d’Internet et, à bien des égards, fonctionne encore comme il y a 30 ans
• Pourtant, déboguer des problèmes de base comme « le domaine est configuré correctement mais ne se résout pas » ou « les résultats DNS de dig et du navigateur sont différents » peut prendre beaucoup de temps
• Les personnes qui trouvent le DNS difficile se bloquent généralement sur les points suivants
  • elles ne se sentent pas à l’aise même avec une simple modification DNS pour un site web
  • elles se trompent sur le fait que les enregistrements DNS ne sont pas poussés, mais tirés (pull)
  • elles connaissent les concepts de base, mais se perdent dans les comportements de détail comme le negative caching ou les différences entre les requêtes DNS faites par dig et par un navigateur

Résolveurs et serveurs de noms invisibles

• Le flux de base lorsqu’un ordinateur envoie une requête DNS paraît simple
  • l’ordinateur envoie une requête à un serveur appelé resolver
  • le resolver vérifie son cache et, si nécessaire, interroge à nouveau un authoritative nameserver
• Dans le débogage réel, plusieurs éléments importants ne sont pas visibles par défaut
  • il est difficile de savoir ce que contient le cache du resolver
  • il n’est pas évident de savoir quelle bibliothèque DNS locale traite la requête
    • il peut s’agir de libc getaddrinfo, glibc, musl, de l’implémentation d’Apple, du code DNS propre au navigateur ou d’une implémentation personnalisée distincte
    • chaque implémentation diffère légèrement par sa configuration, son mode de cache et les fonctionnalités prises en charge
    • le DNS de musl ne prenait pas en charge TCP jusqu’au début 2023
  • les échanges entre le resolver et l’authoritative nameserver ne sont pas visibles
    • si l’on pouvait suivre quel authoritative nameserver a été interrogé et quelle a été sa réponse, beaucoup de problèmes DNS seraient plus faciles à comprendre

Rendre visible le système caché

• Le simple fait d’indiquer quels sont les composants cachés aide beaucoup à l’apprentissage
  • si l’on ignore que, même sur un seul ordinateur, plusieurs bibliothèques DNS peuvent être utilisées selon le contexte, on peut rester longtemps dans la confusion
• Mess With DNS tente une expérimentation en mode fishbowl, qui montre des parties normalement invisibles
  • il permet de voir une partie des échanges entre le resolver et l’authoritative nameserver
• Une autre approche consiste à inclure des informations de débogage dans les réponses DNS
  • il existe déjà une fonctionnalité appelée Extended DNS Errors, ou EDE
  • les outils ajoutent progressivement la prise en charge d’EDE

Les indices fournis par Extended DNS Errors

• Extended DNS Errors est une nouvelle façon pour les serveurs DNS de fournir des informations de débogage supplémentaires dans leurs réponses
• Si l’on interroge le domaine inexistant xjwudh.com avec dig @8.8.8.8 xjwudh.com, on peut obtenir une erreur supplémentaire comme celle-ci

; EDE: 12 (NSEC Missing): (Invalid denial of existence of xjwudh.com/a)

• Cet exemple semble lié à DNSSEC ; l’important est que la réponse contient également un message de débogage supplémentaire
• Pour voir l’exemple ci-dessus, il fallait une version plus récente de dig

dig, puissant mais difficile à lire

• dig est utile pour inspecter l’état interne du DNS
• Avec dig +norecurse, on peut vérifier quels enregistrements un resolver DNS donné a dans son cache
  • 8.8.8.8 semble renvoyer SERVFAIL si la réponse n’est pas en cache
  • google.com étant en cache, il renvoie NOERROR et un enregistrement A
  • homestarrunner.com n’étant pas en cache, il renvoie SERVFAIL, mais cela ne signifie pas qu’il n’existe pas d’enregistrement DNS
• La sortie de dig est difficile à lire quand on n’y est pas habitué
  • des intitulés comme ->>HEADER<<-, flags:, OPT PSEUDOSECTION:, QUESTION SECTION:, ANSWER SECTION: sont peu familiers
  • les sauts de ligne et les espaces entre sections ne semblent pas toujours cohérents
  • dans MSG SIZE rcvd: 47, il est difficile de savoir s’il existe d’autres champs que rcvd
  • il faut savoir que lorsqu’il est indiqué qu’il y a 1 enregistrement dans la section ADDITIONAL, c’est en réalité l’OPT PSEUDOSECTION qui joue ce rôle
• La sortie de dig ressemble moins à un format conçu intentionnellement dès le départ qu’à un script qui a grandi organiquement au fil du temps

Comment rendre les outils DNS plus lisibles

• Une documentation expliquant la sortie de dig elle-même est utile
  • how to use dig explique la structure de la sortie de dig et comment rendre la sortie par défaut plus courte
• On peut aussi créer des outils plus conviviaux
  • il existe des alternatives comme dog, doggo et DNS lookup tool
  • toutefois, quand on a besoin de fonctions avancées comme +norecurse, il peut être préférable de tout faire avec dig
  • remplacer l’étendue des fonctionnalités de dig est un gros chantier
• On pourrait aussi ajouter à la sortie de dig une option comme +human, qui présenterait les mêmes informations de façon plus structurée
  • on pourrait séparer clairement l’en-tête, la requête, la réponse, les sections supplémentaires, le temps, le serveur, le protocole et la taille de la réponse
  • l’approche ne consiste pas à réduire la quantité d’informations, mais à présenter les mêmes informations de manière plus lisible
• Les versions récentes de dig disposent d’un format de sortie +yaml
  • il peut sembler plus clair, mais il peut aussi être si verbeux que même une réponse DNS simple ne tient pas à l’écran

Des pièges DNS fréquents mais difficiles à apprendre

• Le DNS comporte des pièges relativement courants, mais difficiles à connaître tant que quelqu’un ne vous les a pas signalés

• negative caching

  • si l’on visite un domaine qui n’a pas encore d’enregistrement DNS, l’état « absent » de cet enregistrement peut être mis en cache
  • si cet état reste en cache pendant plusieurs heures, cela devient très pénible

• Différences d’implémentation de getaddrinfo

  • musl ne prenait pas en charge le DNS sur TCP jusqu’au début 2023

• Résolveurs qui ignorent les TTL

  • même si l’on définit le TTL d’un enregistrement DNS à 5 minutes, certains resolvers peuvent l’ignorer et le conserver en cache beaucoup plus longtemps, par exemple 24 heures

• Problème de configuration nginx

  • si nginx est mal configuré, il peut mettre des enregistrements DNS en cache indéfiniment

• ndots dans Kubernetes

  • ndots peut ralentir le DNS de Kubernetes

Partager et documenter les pièges

• Les connaissances sur les pièges étranges sont difficiles à acquérir, et il est inefficace que les gens doivent redécouvrir sans cesse les mêmes problèmes
• Lorsqu’on explique un sujet, il est très utile de signaler également les pièges courants
  • pour prendre un exemple hors DNS, l’introduction de Josh Comeau à Flexbox explique le piège de la taille minimale
• Il est aussi utile que la communauté rassemble les pièges courants
  • pour Bash, shellcheck est très utile comme recueil de pièges Bash
• Documenter les pièges DNS est également difficile, car les problèmes rencontrés varient selon les utilisateurs
  • une personne qui configure le DNS de son domaine personnel une fois tous les trois ans et une personne qui exploite le DNS d’un domaine à fort trafic peuvent rencontrer des pièges différents

Utilisation rare et difficulté à expérimenter

• Beaucoup de gens manipulent le DNS très rarement
  • si l’on ne touche au DNS qu’une fois tous les trois ans, il est naturel que ce soit difficile à apprendre
  • un aide-mémoire sur des sujets comme « la procédure de changement de serveurs de noms » peut être utile
• Le DNS est aussi une technologie sur laquelle on hésite à expérimenter, par crainte de casser son propre domaine
  • Mess With DNS a été créé pour réduire cette difficulté à expérimenter

[GN⁺]

Avis sur Hacker News

• Je ne suis pas d’accord avec cet article. DNS est simplement quelque chose que peu de gens prennent le temps d’apprendre ; en réalité, je ne pense pas que ce soit difficile à apprendre
  Ce qu’il y a de bien avec DNS, c’est que le système expose son état interne en réponse aux requêtes. Il est facile d’examiner un serveur DNS pour une zone connue et de comprendre son fonctionnement, et des outils gratuits comme dig sont largement disponibles
  J’ai toujours été surpris que, tout au long de ma carrière, les gens avec qui j’ai travaillé se souviennent surtout de mes connaissances en DNS, parce que je n’ai pas l’impression de savoir quelque chose de mystérieux ou de spécial. DNS est très bien standardisé, les implémentations courantes de serveurs et de clients suivent strictement les standards, et il est facile de l’observer avec des outils gratuits. Cela demande des efforts et du temps, mais ce n’est pas vraiment difficile

  • En tant qu’auteur de l’article, j’aimerais dire quelques mots sur l’idée que DNS n’est pas vraiment difficile. Il m’a fallu plusieurs années avant d’être parfaitement à l’aise pour déboguer des problèmes DNS, et j’ai écrit cet article pour expliquer pourquoi cela m’avait paru difficile
    Avant, je pensais que « non, en fait c’est facile ! » était une forme d’encouragement face à quelqu’un qui disait que c’était difficile à apprendre. J’aime DNS, et je pense aussi qu’il est étonnamment simple à bien des égards. Par exemple, sur https://implement-dns.wizardzines.com, je montre comment implémenter de zéro un résolveur DNS jouet en Python avec du code simple
    Mais avec le temps, j’ai appris que « non, c’est facile à apprendre ! » est souvent perçu moins comme un encouragement du type « tu peux y arriver ! » que comme « ce n’est pas difficile, c’est toi qui es idiot ». Quand on a été embrouillé pendant des années par un sujet, entendre « en fait, c’est facile » n’aide pas beaucoup
    Donc maintenant, j’évite de le dire, et je consacre beaucoup d’efforts à comprendre pourquoi certaines choses paraissent difficiles aux gens et à réduire ces obstacles
  • Je pense que c’est difficile à apprendre si l’on regarde les outils pour apprendre DNS
    BIND fait très bien son travail, mais ses fichiers de configuration ne sont pas terribles, et son manuel est long, aride et parfois inutilement complexe. dig est puissant, mais il abrège tout comme à l’époque des terminaux en 80 colonnes. Pour déboguer des problèmes DNS, Wireshark a parfois été un meilleur outil que dig
    Si l’on faisait utiliser PowerDNS ou d’autres serveurs DNS modernes, je pense qu’il serait beaucoup plus facile de configurer un serveur DNS fonctionnel. Je ne connais pas vraiment de bon client DNS moderne, donc j’ai fini par m’habituer à dig. Comme quelqu’un qui utilise le flag --color de la commande ip, j’aimerais que des outils comme dig proposent une sortie plus moderne. Je mettrai les flags de ligne de commande dans des alias, alors ajoutez juste la fonctionnalité
    Sérieusement, MSG SIZE rcvd: 71 n’avait pas besoin d’être abrégé. flags: qr rd ra aurait aussi pu être écrit en toutes lettres. Je ne vois pas non plus ce que les points-virgules en début de ligne sont censés communiquer ; au contraire, ça ne fait qu’ajouter de la confusion
    Il n’est pas étonnant que les gens soient perdus en apprenant DNS avec les ressources disponibles
  • Tu dis « je ne suis pas d’accord avec cet article », mais tu sembles surtout t’opposer au titre sans vraiment répondre aux arguments de l’article. En plus, tu sembles mélanger DNS est difficile et DNS est difficile à apprendre
    Si cela demande simplement « un peu d’efforts et de temps », combien d’efforts et de temps exactement ? Plusieurs personnes dans ce fil disent l’avoir appris en implémentant un serveur, expliquent qu’il leur a fallu des mois pour comprendre, puis répètent qu’« une fois qu’on a compris, c’est assez facile ». Dans ce cas, ne peut-on pas s’accorder à dire que, pour quelque chose d’aussi répandu et conceptuellement simple, c’est effectivement difficile à apprendre ?
  • En lisant l’article, on voit pourquoi c’est difficile à apprendre. Les concepts sont simples, mais quand on les enseigne, on n’inclut pas tous les détails de l’Internet moderne
    Par exemple, quelles sont les règles selon lesquelles un navigateur met en cache et expire les entrées DNS ? Ces règles sont-elles cohérentes d’un navigateur à l’autre ?
  • Je vois DNS comme l’une de ces technologies dont on peut picorer des fragments ici et là tout au long de sa carrière sans jamais vraiment l’affronter de front. Si beaucoup de gens avaient dû s’y confronter directement, cela leur aurait semblé moins complexe qu’en réalité ; dans notre industrie, ce genre de chose finit par acquérir une sorte d’aura de mystère

• Je pense que l’article met le doigt sur l’essentiel. DNS en lui-même n’est pas difficile, mais apprendre le DNS du monde réel l’est. C’est parce qu’une grande partie de ce qui se passe entre la requête que l’on voulait faire et le résultat attendu est cachée
  Autrefois, la connexion Internet de base, c’était une interface, une passerelle, un fournisseur de serveurs DNS. Aujourd’hui, on peut être connecté simultanément à plusieurs WAN, comme LTE et Wi-Fi, et l’utilisateur a du mal à savoir quel chemin de résolution a réellement été utilisé. On ne sait pas clairement si c’était le navigateur, l’interface standard de la bibliothèque C du système, un résolveur local ou récursif intermédiaire, s’il y a un cache local, ni si des options spéciales sont ajoutées par défaut
  Même quand tout fonctionne, on ne peut pas croire aveuglément que la requête et la réponse d’une application ont suivi le même chemin que celles d’une autre. Trois navigateurs peuvent chacun utiliser une méthode différente, le système d’exploitation peut encore fonctionner autrement, et mDNS peut ajouter une cinquième option

• Il y a une blague selon laquelle il n’existe que trois problèmes difficiles en informatique : l’invalidation du cache et nommer les choses
  Et DNS est un système de cache pour les noms des choses
  https://reddit.com/comments/15c2ul2/comment/jtty9dy

  • Pour être juste, DNS est l’un des cas où le nommage a été bien fait
    Il est géré à l’échelle mondiale (IANA), hiérarchique, fédéré, et facile à modifier

• Le DNS fait partie de ces technologies où il existe un décalage entre l’impression de simplicité qu’elles donnent et la difficulté qui apparaît réellement
  Nous utilisons le DNS tous les jours, et cela paraît très simple. Le vocabulaire DNS du quotidien, ce sont les noms de domaine, les requêtes, les adresses IP. Ce vocabulaire est exposé tel quel dans le navigateur, et cette exposition nous amène à construire un modèle mental de son fonctionnement
  Mais à l’intérieur, il existe un langage complètement différent, avec des zones, des résolveurs, des autorités déléguées, et ce drôle de point derrière les domaines de premier niveau

  • Ce drôle de point s’appelle la racine. Sans point, le nom n’est pas complet ; avec un point, le nom est entièrement défini. Autrement dit, tout est une question de contexte. Sans point, le résolveur peut ajouter à répétition son propre domaine, ou une partie de celui-ci
    Par exemple, nous savons tous les deux ce que signifie host.example.co.uk, mais sans point final, le résolveur peut essayer de rechercher host.example.co.uk.example.co.uk
    Avec la configuration par défaut de Windows, dans ce cas, il peut essayer host.example.co.uk.example.co, host.example.co.uk.example, puis à nouveau host.example.co.uk.example, et enfin host.example.co.uk., et obtenir un résultat. Cela dit, je n’ai jamais vu Windows faire réellement la première tentative, et ce comportement semble avoir été conçu pour gérer des environnements de grandes entreprises où le DNS doit composer avec des Active Directory fédérés monstrueux
    Les navigateurs modernes ont de fortes chances de filer en douce, sans le consentement de l’utilisateur, vers des serveurs DNS over HTTPS (DoH) et de fréquenter toutes sortes d’interlocuteurs louches. Les requêtes DNS sont des données fondamentales, et les FAI ont toujours aimé voir où vont leurs utilisateurs. Les éditeurs de systèmes d’exploitation peuvent évidemment envoyer de la « télémétrie ». Google ne possède pas le poste de travail, mais possède le navigateur ; il est donc dans son intérêt de pousser l’utilisateur à utiliser ses serveurs DNS « sûrs » plutôt que le DNS qu’il a configuré. À cause de ces combines, le dépannage informatique est devenu bien plus palpitant qu’avant
    Il ne faut pas trop s’inquiéter du point final. De toute façon, il est presque certain que vous n’utilisez pas le serveur DNS que vous pensez utiliser. Je comprends pourquoi DoH a été créé, et certains utilisateurs grand public ont des raisons de l’utiliser. Par exemple, si une personne qui n’est pas spécialiste IT utilise un point d’accès Wi-Fi malveillant, le fait que le navigateur revienne en sécurité vers sa base pour effectuer les requêtes DNS offre une certaine protection. Mais savoir si un éditeur de navigateur peut piétiner les choix de sécurité de l’utilisateur sur son endpoint est une autre question
    Le DNS est bien plus complexe qu’une simple recherche d’adresse. Aujourd’hui, c’est une question d’argent — et en réalité, cela l’est depuis environ 2000. Il existe désormais beaucoup de très grandes entreprises extrêmement obstinées qui veulent décider qui tirera profit de l’utilisateur
  • À mon avis, ce qui est difficile, c’est la partie distribuée. Au-dessus du niveau atomique des nœuds individuels, il se passe une quantité énorme de magie noire, et c’est elle qui crée la majeure partie de la complexité et de l’opacité
    Le DNS lui-même est simple. La distribution d’informations indépendamment d’une organisation est vraiment délicate

• Il y a quelques années, je me suis rendu compte que je ne comprenais le DNS que par morceaux. Je connaissais dig(1), BIND, et les concepts de niveau CS101 sur le fonctionnement de la résolution DNS récursive, mais il me manquait les connaissances pratiques nécessaires pour concevoir et implémenter un système non trivial, ou pour déboguer un système qui ne fonctionne pas
  J’ai donc lu “DNS and BIND” presque du début à la fin, et j’ai aussi configuré de vrais serveurs BIND pour quelques sites web personnels peu critiques. Ce n’était pas difficile, mais cela demandait un investissement en temps assez important. BIND n’est pas forcément la bonne réponse pour beaucoup de cas d’usage, mais comme de nombreux concepts et termes du DNS viennent encore de BIND, cela a été très utile
  Je pense que les livres sont sous-estimés pour apprendre ce genre de choses. Les ressources que l’on trouve sur le web sont généralement soit de la théorie de haut niveau, par exemple des schémas de requêtes récursives, soit des contenus orientés tâche, comme la manière d’effectuer une requête récursive avec dig, soit des ressources de bas niveau, comme lire le code source pour comprendre la politique de retry du client DNS local. Pour comprendre chaque pièce, comment elles s’emboîtent, ce qu’elles cherchent à accomplir, jusqu’aux détails d’implémentation comme l’emplacement des caches, il y a peu de substituts à l’approche globale que l’on trouve souvent dans les livres. Sur le web, cela existe aussi, mais c’est rare

• Toute personne travaillant dans l’IT gagnerait à avoir des connaissances pratiques du débogage des problèmes DNS
  Le DNS a historiquement été un vecteur de vulnérabilités de sécurité importantes, et il y a de fortes chances que cela continue. Ces vulnérabilités ouvrent des chemins d’attaque vers presque tous les autres protocoles, comme SMTP. Même le système des autorités de certification utilisé par HTTPS dépend largement d’un protocole qui n’est pas sûr par défaut. Si une banque achetait un certificat DV au lieu d’un OV, le remarqueriez-vous ? Probablement pas
  Donc, pour les personnes peu intéressées, le fait que le DNS paraisse difficile à apprendre n’est pas forcément une mauvaise chose. On voit encore des gens développer des fonctionnalités liées au DNS sans prendre le temps de comprendre correctement l’histoire de choses comme la randomisation des ports, l’empoisonnement de cache ou AXFR

  • Tout ce qui diffuse ou revendique des décisions de routage à n’importe quelle couche du réseau me semble plus simple en apparence qu’en réalité, et potentiellement dangereux

• Pour faire une promotion éhontée de mon side project : l’article disait qu’il serait pratique d’avoir un mode « debug » pour la résolution DNS, et cette fonction existe dans l’interface web de ComfyDNS :3
  https://comfydns.com/
  L’image en haut où il est écrit TRACE google.com A IN montre cette fonctionnalité
  ComfyDNS est aussi un projet né d’un besoin personnel. J’en avais assez de modifier à la main des fichiers de zone bind9, et j’étais curieux de comprendre comment fonctionne le DNS. Je connaissais les grandes lignes, mais pas les détails, alors j’ai implémenté les RFC « depuis le début ». J’ai utilisé netty, mais pas de bibliothèque DNS. C’était assez amusant
  Désolé si le site ne tient pas la charge et tombe. C’est une application Rails qui tourne sur le niveau gratuit d’Oracle Cloud

• La blague que j’ai toujours entendue, c’est que le DNS combine deux des problèmes les plus difficiles de l’informatique : nommer les choses et invalider les caches

  • Le DNS a des compteurs de validité en secondes, et on peut être assez approximatif dans le comptage de ces secondes
    Ce n’est pas le type difficile d’invalidation de cache. En fait, il est rarement nécessaire d’« invalider » quoi que ce soit
    Côté serveur aussi, il est parfaitement acceptable de servir pendant un moment un mélange de l’ancienne et de la nouvelle version
  • Ce n’est pas une blague, c’est exact

• J’ai l’impression de voir encore ce genre d’article. Dans les années 1990, Internet était plus petit et les ordinateurs étaient bien plus lents et moins puissants, mais nous apprenions tout ça très facilement
  À l’époque, pour un FAI, des choses comme DNS, LDAP, SMTP, IMAP étaient vraiment la base, et les gens lisaient réellement des documents officiels comme les RFC. Si l’on voulait exploiter un serveur sur Internet, il fallait apprendre, et avec un petit investissement en temps — c’est-à-dire du temps payé au travail — on pouvait y arriver
  La génération actuelle de développeurs et de DevOps manque de patience ou d’initiative, attend qu’on lui mâche le travail, et copie-colle n’importe quoi depuis StackOverflow et des blogs sans grande valeur. Plutôt que d’apprendre les fondations sur lesquelles Internet a été construit, elle prend l’outil wrapper à la mode de la semaine, suit des instructions de blog médiocres, puis crie à l’injustice quand tout s’effondre et que l’entreprise perd beaucoup d’argent. Tout ça parce qu’elle n’a pas pris le temps d’apprendre les bases de ce qui se passe réellement sur Internet
  J’ai vu ça encore et encore. En réalité, ce n’est pas si difficile. Il suffit de faire ses devoirs

• Ce n’est pas difficile. DNS est l’une des rares technologies qui n’a pas beaucoup changé, et son fonctionnement est assez intuitif
  dig peut être un peu déroutant. Il a plus de fonctionnalités que le vieux nslookup, mais il est moins intuitif. À noter que nslookup fonctionne encore très bien
  À mon avis, l’une des raisons pour lesquelles les jeunes du secteur s’y perdent avec DNS et les protocoles fondamentaux, c’est qu’aujourd’hui trop de choses “fonctionnent tout simplement”
  Par exemple, de nos jours, un routeur Wi-Fi “fonctionne tout simplement” dès qu’on le sort de la boîte. Au début des années 2000, pour configurer ce genre de chose, il fallait un ingénieur réseau qui comprenne DNS, IP, Ethernet, RFC1918, les vrais protocoles de routage et beaucoup d’autres choses, et qui sache très bien pourquoi il configurait tout ainsi
  Si vous trouvez que DNS côté client est déroutant, essayez de configurer BIND ;-)
  /râlerie de vieux barbu grisonnant

  • À 14 ans, j’ai administré de façon assez bancale l’environnement Active Directory d’un restaurant, avec la messagerie, le web et CIFS, sans comprendre DNS ni DHCP
    J’aurais dû faire en sorte que le serveur DHCP du WRT54G distribue l’IP fixe du contrôleur de domaine comme serveur DNS pour que la résolution de noms fonctionne correctement, mais j’ai tout fait tourner avec de simples adresses IP et des entrées dans les fichiers hosts. J’avais aussi configuré l’enregistrement MX du domaine sur l’IP WAN du routeur, sans enregistrement PTR. Avec le recul, c’est un miracle que la livraison des e-mails ait été aussi fluide
    Quelques années plus tard, j’ai compris comment DNS fonctionnait réellement, et au début de la vingtaine, j’ai hérité d’un intranet d’entreprise qui utilisait BIND comme serveur de noms pour toutes les zones de domaines externes de l’entreprise. En migrant cette configuration vers un VPS pour améliorer la fiabilité, j’ai énormément appris sur les transferts de zone, les SOA, etc. Je suis reconnaissant pour cette expérience, mais aujourd’hui presque tout est pris en charge à notre place, ce qui en fait une activité à faible valeur. Pour le meilleur ou pour le pire, “l’IT” n’est pas valorisée de la même manière que “l’ingénierie logicielle”
  • C’est vrai que le fonctionnement est relativement intuitif, mais seulement si l’on ignore toutes les bizarreries possibles, comme les serveurs qui ignorent le TTL
    Je n’oublierai jamais la mise à jour de Firefox qui a activé DNS-over-HTTPS par défaut. Nous distribuions nos serveurs DNS internes aux postes via DHCP, et soudain les messages “mes e-mails ont disparu ! tout est cassé !” ont afflué. Le webmail interne et les serveurs web de l’intranet semblaient avoir tout simplement disparu
    Il nous a fallu beaucoup plus de temps que nécessaire pour comprendre ce qui se passait. En partie parce qu’on se disait : “c’est DNS, pourquoi ça casserait soudainement ?”. Mais il est assez clair que Mozilla n’avait pas anticipé ce problème pourtant facile à prévoir
  • Ce qui est mentionné ici ne représente qu’une petite partie de DNS
    Par exemple, je fais une requête pour thing.behind.cdn.it et j’obtiens une réponse, tandis qu’une autre personne obtient une réponse différente pour le même nom. En soi, c’est assez évident, mais ça se complique quand quelqu’un demande de façon raisonnable : “pouvez-vous ouvrir un trou dans le pare-feu pour thing.behind.cdn.it ?”
    Certains serveurs transmettent les requêtes, d’autres délèguent, certains font la résolution à votre place et d’autres non. Il y a aussi la magie des domaines de recherche côté client, et l’incertitude sur le fait que le client ou la bibliothèque de résolution interne respecte ou non le TTL
    Il existe aussi une quantité innombrable de types d’enregistrements, et parfois le serveur vous demande de vous reconnecter en TCP plutôt qu’en UDP
    DNS est donc assez complexe. Il donne l’illusion d’être simple parce qu’il fonctionne très bien et que la plupart des parties délicates sont abstraites derrière des choses qui “fonctionnent généralement tout simplement”
  • À propos de la connaissance des anciens protocoles, ces dernières semaines j’ai lu Networking for System Administrators et j’ai pris beaucoup de notes sous forme de cartes Anki, que j’ai révisées
    Je suis surpris de voir à quel point cela m’a rendu plus sûr de moi dans ma compréhension de haut niveau du réseau, y compris DNS et ce qu’il y a en dessous, comme ethtool et les trames Ethernet
    J’aime comprendre les choses depuis la base, au point d’avoir choisi le génie électrique plutôt que l’informatique à l’université, donc ce n’est peut-être pas si surprenant
  • Oui, la configuration de BIND est difficile. Unbound/nsd sont beaucoup plus faciles à gérer. Cela dit, trouver la bonne documentation est en soi un exercice agaçant
    Le principe de DNS n’est pas si difficile dès lors qu’on comprend qu’il est récursif. Mais si l’on veut le configurer en tenant compte de la sécurité, disposer de la bonne infrastructure et régler jusqu’au moindre détail, il y a beaucoup à apprendre. Si l’on met BIND de côté, ce n’est pas si difficile