DNSSEC pe înțelesul tuturor

Modulul 8: Securitate și rezolvarea problemelor · Timp de citire: 11 minute

Obiectiv de învățare: După această lecție veți putea explica pe înțelesul tuturor ce protejează DNSSEC, cum funcționează lanțul de încredere și de ce poate apărea o problemă la o mutare.

Concepte-cheie: DNSSEC, semnătură (RRSIG), cheie (DNSKEY), înregistrare DS, lanț de încredere, resolver validator, SERVFAIL

Problema: de unde știți că un răspuns este autentic?

În modulul 1 ați văzut că un resolver pune o serie de întrebări: către root, către serverul TLD și către serverul de nume autoritar. Răspunsul care revine este acceptat ca atare și pus în cache. Dar DNS-ul obișnuit nu verifică dacă acel răspuns provine chiar de la serverul de nume corect. Un atacator care reușește să trimită un răspuns fals înainte ca răspunsul real să ajungă poate face un resolver să creadă că example.com se află la 203.0.113.66 în loc de 192.0.2.10. Acest lucru se numește cache poisoning: cache-ul este „otrăvit”, iar oricine folosește acel resolver ajunge pe serverul greșit.

DNSSEC (DNS Security Extensions) rezolvă această problemă semnând răspunsurile. Resolverul poate verifica astfel dacă un răspuns este autentic și dacă nu a fost modificat pe parcurs.

Ce face și ce nu face DNSSEC

Acesta este cel mai important lucru de reținut:

O semnătură funcționează ca sigiliul de pe un plic: oricine poate citi scrisoarea, dar vedeți imediat dacă cineva a deschis-o.

Cele trei componente

DNSSEC adaugă câteva tipuri de înregistrări. Nu trebuie să le creați dumneavoastră (asta face administratorul DNS sau panoul de control), dar le veți întâlni:

• DNSKEY: cheia publică a zonei. Cu aceasta, oricine poate verifica semnăturile.
• RRSIG: semnătura unui grup de înregistrări. Fiecare răspuns A, MX sau TXT primește o înregistrare RRSIG. O semnătură are o dată de început și de sfârșit: zona trebuie deci resemnată periodic.
• DS (Delegation Signer): o „amprentă” scurtă a cheii zonei dumneavoastră. Aceasta nu se află în propria zonă, ci la părinte: pentru example.com, deci la registrul .com (Verisign), pentru un domeniu .nl la SIDN (registrul domeniului .nl din Țările de Jos).

Așa arată un răspuns semnat (prescurtat):

$ 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...

În RRSIG vedeți, printre altele, algoritmul (13 = ECDSA P-256 cu SHA-256), data de expirare (19 noiembrie 2026), data de început și numărul cheii (30794).

Lanțul de încredere

De ce se află DS la părinte? Pentru că o cheie din propria zonă nu dovedește nimic: un atacator ar putea trimite și el o cheie proprie. De aceea, verificarea se face de sus în jos:

1. Resolverul are încredere în cheia root. Aceasta este încorporată în fiecare resolver validator (trust anchor).
2. Root-ul are o înregistrare DS pentru .com, semnată cu cheia root. Astfel, resolverul știe ce cheie ar trebui să aibă .com.
3. Zona .com are o înregistrare DS pentru example.com, semnată cu cheia .com.
4. Zona example.com are o înregistrare DNSKEY care se potrivește cu acel DS, iar astfel toate înregistrările RRSIG pot fi verificate.

Fiecare verigă o dovedește pe următoarea. Dacă se rupe o verigă, întregul lanț devine nesigur.

Un resolver validator (majoritatea resolverelor publice mari și tot mai mulți furnizori) parcurge acest lanț. Dacă totul este corect, primiți răspunsul. Dacă nu este corect, resolverul nu oferă niciun răspuns, ci starea de eroare SERVFAIL. Pentru vizitator, site-ul pare pur și simplu „inexistent”, chiar dacă înregistrările dumneavoastră ar putea fi perfect corecte.

Puteți vedea acest lucru singuri, folosind un domeniu stricat intenționat:

$ 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.)

Cu +cd („checking disabled”) îi cereți resolverului să omită verificarea. Dacă atunci primiți totuși un răspuns, știți sigur că problema este cauzată de DNSSEC:

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

Un domeniu fără DNSSEC (fără DS la părinte) nu produce SERVFAIL: pur și simplu nu este semnat și este lăsat să treacă ca „nesecurizat”.

Unde apar problemele: transferul domeniului și schimbarea cheilor

DNSSEC în sine se strică foarte rar. Problema apare atunci când DS-ul de la registru nu se mai potrivește cu cheia din zonă. Acest lucru se întâmplă mai ales:

• La o mutare a serverelor de nume sau a furnizorului de DNS. Noul furnizor semnează cu o cheie proprie, dar la registru se află încă DS-ul vechiului furnizor. Rezultat: SERVFAIL pentru toți cei care folosesc un resolver validator. Aceasta este greșeala clasică de după o mutare.
• La o schimbare de chei, atunci când noul DS nu a fost trimis (la timp) la registru.
• Când semnăturile expiră, deoarece zona nu mai este resemnată.

Ordinea sigură la o mutare este, prin urmare:

1. Eliminați DS-ul de la registru (sau cereți noului furnizor să vă dea un DS pe care îl adăugați).
2. Așteptați să treacă TTL-ul vechiului DS.
3. Schimbați serverele de nume.
4. Activați DNSSEC la noul furnizor și cereți ca noul DS să fie plasat la registru.

Multe registrare și panouri de control rezolvă acest lucru automat astăzi, atât timp cât domeniul și DNS-ul se află la același furnizor. Dacă se află la furnizori diferiți, trebuie să transferați DS-ul dumneavoastră manual.

Verificare personală: DNSViz, Zonemaster și internet.nl

Nu trebuie să verificați lanțul cu dig. Există instrumente gratuite care fac asta pentru dumneavoastră și afișează rezultatul.

DNSViz (https://dnsviz.net/) desenează întregul lanț sub formă de imagine. Iată cum îl folosiți:

1. Tastați pe pagina principală numele domeniului în câmpul de căutare (doar numele, fără https:// și fără www) și faceți clic pe Go.
2. DNSViz afișează ultima analiză. Dacă este veche, sau dacă tocmai ați modificat ceva, faceți clic pe Update now. După câteva secunde apare imaginea.
3. Citiți imaginea de sus în jos: sus se află root-ul (.), dedesubt TLD-ul (de exemplu nl), iar jos domeniul dumneavoastră. Fiecare zonă este un chenar.

Ce vedeți în imagine:

Lanțul se urmărește astfel: DS (la părinte) arată către DNSKEY (în zona dumneavoastră), iar acel DNSKEY aplică, printr-o RRSIG, semnătura sa pe înregistrări. Acesta este exact lanțul din această lecție, dar desenat.

Culorile indică dacă totul este corect:

• Albastru: sigur (secure). Lanțul merge neîntrerupt de la root la această componentă.
• Negru: nesemnat (insecure). Nu există niciun DS, deci nu este nimic de verificat. Nu este o eroare, domeniul pur și simplu nu folosește DNSSEC.
• Roșu: stricat (bogus). Un DS nu se potrivește cu o cheie, sau o semnătură nu este corectă. Un resolver validator va returna atunci SERVFAIL.
• Violet (la o semnătură): semnătura a expirat sau încă nu este valabilă. Zona nu mai este resemnată.
• Galben: un avertisment, de exemplu un server de nume care nu răspunde corect, sau un algoritm pe care instrumentul nu îl recunoaște.
• Gri și punctat: se face trimitere la o cheie care nu există. Dacă vedeți un DNSKEY punctat sub un DS, înseamnă că la părinte se mai află încă un DS al unei chei vechi: greșeala clasică de după o mutare.

Lângă o componentă poate apărea un triunghi (avertisment) sau un semn rotund de eroare. Treceți cu mouse-ul peste el, sau consultați lista de sub imagine: acolo este explicat în cuvinte ce anume este greșit.

Încercați cu sidn.nl (totul albastru) și cu dnssec-failed.org (roșu, cu o cheie punctată sub DS).

Alte instrumente care privesc același lucru dintr-un alt unghi:

• Zonemaster (https://zonemaster.net/): verifică întreaga zonă la fel cum ar face-o un registru, inclusiv DNSSEC. Rezultatul este o listă cu verde (bun), portocaliu (avertisment) și roșu (eroare).
• internet.nl (https://internet.nl/): testul pentru site și e-mail arată, printre altele, dacă DNSSEC este în regulă pentru domeniul și serverele dumneavoastră de e-mail, cu bife verzi sau cruci roșii.
• Verisign DNSSEC Debugger (https://dnssec-debugger.verisignlabs.com/): parcurge lanțul pas cu pas și pune la fiecare pas o bifă verde sau o cruce roșie. Util când căutați o eroare concretă.

Folosiți-le după fiecare modificare a DNSSEC și, cu siguranță, înainte și după o mutare. Lăsați instrumentul să analizeze din nou: și aceste instrumente lucrează cu cache-uri și TTL-uri.

În practică: așa arată într-un panou de control

În Contul meu WebOké activați DNSSEC la un domeniu, în secțiunea DNSSEC/DANE; panoul generează cheile și trimite DS-ul la registru. În DirectAdmin și la furnizori externi precum Cloudflare se numește de obicei „Activare DNSSEC”; Cloudflare vă afișează atunci o înregistrare DS pe care trebuie să o introduceți chiar dumneavoastră la registrarul dumneavoastră. Alte panouri funcționează similar: există întotdeauna un pas „generare chei” (la furnizorul DNS) și un pas „DS la registru” (la registrar).

Rezumat

• DNSSEC semnează răspunsurile DNS astfel încât un resolver poate verifica dacă sunt autentice. Nu criptează nimic.
• DNSKEY este cheia, RRSIG este semnătura, DS este amprenta de la părinte.
• Verificarea funcționează ca un lanț de la root până la domeniul dumneavoastră. Dacă se rupe o verigă, un resolver validator returnează SERVFAIL.
• Aproape toate problemele apar deoarece DS-ul de la registru nu se mai potrivește, adesea după o mutare.
• Cu dig +cd vedeți dacă o problemă provine de la DNSSEC.
• DNSViz desenează lanțul: albastru este sigur, negru este nesemnat, roșu este stricat. Zonemaster, internet.nl și Verisign DNSSEC Debugger sunt opinii secundare utile.

Quiz

Exercițiu

Exercițiul Z8.1: Observarea DNSSEC. Aflați care dintre două domenii are DNSSEC corect configurat și care a fost stricat intenționat: sidn.nl și dnssec-failed.org. Solicitați pentru ambele înregistrarea DS și înregistrarea A printr-un resolver validator (de exemplu 1.1.1.1 sau 9.9.9.9), folosind dig sau un instrument online. Completați: numărul cheii (key tag, primul număr) al DS-ului pentru sidn.nl, și starea pe care o obțineți pentru dnssec-failed.org.

Exercițiul Z8.1b: Citirea DNSViz. Analizați nlnetlabs.nl în DNSViz (https://dnsviz.net/, introduceți numele și faceți clic pe Go; faceți clic pe Update now dacă analiza este veche). Citiți imaginea și completați: (1) starea domeniului nlnetlabs.nl (sigur, nesemnat sau stricat), (2) numărul algoritmului înregistrărilor DNSKEY (apare în fiecare oval ca alg=), (3) câte ovaluri DNSKEY se află în zona nlnetlabs.nl, (4) numărul cheii (id=) a DNSKEY-ului umplut cu gri către care indică DS-ul, și (5) starea pe care DNSViz o afișează pentru dnssec-failed.org. Verificarea solicită aceleași date în timp real.

Exercițiul O8.1: Evaluarea a trei zone demonstrative DNSSEC. Am pregătit trei zone demonstrative: signed-demo.dnspractice.com (lanț corect), broken-demo.dnspractice.com (stricată intenționat) și unsigned-demo.dnspractice.com (nesemnată). Aflați pentru fiecare zonă dacă este sigură, stricată sau nesemnată, de exemplu cu DNSViz sau cu dig +dnssec (urmăriți steagul AD și încercați, în cazul unui SERVFAIL, și +cd). Alegeți mai jos răspunsul pentru fiecare zonă.

Lectură suplimentară

Aceste articole descriu pașii din panourile WebOké; la alți furnizori butoanele au alte denumiri.

• Manual WebOké 5.8: DNSSEC și DANE
• Ce este DNSSEC?
• Activare DNSSEC
• Site-ul web sau e-mailul nu funcționează după o mutare sau o modificare DNS: verificați-vă domeniul