DNSSEC: îl activați sau nu, și cum
Împotriva a ce protejează DNSSEC, cum funcționează lanțul de încredere, ce algoritm alegeți și cum semnați o zonă fără să o scoateți din funcțiune.
Ce face și ce nu face DNSSEC
Răspunsurile DNS clasice nu poartă nicio dovadă despre proveniența lor. Un resolver care acceptă un răspuns falsificat, de exemplu printr-o otrăvire a cache-ului, trimite utilizatorii către serverul atacatorului atât timp cât înregistrarea falsă rămâne în cache. DNSSEC (RFC 4033, 4034 și 4035) adaugă semnături digitale peste datele din DNS, astfel încât un resolver care validează poate verifica singur că răspunsul vine într-adevăr de la proprietarul zonei și că nu a fost modificat pe drum. Semnătura acoperă nu o singură înregistrare, ci întregul set de înregistrări cu același nume și același tip; este semnată și informația că un nume sau un tip nu există, așa că un atacator nu vă poate păcăli nici ascunzând o înregistrare care chiar există.
DNSSEC oferă autenticitate și integritate, nu confidențialitate. Interogările și răspunsurile rămân vizibile în rețea; criptarea lor este sarcina DNS over TLS sau DNS over HTTPS. Protecția se întinde, în plus, doar până acolo unde se face efectiv validarea: dacă resolverul folosit de laptopul dumneavoastră validează, beneficiați de ea, însă securitatea drumului dintre dispozitiv și acel resolver este o problemă complet separată, pe care trebuie să o rezolvați aparte. În practică cele două straturi se completează: DNSSEC răspunde de corectitudinea datelor, iar DNS-ul criptat de confidențialitatea lor în tranzit.
| Amenințare | Acoperită de DNSSEC? |
|---|---|
| Răspunsuri falsificate injectate în cache-ul unui resolver | Da, resolverele care validează le resping |
| Un cont compromis la furnizorul de DNS care modifică înregistrări | Nu, furnizorul semnează exact ce se află în zonă |
| Cineva care vede ce nume interogați | Nu, pentru asta aveți nevoie de DNS criptat |
| Furtul domeniului la registrar | Nu, protejați contul de registrar cu MFA și registry lock |
| DNS de încredere pentru înregistrările DANE (TLSA) și SSHFP | Da, aceste tipuri depind direct de DNSSEC |
Lanțul de încredere
Validarea pornește de la o cheie în care orice resolver care validează are deja încredere: cheia de semnare a cheilor din zona rădăcină. Rădăcina semnează o înregistrare DS pentru fiecare domeniu de prim nivel, domeniul de prim nivel semnează o înregistrare DS pentru domeniul dumneavoastră, iar zona dumneavoastră publică înregistrările DNSKEY care se potrivesc cu acel DS. Fiecare verigă garantează pentru veriga de dedesubt; încrederea coboară astfel, pas cu pas, de la rădăcină până la înregistrările dumneavoastră.
| Înregistrare | Unde | Rol |
|---|---|---|
DNSKEY | În zona dumneavoastră | Cheile publice folosite pentru a verifica semnăturile din zonă |
RRSIG | În zona dumneavoastră | Semnătura peste un set de înregistrări, cu momentul de început și cel de expirare |
DS | În zona părinte (registrul) | Amprenta cheii de semnare a cheilor; leagă zona dumneavoastră de părinte |
NSEC / NSEC3 | În zona dumneavoastră | Dovada semnată că un nume sau un tip de înregistrare nu există |
CDS / CDNSKEY | În zona dumneavoastră | Semnalul către părinte despre ce înregistrare DS să publice (RFC 7344, RFC 8078) |
Zonele folosesc adesea două feluri de chei. Cheia de semnare a cheilor (KSK) semnează doar setul DNSKEY și este cea la care face referire înregistrarea DS; cheia de semnare a zonei (ZSK) semnează tot restul, așa că poate fi rotită fără să atingeți nimic la registrar. Mulți furnizori de DNS administrat folosesc în schimb o singură cheie combinată de semnare, o soluție mai simplă de operat și identică din punctul de vedere al validării. Ce model se folosește nu este de obicei alegerea dumneavoastră, ci a furnizorului; singurul lucru care contează cu adevărat este ca acea cheie către care trimite DS-ul să fie într-adevăr publicată în zonă.
Merită să îl activați?
Protecția este reală, dar riscul operațional este la fel de real. O zonă semnată cu lanțul rupt este mult mai rea decât o zonă nesemnată: resolverele care validează returnează SERVFAIL, iar utilizatorii lor nu vă pot deschide deloc site-ul și nici nu vă pot livra e-mail. Fiindcă aproape toate resolverele publice mari validează, o singură defecțiune DNSSEC afectează simultan o parte importantă a utilizatorilor de internet. Nici revenirea nu este instantanee, pentru că datele greșite rămân în cache-urile resolverelor cât durează TTL-ul.
| Situație | Recomandare |
|---|---|
| Furnizorul de DNS administrat semnează automat, registrarul acceptă DS sau CDS | Activați-l; furnizorul se ocupă de semnături și de rotația cheilor |
| Vreți DANE pentru e-mail (înregistrări TLSA) | Obligatoriu; DANE nu funcționează deloc fără DNSSEC |
| DNS autoritativ găzduit de dumneavoastră, fără automatizare | Doar după ce aveți semnare automată și monitorizare |
| Urmează în curând o migrare a furnizorului de DNS | Așteptați încheierea migrării sau planificați o tranziție cu mai mulți semnatari |
| Registrarul nu poate publica înregistrări DS | Nu este posibil până când mutați domeniul sau registrarul adaugă suport |
Pentru majoritatea organizațiilor care folosesc un serviciu de DNS administrat, activarea DNSSEC înseamnă câteva clicuri în panoul furnizorului și o singură înregistrare DS la registrar. Momentele periculoase sunt rare, dar previzibile: schimbarea furnizorului de DNS, schimbarea registrarului și rotațiile manuale de chei. Dacă planificați din timp aceste trei momente, DNSSEC funcționează în rest de la sine, fără să vă mai ceară atenție.
Alegerea algoritmilor
Fiecare înregistrare DNSKEY și DS își indică algoritmul printr-un număr. RFC 8624 dă recomandări de implementare și de utilizare; documentele care îl urmează le mai ajustează din când în când, însă alegerea practică pentru instalările noi a rămas aceeași de ani buni. Dacă furnizorul nu vă oferă exclusiv altceva, alegeți ECDSA P-256 cu SHA-256, adică algoritmul 13.
| Număr | Nume | Pentru semnare nouă |
|---|---|---|
| 13 | ECDSAP256SHA256 | Recomandat: semnături mici, validate pe scară largă |
| 15 | ED25519 | Alegere bună acolo unde furnizorul și validatorii îl acceptă |
| 8 | RSASHA256 | Acceptabil; produce răspunsuri mai mari decât ECDSA |
| 14 | ECDSAP384SHA384 | Acceptabil, însă rareori necesar |
| 5 / 7 | RSASHA1 / RSASHA1-NSEC3-SHA1 | Nu îl folosiți pentru semnare nouă |
Pentru înregistrările DS folosiți SHA-256 (tipul de amprentă 2). Semnăturile ECDSA mici păstrează răspunsurile DNS sub limitele uzuale de dimensiune UDP, ceea ce reduce simțitor căderea pe TCP și problemele de fragmentare. Evitați să publicați mai mulți algoritmi în aceeași zonă: resolverele se așteaptă să găsească o semnătură validă pentru fiecare algoritm anunțat, așa că instalările mixte măresc și răspunsurile, și șansa de eroare.
Pentru NSEC3, RFC 9276 recomandă zero iterații suplimentare și niciun salt. Numerele mari de iterații încarcă degeaba resolverele și nu oferă o protecție semnificativă împotriva enumerării zonei; în plus, unele resolvere tratează valorile foarte mari drept nesigure.
Cum activați DNSSEC în siguranță
- Confirmați că serverele de nume ale domeniului sunt cele de la furnizorul dumneavoastră de DNS, cu interogarea WHOIS sau cu o interogare NS în Interogare DNS.
- Activați semnarea la furnizorul de DNS și așteptați până când zona servește înregistrări
DNSKEYșiRRSIG. - Copiați datele înregistrării DS pe care le afișează furnizorul (key tag, algoritm, tip de amprentă, amprentă) sau DNSKEY-ul, dacă registrarul vă cere asta în schimb.
- Adăugați-le la registrar, în setările DNSSEC ale domeniului. Unele registre acceptă înregistrări CDS sau CDNSKEY din zonă și fac acest pas automat, în locul dumneavoastră.
- Verificați lanțul din afara rețelei dumneavoastră cu
digsaudelv, apoi continuați să îl urmăriți cel puțin o zi. - Adăugați o monitorizare permanentă care alertează la erori de validare și la semnături apropiate de expirare; este important ca acea verificare să ruleze independent de propria infrastructură.
# the DS record published by the parent (com)
dig +short DS example.com
12345 13 2 3F8A...9C1D
# the keys in your zone; one should match the DS key tag
dig +dnssec +multi DNSKEY example.com
# a validating lookup; look for "fully validated"
delv example.com A
# the AD flag from a validating resolver
dig +dnssec example.com A | grep -E 'flags:.* ad'Nu publicați niciodată o înregistrare DS înainte ca zona să fie semnată
Rotația cheilor
Cheile de semnare se înlocuiesc din când în când, fie după un calendar stabilit, fie în urma unei suspiciuni de compromitere. Furnizorii administrați rotesc singuri cheile de semnare a zonei, de obicei fără ca dumneavoastră să observați ceva. Rotația cheii la care face referire înregistrarea DS cere însă și ca părintele să publice o înregistrare DS nouă, pas care este fie automatizat prin CDS/CDNSKEY, fie făcut manual la registrar. De aceea rotațiile cu adevărat riscante sunt tocmai cele care vă cer și dumneavoastră o acțiune.
Metoda sigură este întotdeauna suprapunerea: publicați cheia nouă alături de cea veche, așteptați golirea cache-urilor (cel puțin TTL-ul setului DNSKEY, iar la rotațiile de KSK și TTL-ul înregistrării DS), comutați și abia apoi scoateți cheia veche. Scoaterea prea devreme a cheii vechi sau a DS-ului vechi lasă resolverele cu date în cache care nu se mai potrivesc cu nimic din zonă; majoritatea întreruperilor apar exact din această grabă.
Și semnăturile au un termen de expirare. Fiecare RRSIG poartă un moment de expirare, iar o zonă care nu mai este resemnată, de exemplu pentru că serverul de semnare a fost oprit, începe să pice la validare imediat ce acele momente trec. O monitorizare care avertizează cu câteva zile înainte de expirare elimină complet și definitiv această categorie de incidente.
Schimbarea furnizorului de DNS sau a registrarului
Mutarea unei zone semnate la un furnizor de DNS nou este cel mai frecvent mod de a strica DNSSEC. Furnizorul nou semnează cu alte chei, în timp ce registrul publică în continuare înregistrarea DS pentru cheile vechi. De îndată ce serverele de nume se schimbă, resolverele care validează văd o zonă ale cărei chei nu se potrivesc cu DS-ul și încep să returneze SERVFAIL. Mai mult, defecțiunea rămâne adesea invizibilă pentru echipa care face mutarea, pentru că totul arată perfect atunci când interogați zona nouă direct de la serverele de nume ale furnizorului nou.
| Abordare | Pași | Compromis |
|---|---|---|
| Trecere temporară la nesemnat | Scoateți DS-ul de la registrar, așteptați TTL-ul DS-ului (plus o marjă de siguranță), mutați serverele de nume, semnați la furnizorul nou, adăugați DS-ul nou | Simplu; zona rămâne neprotejată o perioadă scurtă |
| Tranziție cu mai mulți semnatari (RFC 8901) | Fiecare furnizor publică și cheile celuilalt, se adaugă înregistrări DS pentru ambele, apoi furnizorul vechi este scos | Fără perioadă neprotejată; are nevoie de suport de la ambii furnizori |
Transferurile între registrari păstrează de obicei înregistrarea DS, dar verificați acest lucru după ce transferul se încheie. Lista de verificare pentru migrarea domeniului așază acești pași în ordine, împreună cu e-mailul, TLS-ul și redirecționările.
Monitorizarea unei zone semnate
Defecțiunile DNSSEC sunt tăcute pentru dumneavoastră și zgomotoase pentru utilizatori: propriul resolver poate să nu valideze, așa că din birou totul pare în regulă în timp ce o mare parte din internet primește SERVFAIL. De aceea monitorizarea trebuie să interogheze din afara rețelei dumneavoastră, printr-un resolver care validează. Ea trebuie să privească și înainte, pentru că cea mai frecventă defecțiune, expirarea semnăturilor, se poate prevedea cu zile bune în avans.
- Alertați când un resolver care validează returnează SERVFAIL pentru numele importante (apex,
www, serverele MX). - Alertați când momentele de expirare ale înregistrărilor RRSIG sunt la mai puțin de câteva zile distanță.
- Alertați când înregistrarea DS de la părinte nu se mai potrivește cu niciun DNSKEY din zonă.
- Înregistrați schimbările de DNSKEY și DS, astfel încât rotațiile să fie vizibile în istoricul modificărilor.
- Includeți starea DNSSEC în listele de verificare pentru migrări și pentru schimbarea registrarului.
Furnizorii de DNS administrat își monitorizează de obicei propria semnare, însă nu pot vedea greșelile făcute la registrarul dumneavoastră, cum ar fi o înregistrare DS veche rămasă după schimbarea furnizorului. Singura verificare care vede lanțul întreg exact așa cum îl văd utilizatorii este propria dumneavoastră verificare din exterior.
Păstrați verificarea destul de simplă încât să continue să ruleze ani la rând. Un delv zilnic pentru apex, rulat de pe o mașină din cloud, cu o alertă la orice rezultat diferit de "fully validated", acoperă singur cea mai mare parte a riscului. O verificare mică, dar care nu se oprește niciodată, valorează mult mai mult decât o monitorizare complicată lăsată fără întreținere după șase luni.
Depanarea erorilor SERVFAIL
Dacă un domeniu se rezolvă printr-un resolver care nu validează, dar returnează SERVFAIL printr-unul care validează, primul suspect este DNSSEC. Comparați răspunsurile de la cele două resolvere, apoi folosiți dig +cd, care cere resolverului să sară peste validare. Un răspuns cu +cd și SERVFAIL fără el confirmă clar o eroare de validare. Ce rămâne de făcut este să găsiți veriga ruptă din lanț; tabelul de mai jos adună cauzele cele mai frecvente și rezolvarea fiecăreia.
dig @192.0.2.53 example.com A # validating resolver: SERVFAIL
dig @192.0.2.53 example.com A +cd # checking disabled: answer returned| Cauză | Rezolvare |
|---|---|
| DS-ul de la registrar nu se potrivește cu niciun DNSKEY | Publicați DS-ul corect sau scoateți-l și adăugați-l din nou după semnare |
| Semnături RRSIG expirate | Reporniți sau reparați semnarea automată; resemnați zona |
| DS vechi rămas după schimbarea furnizorului de DNS | Scoateți DS-ul vechi; adăugați DS-ul furnizorului nou |
| Algoritm neacceptat sau retras din uz | Treceți la algoritmul 13 sau 15 |
| Înregistrări editate în afara semnatarului (modificare manuală a fișierului de zonă) | Faceți modificările doar prin sistemul de semnare |
Întrebări frecvente
DNSSEC îmi încetinește site-ul?
Aproape deloc. Resolverele care validează fac puțin mai multă muncă și pun rezultatele în cache, iar semnăturile ECDSA păstrează răspunsurile mici. În practică utilizatorii nu simt nicio diferență.
Pot vedea dacă un domeniu folosește DNSSEC?
Interogați înregistrarea DS cu dig DS example.com sau căutați un câmp DNSSEC precum signedDelegation în rezultatul WHOIS al registrului. O înregistrare DS la părinte înseamnă că domeniul este așteptat să fie semnat.
DNSSEC criptează traficul DNS?
Nu. Semnează înregistrările doar pentru ca ele să poată fi verificate. Criptarea interogărilor și a răspunsurilor vine din DNS over TLS sau DNS over HTTPS, care rezolvă o cu totul altă problemă.
Ce se întâmplă dacă renunț la DNSSEC?
Scoateți mai întâi înregistrarea DS de la registrar și așteptați expirarea TTL-ului ei, apoi opriți semnarea. Oprirea semnării cât timp DS-ul este încă publicat duce direct la erori de validare.
Algoritmul 8 (RSASHA256) mai este sigur?
Da, este acceptat pe scară largă și rămâne o alegere acceptabilă. Pentru instalările noi se preferă algoritmul 13, pentru că are chei și semnături mult mai mici.
De ce îmi funcționează domeniul mie, dar nu și unor utilizatori?
Resolverul dumneavoastră poate să nu valideze DNSSEC, în timp ce al lor validează. Când validarea eșuează, resolverele care validează returnează SERVFAIL. Testați printr-un resolver public care validează și cu delv.
Am nevoie de DNSSEC pentru securitatea e-mailului?
Nu pentru SPF, DKIM, DMARC sau MTA-STS. Este însă obligatoriu pentru DANE, care fixează în DNS certificatele serverelor de e-mail, ca alternativă la MTA-STS sau ca o completare a lui.
Surse
- RFC 4033: Introducere și cerințe pentru securitatea DNS
- RFC 4034: Înregistrări de resurse pentru extensiile de securitate DNS
- RFC 4035: Modificări de protocol pentru extensiile de securitate DNS
- RFC 8624: Cerințe de implementare și ghid de utilizare a algoritmilor pentru DNSSEC
- RFC 9276: Ghid pentru setarea parametrilor NSEC3
- RFC 8901: Modele DNSSEC cu mai mulți semnatari
- RFC 7344: Automatizarea întreținerii încrederii în delegarea DNSSEC (CDS/CDNSKEY)