Niet dat dat zo was natuurlijk . Tot nu toe zijn echter vooral de gevolgen besproken, terwijl de diepere oorzaken naar onze mening veel interessanter zijn.
Het staat dus gepland voor 1 februari . De gevolgen van deze gebeurtenis zullen geleidelijk optreden, maar nog steeds sneller dan sommige bedrijven zich eraan kunnen aanpassen.
Wat het is? In eenvoudige bewoordingen is dit het geval 's werelds belangrijkste ontwikkelaars van DNS-servers: bedrijven CZ.NIC, ISC, NLnet Labs en PowerDNS.
Fabrikanten van DNS-software worden al lang geconfronteerd met een probleem: het ontwikkelen van het domeinnaamsysteem, het toevoegen van nieuwe functies die klanten nodig hebben, het oplossen van beveiligingsproblemen - al deze processen worden radicaal vertraagd als gevolg van de coöperatieve structuur van het DNS-systeem en de noodzaak om archaïsche servers te onderhouden die verouderde versies van protocollen implementeren (en zelfs dit gebeurt vaak met fouten).
Uitzonderlijke situatie
Volgens , bevat de huidige specificatie, per 21 januari 2018, 3248 pagina's. Ze bevatten alle relevante RFC's in statussen "internetstandaard", "voorgestelde standaard" (wat vandaag de dag in wezen hetzelfde is), "beste huidige praktijk" и "informatief". Ter vergelijking: het HTTP-protocol, dat inhoud aan alle websites op internet levert, beslaat in totaal 672 pagina's.
Zoals ze zeggen: als de taakomschrijving voor je project er niet zo uitziet, probeer me dan niet eens uit te nodigen.
De noodzaak om de verwerking van alle functies en uitzonderingssituaties te implementeren die op drieduizend pagina's worden beschreven, is op zichzelf al hard werken, en bovendien implementeren een aantal DNS-servers deze of gene functionaliteit verkeerd, wat leidt tot de noodzaak om bovendien niet-geregistreerde gegevens te verwerken. standaard gedrag. In sommige van de bovengenoemde RFC’s kookt de wanhoop die de mensen overwint die met het protocol werken .
Volgens belangrijke DNS-ontwikkelaars is de situatie met de complexiteit van programmacode al ernstig genoeg om radicale maatregelen te nemen. Op 1 februari zullen als onderdeel van een gecoördineerde actie bijgewerkte versies van alle grote DNS-servers worden uitgebracht, waarbij de ondersteuning voor bepaald onjuist gedrag voor nu en voor altijd zal worden stopgezet.
En meer in detail?
Om te verduidelijken wat precies niet langer wordt ondersteund, zal ik een analogie geven. Stel je voor dat tot 1999 mensen niet met bagage in het vliegtuig mochten, maar dat passagiers in 1999 bij officieel besluit van de regelgevende instantie wel tassen (van een bepaald gewicht en afmetingen) aan boord mochten nemen. Best handig, toch? Je kunt veel nuttige dingen vervoeren.
Stel je nu eens voor dat er anno 2019 nog steeds vliegtuigen zijn waarin tassen niet zijn toegestaan, en tot het instappen kun je er niet achter komen of je bagage mee kunt nemen.
Zo staan de zaken er ongeveer bij , het gebrek aan ondersteuning waarvoor vanaf 1 februari zal leiden tot de ontoegankelijkheid van een aantal websites. Grofweg gezegd: vliegtuigen die in februari geen bagage (althans minimaal) aan boord kunnen nemen in verband met hun twintigste verjaardag Op een aantal luchthavens zullen zij niet langer worden toegelaten.
De aankondiging hierover werd vrij vroeg vrijgegeven: in maart-mei 2018 informeerden de belangrijkste organisatoren van DNS Flag Day het publiek over . Bovendien zal het uitbrengen van bijgewerkte versies van DNS-servers op zichzelf niet direct tot problemen leiden, aangezien operators nog steeds naar deze versies moeten overstappen, en dit kost tijd. Maar belangrijker nog: een aantal cloud-DNS-dienstverleners namen ook deel aan DNS Flag Day. Daartoe behoren giganten als Google (en hun beroemde DNS-server met IP-adres 8.8.8.8), Cloudflare, Facebook en Cisco.
Als gevolg hiervan zullen sites die DNS-servers gebruiken zonder EDNS-ondersteuning (dat wil zeggen “vliegtuigen” die geen “bagage aan boord kunnen nemen”) al op 1 februari stoppen met werken voor iedereen die open DNS-servers gebruikt 8.8.8.8, 9.9.9.9, 1.1.1.1 en een aantal andere. Naarmate communicatieproviders hun DNS-servers updaten, zal de lijst groeien.
Het bijzondere aan het functioneren van een DNS-server in een bedrijfsinfrastructuur is dat deze er meestal niet om vraagt, maar werkt en werkt, waardoor vaak niemand deze ooit bijwerkt. Systeembeheerders van de oude school zelfs lange termijn uptime van dergelijke machines. Het probleem is dat wanneer de noodzaak zich voordoet om te upgraden, dit bijvoorbeeld ook de overstap van FreeBSD 5 naar FreeBSD 10 vereist (een reëel geval), wat naast andere problemen een herstart vereist, en vanaf het opnieuw opstarten de oude server is er al. Het kan zijn dat deze er simpelweg niet uitkomt.
Het meest onaangename is dat de oplossing voor het probleem in het algemeen niet neerkomt op het simpelweg updaten van de DNS-servers. Sommige organisaties gebruiken firewalls (zowel software als hardware) die ervoor zorgen dat alle DNS-pakketten met EDNS-functionaliteit worden verwijderd. Dit werd onder meer gedaan door de oude Juniper SRX-modellen, maar de zaak beperkt zich zeker niet tot hen. Als we het hebben over firewalls en DPI-oplossingen in het algemeen, is het vrij lage kwaliteitsniveau bij de ontwikkeling van een aantal van dergelijke oplossingen in principe al lang bekend. Al die jaren hebben de ontwikkelaars van het DNS-protocol geleden onder de problemen die ze objectief hebben veroorzaakt, en nu hebben ze besloten terug te slaan.
Maar het updaten van dergelijke oplossingen kan veel tijd vergen, en in sommige gevallen zal het waarschijnlijk nodig zijn om ooit dure apparatuur in de prullenbak te gooien en nieuwe aan te schaffen, wat veel problemen zal veroorzaken, bijvoorbeeld in het kader van de Russische begrotingscyclus. (vooral als de afgedankte apparatuur in het buitenland is geproduceerd, maar er om de een of andere reden geen mogelijkheid meer is om buitenlandse goederen van een organisatie te kopen - financieel, politiek, ideologisch).
Dus voor degenen die dit probleem hebben, is het tijd om het op te lossen. Houd er rekening mee dat alleen die problemen een onmiddellijke oplossing vereisen wordt weergegeven met rode “STOP”- of “SLOW”-borden. Het uitroepteken in de gele driehoek is voorlopig slechts een waarschuwing en zal op 1 februari geen problemen opleveren (al zal dit probleem op termijn wel opgelost moeten worden).
En dan wat?
Ten eerste mag DNS Flag Day geen grote rampen veroorzaken.
In diverse discussies hoor je kritiek Alexey Lukatsky over Habré: ze zeggen dat de auteur een overdreven alarmistische toon aansloeg. Het is echter onmogelijk om over het hoofd te zien dat Alexey de persoon is die heel goed op de hoogte is van hoe de netwerkinfrastructuur van grote Russische organisaties en overheidsinstanties soms is gestructureerd en welke apparatuur daarop is aangesloten. Dat blijkt uit een onderzoek waarvan de resultaten lijken te kloppen Coördinatiecentrum voor .RU- en .РФ-domeinen, een probleem dat vóór de post van Lukatsky bij een aantal bekende sites werd geregistreerd, manifesteert zich vandaag al in sporenhoeveelheden, dat wil zeggen een bericht op de Cisco-blog (en daaropvolgende opmerkingen, zeg maar op de blog ) had het gewenste effect.
Het succes van DNS Flag Day zal echter uiteraard tot gevolgen leiden, waarvan de belangrijkste is dat dergelijke evenementen in de toekomst zullen blijven plaatsvinden. In het DNS-systeem is er nog steeds , die de ontwikkelaars zo snel mogelijk willen uitbreiden; Bovendien is DNS niet het enige protocol waarin iets te demonteren valt. Het voorbeeld met het BGP-attribuut 0xFF, dat we in het volgende artikel zullen bespreken, laat duidelijk zien dat internet soms baat kan hebben bij vaccinatie.
Wat systeembeheerders vandaag de dag met een vrij duidelijk dilemma achterlaat:
- Ofwel moet de DNS-serverbeheerder het leven van de internetgemeenschap in de gaten houden, in het bijzonder het nieuws van de professionele gemeenschap van DNS-ontwikkelaars, en in het bijzonder in het algemeen aandacht en tijd besteden aan serverupdates;
- Of het beheer van uw eigen domeinzone moet worden overgedragen aan een externe aanbieder die gespecialiseerd is in dergelijk werk (waarvan er in principe veel zijn in de wereld).
We zullen echter waarschijnlijk later op dit onderwerp terugkomen.
Bron: www.habr.com
