DNSSEC v preprostem jeziku

Modul 8: Varnost in odpravljanje težav · Čas branja: 11 minut

Učni cilj: Po tej lekciji boste v preprostem jeziku znali razložiti, kaj DNSSEC ščiti, kako deluje veriga zaupanja in zakaj lahko pride do težav ob prenosu domene.

Ključni pojmi: DNSSEC, podpis (RRSIG), ključ (DNSKEY), zapis DS, veriga zaupanja, validirajoči razreševalnik, SERVFAIL

Problem: kako veste, da je odgovor pristen?

V modulu 1 ste videli, da razreševalnik postavi niz vprašanj: korenskemu strežniku, strežniku TLD in avtoritativnemu imenskemu strežniku. Odgovor, ki pride nazaj, se sprejme kot pravilen in shrani v predpomnilnik. Toda navaden DNS ne preverja, ali ta odgovor res prihaja od pravega imenskega strežnika. Napadalec, ki uspe poslati lažen odgovor, preden prispe pravi, lahko razreševalnik prepriča, da example.com živi na 203.0.113.66 namesto na 192.0.2.10. To se imenuje zastrupljanje predpomnilnika (cache poisoning): predpomnilnik je "zastrupljen" in vsak, ki uporablja ta razreševalnik, pristane na napačnem strežniku.

DNSSEC (DNS Security Extensions) to rešuje tako, da odgovore podpisuje. Razreševalnik lahko nato preveri, ali je odgovor res pristen in ali ni bil med potjo spremenjen.

Kaj DNSSEC zagotavlja in česa ne

To je najpomembneje zapomniti si:

Podpis deluje kot pečat na ovojnici: vsak lahko prebere pismo, vendar takoj vidite, če ga je kdo odprl.

Trije sestavni deli

DNSSEC doda nekaj tipov zapisov. Sami jih ni treba ustvarjati (to opravi Vaš upravljavec DNS ali nadzorna plošča), vendar se boste z njimi srečali:

• DNSKEY: javni ključ cone. S tem lahko vsak preveri podpise.
• RRSIG: podpis ob skupini zapisov. Vsak odgovor A, MX ali TXT dobi svoj RRSIG. Podpis ima začetni in končni datum: cono je zato treba redno znova podpisovati.
• DS (Delegation Signer): kratek "prstni odtis" ključa Vaše cone. Ta ni v Vaši lastni coni, temveč pri nadrejeni coni: za example.com torej pri registru za .com (Verisign), za domeno .nl pri SIDN (register .nl na Nizozemskem).

Tako je videti podpisan odgovor (skrajšano):

$ dig example.com A +dnssec +noall +answer
example.com.  3600  IN  A      192.0.2.10
example.com.  3600  IN  RRSIG  A 13 2 3600 20261119000000 20261029000000 30794 example.com. s7yJ5o...

V RRSIG med drugim vidite algoritem (13 = ECDSA P-256 s SHA-256), končni datum (19. november 2026), začetni datum in številko ključa (30794).

Veriga zaupanja

Zakaj je DS pri nadrejeni coni? Ker ključ v Vaši lastni coni ničesar ne dokazuje: napadalec bi lahko poslal tudi svoj lasten ključ. Zato preverjanje poteka od zgoraj navzdol:

1. Razreševalnik zaupa ključu korena. Ta je vgrajen v vsak validirajoči razreševalnik (zasidrano zaupanje, trust anchor).
2. Koren ima DS za .com, podpisan s korenskim ključem. S tem razreševalnik ve, kateri ključ bi moral imeti .com.
3. Cona .com ima DS za example.com, podpisan s ključem .com.
4. Cona example.com ima DNSKEY, ki ustreza temu DS, in s tem je mogoče preveriti vse RRSIG.

Vsak člen dokazuje naslednjega. Če se en člen poruši, je cela veriga nezanesljiva.

Validirajoči razreševalnik (večina velikih javnih razreševalnikov in vse več ponudnikov) to verigo preveri. Če se ujema, dobite odgovor. Če se ne ujema, razreševalnik ne vrne odgovora, temveč napako SERVFAIL. Obiskovalcu se stran takrat zdi, kot da preprosto "ne obstaja", čeprav so Vaši zapisi morda povsem v redu.

To lahko sami preverite z domeno, ki je bila namenoma pokvarjena:

$ dig dnssec-failed.org A @1.1.1.1
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL
; EDE: 9 (DNSKEY Missing): (no SEP matching the DS found for dnssec-failed.org.)

Z +cd ("checking disabled") razreševalniku naročite, naj preverjanje preskoči. Če takrat dobite odgovor, veste zagotovo, da je vzrok v DNSSEC:

$ dig +cd dnssec-failed.org A @1.1.1.1 +short
96.99.227.255

Domena brez DNSSEC (brez DS pri nadrejeni coni) ne vrne SERVFAIL: preprosto ni podpisana in se obravnava kot "nezaščitena".

Kje gre narobe: prenos domene in menjava ključev

DNSSEC sam po sebi se skoraj nikoli ne pokvari. Težava nastane, ko DS pri registru ne ustreza več ključu v coni. To se zgodi predvsem:

• Ob prenosu na nove imenske strežnike ali drugega ponudnika DNS. Novi ponudnik podpisuje z lastnim ključem, pri registru pa je še vedno DS starega ponudnika. Posledica: SERVFAIL za vsakogar z validirajočim razreševalnikom. To je klasična napaka po prenosu domene.
• Ob menjavi ključa, pri čemer nov DS ni bil (pravočasno) poslan registru.
• Če podpisi potečejo, ker cona ni več znova podpisana.

Varno zaporedje korakov ob prenosu je zato:

1. Odstranite DS pri registru (ali poskrbite, da nov ponudnik najprej pošlje svoj DS, ki ga dodate).
2. Počakajte, da poteče TTL starega DS.
3. Zamenjajte imenske strežnike.
4. Vklopite DNSSEC pri novem ponudniku in poskrbite, da se nov DS postavi pri registru.

Mnogi registrarji in nadzorne plošče danes to urejajo samodejno, dokler sta domena in DNS pri istem ponudniku. Če sta pri različnih ponudnikih, morate DS prenesti sami.

Preverjanje na lastno roko: DNSViz, Zonemaster in internet.nl

Verige Vam ni treba preverjati z dig. Obstajajo brezplačna orodja, ki to naredijo namesto Vas in prikažejo rezultat.

DNSViz (https://dnsviz.net/) narobi celotno verigo kot sliko. Tako ga uporabite:

1. Na začetni strani v iskalno polje vnesite ime domene (samo ime, brez https:// in brez www) ter kliknite Go.
2. DNSViz prikaže zadnjo analizo. Če je stara ali ste pravkar kaj spremenili, kliknite Update now. Po nekaj sekundah se prikaže slika.
3. Sliko berite od zgoraj navzdol: na vrhu je koren (.), pod njim TLD (na primer nl), na dnu Vaša domena. Vsaka cona je okvir.

Kaj vidite na sliki:

Verigo sledite takole: DS (pri nadrejeni coni) kaže na DNSKEY (v Vaši coni), ta DNSKEY pa z RRSIG podpiše zapise. To je natanko veriga iz te lekcije, le da je narisana.

Barve povedo, ali je vse v redu:

• Modra: varno (secure). Veriga poteka neprekinjeno od korena do tega dela.
• Črna: nepodpisano (insecure). Ni DS, zato ni česa preverjati. To ni napaka, domena preprosto ne uporablja DNSSEC.
• Rdeča: pokvarjeno (bogus). DS se ne ujema s ključem, ali podpis ni pravilen. Validirajoči razreševalnik v tem primeru vrne SERVFAIL.
• Vijolična (pri podpisu): podpis je potekel ali še ni veljaven. Cona ni več ponovno podpisana.
• Rumena: opozorilo, na primer imenski strežnik, ki se ne odziva pravilno, ali algoritem, ki ga orodje ne pozna.
• Siva in pikčasta: nanaša se na ključ, ki ne obstaja. Če vidite pikčast DNSKEY pod DS, pomeni, da je pri nadrejeni coni še vedno DS starega ključa: klasična napaka po prenosu domene.

Poleg posameznega dela se lahko prikaže trikotnik (opozorilo) ali okrogel znak napake. Z miško se postavite nanj, ali si oglejte seznam pod sliko: tam je z besedami zapisano, kaj je narobe.

Poskusite z sidn.nl (vse modro) in z dnssec-failed.org (rdeče, s pikčastim ključem pod DS).

Druga orodja, ki isto stvar preverjajo z drugega zornega kota:

• Zonemaster (https://zonemaster.net/): preveri Vašo celotno cono tako, kot to naredi register, vključno z DNSSEC. Rezultat je seznam z zeleno (v redu), oranžno (opozorilo) in rdečo (napaka).
• internet.nl (https://internet.nl/): test spletne strani in e-pošte med drugim pokaže, ali je DNSSEC za Vašo domeno in Vaše poštne strežnike v redu, z zelenimi kljukicami ali rdečimi križci.
• Verisign DNSSEC Debugger (https://dnssec-debugger.verisignlabs.com/): verigo preveri korak za korakom in pri vsakem koraku postavi zeleno kljukico ali rdeč križec. Priročno, če iščete točno določeno napako.

Uporabite jih po vsaki spremembi DNSSEC in zagotovo pred in po prenosu domene. Pustite orodju, da znova izvede analizo: tudi ta orodja delujejo s predpomnilniki in TTL.

V praksi: tako je videti v nadzorni plošči

V Moj WebOké vklopite DNSSEC pri domeni pod DNSSEC/DANE; nadzorna plošča ustvari ključe in pošlje DS registru. V DirectAdmin in pri zunanjih ponudnikih, kot je Cloudflare, se to navadno imenuje "vklop DNSSEC"; Cloudflare Vam nato prikaže zapis DS, ki ga morate sami vnesti pri svojem registrarju. Druge nadzorne plošče delujejo podobno: vedno obstaja korak "ustvarjanje ključev" (pri ponudniku DNS) in korak "DS pri registru" (pri registrarju).

Povzetek

• DNSSEC podpisuje DNS odgovore, da lahko razreševalnik preveri, ali so pristni. Nič ne šifrira.
• DNSKEY je ključ, RRSIG podpis, DS prstni odtis pri nadrejeni coni.
• Preverjanje poteka kot veriga od korena do Vaše domene. Če se en člen poruši, validirajoči razreševalnik vrne SERVFAIL.
• Skoraj vse težave nastanejo, ker DS pri registru ne ustreza več, pogosto po prenosu domene.
• Z dig +cd vidite, ali je težava posledica DNSSEC.
• DNSViz nariše verigo: modra je varno, črna je nepodpisano, rdeča je pokvarjeno. Zonemaster, internet.nl in Verisign DNSSEC Debugger so dobra dodatna mnenja.

Kviz

Naloga

Naloga Z8.1: Opazovanje DNSSEC. Ugotovite, katera od dveh domen ima DNSSEC v redu in katera je bila namenoma pokvarjena: sidn.nl in dnssec-failed.org. Za obe poizvedite zapis DS in zapis A prek validirajočega razreševalnika (na primer 1.1.1.1 ali 9.9.9.9), z orodjem dig ali spletnim orodjem. Vnesite: številko ključa (key tag, prvo število) zapisa DS za sidn.nl, in status, ki ga dobite za dnssec-failed.org.

Naloga Z8.1b: Branje DNSViz. Analizirajte nlnetlabs.nl v DNSViz (https://dnsviz.net/, vnesite ime in kliknite Go; kliknite Update now, če je analiza stara). Preberite sliko in vnesite: (1) status nlnetlabs.nl (varno, nepodpisano ali pokvarjeno), (2) številko algoritma zapisov DNSKEY (zapisano v vsakem ovalu kot alg=), (3) koliko ovalov DNSKEY je v coni nlnetlabs.nl, (4) številko ključa (id=) sivo zapolnjenega DNSKEY, na katerega kaže DS, in (5) status, ki ga DNSViz prikaže za dnssec-failed.org. Preverjanje te podatke pridobi v živo.

Naloga O8.1: Ocena treh demonstracijskih con DNSSEC. Pripravili smo tri demonstracijske cone: signed-demo.dnspractice.com (pravilna veriga), broken-demo.dnspractice.com (namenoma pokvarjena) in unsigned-demo.dnspractice.com (nepodpisana). Za vsako cono ugotovite, ali je varna, pokvarjena ali nepodpisana, na primer z DNSViz ali z dig +dnssec (pazite na zastavico AD, pri SERVFAIL pa poskusite tudi +cd). Spodaj za vsako cono izberite svoj odgovor.

Za nadaljnje branje

Ti članki opisujejo korake v nadzornih ploščah WebOké; pri drugih ponudnikih se gumbi imenujejo drugače.

• Priročnik WebOké 5.8: DNSSEC in DANE
• Kaj je DNSSEC?
• DNSSEC aktiviranje
• Spletna stran ali e-pošta ne deluje po selitvi ali spremembi DNS: preverite svojo domeno