Sigurnost DNS-a: DNSSEC, CAA zapisi i DDoS zaštita

Dana 11. listopada 2026. korijenska zona DNS-a prebacuje se na jedinstveni ključ za potpisivanje ključeva (KSK-2024) — tek druga promjena tog ključa u povijesti. Većina korisnika neće primijetiti nikakvu promjenu: više od 95% poslužitelja za razlučivanje naziva (resolvera) koji sudjeluju u izvještavanju već prepoznaje novi ključ. Neuspjeh će doživjeti samo resolveri koji provjeravaju valjanost (validirajući resolveri) bez oznake ključa 38696 u povjereničkom sidru — provjerite svoj već sada.

Sigurnost DNS-a nije jedna značajka, nego tri komplementarna mehanizma, a svaki štiti drugo svojstvo. DNSSEC autentificira same podatke, pa resolver može provjeriti da odgovor dolazi iz autoritativnog izvora i da nije promijenjen tijekom prijenosa; pritom ne šifrira ništa. CAA zapisi govore certifikacijskim tijelima koja od njih smiju izdavati certifikate za vašu domenu, što sužava rizik od neovlaštenog izdavanja, ali domenu ne čini imune na druge napade. DDoS zaštita održava DNS infrastrukturu dostupnom tijekom poplava prometa, što je preduvjet za svaku drugu uslugu koja ovisi o razlučivanju naziva. Ovaj vodič objašnjava tri mehanizma čitateljima koji poznaju web razvoj, ali nikada nisu upravljali DNS-om. Prolazi kroz konkretne primjere konfiguracije i završava kontrolnim popisom radnji za listopadski rok i razdoblje nakon njega.

Što je DNS i zašto je meta napada

DNS je telefonski imenik interneta: prevodi ljudski čitljiva imena poput example.com u IP adrese na koje se klijenti stvarno spajaju. Preglednik učitava stranicu tako da najprije pita operativni sustav, a on šalje upit rekurzivnom resolveru (poslužitelju za razlučivanje naziva) — usluzi koju vodi vaš ISP, vaša tvrtka ili javni pružatelj poput 1.1.1.1 ili 8.8.8.8 — da pronađe odgovor. Resolver prati lanac autoritativnih DNS poslužitelja — onih koji su izvor istine za pojedinu zonu (dio nazivničkog prostora, obično domena i njezine poddomene) — i vraća rezultat. Najčešći tipovi zapisa jesu A i AAAA (IPv4 i IPv6 adrese), CNAME (alias), MX (poslužitelji e-pošte) i TXT (proizvoljni tekst za zapise provjere poput SPF-a i DKIM-a). Odgovori se uobičajeno prenose UDP-om na portu 53, dok se TCP na portu 53 koristi za veće odgovore.

Napadači ciljaju DNS jer se nalazi između korisnika i svega ostalog. Nekoliko svojstava čini ga privlačnim:

• Dostupnost. Ako DNS prestane odgovarati, ništa se ne razlučuje: web, e-pošta, API-ji i interne usluge odjednom otkazuju. Domena je praktički izvan mreže čak i kad je njezin web poslužitelj potpuno zdrav.
• Integritet. Ako napadač može krivotvoriti DNS odgovor, može preusmjeriti korisnike na zlonamjerni poslužitelj dok adresna traka i dalje pokazuje ispravan naziv domene.
• Povjerljivost. Svaki upit otkriva što korisnik pokušava dohvatiti. DNS sam po sebi ne skriva tu informaciju.

Svaki od tri mehanizma opisana u ovom vodiču pokriva jedno od tih svojstava. DNSSEC štiti integritet i autentičnost izvora. CAA štiti drugu vrstu kontrole: tko smije ishoditi certifikat za vašu domenu. DDoS zaštita štiti dostupnost.

DNSSEC: autentifikacija, a ne šifriranje

DNSSEC (DNS Security Extensions) dodaje digitalne potpise DNS zapisima. Zamislite to kao potpisanu poruku u prozirnoj omotnici: primatelj može provjeriti tko je poruku napisao i da nitko nije promijenio nijednu riječ, no svatko tko rukuje omotnicom i dalje može pročitati sadržaj. Standardi — RFC 4033, RFC 4034 i RFC 4035 — izrijekom navode da DNSSEC pruža autentifikaciju podrijetla podataka i integritet podataka, ali da ne pruža povjerljivost. Ne šifrira upite ni odgovore, ne skriva koje domene pretražujete i ne čini vaš DNS promet privatnim.

Mehanički, zona potpisuje svoje skupove zapisa ključem za potpisivanje zone (ZSK) i objavljuje potpise kao RRSIG zapise. Drugi ključ, ključ za potpisivanje ključeva (KSK), potpisuje DNSKEY zapis zone kako bi se ključevi zone mogli rotirati neovisno. Lanac povjerenja počinje u korijenskoj zoni: nadređena zona objavljuje DS (Delegation Signer) zapis koji sadrži sažetak KSK-a podređene zone, a vaš registrar objavljuje DS zapis za vašu domenu. Validirajući resolver prolazi tim lancem od korijenskog povjereničkog sidra do vaše domene i provjerava svaki potpis. Ako potpis nedostaje ili nije valjan, resolver vraća SERVFAIL i klijent uopće ne dobije odgovor.

Ono što DNSSEC doista štiti jest put odgovora. Validirajući resolver ne može biti prevaren krivotvorenim odgovorom, otrovanom predmemorijom ili odgovorom promijenjenim tijekom prijenosa, jer se potpis neće moći potvrditi. Ono što ne štiti jest sve oko toga: ne zaustavlja napadača koji vas želi preplaviti prometom, ne skriva vaše upite i ne štiti korisnike od domena koje su namjerno zlonamjerne, ali ispravno potpisane. Potpisana zona nije pouzdana zona; to je zona čiji se odgovori mogu provjeriti.

Praktična cijena DNSSEC-a operativne je prirode. Umjesto nijednog ključa držite dva, morate ih rotirati prema rasporedu, a svaki potpis povećava veličinu odgovora, zbog čega su EDNS0 i TCP nastavak važni. Najčešći oblik kvara jest prekinut lanac: potpisana zona čiji DS zapis nikada nije objavljen ili DS zapis koji ne odgovara trenutačnom ključu. Kvar je za krajnje korisnike nevidljiv — jednostavno dobiju SERVFAIL — zbog čega je DNSSEC jedna od rijetkih sigurnosnih kontrola čiji prekid izgleda kao običan mrežni prekid.

Promjena korijenskog KSK-a u listopadu 2026.

KSK korijenske zone krajnje je povjereničko sidro svakog validirajućeg resolvera. Prva promjena dogodila se u listopadu 2018.; druga se događa sada. Novi ključ, KSK-2024, prvi je put objavljen u korijenskoj zoni 11. siječnja 2025., a prema mehanizmu automatskog ažuriranja povjereničkih sidara opisanom u RFC-u 5011 resolveri koji novi ključ promatraju 30 dana počinju mu automatski vjerovati. Dana 11. listopada 2026. korijenska zona počet će koristiti isključivo KSK-2024.

Validirajući resolver koji do tog datuma nema oznaku ključa 38696 u povjereničkom sidru neće moći potvrditi ništa ispod korijena — u praksi potpuni neuspjeh razlučivanja za sve koji ga koriste. ICANN-ova je preporuka provjeriti ručno, umjesto pretpostaviti da su automatska ažuriranja odradila posao:

• ISC BIND: provjerite datoteku bind.keys
• Unbound / PowerDNS Recursor: provjerite datoteku root.key
• Knot Resolver: provjerite datoteku root.keys

Ako oznaka ključa 38696 nedostaje, provjerite jesu li automatska ažuriranja prema RFC-u 5011 omogućena i ima li resolver dozvolu za pisanje u svoj direktorij za pohranu kako bi se novi ključ doista mogao spremiti. Ono u što vaš resolver vjeruje možete provjeriti uobičajenim DNS alatima:

dig +dnssec example.com A
dig DNSKEY example.com
dig DS example.com

Prva naredba prikazuje RRSIG zapise pridružene odgovoru. Druga prikazuje ključeve za potpisivanje zone, a treća ono što nadređena zona objavljuje o podređenoj zoni. Ako upravljate validirajućim resolverom, listopadski datum tretirajte kao tvrdi rok: provjerite povjereničko sidro, omogućite automatska ažuriranja i provjerite ponovno nakon promjene.

CAA zapisi: tko smije izdavati certifikate za vašu domenu

Prema zadanim postavkama svako javno certifikacijsko tijelo (CA) smije izdati certifikat za bilo koju domenu, pod uvjetom da dokaže nadzor nad njome jednom od standardnih metoda provjere. To znači da je javna web PKI infrastruktura snažna koliko i najslabiji proces provjere nekog certifikacijskog tijela. CAA (Certification Authority Authorization) zapis omogućuje vam da objavite popis dopuštenih: ova tijela, i samo ova, smiju izdavati certifikate za ovu domenu.

Format zapisa standardiziran je u RFC-u 8659 (objavljen 2019., zamjenjuje izvorni RFC 6844 iz 2013.). Od rujna 2017. zahtjevi CA/Browser Foruma (Baseline Requirements) obvezuju sva javno priznata certifikacijska tijela da prije izdavanja certifikata provjere CAA. Sintaksa je jednostavna:

example.com. IN CAA 0 issue "letsencrypt.org"

Polja su: ime vlasnika, klasa i tip, zastavica (flag) (gotovo uvijek 0; vrijednost 128 označava kritičan zapis pa tijelo koje ga ne razumije mora odbiti izdavanje), oznaka (tag) i vrijednost. U praksi su važne tri oznake:

• issue — koja tijela smiju izdavati certifikate za domenu i njezine poddomene.
• issuewild — koja tijela smiju izdavati wildcard certifikate (*.example.com). Ako zapis issuewild ne postoji, zapisi issue odnose se i na wildcard izdavanje.
• iodef — kamo tijelo treba prijaviti pokušaj izdavanja koji krši vaša pravila, obično mailto: ili https: adresu.

CAA zapisi su aditivni, a tijelo pri pretraživanju koristi najbliži skup zapisa. Zahtjev za www.community.example.org provjerava www.community.example.org, zatim community.example.org, zatim example.org i zaustavlja se na prvom skupu CAA zapisa koji pronađe. CAA pretraživanje također prati CNAME lance, jer tijelo izdaje certifikat za odredište aliasa. To vam daje fino upravljanje: jednom tijelu možete dopustiti izdavanje za cijelu domenu, a drugom za jednu poddomenu koju hosta dobavljač oblaka.

Praktičan skup zapisa za malu stranicu koja koristi Let’s Encrypt i komercijalno tijelo te želi izvještavanje izgleda ovako:

example.com.   IN CAA 0 issue "letsencrypt.org"
example.com.   IN CAA 0 issue "sectigo.com"
example.com.   IN CAA 0 iodef "mailto:security@example.com"

Da biste dopustili samo obične, a ne wildcard certifikate, dodajte zabranu wildcard izdavanja:

example.com.   IN CAA 0 issuewild ";"

Prazna vrijednost u navodnicima — u praksi zapisana kao ";" — ne odgovara nijednom tijelu, što je upravo poanta. RFC 8659 istim trikom zabranjuje svako izdavanje za naziv, što je povremeno korisno za domene koje želite zadržati bez certifikata. Ono što vaša zona trenutačno objavljuje možete provjeriti naredbom:

dig CAA example.com
dig +short CAA example.com

Što CAA čini, a što ne čini

CAA je kontrola nad izdavanjem certifikata — i samo time. RFC je izrijekom jasan da je usklađenost s objavljenim CAA zapisom nužan, ali ne i dovoljan uvjet za izdavanje te da se CAA ne smije koristiti kao dio provjere certifikata. Praktične posljedice:

• CAA ne štiti certifikate koji su već izdani i valjani. Ograničava samo buduće izdavanje.
• CAA je jak koliko i usklađenost tijela. Tijelo koje ignorira zapis ili tijelo izvan javne WebPKI infrastrukture njime nije zaustavljeno.
• CAA ne zaustavlja phishing, ne sprječava zlouporabu valjanog certifikata te ne štiti vaš DNS od otmice ni vaše poslužitelje od DDoS napada.
• CAA zapisi moraju pokrivati svako tijelo koje za vas izdaje certifikate, uključujući tijela koja koriste treće strane poput vašeg dobavljača hostinga, CDN-a ili dobavljača sigurnosti e-pošte. Objavljivanje CAA zapisa koji izostavlja tijelo o kojem ovisi vaša infrastruktura prekida obnove — prekid izgleda kao istek certifikata.
• Vrijednost CAA-a raste kada su zapisi potpisani DNSSEC-om. RFC 8659 snažno preporučuje DNSSEC za CAA, jer se potpisani CAA zapis ne može krivotvoriti ni potisnuti, a tijelo može dokazati da je provjerilo ispravan skup zapisa.

CAA je najbolje shvatiti kao kontrolu smanjenja rizika, a ne kao jamstvo. Zadano stanje “svako tijelo smije izdavati” pretvara u “smiju izdavati samo tijela koja sam odabrao”, što osjetno sužava površinu za neovlašteno izdavanje certifikata, a košta gotovo ništa za održavanje.

DDoS zaštita na DNS razini i razlika u odnosu na mrežno i aplikacijsko ublažavanje

Distribuirani napad uskraćivanjem usluge (DDoS) ima cilj učiniti uslugu nedostupnom preplavljivanjem prometom. CISA-ine zajedničke smjernice dijele napade u tri obitelji: volumetrijski napadi koji troše propusnost, protokolni napadi koji iskorištavaju slabosti u obradi veza i aplikacijski napadi koji iscrpljuju resurse pojedine aplikacije. DNS privlači sve tri, uz nekoliko oblika napada svojstvenih načinu na koji DNS radi.

• Refleksija i pojačanje (amplifikacija). Napadač šalje mali upit s lažiranom izvornom adresom mnogim otvorenim resolverima, koji žrtvi odgovaraju znatno većim odgovorima. Napadačev se promet umnožava višestruko.
• Poplava nasumičnih poddomena (DNS water torture). Napadač upituje milijune nasumičnih poddomena ciljane domene. Svaki je upit promašaj predmemorije, pa autoritativni poslužitelj mora obraditi svaki pojedinačno, a legitimni se upiti gube u šumu.
• NXDOMAIN poplave. Poplava upita za nazive koji ne postoje, čime se iscrpljuje autoritativni poslužitelj i predmemorije resolvera ispred njega.
• Izravne poplave upita i TCP SYN poplave. Velika količina običnih upita ili poplava veza prema TCP/53 krajnjoj točki koju veliki odgovori zahtijevaju.

Razlog zašto DDoS napad na DNS znači više od istog prometa prema web poslužitelju jest jedinstvena točka kvara. Ako web poslužitelj padne, korisnici vide stranicu pogreške. Ako DNS padne, korisnici ne mogu ni pronaći web poslužitelj, a e-pošta, API-ji i interne usluge otkazuju zajedno s njim. DNS zaštita stoga je preduvjet za svaku drugu razinu dostupnosti.

Ublažavanje na DNS razini održava put razlučivanja aktivnim. Standardni gradivni blokovi:

• Anycast. Ista IP adresa oglašava se s mnogo poslužitelja na mnogo lokacija; promet pristaje na najbliži, a napad se širi cijelom mrežom umjesto da se koncentrira na jedan poslužitelj.
• Ograničavanje stope prometa (rate limiting) i ograničavanje stope odgovora (RRL). Poslužitelj odbacuje ili usporava prekomjeran promet s jednog izvora, uključujući odgovore sklone pojačanju zbog kojih refleksijski napadi djeluju.
• DNS vatrozidi i RPZ. Filtriranje na resolveru ili rubu mreže na temelju političkih zona, što pomaže apsorbirati poplave nasumičnih poddomena i NXDOMAIN upita.
• Upravljani DNS pružatelji. Komercijalne DNS usluge (uključujući velike pružatelje oblaka) vode anycast infrastrukturu s ugrađenom apsorpcijom DDoS napada, pa vaši autoritativni poslužitelji nikada ne vide poplavu.

Mrežno ublažavanje (L3/L4) šire je: štiti mrežni i prijenosni sloj za bilo koju uslugu — zaštitu od SYN poplava, pročišćavanje paketa i blackholing na rubu mreže. Centar za pročišćavanje može apsorbirati volumetrijski napad usmjeren na vaše IP adrese prije nego stigne do vaše infrastrukture. To je opća kontrola koja ne razlikuje radi li se o DNS-u ili nečem drugom.

Aplikacijsko ublažavanje (L7) uže je u drugom smjeru: štiti samu aplikaciju — vatrozid za web aplikacije (WAF), upravljanje botovima, zaštita od HTTP poplava i CDN predmemoriranje održavaju web stranicu odzivnom tijekom aplikacijskih napada. Na toj razini živi većina onih koji o “DDoS zaštiti za web stranicu” razmišljaju, i to je razina na kojoj su TLS, predmemoriranje i zaštita izvornog poslužitelja važni.

Tri su razine komplementarne, a načini kvara različiti. Možete imati izvrsnu aplikacijsku zaštitu i i dalje biti izvan mreže ako napadač preplavi vaš autoritativni DNS. Možete imati izvrsnu DNS zaštitu i i dalje izgubiti web aplikaciju zbog HTTP poplave. Mrežno pročišćavanje štiti oboje, ali samo ako promet doista prolazi kroz infrastrukturu za pročišćavanje. Razuman redoslijed operacija: najprije zaštitite DNS, zatim mrežni put, zatim aplikaciju. DNSSEC u tu sliku ulazi samo kao sloj autentifikacije — krivotvoreni odgovori ne prolaze provjeru, ali napadaču koji vas samo želi preplaviti potpisi nisu važni i jednostavno će poslati još upita.

Operativni kompromisi

Svaka kontrola ovdje ima cijenu, a pošten način izbora jest usporediti cijenu s rizikom.

DNSSEC zahtijeva stalan operativni rad. Umjesto nijednog ključa upravljate s dva, morate ih rotirati prema rasporedu, a svaki je potpisani odgovor veći, što znači da vaša DNS infrastruktura treba EDNS0 i ispravan TCP nastavak. NSEC zapisi koji dokazuju nepostojanje također otkrivaju nazive u vašoj zoni; NSEC3 ih raspršuje po cijenu više računanja i većih odgovora. Najveći stvarni rizik jest tihi prekid: DS zapis koji zastari ili potpis kojem istekne valjanost pretvara valjane upite u SERVFAIL, a kvar izgleda kao mrežni prekid, a ne kao pogreška konfiguracije. Većina registrara, DNS usluga u oblaku i CDN-ova danas podržava DNSSEC jednim klikom, što uklanja većinu operativnog tereta; preostaju nadzor i higijena ključeva.

CAA zahtijeva koordinaciju. Kontrola je ispravna samo ako skup zapisa odgovara stvarnosti: mora pokriti svako tijelo koje za vas izdaje certifikate, uključujući tijela koja koriste vaš hosting, CDN i dobavljači e-pošte. Popis onih koji danas mogu izdavati certifikate za vaše domene preduvjet je, zajedno s postupkom dodavanja tijela prije nego što ga počnete koristiti. Način kvara jest prekid obnove, zbog čega kontrolni popis u nastavku uključuje testiranje izdavanja nakon svake CAA promjene. Korist — sužavanje rizika od neovlaštenog izdavanja — stvarna je, ali za većinu stranica skromna, pa je CAA najbolje tretirati kao higijensku kontrolu koja se postavlja za nekoliko minuta i gotovo ništa ne košta za održavanje.

DDoS zaštita košta novac ili kontrolu. Upravljani DNS s anycastom i ugrađenim ublažavanjem košta malo i uklanja jedinstvenu točku kvara, po cijenu ovisnosti o pružatelju. Vlastiti DNS daje punu kontrolu, ali vas čini odgovornima za problem dostupnosti: bez anycasta i pročišćavanja odlučan napadač mora samo pronaći vaše IP adrese. Stalna zaštita košta više od one na zahtjev, ali izbjegava latenciju aktivacije koja napadu omogućuje da pobijedi u prvim minutama. Ograničavanje stope ima lažne pozitivne rezultate: legitimni korisnici iza zajedničkog NAT-a ili velikog korporativnog resolvera mogu biti usporeni zajedno s napadačem. Ne postoji konfiguracija koja je istodobno maksimalno zaštitna i nikada pogrešna, pa je realan cilj zaštita koja je dovoljno dobra, mjerljiva i redovito testirana.

Uobičajene pogreške

• Pretpostavka da DNSSEC šifrira vaše upite. On autentificira; ne skriva. Ako vam je privatnost upita važna, dodajte DNS over TLS (DoT) ili DNS over HTTPS (DoH) na resolveru.
• Uključivanje DNSSEC-a bez DS zapisa. Potpisana zona bez DS zapisa kod registrara nevidljiva je validirajućim resolverima, a neusklađen DS zapis prekida lanac u potpunosti.
• Objavljivanje CAA zapisa bez popisa svojih tijela. Prva obnova nakon CAA promjene otkrit će tijelo koje ste zaboravili — ono vašeg dobavljača hostinga.
• Uvjerenje da CAA zaustavlja phishing ili DDoS. Ono ograničava samo izdavanje certifikata, i to samo među usklađenim tijelima.
• Tretiranje anycasta kao cjelovitog odgovora na DDoS. Anycast raspoređuje opterećenje; ograničavanje stope, nadzor i plan za najveće napade i dalje su važni.
• Zanemarivanje dozvola za pisanje resolvera. Automatska ažuriranja prema RFC-u 5011 tiho propadaju kada resolver ne može zapisati pohranu povjereničkog sidra — upravo tako resolveri propuste KSK-2024.
• Vlastiti autoritativni DNS bez redundancije i ublažavanja. Pojedinačni poslužitelj s javnom IP adresom najlakša je meta na internetu.
• Izostanak nadzora jer je DNSSEC uključen. Greške provjere isplivaju kao SERVFAIL, a ne kao upozorenja; bez nadzora nećete znati da se lanac prekinuo.

Kontrolni popis radnji

• Prije 11. listopada 2026. provjerite sadrži li povjereničko sidro vašeg validirajućeg resolvera oznaku ključa 38696 (bind.keys za BIND, root.key za Unbound/PowerDNS Recursor, root.keys za Knot Resolver) te jesu li automatska ažuriranja prema RFC-u 5011 omogućena uz pravo pisanja u direktorij za pohranu. Provjerite ponovno nakon datuma promjene.
• Uključite DNSSEC na domenama kojima upravljate i objavite DS zapis kod registrara. Ako potpisivanje umjesto vas vodi vaš DNS pružatelj ili CDN, uključite ga tamo.
• Objavite CAA zapise za tijela koja vi i vaši pružatelji doista koristite, dodajte iodef zapis za izvještavanje i testirajte izdavanje (Let’s Encryptovo staging okruženje sigurno je mjesto za to) prije i poslije promjene.
• Stavite autoritativni DNS iza upravljanog DNS-a s anycastom ili provjerite objavljuje li vaš trenutačni pružatelj svoj stav o DDoS zaštiti jasnim jezikom.
• Dodajte šifrirani DNS (DoT ili DoH) za putove resolvera na kojima vam je privatnost upita važna.
• Pratite SERVFAIL i greške provjere te postavite godišnji podsjetnik za reviziju ključeva, tijela i DNS pružatelja.

Tri mehanizma odgovaraju na tri različita pitanja. DNSSEC odgovara na pitanje “mogu li vjerovati ovom odgovoru?”, CAA na pitanje “tko smije izdavati certifikate za moju domenu?”, a DDoS zaštita na DNS razini na pitanje “hoće li se moja domena i dalje razlučivati tijekom napada?”. Oni su komplementarni, a ne zamjenjivi — a listopadska promjena korijenskog ključa koristan je podsjetnik da i najtemeljnija sigurnosna kontrola zahtijeva aktivno, stalno održavanje, a ne jednokratnu konfiguraciju.

Izvori: ICANN: Priprema za promjenu korijenskog KSK-a, CISA: Razumijevanje i odgovor na distribuirane napade uskraćivanjem usluge, RFC 4033: Uvod u sigurnost DNS-a i zahtjevi, RFC 8659: DNS Certification Authority Authorization (CAA) Resource Record, RFC 5011: Automatska ažuriranja DNSSEC povjereničkih sidara, Let’s Encrypt: Certificate Authority Authorization (CAA)