Domain Name System Security Extensions

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 szerint 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 ilyen). 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álaszthat).

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

1. 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.
2. 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, a .com domén alatt pedig 2011. április 1-jével 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”. 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.

A stub resolver a kéréseket egyszerűen továbbítja egy rekurzív névkiszolgáló felé, a válaszban beállítva az Authenticated Data (AD) bitet, ami „utalás arra, hogy a rekurzív névkiszolgáló képes volt-e ellenőrizni a válaszban szereplő összes »Answer« és »Authority« szekcióhoz tartozó aláírásokat”. Ez azt is jelenti, hogy a stub resolvert meghívó kliensnek bíznia kell abban, hogy a(z általában az internetszolgáltatónál lévő) rekurzív névkiszolgáló nem végez közbeékelődéses támadást és állítja be a hamisított eredményre az AD bitet.

A stub resolverek saját maguk is elvégezhetik az aláírások ellenőrzését, ha a lekérdezésekben beállítják a Checking Disabled (CD) bitet. Egy „ellenőrző stub resolver” (validating stub resolver) a CD bit beállításával önállóan elvégzi a rekurzív autentikációt egészen a DNSSEC gyökeréig; ennek működőképességéhez a DNSSEC gyökértanúsítványnak helyben elérhetőnek kell lennie. Egy ilyen ellenőrző stub resolver használata a DNSSEC-et implementáló domének számára teljes körű (végponttól végpontig terjedő) DNS-biztonságot képes nyújtani, még akkor is, ha az internetszolgáltatót nem tekintjük megbízhatónak. Az ellenőrző stub resolverre példa a BSD-licencű Unbound program. A Windows 7-ben található DNS-kliens önálló ellenőrzésre nem képes, de viselkedése csoportházirenddel szabályozható, például kiköthető, hogy beállítsa-e a DO bitet, illetve hogy IPsec-kel kapcsolódjon-e a DNS-szerverhez.

Bizalmi horgonyok és autentikációs láncok

Egy DNS-től kapott válasz érvényességének igazolásához szükséges, hogy a lekérést végző rendelkezzen legalább egy kulccsal vagy DS rekorddal, ami a DNS-en kívüli forrásból származik. Az ilyen kiindulási pontokat nevezik bizalmi horgonynak (trust anchor), és általában az operációs rendszerből vagy más megbízható forrásból származnak. A DNSSEC tervezésekor úgy gondolták, az egyetlen bizalmi horgony, amire szükség lesz, a DNS-gyökér. A DNS-gyökér horgonya 2010. július 15-én került publikálásra.

Az autentikációs lánc egymással összekapcsolt DS és DNSKEY rekordok sorozata, ami a bizalmi horgonynál kezdődik és a lekérdezett domén autoritatív névkiszolgálójáig tart. Ha az autentikációs lánc nem teljes, a DNS-lekérdezésre kapott választ nem lehet biztonságosan autentikálni.

Aláírások a zónában

A visszajátszásos támadások lehetőségeinek korlátozása céljából a DNSSEC esetében a normál DNS-gyorsítótárazás Time to Live (élettartam-) értékein kívül az RRSIG rekordokhoz további, az aláírás érvényességét korlátozó időbélyegek is kapcsolódnak. Míg a TTL-értékek relatívak, a rekordok elküldésének idejétől kell számítani őket, az időbélyegek abszolútak. Ez azt is jelenti, hogy a biztonságtudatos DNS-resolverek óráinak szinkronban kell lenniük, legfeljebb néhány perces eltérés elfogadható.

Az időbélyegek használatából az is következik, hogy a zónát rendszeres időközönként újra alá kell írni, és a másodlagos szerverek felé ezt továbbítani, különben az aláírásokat a DNSSEC-et értő resolverek vissza fogják utasítani.

Kulcsmenedzsment

A DNSSEC protokoll számos különböző kulcs kezelését teszi szükségessé; egy részét a DNSKEY rekordok tartalmazzák, mások egyéb forrásokból származnak és bizalmi horgonyt képeznek. A kulcsok cseréjéhez szükség van egy kulcsmegújítási protokollra (key rollover scheme). Jellemzően ez úgy működik, hogy először publikálják az új kulcsokat új DNSKEY rekordokban, a már meglévő kulcsok mellett. Ezután, ha már biztonságosan feltételezhető, hogy a régi kulcsok gyorsítótárazásából eredő Time to Live-időtartam elmúlt, az új kulcsokat lehet a rekordok aláírására használni. Végül, amikor már feltehetően a régi kulcsokkal aláírt rekordok is kikerültek a gyorsítótárakból, a régi DNSKEY rekordok törölhetők. Ez a folyamat sokkal bonyolultabb lehet a bizalmi horgonyt jelentő kulcsoknál, például a gyökér esetében, amikor a kulcs cseréje az operációs rendszer frissítését igényelheti.

A DNSKEY rekordokban található kulcsokat két különböző célra használják, és jellemzően különböző DNSKEY rekordokat használnak hozzájuk. Az első a Key Signing Key (KSK, kulcs-aláíró kulcs), amivel a zóna-aláíró kulcsot írják alá. A második fajta a Zone Signing Key (ZSK, zóna-aláíró kulcs), amivel az egyes rekordokat írják alá. Míg a KSK-t a szülő zónával alá kell íratni, addig a ZSK-t egy adott DNS-zóna használja és annak van teljes kontrollja fölötte, ezért könnyebben és gyakrabban cserélhető. A ZSK-k tehát jóval rövidebbek lehetnek a KSK-knál és még így is biztonságosak lehetnek, és az RRSIG/DNSKEY rekordok mérete sem duzzad fel túlzottan.

Egy új KSK létrehozásakor a DS rekordot át kell helyezni a szülőzónába és publikálni kell ott. A DS rekordok nem a teljes KSK-t tartalmazzák, csak annak az üzenetkivonatát, hogy a rekordok ne nőjenek túl nagyra. Ez hasznos az olyan nagyméretű zónáknál, mint például a .com domén. A szülőzóna DS kulcsainak frissítését az újabb DNSSEC-változatokban egyszerűbbé tették.

DANE munkacsoport

Létezik az IETF-nek egy munkacsoportja, a DNS-based Authentication of Named Entities (DANE; „nevesített entitások DNS-alapú autentikációja”), melynek célja, hogy olyan olyan protokollokat és technikákat fejlesszen ki, melyek lehetővé teszik az internetes alkalmazások kriptografikusan biztonságos kommunikációját (IPsec, TLS, DTLS) a DNSSEC alapján.

Az újonnan kifejlesztett protokollok a nyilvános kulcsú infrastruktúra (PKI) alapján felépített hagyományos modellhez képest további biztosítékokat és megszorításokat nyújtanak majd. Lehetővé teszik majd azt is, hogy egy domén tulajdonosa a DNSSEC-en keresztül ellenőrizhető tanúsítványt állítson ki saját magának, harmadik fél hitelesítésszolgáltató (CA) igénybe vétele nélkül.

A DNSSEC-kel „összetűzött tanúsítványok” (stapled certificates) támogatása a Google Chrome 14-ben jelent meg, de dolgoznak a Mozilla Firefox fejlesztői is a támogatásán.

Története

Bár a DNS az internet egyik alapvető és kritikus fontosságú szolgáltatása, 1990-ben Steve Bellovin komoly biztonsági tervezési hibákat fedezett fel benne. Megkezdődött a biztonságossá tételére irányuló kutatás, ami Bellovin tanulmányának 1995-ös közzétételével drámaian felgyorsult. Az IETF először 1997-ben az RFC 2065-öt publikálta, aminek az implementációjával való próbálkozás 1999-re egy áttervezett (és már használhatónak ítélt) RFC 2535 specifikációhoz vezetett. Tervek születtek a DNSSEC bevezetésére az RFC 2535 alapján.

Sajnálatos módon az IETF RFC 2535 specifikációnak komoly gondjai adódtak a teljes internet méretére skálázáskor; 2001-re nyilvánvalóvá vált, hogy nagy hálózatokban használhatatlan. A normál üzemmenet során a DNS-kiszolgálók gyakran elveszítik a szülőkkel a szinkronizációt. Ez általában nem probléma, de a DNSSEC bekapcsolásával a szerver a szinkronból kiesett adattal komoly szolgáltatásmegtagadást volt képes okozni saját magának. Az eredeti DNSSEC-ben egy gyermek kulcscseréje komplex, hat üzenetből álló protokoll szerint, rengeteg adat továbbításával történt (a DNS gyerekzóna minden adatot felküldött a szülőnek, a szülő aláírt minden egyes rekordot és visszaküldte a gyermeknek, hogy az egy SIG rekordban tárolja). A nyilvános kulcsok cseréje abszurd mellékhatásokkal járt; például ha a com zóna megváltoztatta volna a publikus kulcsát, 22 millió rekordot kellett volna elküldenie (mivel minden gyermekén frissítenie kellett volna az aláírásokat). Így tehát az RFC 2535 szerint meghatározott DNSSEC nem volt alkalmas az internetre való bevezetésre.

AZ IETF alapjaiban átírta a DNSSEC-et, amit ettől kezdve, ha szükséges az eredeti DNSSEC-től való megkülönböztetés, DNSSEC-bis névvel illetnek. Az új verzió a „delegation signer (DS)” erőforrásrekordokat használja egy újabb indirekciós szint kiépítésére a szülő- és gyermekzóna között. Az új megközelítés szerint ha egy gyermek mester nyilvános kulcsa megváltozik, ahelyett hogy a gyermek minden rekordjához hat üzenettel oldanák meg a cserét, egyetlen, egyszerű üzenet megy: a gyermek (persze aláírva) felküldi az új nyilvános kulcsot a szülőnek. A szülő egyszerűen eltárol minden gyermekhez egy mester nyilvános kulcsot, ami jóval praktikusabb. Ily módon kevesebb adat áramlik a szülő felé, a korábbi masszív szülő-gyermek adatáramláshoz képet. Az új protokoll azzal is jár, hogy a klienseknek több munkával jár a kulcsok ellenőrzése. Specifikusan, egy DNS-zóna KEY RRset-jének (tehát a KEY típusú erőforrásrekordok halmazának) ellenőrzése két aláírás-ellenőrzéssel jár az RFC 2535-ben definiált eggyel szemben (az egyéb RRsetek ellenőrzésekor nincs változás). A legtöbben ezt alacsony árnak tekintik azért, hogy cserébe a DNSSEC bevezetése praktikusabbá válhat.

A zónabejárási probléma, viták, NSEC3

Bár a DNSSEC célkitűzése a biztonság megnövelése, a 4033-4035-től terjedő RFC-kben definiált DNSSEC egy új problémát vet fel, amit sokan sebezhetőségnek tartanak: a zóna-számbavétel vagy zónabejárás (zone enumeration/walking) ügyét. A DNSSEC alkalmazásával kényszerűen olyan információkat kell felfedni, amiket a megszokott DNS-ügymenet szerint jobb nem nyilvánosként kezelni. A probléma megoldására az NSEC3-at (RFC 5155) fejlesztették ki, ami 2008 márciusában jelent meg. Ez jelentősen enyhítette a zónabejárás problémáját, bár teljesen nem szüntette meg, hiszen továbbra is elképzelhető egy zóna összes lehetséges nevének a kimerítő végigkérdezése.

Miért nem szokás a DNS-zónaadatokat nyilvánossá tenni

A DNS protokoll tervezésekor nem volt cél, hogy rejtett információkat tároljanak benne. Mivel azonban a DNS információkat tartalmaz egy adott tartomány hálózatának belső felépítéséről, sokan a DNS-adatbázisuk tartalmát privátnak tekintik. Különösképp jellemző, hogy a DNS-t úgy konfigurálják, hogy a legtöbb felhasználónak ne legyen engedélye egy zónából a nevek vagy más információk teljes listáját kinyerni. Egy ilyen lista nagy segítség a támadóknak, hiszen egyből tudhatják, milyen számítógépek léteznek a hálózatban.

Egyes rendszergazdák rendszerszintű konfigurációs információkat is a DNS-ben tárolnak (jellemzően az Active Directory-integrált DNS is ilyen), ami még értékesebbé teszi azt a támadó számára. Széles körben forgatott DNS and BIND (4. kiadás) könyvükben Albitz és Liu így magyarázzák:

„Vitatható ugyan, de annál, hogy ki kérdezheti le a névkiszolgálónkat még fontosabb annak kézben tartása, hogy csak azok saját, tényleges másodlagos névkiszolgálóik végezhessenek zónatranszfert róluk. A távoli gépnél ülő felhasználók az általuk ismert tartományból csak egyenként kérhetnek le rekordokat (pl. címeket). A különbség pont akkora, mint aközött, hogy az utcáról bárkinek lehetőséget adunk rá, hogy felhívhassa a telefonközpontost és megkérdezhesse Kovács János telefonszámát, és aközött, hogy mindjárt el is küldjük neki a céges telefonkönyv egy példányát.”

Ráadásul, a bejárt zónából nyert információk WHOIS-lekérdezésekhez is felhasználhatók; így nyilvánosságra kerülhetnek a regisztrálók adatai, amit számos regisztrátor cég szerződéses titokként kezel. Emiatt az sem biztos, hogy a DNSSEC-et minden országban legálisan be lehet vezetni; a német DENIC kijelentette, hogy a DNSSEC zónabejárási hiányosságai miatt nem felel meg Németország adatvédelmi törvényének, és több más európai országokban is hasonló szabályozás tiltja egyes információk közzétételét.

Létezik a problémának egy „nyilvánvaló” megoldása, a maszkolt DNS (split-horizon DNS) használata (tehát hogy a belülről és a kívülről érkező DNS lekérdezések más eredményt adnak vissza), ami a DNSSEC nélküli DNS esetében viszonylag elterjedt – de a maszkolt DNS nem könnyen hozható közös nevezőre a DNSSEC-kel. A maszkolt DNS-megközelítésben a DNS szerver egyes nevek létezését valamely kliensek felé tagadja, mások számára helyes információt nyújt róluk. Mivel azonban a DNSSEC-információ kriptografikusan alá van írva, mint autoritatív, ezért egy kellően meg nem tervezett hálózati konfiguráció esetében előfordulhat az, hogy a támadó kikér egy aláírt „nem létezik” rekordot, majd továbbítja azt más kliensek felé, DoS támadást valósítva meg. A DNSSEC alapjaiban változtatja meg a DNS-t azért, hogy autoritatív információt nyújthasson – ezért nem működik jól együtt az egyes felhasználóknak hamis információt nyújtó módszerekkel. A kétfajta DNS-funkció helyes összekapcsolására léteznek kidolgozott ajánlások.

A problémát a DNSSEC-nek az a sajátossága okozta, hogy muszáj visszajelzést adnia arról, ha egy nevet nem talált meg. A DNSSEC-et használó DNS-szervereknek aláírt választ kell adniuk egy név nem létezéséről, különben könnyen hamisítani lehetne a „nem találtuk”-jelentést. Biztonsági megfontolásokból viszont elvárható, hogy az aláíró kulcs ne egy online szerveren tárolódjon. Kerülő megoldásként a DNSSEC-et úgy alkották meg, hogy a visszaadott, aláírt üzenet azt tartalmazza, hogy egy valamettől valameddig terjedő nevek nem léteznek, hiszen ezt offline, előre alá lehet írni. Sajnálatos módon ezen információ segítségével a támadó jóval több információhoz juthat, mint ami egyébként hozzáférhető lett volna számára – elég ahhoz, hogy egy zóna neveit gyorsan össze lehessen gyűjteni, és célzott lekérdezésekkel a zóna adatainak nagy részét rekonstruálni lehessen.

Ahogy korábban említésre került, a DNSSEC használható lenne az elektronikusan aláírt e-maileknek szánt nemzetközi, publikus kulcsú titkosítást alkalmazó infrastruktúra alapjának is, ahol a DNS-ből lehetne lekérdezni az e-mail-tanúsítványokat és a DNSSEC érvényesítené azokat. Azonban a zónabejárási probléma miatt ez a megoldás a legtöbb vállalat számára, legalábbis közvetlenül, aligha járható. Ahogy az RFC 4398-ban olvasható: „Ha egy szervezet tanúsítványokat oszt ki a dolgozóinak, a DNS-ben a tulajdonos nevéhez csatolt CERT RR-ekkel, akkor ha a DNSSEC-et (NSEC-kel) használják, bárki kigyűjtheti a szervezet dolgozóinak listáját. Ezt általában nem tekintik kívánatosnak, ugyanazon okból, amiért a vállalati telefonkönyveket nem szokás nyilvánosságra hozni, sőt inkább bizalmasan kezelik.”

Kezdeti reakciók

Eredetileg az IETF DNS Extensions munkacsoportjából többen kijelentették, hogy a zóna-számbavétel nem jelentős probléma, kijelentve, hogy a DNS-ben lévő adatok eleve nyilvános, vagy annak kéne lenniük. A regisztrátorok és nagyvállalatok azonban közölték a munkacsoport tagjaival, hogy a DNSSEC-nek az aktuális változatát elfogadhatatlannak tartják, és nem fogják (vagy jogi okokból nincs is lehetőségük) bevezetni.

Online aláírás

A zóna-számbavétel megakadályozásának egy korai módszerét az RFC 4470 foglalja írásba. Ahelyett, hogy előre aláírnák a „nem találtuk” válaszokat, minden lekérdezéshez generálnak egy ilyen választ. Például, ha a névkiszolgáló kap egy lekérdezést a b.example.com-ra vonatkozóan, akkor nem azt a korábban aláírt választ adja vissza, hogy „nem létezik név az a.example.com és a mail.example.com között”, amiből nyilvánvalóvá válik a mail.example.com létezése, hanem például azt a (valós időben aláírt) választ, hogy „nem létezik név a b.example.com és a ba.example.com között”. Ha a következő lekérdezés a ba.example.com-ra vonatkozik, a válasz lehet például ez: „nem létezik név a ba.example.com és a baa.example.com között”. Ezzel a zóna bejárását praktikusan sikerült kiküszöbölni.

Ennek a megközelítésnek komoly hátrányai miatt nem sikerült elterjednie. Szükségessé teszi ugyanis, hogy az aláírókulcs online és minden DNS-szerver számára elérhető legyen. Sok zónaaláíró kulcsot eleve online tartanak a dinamikus zónafrissítések vagy az automatikus újra-aláírás miatt, de ezekre a funkciókra csak egyetlen, mester-DNS-kiszolgálón van szükség, míg az azonnali aláíráshoz a zóna aláírókulcsának minden autoritatív DNS-szerveren jelen kell lennie. Egyes autoritatív szervereknek az internet felől elérhetőnek kell lenniük, ideális esetben földrajzilag is szétszórva, ami megnehezíti a kulcsok ellenőrzés alatt tartását. DoS-támadás is lehetséges, ha egy támadó elkezdi nem létező nevekre irányuló, az aláírás időigényessége miatt hosszú kiszolgálási idejű kérésekkel megszórni a DNS-szervert, aminek a legitim kérésekre alig jut ideje.

NSEC3

Gondos mérlegelés után a DNSSEC kapott egy kibővítést: „DNSSEC Hashed Authenticated Denial of Existence” (informálisan csak NSEC3). Eszerint a DNSSEC-at implementáló szerverek dönthetnek úgy, hogy nem létező rekordra vonatkozó kérésre válaszként NSEC helyett NSEC3 rekordot küldenek. Az NSEC3 kód is alá van írva, de ahelyett, hogy egyszerűen egy nevet írnának alá (ami könnyű zónabejárást tenne lehetővé), az NSEC3 rekord a név hashelt értékét tartalmazza. Az NSEC3 rekordban a több iterációs hashelés mellett opcionálisan saltot is felhasználnak, mindkettő csökkenti a szótáralapú támadások hatékonyságát. A salt a támadáshoz szükséges szótárak számát, mindegy egyes hash-iteráció pedig a szótárak előállításához szükséges számítási költséget növeli. Az NSEC3PARAM paraméterrekordból derül ki, hogy milyen algoritmussal és milyen salttal kell képezni a nevekből a hasht, illetve hogy részt vesznek-e a listában a DNSSEC-kel alá nem írt nevek.

2008 márciusában az NSEC3-at formálisan is meghatározták az RFC 5155-ben.

Bevezetése

Az internet civilizációnk infrastruktúrájának egyik kritikus eleme, működése mégis az alapvetően nem biztonságos DNS-től függ. Így erős a késztetés a DNS biztonságossá tételére, és a DNSSEC bevezetése általános nézet szerint ennek igen fontos lépése. A 2003-as amerikai stratégiai dokumentum, a National Strategy to Secure Cyberspace külön kiemelte a DNS biztonságossá tételének igényét. A DNSSEC széles körű elterjedése több más biztonsági problémát is megoldana, például az e-mailcímekhez tartozó kulcsok biztonságos terjesztéséét.

A DNSSEC specifikációjának megalkotása azonban kemény diónak bizonyult. Az egyik kritikus elemet, az NSEC3-at mindössze 2008 márciusában írták le egy RFC-ben, és azóta se terjedt el széles körben.

A DNSSEC nagy léptékű hálózatokon való bevezetése szintén nem problémáktól mentes. Ozment és Schechter megfigyelése szerint a DNSSEC (ahogy más technológiák) bevezetését a „tyúk-tojás” probléma akadályozza; a felhasználók jellemzően akkor vezetnek be egy technológiát, ha abból közvetlen előnyük származik, de ha szükség van egy minimális szintű elterjedésre mielőtt bármelyik felhasználó haszna meghaladná a költségeket (ami a DNSSEC-re igaz), akkor a bevezetés nehéz lesz. A DNSSEC a DNS hierarchiájának bármely szintjén alkalmazható, de használatának el kell érnie egy szintet a zónában, mielőtt a felhasználók számára kívánatos lenne. A DNS-szervereket frissíteni kell a DNSSEC-et alkalmazni tudó szoftverre, a DNS zónához hozzá kell adni a DNSSEC-specifikus adatokat. A TCP/IP kliensek DNS-resolvere sem feltétlenül ismeri frissítés nélkül a DNSSEC protokollt. Bármilyen resolvernek tartalmaznia kell (vagy képesnek kell lennie szerezni) legalább egy megbízható nyilvános kulcsot a DNSSEC használatának megkezdése előtt.

A DNSSEC implementálása jelentősen megnövelheti a DNS-szerverek terhelését. Általában a DNSSEC-kel aláírt válaszok mérete jóval meghaladja az UDP DNS-ben használt alapértelmezett 512 bájtos határértéket. Elméletben ez kezelhető lenne az IP-csomagok fragmentálásával, de számos hálózati eszköz ezt nem kezeli megfelelően, emiatt a TCP-t használják. Számos TCP-megvalósításban azonban minden egyes TCP-kapcsolathoz sok adat tárolódik le; a magas terhelésű szerverek kifogyhatnak az erőforrásokból csak azáltal, hogy nagy mennyiségű (potenciálisan hamis) DNSSEC-lekérésre válaszolnak. A terhelés csökkentésére különböző protokollkiterjesztéseket fejlesztettek ki, köztük a TCP Cookie Transactionst. A DNSSEC fenti bevezetési problémáinak megoldására az iparági szereplők jelentős erőfeszítéseket tesznek.

Korai alkalmazók

A DNSSEC-et az elsők között Brazília (.br), Bulgária (.bg), Csehország (.cz), Puerto Rico (.pr) és Svédország (.se, 2005) vezette be országkód szerinti legfelső szintű tartományában; Az európai Regionális Internet Nyilvántartó, a RIPE NCC az összes IANA-tól kapott reverz zónáját (in-addr.arpa) aláírja. Az amerikai ARIN szintén aláírja a reverz zónáit. Az internetszolgáltatók közül a svéd TDC nyújtotta először ezt a szolgáltatást.

Az IANA 2007 júniusától kezdte meg egy próba aláírt gyökér tesztelését. Ebben az időszakban, még mielőtt a DNS gyökerét üzemszerűen aláírták volna, számos alternatív bizalmi horgony létezett. Az IKS Jena a sajátját még 2006. január 19-én telepítette, az Internet Systems Consortium ugyanazon év március 27-én adta ki a sajátját, míg az ICANN harmadikként 2009. február 17-én.

Pilot projektek és kísérletek széles skáláját végezték el és végzik jelenleg is. A dnssec.net oldalon listázzák ezeket a projekteket. Létezik egy Google Térkép is a DNSSEC-telepítések helyzetéről a világban.

2008. szeptember 26-án a Public Interest Registry felvázolta terveit, miszerint az .org zónában az első fázisban (2009 elején) azok a nagy regisztrátorcégek írhatják majd alá a doménjeiket, akikkel jó munkakapcsolatban vannak. Végül 2009. június 2-án írták alá a .org zónát 2010. június 23-án 13 regisztrátor szerepelt az .org doménben DNSSEC szolgáltatásokat nyújtók listájában.

A Verisignnak volt egy pilot projektje, ahol .com és .net doméneket lehetett regisztrálni az NSEC3-mal való kísérletezésre. 2009. február 24-én bejelentették, hogy 24 hónapon belül be fogják vezetni a DNSSEC-et az összes legfelső szintű doménjükben (.com, .net stb.), ugyanazon év november 16-án pedig azt, hogy némi technikai okokból eredő késlekedés után elsőként a .com és .net doméneket fogják aláírni, 2011 első negyedévében. Ezt a célkitűzést sikerült időben teljesíteniük és a Verisign DNSSEC-kel foglalkozó igazgatója, Matt Larson elnyerte az InfoWorld 2011-es Technology Leadership díját a DNSSEC előmozdításában játszott szerepéért.

Telepítése a DNS-gyökérzónában

A DNSSEC-et a pilot projektet és tesztek után 2010. július 15-én telepítették a DNS gyökérzónájába. Ez várhatóan egyszerűsíti a DNSSEC-es resolverek alkalmazását, hiszen a gyökérben lévő bizalmi horgony segítségével a teljes bizalmi lánc végigellenőrizhető. Mivel a bizalmi láncnak szakadásmentesnek kell lennie az ellenőrizhetőséghez, továbbra is szükség van bizalmi horgonyok beállítására, ha valamelyik feljebb lévő zóna még nem alkalmazza a DNSSEC-et. Például ha a signed.example.org alá van írva, de az example.org nem, akkor hiába van az org zóna és a gyökér aláírva, valamilyen bizalmi horgonyt kell használni a zóna érvényesítéséhez.

A DNS-gyökér aláírásával kapcsolatban állandó jelleggel politikai kérdések is felmerülnek, többnyire a következőkkel kapcsolatban:

• Egyes országok aggódnak az internet amerikai irányítása miatt, ezért visszautasítják bármilyen központosított aláírás használatát.
• Egyes kormányok megpróbálhatják betiltani a DNSSEC-alapú titkosítókulcs-terjesztést.

Tervezés

2008 szeptemberében az ICANN és a VeriSign közzé tette implementációs javaslatait, majd októberben az amerikai kereskedelmi minisztériumhoz tartozó nemzeti távközlési és információs hivatal (National Telecommunications and Information Administration, NTIA) összegyűjtötte az erre vonatkozó nyilvános javaslatokat. Nem tudni, hogy a beérkezett hozzászólásokat figyelembe vették-e a végső telepítési terv kidolgozásánál.

2009. június 3-án a mérésügyi szabványokkal foglalkozó hivatal, a National Institute of Standards and Technology (NIST) bejelentette, hogy a tervek szerint az ICANN-nal, a VeriSignnal és az NTIA-val együttműködve 2009 végén aláírják a DNS-gyökeret.

A 2009. október 6-i, 59. RIPE konferencián az ICANN és a VeriSign bejelentette a DNSSEC gyökérzónában történő implementálásának tervezett menetrendjét. Az ülésen elhangzott, hogy 2009. december 1-jétől inkrementálisan, havonta egy szerverre telepítenék, így az utolsó gyökér-névszerver 2010. július 1-jén kapja meg a DNSSEC-kel aláírt zónát, és a gyökérzónát RSA/SHA256 DNSKEY-vel írnák alá. Az inkrementális bevezetési időszak során a gyökérzóna egy szándékosan érvénytelen, próbakulcsokat tartalmazó zónát (Deliberately Unvalidatable Root Zone, DURZ) szolgálna ki, a végleges DNSKEY rekordot csak 2010. július 1-jén kapva meg. A szándékosan érvénytelen zóna használatának az volt az értelme, hogy a végleges bevezetés előtt monitorozni lehessen a nagyobb méretű DNSSEC-válaszok okozta hálózati forgalombeli változásokat.

Az .org TLD-t 2010 júniusában írták alá, ezt 2010-ben és 2011-ben a .com, .net és az .edu követte. Az országkód szerinti legfelső szintű tartományok 2010 májusától írathatják alá kulcsaikat. 2011 novemberére a legfelső szintű domének több mint 25%-a már alá volt írva DNSSEC-kel.

Bevezetés

2010. január 25-én kezdte meg az L DNS-gyökérkiszolgáló a szándékosan érvénytelen, hamis kulcsokat tartalmazó zóna (Deliberately Unvalidatable Root Zone, DURZ) terjesztését. A zóna az RSA-eljárással készült, SHA-2 (SHA-256) hashet használ, ahogy az RFC 5702 meghatározza. 2010 májusára mind a tizenhárom gyökérkiszolgáló megkezdte a DURZ terjesztését. 2010. július 15-én pedig aláírták az első nem kísérleti, végleges DNSSEC-gyökérzónát, a 2010071501-es sorszámú SOA-val. A gyökérszintű bizalmi horgonyok az IANA oldalán elérhetők.

TLD-szintű bevezetés

A gyökér szintje alatt számos legfelső szintű tartomány van, amiknek aláírásra kell kerülnie a teljes DNSSEC-bevezetés eléréséhez. Az Internetes legfelső szintű tartománynevek listája oldal részletezi, hogy mely legfelső szintű tartományokat írták már alá, és kötötték össze a gyökérrel. (Jelenleg az angol nyelvű cikk tartalmazza ezeket az információkat: en:List of Internet top-level domains.)

DNSSEC Lookaside Validation

2006 márciusában az Internet Systems Consortium bevezette a DNSSEC Lookaside Validation registryt (kb. DNSSEC kiegészítő ellenőrzési adatbázis). A DLV célja a DNSSEC alkalmazásának megkönnyítése gyökérszintű bizalmi horgony hiányában. Akkoriban úgy tűnt, hogy az ellenőrzést végző kliensnek a DNS egyes aláírt al-ágaihoz tartozó bizalmi horgonyok nagy tömegével kell majd dolgoznia. A DLV lehetővé teszi, hogy a DNSSEC-ellenőrzést végző a bizalmi horgonyok nyilvántartásának feladatát egy megbízható harmadik félre bízza. A DLV adatbázisa tehát a bizalmi horgonyok központi helyen nyilvántartott listája, ami feleslegessé teszi, hogy minden egyes ellenőrzést végző saját listát tartson karban.

A DLV használatához a DLV-t kezelni képes DNS-szoftverre van szükség, ilyen pl. a BIND vagy az Unbound DNS-szerver, és konfigurálni kell benne egy DLV-zóna bizalmi horgonyát. Ez a zóna DLV rekordokat tartalmaz, ezek formátuma megegyezik a DS rekordokéval, de nem egy delegált alzónára hivatkoznak, hanem a DNS-fában más helyen lévő zónára. Ha a DNSSEC-ellenőrzést végző nem talál a DNS-gyökértől az épp ellenőrizendő RRset-hez vezető, megszakítatlan bizalmi láncot, akkor megpróbálja megkeresni az alternatív bizalmi láncot nyújtó DLV rekordot.

A DLV a DNS-gyökér aláírása után sem vált haszontalanná. Amíg rések találhatók a bizalmi láncban, például aláíratlan legfelsőbb szintű domének vagy a DNSSEC-delegációt nem támogató regisztrátorok, az alacsonyabb szintű domének gazdái a DLV segítségével nyújthatnak ellenőrizhető DNS-adatokat felhasználóik felé.

Magyarországi bevezetése

A .hu TLD-nél 2011-ben kísérleti üzemben kezdték használni a DNSSEC-et, a sechu.iszt.hu névkiszolgáló segítségével. 2014. októbere óta a .hu zóna alá van írva, és 2015 februárjában bekerült a gyökér zónába a .hu-hoz tartozó DS rekord. A regisztrátorok 2015 augusztusában kezdtek el aldomain-okat DNSSEC-cel delegálni. 2017 decemberében a .hu aldomain-ok 19%-a DNSSEC-cel védett.

DNSSEC-támogatás resolverekben

Számos ISP kezdte meg a DNSSEC-ellenőrzést végző rekurzív DNS-resolverek bevezetését. Az Egyesült Államokban a Comcast volt az első nagyobb internetszolgáltató, aki így tett; a bevezetés szándékát 2010. október 18-án jelentették be, és 2012. január 11-én sikerült befejezniük.

A CircleID tanulmánya szerint a DNSSEC-érvényesítést végző DNS-resolvereket használó kliensek aránya 2013 májusára 8,3%-ra nőtt. Ezeknek a klienseknek mintegy a fele a Google nyilvános DNS-resolverét használta.

Google Public DNS

A Google Public DNS egy ingyenes és nyilvános DNS-resolver szolgáltatás, ami teljes körűen támogatja a DNSSEC-et.

A Google Public DNS 2009-es indulásakor még nem támogatta a DNSSEC protokollkiegészítést; le lehetett kérdezni az RRSIG rekordokat, de a válaszüzenetben az AD flag (Authenticated Data, annak jelzése, hogy a szerver végigellenőrizte az aláírások láncolatát) sohasem került beállításra.

2013. január 28-án minden külön bejelentés nélkül a Google DNS-szerverei elkezdtek DNSSEC-érvényességi információt adni azon kliensek számára, melyek explicit módon beállították a lekérdezésben a DNSSEC OK (DO) kapcsolót.

2013. május 6-án a Google Public DNS alapértelmezetten bekapcsolttá tette a DNSSEC-validációt, tehát az minden esetben megtörténik, ha a kliens explicit nem kéri, hogy tekintsenek el tőle.

Eszközök

A DNSSEC bevezetése szerver- és kliensoldali szoftvertámogatást is igényel. A DNSSEC-et támogató eszközök közé tartoznak:

• A Windows 7-ben és a Windows Server 2008 R2-ban található DNS-kliens olyan stub resolver, ami képes megkülönböztetni a rekurzív névkiszolgáló által visszaadott biztonságos és nem biztonságos válaszokat.
• A legnépszerűbb DNS névkiszolgáló, a BIND (ami tartalmazza a dig eszközt is) 9.3-as verziója implementálta a DNSSEC-bis protokollt (DS rekordok), de csak NSEC-et támogatott. A 2008 decemberében megjelent BIND 9.6 támogatta elsőként teljes körűen az NSEC3 rekordokat.
• A Drill egy DNSSEC-et kezelni képes dig-szerű eszköz, amit az ldns-sel együtt terjesztenek.
• A Drill Firefox-kiterjesztés segítségével Linux alatt a Mozilla Firefox ellenőrizni tudja egy domén DNSSEC-aláírását (vagy jelezheti annak hiányát).
• A DNSSEC-Tools egyszerűen használható eszközöket nyújt a DNSSEC használatához felhasználóknak és rendszergazdáknak egyaránt. Eszközöket nyújt az autoritatív zónák, autoritatív szerverek és rekurzív névkiszolgálók adminisztrátorainak, továbbá egy programkönyvtárat és egyéb eszközöket alkalmazásfejlesztők részére, és összegyűjtik a DNSSEC-patcheket néhány gyakori alkalmazáshoz is.
• A Zone Key Tool a DNSSEC-et használó zónák karbantartását könnyíti meg. Elsősorban kevés vagy közepes számú zóna kiszolgálására való, teljesen automatizálja az aláírókulcs cseréjét és a zóna újra-aláírását is.
• Az Unbound DNS-szervert az alapoktól a DNSSEC koncepciója köré építették fel.
• A GbDns egy kompakt, könnyen telepíthető DNSSEC-névkiszolgáló Microsoft Windows platformra.
• A mysqlBind DNS-kezelő szoftver is támogatja a DNSSEC-et.
• Az OpenDNSSEC egy DNSSEC-aláíró célszoftver, ami PKCS#11-en keresztül kapcsolódik a biztonsági hardvermodulokhoz (HSM).
• A SecSpider követi a DNSSEC-bevezetést, monitorozza a zónákat, kilistázza a megfigyelt publikus kulcsokat.
• A DNSViz és a DNSSEC Analyzer webes eszközök, amik felrajzolják egy domén DNSSEC autentikációs láncolatát.
• A DNSSEC Validator egy Mozilla Firefox-bővítmény, ami vizuálisan megjeleníti az éppen látogatott domén DNSSEC-státusát.
• A DNSSHIM avagy DNS Secure Hidden Master egy nyílt forrású eszköz a DNSSEC-es zónák ellátására.
• A Net::DNS::SEC egy PERL-ben írt DNS resolver

Források

• DNSSEC – elv és konfiguráció Archiválva 2017. december 6-i dátummal a Wayback Machine-ben
• DNSSEC: érvek s ellenérvek

Fordítás

• Ez a szócikk részben vagy egészben a Domain Name System Security Extensions című angol Wikipédia-szócikk ezen változatának fordításán alapul. Az eredeti cikk szerkesztőit annak laptörténete sorolja fel. Ez a jelzés csupán a megfogalmazás eredetét és a szerzői jogokat jelzi, nem szolgál a cikkben szereplő információk forrásmegjelöléseként.

További információk

• Az NSEC és az NSEC3 rekord magyarázata
• DNSSEC Validator Firefox plugin
• Az ICANN napi jelentése a TLD-k DNSSEC-kel való ellátásának helyzetéről Archiválva 2019. március 25-i dátummal a Wayback Machine-ben
• A DNSSEC rövid, kézikönyvszerű összefoglalása
• Microsoft TechNet: Secure DNS Deployment Guide

Kapcsolódó szócikkek

• DNS-zóna
• DNS-zónafájl
• EDNS