Net dat it wie, fansels . Lykwols, oant no ta is benammen besprutsen de gefolgen, wylst, neffens ús, de woartel oarsaken binne folle nijsgjirriger.
Dat, it is pland foar 1 febrewaris . De effekten fan dit evenemint sille stadichoan foarkomme, mar noch flugger as guon bedriuwen har oanpasse kinne.
Wat is it? Yn ienfâldige termen, dit is de wrâld syn wichtichste ûntwikkelders fan DNS tsjinners: bedriuwen CZ.NIC, ISC, NLnet Labs en PowerDNS.
Fabrikanten fan DNS-software hawwe lang te krijen mei in probleem: it ûntwikkeljen fan it domeinnammesysteem, it tafoegjen fan nije funksjes dy't klanten fereaskje, it oplossen fan feiligensproblemen - al dizze prosessen wurde radikaal fertrage troch de koöperative struktuer fan it DNS-systeem en de needsaak om argayske tsjinners te behâlden dy't ferâldere ferzjes fan protokollen ymplementearje (en sels dit wurdt faak dien mei flaters).
Útsûnderlike situaasje
Neffens , de aktuele spesifikaasje befettet, fanôf 21 jannewaris 2018, 3248 siden. Se befetsje alle relevante RFC's yn statusen "ynternet standert", "foarstelde standert" (wat hjoed yn wêzen itselde ding is), "bêste hjoeddeistige praktyk" и "ynformatyf". As ferliking, it HTTP-protokol, dat ynhâld leveret oan alle websiden op it ynternet, beslacht yn totaal 672 siden.
Sa't se sizze, as de betingsten fan referinsje foar jo projekt net lykje op soksawat, besykje net iens my út te noegjen.
De needsaak om de ferwurking fan alle funksjes en útsûnderingssituaasjes te ymplementearjen dy't beskreaun binne op 3 tûzen siden is hurd wurk op himsels, en boppedat implementearje in oantal DNS-tsjinners dizze of dy funksjonaliteit ferkeard, wat liedt ta de needsaak om ekstra net- standert gedrach. Yn guon fan 'e boppeneamde RFC's siket de wanhoop fan minsken dy't mei it protokol wurkje .
Neffens wichtige DNS-ûntwikkelders is de situaasje mei de kompleksiteit fan programmakoade al serieus genôch om radikale maatregels te nimmen. Op 1 febrewaris wurde, as ûnderdiel fan in koördinearre aksje, aktualisearre ferzjes fan alle grutte DNS-tsjinners frijlitten, wêryn stipe foar beskaat ferkeard gedrach no en foar altyd stoppe wurdt.
Wat oer mear details?
Om dúdlik te meitsjen wat krekt net mear stipe wurde sil, sil ik in analogy jaan. Stel jo foar dat minsken oant 1999 net tastien wiene op fleantugen mei bagaazje, mar yn 1999, troch in offisjele beslút fan 'e regeljouwende autoriteit, passazjiers mochten tasjes (fan in bepaald gewicht en ôfmjittings) oan board nimme. Hiel handich, krekt? Jo kinne in protte nuttige dingen ferfiere.
Stel jo no mar foar dat d'r yn 2019 noch fleantugen binne wêryn't tassen net tastien binne, en oant it ynstappen hawwe jo gjin manier om út te finen oft jo bagaazje meinimme kinne.
Dit is likernôch hoe't dingen binne mei , it ûntbrekken fan stipe wêrfoar fan 1 febrewaris sil liede ta de ûnberikberens fan in oantal websiden. Rûchwei, fleantugen dy't yn febrewaris yn ferbân mei harren tweintichste jubileum gjin bagaazje oan board kinne nimme (op syn minst minimaal) Se meie net mear ta in tal fleanfjilden.
De oankundiging hjiroer waard frij betiid frijjûn: yn maart-maaie 2018 hawwe de haadorganisatoaren fan DNS Flaggedei it publyk ynformearre oer . Derneist sil de frijlitting fan aktualisearre ferzjes fan DNS-tsjinners op himsels net direkt ta problemen liede, om't operators noch moatte oerstappe nei dizze ferzjes, en dit duorret tiid. Mar, wichtiger, in oantal wolk DNS-tsjinstferlieners die ek mei oan DNS Flag Day. Dizze omfetsje sokke reuzen as Google (en har ferneamde DNS-tsjinner mei IP-adres 8.8.8.8), Cloudflare, Facebook en Cisco.
As resultaat sille siden dy't DNS-tsjinners brûke sûnder EDNS-stipe (dat is, "fleantugen" dy't gjin "bagaazje oan board kinne nimme") al op 1 febrewaris stopje mei wurkjen foar elkenien dy't iepen DNS-tsjinners 8.8.8.8, 9.9.9.9 brûkt, 1.1.1.1 en in oantal oaren. As kommunikaasjeproviders har DNS-tsjinners bywurkje, sil de list groeie.
De eigenaardichheid fan it funksjonearjen fan in DNS-tsjinner yn in bedriuwsynfrastruktuer is dat it der normaal net om freget, it wurket en wurket, sa faak dat gjinien it ea bywurket. Systeembehearders fan de âlde skoalle sels lange-termyn uptime fan sokke masines. It probleem is dat as de needsaak ûntstiet om te upgrade, it docht bliken dat dit bygelyks ek ferpleatst fan FreeBSD 5 nei FreeBSD 10 (in echte gefal), dy't, ûnder oare problemen, in trochstart nedich is, en fan 'e herstart de âlde server is al It kin gewoan net útkomme.
De meast onaangename ding is dat de oplossing foar it probleem yn it algemiene gefal net delkomt op gewoan it bywurkjen fan de DNS-tsjinners. Guon organisaasjes brûke firewalls (sawol software as hardware) dy't twinge om alle DNS-pakketten mei EDNS-funksjonaliteit te fallen. Dit waard ûnder oaren dien troch de âlde Juniper SRX-modellen, mar de saak is net beheind ta har. Yn prinsipe, as wy prate oer firewalls en DPI-oplossingen yn 't algemien, is it nochal leech nivo fan kwaliteit yn' e ûntwikkeling fan in oantal sokke oplossingen al lang bekend. Al dizze jierren hawwe de ûntwikkelders fan it DNS-protokol lêst fan 'e problemen dy't se objektyf feroarsake hawwe, en no hawwe se besletten om werom te slaan.
Mar it bywurkjen fan sokke oplossingen kin in soad tiid nimme, en yn guon gefallen sil it wierskynlik nedich wêze om ienris djoere apparatuer yn it jiskefet te smiten en nije te keapjen, wat in protte swierrichheden feroarsaakje sil, bygelyks yn it ramt fan 'e Russyske budzjetsyklus (benammen as de ôfset apparatuer waard produsearre yn it bûtenlân, mar der is gjin mooglikheid mear om te keapjen bûtenlânske guod fan in organisaasje foar ien of oare reden - finansjeel, politike, ideologyske).
Dus foar dyjingen dy't dit probleem hawwe, is it tiid om it te begjinnen op te lossen. Tink derom dat allinich dy problemen dy't direkte oplossingen nedich binne toant mei reade "STOP" of "SLOW" tekens. It útropteken yn de giele trijehoek is noch mar in warskôging en sil op 1 febrewaris gjin problemen opleverje (hoewol't dit probleem op 'e lange termyn ferholpen wurde moat).
Wat fierder?
As earste moat DNS Flag Day gjin wichtige rampen útlokje.
Krityk hearre jo yn ferskate diskusjes Alexey Lukatsky oer Habré: se sizze dat de skriuwer in al te alarmistyske toan naam. It is lykwols ûnmooglik om net te merken dat Alexei de persoan is dy't tige goed bewust is fan hoe't de netwurkynfrastruktuer fan grutte Russyske organisaasjes en oerheidsynstânsjes soms strukturearre is en hokker apparatuer dêrmei ferbûn is. Neffens in stúdzje wêrfan de resultaten lykje te Koördinaasjesintrum foar .RU- en .РФ-domeinen, in probleem dat waard registrearre mei in oantal bekende siden foar Lukatsky's post, wurdt hjoeddedei al manifestearre yn spoarbedragen, dat is in yngong op it Cisco-blog (en folgjende notysjes, sizze, op it blog ) hie it winske effekt.
It súkses fan DNS Flag Day sil lykwols fansels liede ta gefolgen, wêrfan de wichtichste is dat sokke eveneminten yn 'e takomst bliuwe wurde hâlden. Yn it DNS-systeem is der noch , dy't de ûntwikkelders sa gau mooglik útwreidzje wolle; Derneist is DNS net it ienige sa'n protokol wêryn d'r wat is om te disassemble. It foarbyld mei it BGP-attribút 0xFF, dat wy sille besprekke yn it folgjende artikel, lit dúdlik sjen dat soms it ynternet profitearje kin fan faksinaasje.
Wat hjoeddedei systeembehearders mei in frij dúdlik dilemma lit:
- Of de DNS-tsjinnerbehearder moat it libben fan 'e ynternetmienskip kontrolearje, benammen it nijs fan' e profesjonele mienskip fan DNS-ûntwikkelders, en, benammen, yn 't algemien omtinken en tiid oan serverupdates;
- Of it behear fan jo eigen domein sône moat wurde oerdroegen oan in tredde partij provider spesjalisearre yn sok wurk (dêr't der yn prinsipe in protte yn 'e wrâld).
Wy komme lykwols nei alle gedachten letter werom op dit ûnderwerp.
Boarne: www.habr.com
