Ce n'était pas, bien sûr, la
première discussion d'une question sur Habré . Cependant, jusqu'à présent, les conséquences ont été principalement discutées, alors que, à notre avis, les causes profondes sont beaucoup plus intéressantes.
Ainsi, la
journée du drapeau DNS est prévue pour le 1er février. Les effets de cet événement se produiront progressivement, mais toujours plus vite que certaines entreprises ne pourront s'y adapter.
Qu'est ce que c'est En termes simples, il s'agit d'un
manifeste des principaux développeurs de serveurs DNS
du monde: CZ.NIC, ISC, NLnet Labs et PowerDNS.
Les fabricants de logiciels DNS sont confrontés depuis longtemps à un problème: le développement d'un système de noms de domaine, l'ajout de nouvelles fonctions requises par les clients, la solution de problèmes de sécurité - tous ces processus sont considérablement ralentis en raison de la structure coopérative du système DNS et de la nécessité de prendre en charge des serveurs archaïques qui implémentent des versions de protocole héritées (et même cela se fait souvent avec des erreurs).
Situation exceptionnelle
Selon le
catalogue des normes de protocole DNS , la spécification actuelle contient, au 21 janvier 2018, 3248 pages. Ils incluent tous les RFC pertinents dans les statuts de
«norme Internet» ,
«norme proposée» (qui est essentiellement la même pour aujourd'hui),
«meilleures pratiques actuelles» et
«informationnel» . À titre de comparaison: le protocole HTTP, qui fournit la diffusion de contenu pour tous les sites Web sur Internet, est décrit au total sur 672 pages.
Comme le dit le proverbe, si le mandat de votre projet ne ressemble pas à quelque chose comme ça, n'essayez même pas de m'inviter.
La nécessité d'implémenter le traitement de toutes les fonctions et exceptions décrites sur 3000 pages est un travail difficile en soi, et en outre, un certain nombre de serveurs DNS implémentent incorrectement telle ou telle fonctionnalité, ce qui conduit à la nécessité de traiter en plus un comportement non standard. Dans certains des RFC susmentionnés, le désespoir des personnes accablantes travaillant avec le protocole est éclaboussé
même dans le nom .
Selon des développeurs DNS clés, la situation avec la complexité du code du programme est déjà suffisamment grave pour prendre des mesures drastiques. Le 1er février, dans le cadre d'une action coordonnée, des versions mises à jour de tous les principaux serveurs DNS seront publiées, dans lesquelles la prise en charge de certains comportements incorrects sera interrompue maintenant et pour toujours.
Et plus en détail?
Pour expliquer ce qui cessera exactement d'être pris en charge, je donnerai une analogie. Imaginons que jusqu'en 1999, les gens n'étaient pas autorisés à monter dans un avion avec des bagages et qu'en 1999, par une décision officielle de l'autorité de contrôle, les passagers étaient autorisés à embarquer des bagages (d'un certain poids et d'une certaine taille). Assez confortable, non? Vous pouvez transporter beaucoup de choses utiles.
Imaginez maintenant qu'en 2019, il y a encore des avions qui ne peuvent pas être transportés avec des bagages, et jusqu'à l'embarquement, vous n'avez aucun moyen de savoir si vous pouvez apporter des bagages avec vous.
C'est à peu près le cas de
l'extension EDNS , dont le manque de prise en charge à partir du 1er février entraînera l'inaccessibilité de plusieurs sites Internet. Grosso modo, en février, en raison du vingtième anniversaire de la
première norme EDNS , les avions qui ne savent pas embarquer les bagages (au moins minimes) ne seront plus autorisés dans un certain nombre d'aéroports.
Une annonce à ce sujet a été publiée suffisamment à l'avance: en mars-mai 2018, les principaux organisateurs de la journée du drapeau DNS ont informé le public lors de
plusieurs conférences populaires de l'industrie . De plus, la publication de versions mises à jour des serveurs DNS à elle seule ne posera pas de problème immédiatement, car les opérateurs doivent toujours passer à ces versions, ce qui prend du temps. Mais, plus important encore, un certain nombre de fournisseurs de services DNS basés sur le cloud ont également rejoint DNS Flag Day. Il s'agit notamment de géants tels que Google (et leur célèbre serveur DNS avec une adresse IP de 8.8.8.8), Cloudflare, Facebook et Cisco.
En conséquence, les sites qui utilisent des serveurs DNS sans prise en charge EDNS (c'est-à-dire des "avions" qui ne savent pas "transporter des bagages à bord") cesseront de fonctionner pour tous ceux qui utilisent des serveurs DNS ouverts 8.8.8.8, 9.9.9.9 à partir du 1er février, 1.1.1.1 et plusieurs autres. À mesure que les fournisseurs DNS mettent à niveau leurs FAI, la liste s'allonge.
La particularité du fonctionnement du serveur DNS dans l'infrastructure d'entreprise est qu'il ne demande généralement pas, qu'il fonctionne pour lui-même et fonctionne, par conséquent, il n'est souvent jamais mis à jour par personne. Les administrateurs système de la vieille école
aiment même
être fiers de la disponibilité à long terme de ces machines. Le problème est que lorsqu'il devient nécessaire de mettre à niveau, il s'avère que pour cela, vous devez, par exemple, également passer de FreeBSD 5 à FreeBSD 10 (le cas réel), qui, entre autres problèmes, nécessitera un redémarrage, et à partir du redémarrage, l'ancien serveur est déjà peut tout simplement pas sortir.
La chose la plus désagréable est que la solution au problème dans le cas général ne se résume pas à une simple mise à jour des serveurs DNS. Certaines organisations utilisent des pare-feu (logiciels et matériels-logiciels) qui forcent la suppression forcée de tous les paquets DNS avec la fonction EDNS. Entre autres choses, les anciens modèles Juniper SRX y étaient engagés, mais la question ne se limite nullement à eux. En principe, si nous parlons de pare-feu et de solutions DPI en général, le niveau de qualité de développement d'un certain nombre de ces solutions est assez connu depuis longtemps. Toutes ces années, les développeurs du protocole DNS ont souffert des problèmes qu'ils ont objectivement causés, et maintenant ils ont décidé de riposter.
Mais la mise à jour de ces solutions peut prendre un temps considérable, et dans certains cas, il peut être nécessaire de jeter l'équipement jadis cher à la poubelle et d'en acquérir de nouvelles, ce qui entraînera de nombreuses difficultés, par exemple, dans le cadre du cycle budgétaire russe (en particulier si l'équipement mis au rebut a été fabriqué en à l'étranger, et il n'y a plus de possibilité d'acheter des étrangers auprès d'une organisation pour une raison ou une autre - financière, politique, idéologique).
Donc, pour ceux qui ont ce problème, il est temps de commencer à le résoudre. Notez que les solutions immédiates ne nécessitent que les problèmes que l'
outil de vérification correspondant affiche avec «STOP» ou «SLOW» en rouge. Le point d'exclamation dans le triangle jaune n'est pour l'instant qu'un avertissement et le 1er février ne posera pas de problème (bien qu'à long terme ce problème doive être résolu).
Et puis quoi?
Premièrement, le DNS Flag Day ne devrait pas provoquer de cataclysmes importants.
Dans diverses discussions, on peut entendre des critiques du
message original d' Alexei Lukatsky sur Habré: ils disent que l'auteur a pris un ton trop alarmiste. Néanmoins, on ne peut manquer de remarquer qu'Aleksey est la personne même qui sait très bien comment l'infrastructure de réseau des grandes organisations et institutions publiques russes est liée et à quel équipement est connecté. Selon l'étude, dont les résultats
sont apparemment
disponibles pour le .RU et le centre de coordination de domaine ., le problème qui, avant que le message de Lukatsky ne soit enregistré sur un certain nombre de sites bien connus, apparaît déjà aujourd'hui en quantités infimes, c'est-à-dire une entrée de blog sur Cisco (et les notes suivantes, disons sur le blog de
Roskomsvoboda ) ont eu l'effet souhaité.
Cependant, le succès du DNS Flag Day entraînera évidemment des conséquences, dont la principale est que de telles actions se poursuivront à l'avenir. Il y a encore
beaucoup d'endroits dans le système DNS que les développeurs souhaiteraient développer le plus rapidement possible; de plus, DNS n'est pas le seul de ces protocoles dans lequel il y a quelque chose à analyser. L'exemple avec l'attribut BGP 0xFF, dont nous parlerons dans le prochain article, montre clairement: parfois le vaccin est utile pour Internet.
À ce jour, cela laisse aux administrateurs système un dilemme plutôt sans ambiguïté:
- Ou bien, l'administrateur du serveur DNS doit surveiller la vie de la communauté Internet, en particulier, les nouvelles de la communauté professionnelle des développeurs DNS, et, en particulier, prêter attention et du temps aux mises à jour du serveur;
- Ou la gestion de votre propre zone de domaine devrait être transférée à un fournisseur tiers spécialisé dans un tel travail (dont il y a, en principe, beaucoup de monde dans le monde).
Cependant, nous reviendrons probablement sur ce sujet également.