Sinkronizimi i DNS: Kopje të plota, rsync dhe Pemët Merkle

Besueshmëria e Sistemit të Emrave të Domenit (DNS), libri i adresave i internetit që i kthen emrat e domenit të njohur për njerëzit në adresa numerike IP, varet nga mijëra serverë të pavarur që i mbajnë kopjet e tyre të të dhënave në hap të përsosur. Në një postim në blogun APNIC më 13 korrik 2026, Geoff Huston eksploron mjetet e përdorura për të sinkronizuar të dhënat e replikuara, duke filluar nga një incident i botës reale: në mëngjesin e hershëm të 8 korrikut 2026, ofruesi australian i shërbimeve të rrjetit Telstra pësoi një ndërprerje në shkallë të gjerë që ndaloi disa shërbime trenash urbanë dhe rajonalë, shkaktoi dështime të terminaleve të pikave të shitjes dhe prishi platformën celulare të Telstra-s. Një raport lajmesh atë ditë ia atribuoi dështimin një dështimi sinkronizimi nëpër qendrat e të dhënave, gjë që Huston e vëren si plotësisht të besueshme në një platformë ofruesi shërbimi të pritur në shumë vende.

Huston së pari vëren se interneti i sotëm funksionon mbi të dhëna të replikuara në masë të madhe, dhe qëndrueshmëria nëpër pika të shpërndara e ndan rendin nga kaosi. Protokolli i Gateway-t Kufitar (BGP), protokolli i rutimit që u lejon ofruesve të internetit të shkëmbejnë informacion për arritshmërinë, i mban ruterat aktivë të sinkronizuar në mënyrë që çdo ruter të mund të përcjellë në mënyrë të pavarur paketat në mënyrë korrekte. DNS përballet me sfida të ngjashme sinkronizimi. Më pas ai shqyrton disa qasje, duke filluar me forcën brutale.

Metoda më e thjeshtë e sinkronizimit është që një server dytësor të tërheqë një kopje të plotë të të dhënave nga një burim parësor dhe të mbishkruajë kopjen e tij lokale. Kjo qasje me kopje të plotë kërkon vetëm të dijë se ku ndodhet burimi origjinal, dhe çdo server tjetër e tërheq të gjithë grupin e të dhënave sa herë që duhet të rifreskohet. Për të vendosur nëse një skedar ka ndryshuar, sistemet zakonisht krahasojnë madhësinë e skedarit dhe datën dhe orën e modifikimit të tij, gjë që e bën të rëndësishëm kohën e sinkronizuar nëpër sisteme të rrjetit. Kur një pamje e tillë uniforme e kohës nuk është e disponueshme, krahasimi duhet të mbështetet në një llogaritje më të kushtueshme siç është hash-i MD5 ose SHA i përmbajtjes së skedarit. Ky është modeli i përdorur nga sinkronizimi i pasqyrimit të sistemeve të skedarëve bazuar në FTP. Është i thjeshtë por jashtëzakonisht joefikas: skedarët e regjistrit që shkruhen në modalitetin shtesë transferohen të plotë çdo herë, çdo skedar i ndryshuar shkarkohet përsëri në tërësinë e tij, dhe koleksionet shumë të mëdha kërkojnë që klienti dhe serveri të kalojnë nëpër të gjithë hapësirën e skedarëve duke kontrolluar çdo skedar. Huston gjithashtu vë në dukje se FTP në modalitetin e pasqyrimit është një zgjedhje e dobët sepse i transferon të dhënat në kanal të qartë dhe i shkëmben kredencialet hapur.

Një përmirësim është rsync, i projektuar nga Andrew Tridgell në 1996. rsync e trajton një skedar si një sekuencë blloqesh dhe përditëson vetëm blloqet që ndryshojnë, jo të gjithë skedarin. Marrësi i dërgon dërguesit një listë emrash skedarësh dhe shuma kontrolli për secilin bllok; aty ku shumat e kontrollit ndryshojnë, dërguesi dërgon një bllok zëvendësues. Një bllok përcaktohet nga rsync si maksimumi prej 700 bajtësh dhe rrënja katrore e gjatësisë së skedarit. Protokolli gjithashtu ka mekanizma për të përballuar futjet dhe fshirjet, jo vetëm shtesat. Kjo qasje bllok-për-bllok redukton trafikun e rrjetit por rrit ngarkesën e përpunimit në të dy skajet për shkak të llogaritjes së shumave të kontrollit dhe shtrirjes së blloqeve. Funksionon mirë kur numri i skedarëve është i moderuar, skedarët nuk janë masivë dhe ndryshimet janë rritëse. Megjithatë, kur grupi i të dhënave përmban një numër shumë të madh skedarësh, gjenerimi dhe dërgimi i shumave të kontrollit për çdo skedar bëhet një proces intensiv. Dërguesi gjithashtu duhet të punojë shumë për të kontrolluar sekuencat dhe për të riorganizuar kufijtë e blloqeve, dhe kjo punë është konstante edhe nëse vetëm një bajt ka ndryshuar në një skedar. Në një koleksion prej një milion skedarësh, Huston vëren se kjo ngarkesë pune është një shpenzim konstant, dhe ndonjëherë mund të jetë më e shpejtë të heqësh dorë nga shumat e kontrollit të rsync dhe të kryesh një kalim të thjeshtë pasqyrimi FTP sepse kontrollet e skedarëve janë shumë më të shpejta për t'u llogaritur.

Një qasje tjetër e trajton gjendjen aktuale të një koleksioni të dhënash si rezultat i transaksioneve të redaktimit të aplikuara në një gjendje të mëparshme. Kjo përshkruhet më së miri nga protokolli i transferimit incremental të zonës DNS, IXFR, i përcaktuar në RFC 1995. Kur një zonë DNS ndryshon, serveri parësor përditëson numrin serial të Start of Authority (SOA). Një server dytësor që dëshiron të sinkronizohet dërgon një kërkesë IXFR me numrin e tij aktual serial SOA. Nëse serveri parësor mbështet IXFR dhe mban një skedar regjistri të ndryshimeve midis atij seriali dhe atij aktual, ai dërgon vetëm sekuencën e shtesave dhe fshirjeve. Kjo qasje përdoret gjithashtu në Near Real Time Mirroring (NRTM) të përcaktuar në RFC 7682 për sinkronizimin e Regjistrit të Rrugëve dhe në Protokollin e Deltës së Depove RPKI (RRDP) të përcaktuar në RFC 8182 për Infrastrukturën e Çelësave Publikë të Burimeve. Serveri mban një shpenzim konstant duke caktuar numra versionesh dhe duke regjistruar ndryshimet midis versioneve, por avantazhi është se transmetohen vetëm operacionet që e transformojnë një version në tjetrin. Kjo mund të aplikohet për skedarë individualë ose koleksione të tëra, kështu që edhe koleksione shumë të mëdha skedarësh mund të trajtohen si një artefakt i vetëm i regjistruar. Në disa skenarë është joefikas: një klient që tërheq një kopje aktuale merr ndryshime më të vjetra që mund të zhbëhen më vonë në sekuencë. Një kuptim më i mirë i të dhënave mund ta përmirësojë këtë. Për shembull, vetë BGP kryen kompresim delta në përditësimet e rutimit. Çdo bashkëmoshatar BGP përditësohet afërsisht çdo 30 sekonda nëse përdoren kohëmatësit e Intervalit Minimal të Reklamimit të Rrugës (MRAI). Kur përpunohet një përditësim rutimi, ajo që vihet në radhë është vlera e prefiksit, jo vetë përditësimi. Kur skadon kohëmatësi MRAI, folësi lokal BGP e heq nga radha çdo prefiks dhe kërkon gjendjen e tij aktuale në Bazën Lokale të Informacionit të Përcjelljes (FIB), pastaj e dërgon atë gjendje te bashkëmoshatari. Nëse folësi lokal mban një regjistër të asaj që i ka dërguar tashmë bashkëmoshatarit, ai nuk dërgon asnjë përditësim kur gjendja është e pandryshuar. Ky lloj kompresimi delta kërkon që artikujt e të dhënave të kenë një çelës primar unik dhe një vlerë; çelësat me shumë vlera nuk mund të mbështeten lehtësisht.

Pemët Merkle ndërmarrin një qasje hierarkike. Artikujt individualë të të dhënave renditen në një sekuencë kanonike, çdo artikull hashohet kriptografikisht, hash-et çiftohen në rend dhe hashohen përsëri, duke u përsëritur derisa të mbetet një hash i vetëm rrënjë. Nëse ndonjë e dhënë ndryshon, hash-i i ndryshuar përhapet deri te rrënja, kështu që krahasimi i dy grupeve të dhënash mund të fillojë duke krahasuar vetëm hash-et e tyre rrënjësore. Dallimet mund të gjenden duke zbritur në pemë dhe duke injoruar degët, vlerat e hash-eve superiore të të cilave përputhen. Pemët Merkle përdoren në sistemin e skedarëve ZFS, Bitcoin, Sistemin Ndërplanetar të Skedarëve dhe transparencën e certifikatave. Huston shkruan se parakushti është një rend kanonik i artikujve të të dhënave, dhe funksioni i sinkronizimit funksionon në mënyrë efikase mbi grupe të dhënash të mëdha dhe të vogla. Aktualisht propozohet për Infrastrukturën e Çelësave Publikë të Burimeve (RPKI) dhe protokollin ERIC, ku çdo klient duhet të mbajë një kopje lokale të sinkronizuar të të gjithë PKI-së. Ndërsa përdorimi i RPKI rritet, barra e sinkronizimit rritet me produktin e numrit të klientëve dhe objekteve, por pemët Merkle mund ta thyejnë këtë rritje duke funksionuar në një shkallë të logaritmit të numrit të objekteve. Një përmirësim i mëtejshëm përdor vlerat hash si identifikues të dhënash për marrje: kërkimi i një nyje të ndërmjetme kthen çiftin e renditur të dy vlerave të saj hash në varësi, ndërsa një nyje terminale kthen vetë artikullin e të dhënave. Një skemë e tillë e emërtimit të të dhënave i përshtatet replikimit anycast, në të cilin e njëjta adresë shpallet nga shumë vende, duke përmirësuar më tej shkallëzueshmërinë.

Huston gjithashtu i kundërvë modelet tërheqëse dhe shtytëse. Në një model tërheqës, klienti e pyet serverin nëse kopja e tij ndryshon dhe tërheq të dhënat kur është e nevojshme. Ai përdor si shembull kuadrin CDS/CDNSKEY të përcaktuar në RFC 8078. Një domen fëmijë i deleguar publikon një rekord CDS të nënshkruar me DNSSEC që përmban një hash të ri çelësi që fëmija dëshiron që prindi ta publikojë si rekord DS. Prindi periodikisht skanon zonën e deleguar duke kërkuar një rekord CDS në majë të zonës. Nëse rekordi mund të vërtetohet me DNSSEC duke përdorur Çelësin e Nënshkrimit të Zonës (ZSK) të fëmijës, prindi mund ta publikojë atë si rekord DS. RFC 8078 rekomandon që periudha midis publikimit të CDS/CDNSKEY nga fëmija dhe publikimit të rekordit DS të sinkronizuar nga prindi duhet të jetë sa më e shkurtër që të jetë e mundur, por për një zonë të madhe ky skanim periodik i çdo delegimi mund të bëhet një ngarkesë e vështirë. Një shembull tjetër tërheqës është sistemi i publikimit RPKI: klientët mbajnë një kopje të sinkronizuar të të gjitha kredencialeve të publikuara por nuk e dinë se kur një botues përditëson, kështu që ata motivohen të pyesin shpesh. Në të kundërt, zgjidhësit rekursivë DNS mbajnë kopje të ruajtura në memorie të të dhënave autoritative, dhe çdo rekord DNS mbart një vlerë Time-to-Live (TTL) që i tregon zgjidhësit se sa kohë mund ta mbajë kopjen e ruajtur përpara se të kontrollojë për përditësime. Kjo i lejon çdo botuesi të dhënash të zgjedhë midis përhapjes më të shpejtë të përditësimeve dhe performancës së përmirësuar të serverit. Tërheqja është e thjeshtë dhe nuk kërkon regjistrim të klientit, por e ekspozon serverin ndaj një ngarkese të pakufizuar që rritet si me numrin e klientëve ashtu edhe me frekuencën e kontrolleve të tyre. Fusha TTL është një përgjigje e dobishme sepse vetë të dhënat specifikojnë se sa larg mund të shkojë një kopje lokale nga versioni autoritativ. Në një model shtytës, nga ana tjetër, serveri i dërgon të dhënat klientëve sa herë që të dhënat ndryshojnë.

Për përdoruesit e zakonshëm të internetit dhe operatorët e faqeve të internetit, këto mekanizma të brendshme sinkronizimi janë të padukshëm por thelbësorë; kur ato dështojnë, si në incidentin e Telstra-s, trenat, pagesat me kartë dhe rrjetet celulare mund të ndalen së bashku. Ato gjithashtu nënvizojnë pse zgjedhja e një zgjidhësi rekursiv DNS të besueshëm ka rëndësi. Një shërbim DNS i koduar që i jep përparësi privatësisë si AEU DNS i lejon përdoruesit t'i mbajë kërkimet e tij të koduara dhe jashtë regjistrave të palëve të treta, megjithëse nuk e ndryshon mënyrën se si serverët autoritativë sinkronizojnë të dhënat e zonës. Kuptimi i kompensimeve midis kopjeve të plota, përditësimeve në nivel blloku, deltave dhe pemëve Merkle ndihmon të shpjegohet pse DNS ka arritur kaq larg dhe pse po merren parasysh propozime të reja si protokolli ERIC.