Ikke at det var det, selvfølgelig . Indtil nu har konsekvenserne dog primært været diskuteret, mens de grundlæggende årsager efter vores mening er meget mere interessante.
Så det er planlagt til 1. februar . Virkningerne af denne begivenhed vil opstå gradvist, men stadig hurtigere end nogle virksomheder vil være i stand til at tilpasse sig til den.
Hvad er det? Enkelt sagt er dette verdens vigtigste udviklere af DNS-servere: virksomheder CZ.NIC, ISC, NLnet Labs og PowerDNS.
Producenter af DNS-software har længe stået over for et problem: udvikling af domænenavnesystemet, tilføjelse af nye funktioner til det, som kunderne har brug for, løsning af sikkerhedsproblemer - alle disse processer bremses radikalt på grund af DNS-systemets samarbejdsstruktur og behovet at vedligeholde arkaiske servere, der implementerer forældede versioner af protokoller (og selv dette gøres ofte med fejl).
Ekstraordinær situation
Ifølge , den nuværende specifikation indeholder pr. 21. januar 2018 3248 sider. De inkluderer alle relevante RFC'er i statusser "internet standard", "forslag til standard" (hvilket i dag stort set er det samme), "bedste nuværende praksis" и "information". Til sammenligning dækker HTTP-protokollen, som leverer indhold til alle hjemmesider på internettet, i alt 672 sider.
Som de siger, hvis kommissoriet for dit projekt ikke ligner sådan noget, så prøv ikke engang at invitere mig.
Behovet for at implementere behandlingen af alle funktioner og undtagelsessituationer beskrevet på 3 tusinde sider er hårdt arbejde i sig selv, og derudover implementerer en række DNS-servere denne eller hin funktionalitet forkert, hvilket fører til behovet for yderligere at håndtere ikke- standard adfærd. I nogle af de ovennævnte RFC'er koger den desperation, der overvinder de mennesker, der arbejder med protokollen over .
Ifølge vigtige DNS-udviklere er situationen med programkodens kompleksitet allerede alvorlig nok til at træffe radikale foranstaltninger. Den 1. februar vil der som led i en koordineret handling blive frigivet opdaterede versioner af alle større DNS-servere, hvor understøttelse af visse forkerte adfærd nu og for altid vil blive stoppet.
Hvad med flere detaljer?
For at præcisere, hvad der præcist ikke længere vil blive understøttet, vil jeg give en analogi. Forestil dig, at personer indtil 1999 ikke var tilladt på et fly med bagage, men i 1999, ved en officiel beslutning fra den regulerende myndighed, fik passagerer lov til at tage tasker om bord (af en vis vægt og dimensioner). Ganske praktisk, ikke? Du kan transportere en masse nyttige ting.
Forestil dig nu, at der i 2019 stadig er fly, hvor tasker ikke er tilladt, og indtil boarding har du ingen mulighed for at finde ud af, om du kan tage bagage med dig.
Sådan er det nogenlunde , den manglende støtte, som fra 1. februar vil føre til utilgængelighed af en række hjemmesider. Groft sagt fly, der ikke kan tage bagage om bord (i hvert fald minimalt) i februar i forbindelse med deres tyveårs jubilæum De får ikke længere adgang til en række lufthavne.
Meddelelsen om dette blev offentliggjort ret tidligt: i marts-maj 2018 informerede hovedarrangørerne af DNS Flagdag offentligheden om . Derudover vil frigivelsen af opdaterede versioner af DNS-servere i sig selv ikke føre til problemer med det samme, da operatørerne stadig skal skifte til disse versioner, og det tager tid. Men, mere markant, en række cloud-DNS-tjenesteudbydere sluttede sig også til DNS Flag Day. Disse omfatter sådanne giganter som Google (og deres berømte DNS-server med IP-adresse 8.8.8.8), Cloudflare, Facebook og Cisco.
Som et resultat vil websteder, der bruger DNS-servere uden EDNS-understøttelse (det vil sige "fly", der ikke kan "tage bagage om bord"), stoppe med at fungere allerede den 1. februar for alle, der bruger åbne DNS-servere 8.8.8.8, 9.9.9.9, 1.1.1.1 og en række andre. Efterhånden som kommunikationsudbydere opdaterer deres DNS-servere, vil listen vokse.
Det særlige ved en DNS-servers funktion i en virksomhedsinfrastruktur er, at den normalt ikke beder om det, den virker og virker, så ofte er der ingen, der opdaterer den. Systemadministratorer af den gamle skole endda langsigtet oppetid for sådanne maskiner. Problemet er, at når behovet opstår for at opgradere, viser det sig, at dette for eksempel også kræver, at man flytter fra FreeBSD 5 til FreeBSD 10 (et rigtig tilfælde), hvilket blandt andet vil kræve en genstart, og fra genstarten. den gamle server er allerede. Det kan simpelthen ikke komme ud.
Det mest ubehagelige er, at løsningen på problemet i det generelle tilfælde ikke kommer ned på blot at opdatere DNS-serverne. Nogle organisationer bruger firewalls (både software og hardware), der tvinger alle DNS-pakker med EDNS-funktionalitet til at blive droppet. Det blev blandt andet gjort af de gamle Juniper SRX-modeller, men sagen er på ingen måde begrænset til dem. I princippet, hvis vi taler om firewalls og DPI-løsninger generelt, har det ret lave kvalitetsniveau i udviklingen af en række af sådanne løsninger længe været kendt. Alle disse år har udviklerne af DNS-protokollen lidt under de problemer, de objektivt set forårsagede, og nu har de besluttet at slå tilbage.
Men opdatering af sådanne løsninger kan tage betydelig tid, og i nogle tilfælde vil det sandsynligvis være nødvendigt at smide en gang dyrt udstyr i skraldespanden og købe nyt, hvilket vil forårsage mange vanskeligheder, for eksempel inden for rammerne af den russiske budgetcyklus (især hvis det kasserede udstyr blev produceret i udlandet, men der ikke længere er mulighed for at købe udenlandske varer fra en organisation af en eller anden grund - økonomisk, politisk, ideologisk).
Så for dem, der har dette problem, er det tid til at begynde at løse det. Bemærk, at kun de problemer, der kræver øjeblikkelige løsninger vises med røde "STOP" eller "SLOW"-skilte. Udråbstegnet i den gule trekant er kun en advarsel indtil videre og vil ikke give problemer den 1. februar (selvom dette problem skal rettes på lang sigt).
Hvad er det næste?
For det første bør DNS Flag Day ikke fremprovokere nogen væsentlige katastrofer.
Man kan høre kritik i forskellige diskussioner Alexey Lukatsky om Habré: de siger, at forfatteren tog en alt for alarmerende tone. Det er dog umuligt ikke at bemærke, at Alexey er den person, der er meget klar over, hvordan netværksinfrastrukturen i store russiske organisationer og statslige agenturer nogle gange er opbygget, og hvilket udstyr der er forbundet til det. Ifølge en undersøgelse, hvis resultater synes at Koordinationscenter for .RU- og .РФ-domæner, et problem, der blev registreret på en række velkendte websteder før Lukatskys indlæg, manifesterer sig allerede i dag i spormængder, det vil sige en post på Cisco-bloggen (og efterfølgende noter, sige på bloggen ) havde den ønskede effekt.
Men succesen med DNS Flag Day vil naturligvis føre til konsekvenser, hvoraf den vigtigste er, at sådanne begivenheder fortsat vil blive afholdt i fremtiden. I DNS-systemet er der stadig , som udviklerne gerne vil udvide så hurtigt som muligt; Derudover er DNS ikke den eneste sådan protokol, hvor der er noget at skille ad. Eksemplet med BGP-attributten 0xFF, som vi vil diskutere i den næste artikel, viser tydeligt, at nogle gange kan internettet drage fordel af vaccination.
Hvilket i dag efterlader systemadministratorer med et ret klart dilemma:
- Enten skal DNS-serveradministratoren overvåge internetsamfundets liv, især nyhederne om det professionelle fællesskab af DNS-udviklere, og i særdeleshed generelt være opmærksom på og tid til serveropdateringer;
- Eller administrationen af din egen domænezone skal overføres til en tredjepartsudbyder med speciale i sådant arbejde (som der i princippet er mange af i verden).
Dette emne vender vi dog nok tilbage til senere.
Kilde: www.habr.com
