DNSSEC: Kuidas see toimib ja miks see on oluline?

Domeeninimede süsteem DNS on interneti telefoniraamat, mis tõlgib inimloetavaid nimesid IP-aadressideks miljardeid kordi päevas. DNS-andmebaasis hoitakse kriitilisi DNS-kirjeid, nagu IP-aadressid ja domeeni varjunimed, mis muudab selle küberohtude sihtmärgiks. Kuid see kriitiline infrastruktuur projekteeriti 1980ndatel ilma sisseehitatud turvaseadmeteta. Traditsiooniline DNSi valideerimine tugines vastuste puhul sama IP-aadressi sobitamisele, mis on ebaturvaline, sest IP-aadresse saab võltsida. DNSSEC on loodud selle põhilise puudujäägi kõrvaldamiseks, lisades krüptograafilise kontrolli süsteemile, mis algselt toimis üksnes usalduse alusel.

DNSSEC lühidalt

Domain Name System Security Extensions, üldtuntud kui DNSSEC, tähendab DNS Security Extensions ja on IETFi protokolli spetsifikatsioonide kogum, mis lisab DNS-andmetele krüptograafilisi allkirju. Need allkirjad võimaldavad DNS-lahendajatel kontrollida, et saadud teave pärineb tõepoolest autoriteetsest allikast ja et seda ei ole teel muudetud.

Põhiprobleem, mille DNSSEC lahendab, on lihtne: ilma selleta saavad ründajad sisestada võltsitud DNS-vastuseid lahendajate vahemäludesse. See rünnak, mida nimetatakse DNS-cache poisoning’iks, suunab kasutajaid nende teadmata pahatahtlikele saitidele. DNSSEC takistab seda, võimaldades andmete päritolu autentimist ja tagades DNS-kirjete terviklikkuse digitaalallkirjade abil, kasutades avaliku võtme krüptograafiat ja nõudes DNS-vööndi võtmete hoolikat haldamist, et vältida isikustamist ja andmete võltsimist.

IETF (Internet Engineering Task Force) standardiseeris DNSSECi mitmete RFC-de kaudu 2000. aastate alguses, sealhulgas RFC 4033, 4034 ja 4035. Suurim kasutuselevõtu verstapost oli 2010. aasta juulis, kui ICANN allkirjastas DNS-i juurvööndi, luues ülemaailmse usaldusankri, mis võimaldas DNSSECi praktilist kasutuselevõttu kogu maailmas.

Oluline on mõista, mida DNSSEC teeb ja mida mitte. DNSSEC autentib DNS-andmeid, kinnitades, et A, AAAA, MX ja TXT kirjed on ehtsad ja muutmata. See ei krüpteeri siiski DNS päringuid ega vastuseid. Teie DNS-liiklus jääb nähtavaks kõigile, kes saavad seda jälgida. Krüpteerimiseks on vaja täiendavaid protokolle, nagu DNS over TLS või DNS over HTTPS.

DNSSEC ei takista ka kõiki DNS-infrastruktuuri vastu suunatud rünnakuid. Mahulised DDoS-rünnakud võivad allkirjastamisest olenemata ikkagi DNS-servereid üle koormata. DNSSEC ei saa ka takistada kasutajaid külastamast seaduslikult registreeritud andmepüügidomeene, mis näevad veenvalt välja.

DNSSECi rakendamine võib olla keerukas, kuna on vaja hallata võtmeid ja luua usaldusahel. Edukas DNSSECi kasutuselevõtt eeldab, et ka vanemtsoon ja kõik ahelas olevad tsoonid on allkirjastatud.

Enamik tippdomeene toetab tänapäeval DNSSECi – ICANNi andmetel on üle 1400 tippdomeeni allkirjastatud. Teise taseme domeenide kasutuselevõtt räägib aga teistsugust lugu. Vaid umbes 1-2% .com-vöönditest on DNSSECi kasutamine lubatud, samas kui riigikoodiga tippdomeenid, nagu .nl (Madalmaad) ja .se (Rootsi), ületavad kohustusliku poliitika tõttu 90% allkirjastamise määra.

Miks peaks teid see huvitama? Sest ilma DNSSECita on iga DNS päring, mida teie organisatsioon teeb, haavatav vaikiva manipuleerimise suhtes. Ründaja, kes mürgitab teie lahendaja vahemälu, võib suunata teie töötajad ümber saitidele, kus kogutakse volitusi, või peatada e-posti kättetoimetamise – ja seda kõike ilma ilmseid hoiatusi vallandamata.

Kuidas DNS ja DNSSEC omavahel sobivad

Enne DNSSECi põhjalikumalt tundmaõppimist meenutame lühidalt, kuidas domeeninimede süsteem täna toimib. Kui sisestate veebilehitsejasse URL-aadressi, võtab teie arvuti tüviresolver ühendust rekursiivse DNS-resolveriga – sagelipakub seda teie internetiteenuse pakkuja, ettevõtte võrk või avalik teenus, näiteks Google’i 8.8.8.8.8 või Cloudflare’i 1.1.1.1.1. DNS-resolver töötleb DNS-päringuid, järgides serverite ahelat, et saada õige IP-aadress, tagades tõhusa ja täpse lahenduse.

Kaaluge lahendamist www.example.com. Rekursiivne DNS-resolver küsib kõigepealt ühte 13-st loogilisest DNS-nimede juurserverist, küsides teavet .com-i kohta. Juurserver vastab, viidates Verisigni hallatavatele .com tippdomeeni serveritele. Seejärel küsib resolver .com serveritelt teabe example.com kohta, saades teise viite example.com-i autoriteetsele nimeserverile. Lõpuks teeb resolver päringu sellele autoriteetsele serverile ja saab tegeliku A-kirje, mis sisaldab www.example.com IP-aadressi.

Selles hierarhilises süsteemis töötavaderinevad DNS-komponendid – näiteks ressursikirjed, autoriteetsed nimeserverid ja tsoonide allkirjastamisvõtmed –koos, et hallata, kontrollida ja turvata iga DNS-vööndit.

See elegantne hierarhiline süsteem määratleti juba 1987. aastal RFC 1034 ja 1035. Probleem? Klassikaline DNS-protokoll on loodud ilma tugeva autentimiseta. Vastuseid valideeriti peamiselt lähtekoha IP-aadresside ja 16-bitiste tehingu ID-devõrdlemise teel –süsteemi, mida ründajad õppisid ära kasutama.

2008. aasta Kaminsky haavatavus näitas, kui haavatav see konstruktsioon oli. Turvalisuse uurija Dan Kaminsky näitas, et ründajad võivad suure tõenäosusega sisestada võltsitud vastuseid resolveri vahemällu, kasutades ühe päringuakna jooksul arvamist. See avastus ajendas kogu tööstusharu hädaparandusi tegema ja kiirendas märkimisväärselt DNSSECi kasutuselevõttu kogu maailmas.

DNSSEC integreerub laienduskihina, mis haarab olemasoleva DNSi ümber, muutmata põhilist päringu-vastuse mudelit. Allkirjastamata tsoonid töötavad jätkuvalt normaalselt mittevalideerivate lahendajate puhul. Valideerivad lahendajad viivad allkirjastatud tsoonide puhul lihtsalt läbi täiendavaid krüptograafilisi kontrolle. Selline tagasiulatuv ühilduvus oli oluline DNS-nimede järk-järguliseks kasutuselevõtuks kogu DNS-nimede ruumis.

DNSSECi põhimõisted ja kirjete tüübid

DNSSEC võtab kasutusele mitu uut DNS-ressursikirje tüüpi, mis töötavad koos, et luua kontrollitav usaldusahel. Nende kirjete ja nende seoste mõistmine on oluline igaühe jaoks, kes töötab allkirjastatud tsoonidega.

DNSSECi alusüksus on ressursikogum ehk RRSet. See on DNS-kirjete rühmitus, millel on sama nimi, tüüp ja klass. Üksikute kirjete allkirjastamise asemel allkirjastab DNSSEC terved RRS-kogumid. Selline lähenemine tagab aatomi terviklikkuse – te ei saa manipuleerida ühte kirjet komplektis, ilma et kõigi nende allkirja kehtetuks muutuks.

RRSIG-kirje sisaldab digitaalallkirja, mis hõlmab RRS-üksust. Iga ressursikirje allkiri, mis on loodud tsooni privaatvõtme abil, sisaldab metaandmeid, nagu allkirjastaja nimi, kehtivusaeg ja kasutatud algoritm. Resolverid kontrollivad neid allkirju, arvutades uuesti RRSeti andmete hashi ja kontrollides seda krüptograafilise allkirjaga.

DNSKEY kirje avaldab avaliku võtme, mida kasutatakse allkirjade kontrollimiseks. Need kirjed ilmuvad tsooni tipus (nagu näiteks example.com.) ja sisaldavad lipukesi, mis näitavad võtme rolli. Lipu väärtus 256 tähistab tsooni allkirjastamisvõtit, samas kui 257 tähistab võtme allkirjastamisvõtit.

DS-kirje ehk delegatsiooni allkirjastaja kirje loob sideme vanem- ja lapsvööndite vahel. See on salvestatud vanemtsoonis ja sisaldab lapstsooni avaliku võtme krüptograafilist hashi. Näiteks example.com-i DS-kirje on salvestatud .com-vööndisse, mis võimaldab lahendajatel kontrollida, et example.com-i DNSKEY-kirje on autentne. Iga tsooni avalik võti on allkirjastatud selle vanemtsooni privaatvõtmega, mis on oluline usaldusahela loomiseks DNSSECis. See protsess tagab, et usaldus kandub vanemtunnusest lapstunnusele, moodustades turvalise ja kontrollitava hierarhia.

NSEC- ja NSEC3-kirjed võimaldavad autenditud eksistentsi keelamist. Kui DNS päring küsib nime, mida ei ole olemas, tõestavad need kirjed, et seda nime tõesti ei ole – see takistab ründajatel väita, et olematu nimi on tõeline. NSEC seob olemasolevad nimed sorteeritud järjekorras, samas kui NSEC3 kasutab krüptograafiliselt räsitud kirjete nimesid, et vältida tsooni sisu lihtsat ülesarvamist.

CDS ja CDNSKEY kirjed toetavad automaatset võtmehaldust. Need võimaldavad lapsvöönditel edastada uuendatud DS- või DNSKEY-teavet vanemvöönditele, vähendades tavapäraselt registripidajatega nõutavat käsitsi kooskõlastamist.

Erilist tähelepanu väärib tsooni allkirjastamisvõtme (ZSK) ja võtme allkirjastamisvõtme (KSK) eristamine. ZSK allkirjastab tavalisi tsooniandmeid (A, AAAA, MX kirjed), samas kui KSK allkirjastab ainult DNSKEY RRSet ise. Selline eraldamine võimaldab operaatoritel ZSK-d sageli pöörata, hoides samal ajal stabiilsemat KSK-d – ja sellega seotud DS-kirjet vanemtsoonis – muutumatuna.

Nimesüsteemi turvarakendused

Nimesüsteemi turvarakendused (NSSE) kujutavad endast ulatuslikku protokollide ja standardite kogumit, mille eesmärk on tugevdada domeeninimede süsteemi (DNS) turvalisust. NSSE keskmes on DNSSEC, mis kasutab digitaalallkirju ja avaliku võtme krüptograafiat DNS-andmete autentimiseks ja nende terviklikkuse tagamiseks. Nende süsteemi turvalisuse laienduste peamine eesmärk on kaitsta end selliste ohtude eest nagu DNS-i võltsimine ja DNS-i vahemälu mürgitamine – rünnakud, millega saab manipuleerida DNS-i andmeid ja suunata kasutajaid petturisaitidele.

Kasutades nimesüsteemi turvarakendusi, saavad domeeniomanikud tagada, et nende domeenidega seotud DNS-andmed on internetis liikudes nii autentsed kui ka muutmata. See saavutatakse avaliku võtme infrastruktuuri abil, kus iga allkirjastatud tsoon avaldab avaliku võtme, mida lahendajad kasutavad DNS-kirjete digitaalallkirjade kontrollimiseks. Selle tulemusena saavad kasutajad ja rakendused usaldada, et domeeninimede süsteemist saadud teave on õiguspärane, mis aitab säilitada kasutajate usaldust ja kaitsta mitmesuguste küberohtude eest.

Kuidas DNSSEC valideerimine töötab otsast lõpuni

DNSSECi valideerimine järgib DNSi lahendusteed, ehitades kontrollimise teadaolevast lähtepunktist, mida nimetatakse usaldusankriks. Enamiku lahendajate puhul on selleks ankuriks juurtsooni KSK, mida levitatakse IANA ja lahendajate tarkvarauuenduste kaudu. Kui valideeriv rekursiivne lahendaja tegeleb allkirjastatud domeeni päringuga, teostab ta krüptograafilise kontrolli DNS-hierarhia igal astmel. Resolver usaldab juba juur-DNSKEY-d. Seda võtit kasutades kontrollib ta juurvööndi RRSIGi, mis hõlmab tippdomeeni (nt .com) DS-kirjet. Seejärel hangib ta .com-i DNSKEY ja kontrollib selle vastavust DS-hashile. See protsess jätkub kuni sihtdomeenini.

Kaaluge www.example.com päringute tegemist täielikult allkirjastatud keskkonnas. Resolver kontrollib:

• Root’i DNSKEY (usaldusväärne ankur) allkirjastab .com’i DS-rekordi.
• .com’i DNSKEY vastab DS hashile ja allkirjastab example.com’i DS kirje
• example.com’i DNSKEY vastab selle DS-le ja allkirjastab www’i A-rekordi.

See loob katkematu usaldusahela juurtunnusest kuni taotletud DNS-kirjeeni. Iga mittevastavus – kehtetu allkiri, aegunud RRSIG või DS/DNSKEY hash-vea – katkestab ahela.

Kontrollida saab valideerimise ebaõnnestumisi, kasutades testdomeene nagu dnssec-failed.org, mille ICANN on tahtlikult valesti konfigureerinud. Valideerivad lahendajad annavad selle domeeni kohta SERVFAILi tagasi, blokeerides juurdepääsu täielikult. Kasutajate jaoks, kes on valideerimata lahendajate taga (endiselt umbes 70% kogu maailmas), lahendatakse domeen normaalselt, mis näitab, et praeguses kasutuselevõtus on puudujääke.

DNSSEC ei muuda rakendusprotokolle nagu HTTP või SMTP. See lihtsalt tagab, et IP-aadress ja muud DNS-rakenduste poolt saadavad andmed on autentsed ja muutmata. Veebilehitseja loob ikka veel tavapäraselt HTTPS-ühenduse; DNSSEC lihtsalt tagab, et DNS-päringu vastused osutavad seaduslikule serverile.

Autenditud eksistentsi eitamise korral tõestavad NSEC- või NSEC3-kirjed, et küsitud nime või tüüpi ei eksisteeri. Resolver saab krüptograafiliselt allkirjastatud tõendi, mis näitab, millised nimed on tsoonis olemas, mis võimaldab tal kinnitada lünka, kus küsitud nimi peaks olema.

DNSSEC-i ressursikirjed praktikas

Uurime peamisi DNSSECiga seotud DNS-kirjete tüüpe üksikasjalikumalt.

RRSIG-kirjed genereeritakse, kasutades tsooni privaatvõtit – tavaliste kirjete puhul tavaliselt ZSK. Iga allkiri määrab ära allkirjaalgoritmi (näiteks ECDSAP256SHA256), allkirjastatud nimes sisalduvate märgete arvu, algse TTL-i ja algus- ja lõpptähtaega. Need ajatemplid on kriitilised: lahendajad lükkavad tagasi allkirjad, mille kehtivusaeg on väljaspool nende kehtivusaega, mis tavaliselt on määratud 30 päevaks. Vööndioperaatorid peavad enne kehtivusaja lõppemist kirjeid tagasi astuma, et vältida valideerimisvigastusi.

DNSKEY kirjed ilmuvad tsooni tipus ja võivad sisaldada mitu võtit uuendamise ajal. Lipuväljal eristatakse võtme rolle: 257 tähistab KSK-d, mille SEP (Secure Entry Point) bitt on seatud, 256 aga ZSK-d. Võtmesilt – 16-bitine identifikaator, mis arvutatakse võtmeandmete põhjal – aitab lahendajatel DNSKEY-kirjeid kiiresti vastavate DS-kirjetega sobitada.

DS-kirjed vanemtsoonis sisaldavad lapstsooni KSK-i hash’i. Tüüpiline DS-kirje sisaldab võtmesildi, algoritmi numbrit, digesti tüüpi (tavaliselt SHA-256) ja digesti ennast. DNSSECi valideerimise ajal hangivad lahendajad lapse DNSKEY, arvutavad hashi ja võrdlevad seda. Vastavus annab BOGUS-staatuse, mis põhjustab valideerimise ebaõnnestumise.

NSEC-kirjed läbivad tsooni nimed kanoonilises järjestuses. Iga NSEC viitab järgmisele olemasolevale nimele ja loetleb selle nime juures olevad kirjete tüübid. See tõestab mitteolemasolu, kuid paljastab tsooni sisu “tsooni kõndimisele” – ründajad saavad iga nime üles lugeda, järgides ahelat.

NSEC3 tegeleb tsoonide kõndimisega, kasutades enne aheldamist nimede hashingutamist soola ja iteratsiooniarvuga. Kuigi see takistab triviaalset loendamist, saavad sihikindlad ründajad siiski etteaimatavate nimede murdmist võrguühenduseta. Väljajätmise märk võimaldab allkirjastamata delegatsioone muidu allkirjastatud tsoonides, mis on kasulik suurte tsoonide puhul, kus on palju allkirjastamata alamdomeene.

CDS ja CDNSKEY kirjed peegeldavad DS ja DNSKEY vorminguid, kuid need avaldatakse lapsvööndis endas. Vanemtsoonide operaatorid saavad neid kirjeid küsitleda, et automaatselt uuendada delegatsiooni allkirjastajate kirjeid, lihtsustades võtmete uuendamist ja DNSSECi esialgset kasutuselevõttu.

DNS kirjete rühmitamine

DNSSECi rakendamise põhiline aspekt on DNS-kirjete rühmitamine ressursikirjete kogumitesse (Resource Record Sets, RRSets). RRSet on DNS-kirjete kogum, millel on tsoonis sama nimi ja tüüp. Iga üksiku kirje allkirjastamise asemel allkirjastab DNSSEC kogu RRSETi ühe RRSIG-kirjega. See lähenemisviis lihtsustab DNS-andmete allkirjastamise ja valideerimise protsessi, muutes selle tõhusamaks nii domeeniomanike kui ka valideerivate lahendajate jaoks.

DNS-kirjete rühmitamine RRSets’iks mitte ainult ei lihtsusta DNSSECi rakendamist, vaid parandab ka DNS-infrastruktuuri hallatavust. Kui RRSet’i mis tahes kirje muudetakse, allkirjastatakse kogu kogum uuesti, tagades kõigi seotud DNS-andmete terviklikkuse ja autentsuse säilimise. Domeeniomanike jaoks tähendab see vähem keerukust allkirjade haldamisel ja tugevamat kaitset DNS-kirjete võltsimise või volitamata muudatuste vastu. Lõppkokkuvõttes on DNS-kirjete rühmitamine parim tava, mis toetab kaasaegse DNS-infrastruktuuri skaleeritavust ja turvalisust.

Tsooni allkirjastamisvõti, allkirjastamisrežiimid ja võtmehaldus

DDNSSECi võtmehalduse keskmes on kaks erinevat rolli. Tsooni allkirjastamise võti (ZSK ) tegeleb igapäevaselt tsooni andmete allkirjastamisega – A, AAAA, MX, TXT ja muude tavaliste kirjete allkirjastamisega. Allkirjastamise võti (KSK ) täidab piiratumat, kuid kriitilisemat funktsiooni: ta allkirjastab ainult DNSKEY RRSet’i, luues usaldusväärse seose vanemtsooni DS-kirjega.

Operaatorid eraldavad need rollid headel põhjustel. ZSK privaatvõtit kasutatakse sageli ja sellega kaasneb suurem risk, mistõttu selle rotatsioon iga 30-90 päeva tagant piirab võimalikku kahju, mis tuleneb kompromissist. KSK muutub harva – igal aastalvõi harvemini-, sest iga rotatsioon nõuab DS-kirje uuendamist vanemtsoonis, mis tavaliselt hõlmab registripidaja kooskõlastamist.

DNSSECi rakendamiseks on olemas kolm peamist allkirjastamisviisi:

• Offline allkirjastamine: Vöönd allkirjastatakse õhupiiril olevas masinas või HSM-is, seejärel edastatakse allkirjastatud tsoonifail autoriteetsetele serveritele. Parim staatiliste tsoonide puhul, kus turvalisus kaalub üles töömugavuse.
• Tsentraliseeritud veebipõhine allkirjastamine: Spetsiaalne allkirjastamisteenus võtab vastu allkirjastamata uuendused ja allkirjastab need enne levitamist autoriteetsetele DNS-serveritele. Tasakaalustab turvalisust ja dünaamiliste uuenduste toetamist.
• Kohapeal allkirjastamine: Autoriteetsed serverid genereerivad DNSSEC-allkirju reaalajas, kui DNS-päringud saabuvad. Sobib väga dünaamiliste tsoonide jaoks, kuid suurendab võtme kokkupuute riski, kui serverid on ohustatud.

Võtmete ümberpaigutamine nõuab hoolikat ajastamist, et vältida usaldusahela katkemist. Standardne lähenemisviis avaldab uued võtmed eelnevalt: lisage uus võti DNSKEY RRSet’ile, oodake, kuni vahemälu aegub (tavaliselt kaks TTL-perioodi), seejärel kõrvaldage vana võti. KSK-i ümberpaigutamise puhul peab uus DS ka vanemtsoonis levima, enne kui vana KSK eemaldatakse.

2018 root KSK rollover illustreeris panuseid. Hoolimata ulatuslikust ettevalmistusest ei suutnud ligikaudu 0,3 % lahendajatest oma usaldusankruid ajakohastada, saades ajutisi SERVFAIL-vastuseid. Ühe tsooni puhul võivad sellised vead tunduda tühised, kuidneed viivad domeeni mõjutatud kasutajate jaoks tõhusalt offline.

Delegatsiooni allkirjastaja

Delegatsiooni allkirjastaja (DS) kirje on DNSSECi usaldusahela nurgakivi, mis seob DNS-hierarhias lapsvööndi turvalisuse oma vanemvööndiga. DS-kirje sisaldab krüptograafiliselt räsitud versiooni lapsvööndi allkirjastamisvõtmest (Key Signing Key, KSK) ja see avaldatakse vanemvööndis. See võimaldab rekursiivsetel lahendajatel kontrollida, et lapsvööndi esitatud DNSKEY kirje on autentne ja seda ei ole võltsitud.

Selle ühenduse loomisega võimaldab DS-kirje domeeniomanikel laiendada usaldust vanemtsoonist kuni oma DNS-andmeteni, tagades, et iga samm lahendamisprotsessis on kinnitatud. See mehhanism on oluline kogu DNS-infrastruktuuri terviklikkuse säilitamiseks, kuna see takistab ründajatel sisestada pettuse eesmärgil DNS-andmeid mis tahes punktis ahelas. Domeeniomanike jaoks on delegatsiooni allkirjastajate kirjete nõuetekohane konfigureerimine kriitiline samm DNSSECi kasutuselevõtmisel ja domeenide kaitsmisel DNS-põhiste rünnakute eest.

DNSSECi eelised ja piirangud

DNSSECi peamine väärtus on kaitsmine DNS-cache poisoning ja DNS-spoofing-rünnakute vastu. Krüptograafiliselt tõestades vastuse autentsust, takistab see ründajatel kasutajaid vaikselt ümber suunata andmepüügisaitidele või võltsitud MX-kirjete kaudu e-kirju pealtkuulata. Kaminsky 2008. aasta haavatavus näitas, kui laastavad võivad sellised rünnakud olla; DNSSEC muudab need põhimõtteliselt ebatõhusaks allkirjastatud tsoonide vastu.

Lisaks põhilisele kaitsele võimaldab DNSSEC täiustatud turvarakendusi. DANE (DNS-Based Authentication of Named Entities ) võimaldab domeeniomanikel avaldada TLS-sertifikaadi teavet otse DNSis, kasutades TLSA-kirjeid. Sellega saab kontrollida SMTP-serverite või veebiteenuste sertifikaate, ilma et oleks vaja tugineda ainult traditsioonilistele sertifitseerimisasutustele. Sellised rakendused vajavad autentitud DNS-andmeid – täpselt seda, mida DNSSEC pakub.

Sama oluline on mõista ka piiranguid:

• Konfidentsiaalsus puudub: DNSSEC autentib, kuid ei krüpteeri. DNS päringud ja DNS päringute vastused jäävad vaatlejatele nähtavaks. Krüpteerimine nõuab DNS over TLS või DNS over HTTPS.
• Puudub DDoS-kaitse: DNSSEC ei suuda peatada DNS-infrastruktuuri vastu suunatud mahurünnakuid. Tegelikult võivad suuremad allkirjastatud vastused potentsiaalselt süvendada võimendusrünnakuid.
• Puudub kaitse õiguspärase väljanägemisega ohtude eest: DNSSEC ei saa takistada kirjavigu või seda, et kasutajad usaldavad eksitavaid domeeninimesid, mis on õiguspäraselt registreeritud ja nõuetekohaselt allkirjastatud.

Jõudluse kaalutlused hõlmavad oluliselt suuremaid DNS-vastuseid – allkirjadlisavad umbes 500 baiti ühe RRSeti kohta. See käivitab mõnikord TCP tagasilöögi (lisab latentsust) ja suurendab ribalaiuse tarbimist. DNSSECiga avatud lahendajad võivad võimendada peegeldusrünnakuid 50 korda või rohkem võrreldes tavalise DNSiga.

Vaatamata nendele kompromissidele soovitavad turvaorganisatsioonid, sealhulgas ICANN ja NIST, DNSSECi kõrge väärtusega domeenide puhul. See on küll koormav, kuid avalikkusele suunatud teenuste puhul, kus DNS-i võltsimine võib võimaldada tõsiseid rünnakuid, õigustab kaitse keerukust.

Riskid, väljakutsed ja põhjused, miks kasutuselevõtt on endiselt ebaühtlane

DNSSEC toob kaasa operatsioonilisi riske, mis seletavad suurt osa vastuvõtmisega seotud kõhklusi. Väärad konfiguratsioonid – aegunud allkirjad, DS/DNSKEY mittevastavused või kehtetud allkirjade ahelad – põhjustavad valideerimishäireid. Ligikaudu 30% kasutajate jaoks, kes on valideerivate lahendajate taga, lõpetab valesti konfigureeritud tsoon lihtsalt töötamise. Graatsilist lagunemist ei toimu; päringud tagastavad SERVFAIL.

DNSSECi kasutuselevõttu aeglustavad mitmed takistused:

• Mitme osapoolega kooskõlastamine: Allkirjastamine nõuab domeeniomanike, registripidajate ja DNS-hostingu pakkujate vahelist kooskõlastamist. DS-kirjed peavad registripidajate süsteemide kaudu jõudma vanemtsooni.
• Ekspertiisilüngad: Paljudel organisatsioonidel puudub DNSSEC-kogemus. Hirm, et valesti konfigureerimise tõttu tekivad katkestused, takistab neid alustamast.
• Pärandiinfrastruktuur: Mõne ettevõtte keskkonnas on kasutusel lahendajad või seadmed, mis ei toeta täielikult DNSSECi valideerimist, mis tekitab ühilduvusprobleeme.

Vastuvõtustatistika näitab ebaühtlast arengut. DNS-i juurvöönd on allkirjastatud alates 2010. aastast ja üle 1400 tippdomeeni toetab nüüd DNSSECi. Teise taseme kasutuselevõtt on aga väga erinev. Tsooni .nl allkirjastamine on üle 95%, mis on tingitud registri stiimulitest ja kohustuslikust poliitikast. Seevastu .com on umbes 1,5% – miljoniddomeenid on endiselt allkirjastamata.

APNICi mõõtmised näitavad, et umbes 30% DNS-resolvijatest teostab DNSSECi valideerimist kogu maailmas, võrreldes umbes 10%-ga 2018. aastal. Edasiminek jätkub, kuid enamik lõppkasutajatest saab endiselt valideerimata DNS-vastuseid.

DNSSEC esitab ka muid turvakaalutlusi peale valideerimisvigade. Suured allkirjastatud vastused muudavad autoriteetsed serverid DNS-võimendusrünnakute jaoks atraktiivseks. Operaatorid peavad rakendama vastamiskiiruse piiramist ja järgima häid tavasid lahendajate konfigureerimisel, et vältida tahtmatut rünnaku infrastruktuuri muutumist.

Suuremad organisatsioonid jätkavad laialdasema kasutuselevõtu propageerimist. ICANN avaldab kasutusjuhendeid ja riiklikud küberturvalisuse asutused soovitavad üha enam DNSSECi kasutamist valitsuse ja kriitiliste infrastruktuuride domeenide puhul. Prognooside kohaselt võib teise tasandi kasutuselevõtt jõuda 2030. aastaks 50%ni, kuna automatiseerimine CDS/CDNSKEY abil vähendab operatsioonide hõõrdumist.

Reaalsed toimingud: DNS juurtsooni allkirjastamise tseremoonia ja usaldusankrid

DNS-i juurvööndil on DNSSECi arhitektuuris ainulaadne positsioon. Kuna puudub vanemtsoon, mis pakuks DS-kirjet, tuleb root’i KSK-d usaldada väljaspool sidet kui lõplikku usaldusankrit. Selle õigeks tegemine on väga oluline – kõikDNSSECi usaldusahelad saavad alguse siit.

ICANN korraldab neli kuni kuus korda aastas juurtele allakirjutamise tseremooniaid turvalistes rajatistes USAs ja Euroopas. Need tseremooniad hõlmavad erakorralist menetluslikku kontrolli: Riistvaralised turvamoodulid (HSM) hoiavad juurvõti, millele pääseb ligi ainult siis, kui mitu krüptoametnikku kasutavad samaaegselt nutikaarte ja PIN-koode. Füüsiliste kaitsemeetmete hulka kuuluvad võltsimiskindlad kotid, jälgitavad seifid ja täielik videodokumentatsioon.

Esimene juurtsoonide allkirjastamine 2010. aasta juulis tähistas DNSSECi üleminekut teooriast praktilisele ülemaailmsele kasutuselevõtule. 2018 KSK rollover – mis asendas esialgse 2010. aasta KSK-i KSK-2016-ga – testis süsteemi võimet ajakohastada põhilist usaldusankrit. Hoolimata ulatuslikust teavitustegevusest esines umbes 0,2%-l lahendajatest probleeme, mis olid tingitud vananenud tarkvarast või konfiguratsioonist. Tulevased uuendused on kavandatud 2020. aastate keskpaigaks.

Rekursiivsed lahendajad saavad root trust anchor’i tarkvara levitamise või IANA poolt hallatavate automaatsete uuendamisprotokollide kaudu. Kaasaegne lahendustarkvara sisaldab tavaliselt praeguseid ankurdusi ja mehhanisme uuenduste hankimiseks, tagades, et usaldusahel jääb võtmete muutumisel puutumatuks.

Need tseremooniad võivad tunduda keerulised, kuid need annavad õigustatud kindlustunde. DNSSECi aluseks on juurtsooni terviklikkus kogu maailmas ning dokumenteeritud, auditeeritav protsess suurendab usaldust, et see kriitiline infrastruktuur toimib asjakohase rangusega.

DNSSEC-i kasutuselevõtt teie domeenides

Kas olete valmis oma domeenide jaoks DNSSECi lubamiseks? Protsess hõlmab mitmeid etappe, alates kontrollimisest kuni pideva hooldamiseni.

Eeldused kinnitamiseks:

• Teie tippdomeen toetab DNSSECi (vaadake ICANNi kasutuselevõtu ressursse).
• Teie registripidaja aktsepteerib DS-kirjete esitamist
• Teie DNS hosting teenusepakkuja toetab tsooni allkirjastamist ja DNSKEY haldamist

Paljud hallatud DNS-teenuse pakkujad, nagu Cloudflare ja AWS Route 53, tegelevad allkirjastamisega automaatselt. Isehaldatavate tsoonide puhul vajate allkirjastamistööriistu, mis ühilduvad teie autoriteetse serveri tarkvaraga.

Tüüpilised kasutuselevõtu sammud:

1. ZSK- ja KSK-paaride loomine (või teenusepakkuja hallatava allkirjastamise võimaldamine)
2. DNS-vööndi allkirjastamine ja DNSSEC allkirjade kontrollimine lokaalselt
3. DNSKEY kirjete avaldamine (ja valikuliselt CDS/CDNSKEY automaatse DS-halduse jaoks)
4. DS-kirjete esitamine registripidaja liidese kaudu
5. Laske paljundusaeg, seejärel kontrollige kogu ahelat.

Sama oluline on ka valideerimine. Kui teie organisatsioon kasutab rekursiivseid lahendajaid, lubage DNSSEC valideerimine (nt dnssec-validation yes BINDis). Testige tuntud domeenide suhtes: korralikult allkirjastatud saidid peaksid tagastama AD (Authenticated Data) lipu, samas kui dnssec-failed.org peaks andma SERVFAIL.

Parimad tegevuspõhimõtted:

• Jälgige allkirja aegumist: RRSIGi kehtivusaeg on tavaliselt 30 päeva. Automatiseerige tagasiastumine aegsasti enne aegumist.
• Testi võtme ümberlülitamist: Harjutage üleviimise protseduuri staging-keskkonnas enne tootmist.
• Rakendage hoiatus: Konfigureerige DNSSEC valideerimise ebaõnnestumiste seire teie lahendites.
• Dokumentatsioonimenetlused: Selged tööjuhendid hoiavad ära paanika vahejuhtumite või plaaniliste ümberpaigutuste ajal.

Täpne kasutajaliides varieerub registripidaja ja teenusepakkuja lõikes, seega keskenduge pigem põhiliste ülesannete mõistmisele kui konkreetsete nupuvajutuste meeldejätmisele. Eesmärk on DNSSECi kasutuselevõtt ilma katkestusi põhjustamata – hoolikasettevalmistus ja testimine muudavad selle saavutatavaks.

DNSSECi parimad tavad

DNSSECi edukas kasutuselevõtt nõuab enamat kui lihtsalt allkirjade võimaldamist – see nõuab pidevat tähelepanu üksikasjadele ja tööstuse parimate tavade järgimist. Domeeniomanikud peaksid seadma prioriteediks võtmete regulaarse rotatsiooni, et vähendada võtmete ohu ohtu, ning tagama, et kõiki privaatvõtmeid hoitakse turvaliselt, kasutades ideaalis riistvaralisi turvamooduleid või muid kaitstud keskkondi.

DNSSECi valideerimise pidev jälgimine on oluline; see hõlmab allkirjade aegumise kuupäevade jälgimist ja kirjete viivitamatut tühistamist enne nende aegumist. Samuti on oluline kontrollida, et kõik teie DNS-infrastruktuuri komponendid – autoriteetsed serverid, rekursiivsed lahendajad ja registripidaja liidesed – toetaksid täielikult DNSSECi rakendamist ja valideerimist.

Teine oluline samm on testimine. Domeeniomanikud peaksid korrapäraselt kontrollima, et nende DNS-andmed on korrektselt allkirjastatud ja valideeritud, kasutades selleks vahendeid ja testdomeene, et simuleerida nii eduka kui ka ebaõnnestunud valideerimise stsenaariume. Neid parimaid tavasid järgides saavad domeeniomanikud säilitada vastupidavat DNS-infrastruktuuri, kaitsta oma kasutajaid DNS-põhiste rünnakute eest ning tagada oma domeeninimede süsteemi pideva terviklikkuse ja usaldusväärsuse.

Kokkuvõte ja järgmised sammud

DNSSEC muudab domeeninimede süsteemi usalduse kõikehõlmavast arhitektuurist krüptograafilise kontrolliga digitaalallkirjade ja hierarhilise usaldusahela abil, mis tegeleb haavatavustega, mis on olnud olemas alates DNSi loomisest 1980ndatel. Kaitsemehhanismid – RRSIG-allkirjad, DNSKEY/DS-ühendused ja autenditud eitamine NSEC/NSEC3 kaudu – takistavad DNS-cache poisoning ja DNS-spoofing-rünnakuid, mis võiksid muidu kasutajaid vaikselt ümber suunata. Olemasolevate DNS-kirjete puhul, mis sisaldavad võltsitud DNS-andmeid, lükkavad valideerivad lahendajad manipuleeritud DNS-andmed lihtsalt täielikult tagasi.

Hoolimata tegevuse keerukusest on DNSSEC pärast 2010. aasta juurallkirjastamist märkimisväärselt arenenud. Laiaulatuslik tippdomeenide tugi, automatiseerimise paranemine CDS/CDNSKEY abil ja kasvav lahendajate valideerimise määr näitavad, et see on hoogustunud. Suuremad turvaorganisatsioonid toetavad seda domeenide puhul, kus võltsimine võib põhjustada tõsist kahju.

DNS-infrastruktuuri eest vastutavate isikute jaoks on järgmised praktilised sammud järgmised:

• Inventuur, millised domeenid ja tsoonid on praegu allkirjastatud.
• Kavandage DNSSECi järkjärguline kasutuselevõtt, alustades kriitilistest avalike teenuste osutamisest.
• Võimaldage DNSSEC valideerimine sisemistel lahendajatel, kui see on võimalik.
• kehtestab DNSSECi tõrgetega seotud seire- ja reageerimismenetlused.

Täiendavate õppevahendite hulka kuuluvad peamised DNSSEC RFC-d (4033, 4034, 4035), ICANNi ja piirkondlike võrguteabekeskuste kasutuselevõtu juhendid ning testimisvahendid, nagu Verisigni DNSSEC Analyzer. Tee mõistmisest tegudeni on selgem kui kunagi varem – ja turvalisusest saadav kasu õigustab investeeringut.