A DNSSEC (Domain Name System Security Extensions) az internet (illetve az IP-alapú hálózatok) egyik alapvető, névfeloldást biztosító szolgáltatásának, a DNS-nek az Internet Engineering Task Force (IETF) által specifikált, biztonsági célú kiterjesztése. Célja a DNS-kliensek (illetve resolverek) számára a DNS-ben található adatok integritásának és autentikusságának biztosítása, illetve egy rekord nem létezésének autentikus bizonyítása – nem célja viszont sem a tényleges elérhetőség igazolása, sem az adatok titkos kezelése.
Áttekintés A Domain Name System (DNS) eredeti céljai között nem szerepelt a biztonság; jól skálázható, elosztott rendszernek tervezték. A Domain Name System Security Extensions (DNSSEC) megpróbálja utólag biztonságossá tenni a DNS protokollt, a visszamenőleges kompatibilitás megőrzésével. Az RFC 3833 dokumentál néhány ismert, DNS elleni támadást és a DNSSEC által azokra nyújtott válaszokat.
A DNSSEC tervezési célja szerint megvédi az internetes resolvereket (klienseket) a hamisított DNS-adatoktól, pl. egy DNS-gyorsítótár-mérgezéses támadás során. A DNSSEC-ben minden válaszüzenet digitálisan alá van írva. Az aláírás ellenőrzésével a DNS-resolver igazolni tudja, hogy a kapott információ megegyezik (korrekt és teljes) az autoritatív (mérvadó) névkiszolgáló által nyújtottal. Bár a felhasználók számára többnyire az IP-címek védelme a legsürgetőbb, fontos, hogy a DNSSEC képes megvédeni a DNS-ben tárolt egyéb információkat, pl. a CERT rekordokban tárolt általános célú kriptográfiai tanúsítványokat. Az RFC 4398 ad egy ajánlást ezen, e-mailre is használható tanúsítványok terjesztésére, aminek segítségével kiépíthető lenne egy DNSSEC-re épülő nemzetközi infrastruktúra az elektronikusan aláírt e-maileknek.
A DNSSEC nem foglalkozik az adatok titkosításával; a DNSSEC-válaszüzenetek digitálisan alá vannak írva, de nem titkosak. A DNSSEC nem nyújt közvetlenül védelmet a túlterheléses támadásokkal szemben, bár az az indirekt előnye megvan, hogy potenciálisan nem megbízható hálózatokon is lehet kommunikálni a segítségével. Nagy mennyiségi adat DNS-szerverek közötti biztonságos átvitelével (pl. DNS-zónatranszfer) más szabványok, nem a DNSSEC foglalkozik. Ahogy az IETF RFC 4367 megállapítja, egyes felhasználók és fejlesztők hamis feltevésekkel élnek a DNS-nevekkel kapcsolatban, például feltételezik, hogy egy vállalat domainneve mindig előáll, ha a közkeletű elnevezése után írjuk a „.com”-ot. A DNSSEC nem képes védelmet nyújtani az ilyen hamis feltevésekkel szemben, csak azt tudja bizonyítani, hogy az adat ténylegesen adott domain tulajdonosától származik-e.
A DNSSEC specifikációi (DNSSEC-bis néven) részletekbe menően leírják a DNSSEC protokoll jelenlegi működését. Lásd RFC 4033, RFC 4034 és RFC 4035. Ezen új RFC-k kiadásával (2005. március) a korábbi RFC 2535 elavultnak minősül.
Általános nézet szerintInterview with Dan Kaminsky on DNSSEC (25 Jun 2009) Kaminsky interview: DNSSEC addresses cross-organizational trust and security a DNS biztonságossá tétele kritikus fontosságú az egész internet biztonságának növeléséhez, bevezetését azonban számos tényező hátráltatja: Olyan visszamenőleg kompatibilis szabványt kell létrehozni, ami az egész internet méretéig skálázható Meg kell akadályozni a DNS-zóna bejárását („zone enumeration”) Implementálni kell a DNSSEC-et DNS-kiszolgálók és -kliensek (resolverek) széles körében Meg kell egyezni arról, hogy ki birtokolja a TLD-k gyökereihez tartozó kulcsokat Túl kell lépni a DNSSEC, illetve a DNSSEC bevezetésének látszólagos bonyolultságán
Ezen problémák egy részének megoldása folyamatban van, a bevezetés különböző területeken (és tartományokban) halad előre.
Működése A DNSSEC működésének lényege, hogy a DNS-lekérdezéskor visszaadott erőforrásrekordokat digitálisan aláírja nyilvános kulcsú rejtjelezés segítségével. A megfelelő DNSKEY rekordot egy bizalmi lánc (chain of trust) hitelesíti, ami a DNS-gyökérzóna ellenőrzött nyilvános kulcsaitól indul ki, ami az eljáráshoz szükséges megbízható harmadik fél.
Összetevők Rekordok A DNSSEC megvalósításához több új DNS-rekordtípusra volt szükség, ezek: RRSIG (Resource record signature) DNSKEY DS (Delegation signer) NSEC (Next-Secure record) NSEC3 (Next-Secure record version 3) NSEC3PARAM (Parameter record for use with NSEC3) nem új rekordtípus, de fontos megemlíteni az RRset-eket (Resource Record set, erőforrásrekord-halmaz). Ezek a zónában létező azonos típusú rekordok (pl. az NS rekordok összessége), egyetlen aláírás védi őket.
A DNSSEC használatakor minden lekérdezésre adott válasz a kért rekordon kívül egy RRSIG DNS-rekordot is tartalmazni fog. Az RRSIG-rekord a válaszrekord(ok) hashéhez tartozó digitális aláírás, amit ellenőrizni a DNSKEY rekordban található megfelelő nyilvános kulcs segítségével lehet. A DS rekordot (a szülő zónában a gyerek kulcsát igazoló rekord) a bizalmi láncban található DNSKEY-k végigkeresése során használják. Az NSEC és NSEC3 rekordok a kért cím nem létezését igazolják hiteles módon (az NSEC3 opt-out flagje jelzi, hogy a DNSSEC-kel alá nem írt neveket is belefoglalták-e; a lényeg, hogy minden aláírt névhez KELL tartoznia egy őt igazoló NSEC3 rekordnak, míg az aláíratlan nevekhez LEHET hogy tartozik ilyenRFC 5155: Zones using Opt-Out MAY contain a mixture of Opt-Out NSEC3 RRs and non-Opt-Out NSEC3 RRs. Each owner name within the zone that owns authoritative RRSets MUST have a corresponding NSEC3 RR. Owner names that correspond to unsigned delegations MAY have a corresponding NSEC3 RR.). Az NSEC3PARAM paraméterrekordból derül ki, hogy a nem létezési igazolás kiállításakor milyen algoritmussal és milyen salttal, hány menetben képeztek hasht a zóna neveiből (ha egy zónában több NSEC3PARAM RR létezik, akkor több érvényes NSEC3-lánc tartozik a zónához, melyekből a szerver választhatRFC 5155: If there are multiple NSEC3PARAM RRs present, there are multiple valid NSEC3 chains present. The server must choose one of them, but may use any criteria to do so.).
Kapcsolóbitek A DNS-üzenetek szerkezete is bővítésre szorult. Az EDNS0 bővítmény (Extended DNS, RFC2671) szerinti DNS-fejlécben néhány új kapcsolóbit került bevezetésre: DO (Dnssec Ok): lekérdezésnél használatos, azt jelenti hogy a kérdező a válasszal együtt a válaszhoz tartozó DNSSEC rekordokat is kéri. CD (Checking Disabled): lekérdezésnél használatos, jelentése: „ne ellenőrizz, majd én”. Ilyenkor a DNS-szerver az egyébként hiányos vagy hibás adatot is elküldi. AD (Authenticated Data): válaszokban használatos. Azt jelenti, hogy a kérdező névkiszolgáló a bizalmi láncon végigment, ellenőrizte és rendben találta az információt DNSSEC szerint.
Algoritmusok A DNSSEC-et a kezdetektől bővíthetőre tervezték, hogy a titkosító algoritmusokat egy új, hatásos támadás nyilvánosságra hozása után visszamenőlegesen kompatibilis módon lehessen újra cserélni. Jelenleg (2013. július) a következő fontosabb biztonsági algoritmusokat használják a DNSSEC-ben:
Algoritmusmező Algoritmus Forrás Implementációs státusz 1 RSA/MD5 ELAVULT 3 DSA/SHA-1 opcionális 5 RSA/SHA-1 KÖTELEZŐ 7 RSASHA1-NSEC3-SHA1 RFC 5155 javasolt 8 RSA/SHA-256 RFC 5702 javasolt 10 RSA/SHA-512 javasolt 12 GOST R 34.10-2001 RFC 5933 opcionális 13 ECDSA/SHA-256 RFC 6605 javasolt 14 ECDSA/SHA-384 javasolt
A lekérdezési folyamat Egy DNS-lekérdezés eredményéből a biztonságosra tervezett DNS-resolver meg tudja állapítani, hogy a válasz megbízható-e, ha pedig nem megbízható, annak oka az-e, hogy a névkiszolgáló nem támogatja a DNSSEC-et vagy más probléma merült föl. A lekérdezési folyamat más a rekurzív névkiszolgálók (pl. ISP-k) esetében és a kliens operációs rendszereken általános ún. stub resolvereknél.
Rekurzív névkiszolgálók A bizalmi lánc modellje szerint haladva a szülőtartomány (DNS-zóna) Delegation Signer (DS) erőforrásrekordja használható a gyermektartomány (subdomain) DNSKEY rekordjának ellenőrzésére; a gyermektartomány szintén tartalmazhat DS rekordokat, amikkel a még alacsonyabb szintű tartományok ellenőrizhetők. Tegyük fel, hogy egy rekurzív névkiszolgáló, például egy ISP-é szeretne hozzájutni a www.example.com domén IP-címeihez (A rekord és/vagy AAAA rekord).
A folyamat első lépéseként a biztonságtudatos resolver beállítja a DNS-lekérdezés „DO” kapcsolóbitjét. Mivel a DO bit az EDNS-ben definiált kiterjesztett flagek egyike, valamennyi DNSSEC-műveletnél szükség van az EDNS-támogatásra. Az EDNS-támogatás a DNSSEC-műveletek nagyobb csomagméretei miatt is szükséges. Miután a resolver megkapja a normál DNS-lekérdezés során a választ, ellenőrzi, hogy a válasz helyes-e. Ideális esetben először a DNS-gyökér DS és DNSKEY rekordjainak ellenőrzését végzi el; a következő lépésben a gyökérben található, a com legfelső szintű tartományra vonatkozó DS rekordok alapján ellenőrzi a com zóna DNSKEY rekordjait. Ezután megvizsgálja, hogy létezik-e a com zónában DS rekord az example.com gyermektartományhoz, és ha igen, a DS rekord alapján ellenőrzi az example.com zónában található DNSKEY rekordot. Végül sor kerül a www.example.com A rekordjaihoz tartozó RRSIG rekord ellenőrzésére.
A fenti ideális példától számos eltérés képzelhető el.
Először is, ha az example.com nem támogatja a DNSSEC-et, a válasz nem fog tartalmazni RRSIG rekordot, és a com zónában nem lesz az example.com-hoz tartozó DS rekord. Ha az „example.com”-hoz mégis tartozik DS rekord, de a válaszban nincs RRSIG rekord, valami nincs rendben – talán épp egy közbeékelődéses támadás zajlik, és a támadó kitörli a DNSSEC-információkat és meghamisítja az A rekordokat. Az is előfordulhat persze, hogy útközben egy nem biztonságtudatos névkiszolgáló nullázta a lekérdezés DO flagjét vagy a válasz RRSIG rekordját. Vagy konfigurációs hiba is történhetett.
Továbbá, lehet hogy nem létezik a www.example.com doménnév, ebben az esetben a válasz nem RRSIG rekordot fog tartalmazni, hanem vagy NSEC, vagy NSEC3 rekordot. Ezek a „következő biztonságos” rekordok, amiknek segítségével a resolver igazolhatja, hogy adott tartománynév nem létezik. Az NSEC/NSEC3 rekordokhoz tartoznak RRSIG rekordok, amik az előzőekben ismertetett módon ellenőrizhetők. („Következő biztonságos” – tehát valamilyen sorrend szerint a zónában található következő, aláírt bejegyzés. Azért nem adhatja vissza a kiszolgáló egyszerűen, hogy a „www.example.com nem létezik”, mivel akkor ennek – és az összes lehetséges nem létező doménnévnek – a nem létezéséről aláírt bizonyítékot kellene szolgáltatnia, márpedig nem célszerű a DNS-szerveren tárolni az aláíráshoz szükséges privát kulcsot.)
Végül elképzelhető az is, hogy az example.com zónában már alkalmazzák a DNSSEC-et, de a com zónában vagy a gyökérzónában még nem, így olyan szigetszerű biztonságot hozva létre, amit más módon kell ellenőrizni. A példánál maradva ez a helyzet nem áll fenn, hiszen a DNSSEC-et a gyökérzónában 2010. július 15-én,Root DNSSEC: Status Update, 2010-07-16 a .com domén alatt pedig 2011. április 1-jévelhttp://www.v3.co.uk/v3-uk/news/2039287/verisign-adds-dnssec-com-domain-boost-online-security/ bevezették.
Stub resolverek A stub resolverek (kb. csonka névfeloldók) „olyan minimalista DNS-resolverek, amelyek a rekurzív lekérdezés használatával a DNS-feloldás munkájának nagy részét egy rekurzív névkiszolgálóra hárítják át”. Egy korábbi RFC korábbi definíciója szerint: Ahhoz, hogy a stub resolver megbízhatóan támaszkodhasson a DNSSEC szolgáltatásaira, meg kell bíznia nem csak a kérdéses névkiszolgálókban, de a hozzájuk vezető kommunikációs vonalakban is, pl. SIG(0), TSIG vagy IPSec használatával.