|
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ésA 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[1] 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:
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éseA 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őkRekordokA DNSSEC megvalósításához több új DNS-rekordtípusra volt szükség, ezek:
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[2]). 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[3]). KapcsolóbitekA 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:
AlgoritmusokA 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:[4]
A lekérdezési folyamatEgy 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ókA 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
A fenti ideális példától számos eltérés képzelhető el. Először is, ha az Továbbá, lehet hogy nem létezik a Végül elképzelhető az is, hogy az Stub resolverekA 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”.[8] 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.[9] 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”.[9] 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.[9] 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.[10] Bizalmi horgonyok és autentikációs láncokEgy 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.[11] 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ábanA 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. KulcsmenedzsmentA 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 munkacsoportLétezik az IETF-nek egy munkacsoportja, a DNS-based Authentication of Named Entities (DANE; „nevesített entitások DNS-alapú autentikációja”),[12] 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.[13] A DNSSEC-kel „összetűzött tanúsítványok” (stapled certificates) támogatása a Google Chrome 14-ben jelent meg,[14] de dolgoznak a Mozilla Firefox fejlesztői is a támogatásán.[15] TörténeteBá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.[16] 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 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, NSEC3Bá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.[17] Miért nem szokás a DNS-zónaadatokat nyilvánossá tenniA 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:
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.[19] 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ókEredetileg 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ásA 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. NSEC3Gondos 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éseAz 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.[20] 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.[21] 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.[22] 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ókA 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;[23] 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.[24] Az amerikai ARIN szintén aláírja a reverz zónáit.[25] 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[halott link] 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,[26] az Internet Systems Consortium ugyanazon év március 27-én adta ki a sajátját,[27] míg az ICANN harmadikként 2009. február 17-én.[28] 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.[29] Végül 2009. június 2-án írták alá a .org zónát[30] 2010. június 23-án 13 regisztrátor szerepelt az .org doménben DNSSEC szolgáltatásokat nyújtók listájában.[31] 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.),[32] 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.[33] Ezt a célkitűzést sikerült időben teljesíteniük[34] é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.[35][36] Telepítése a DNS-gyökérzónábanA 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.[37] 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 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:
Tervezés2008 szeptemberében az ICANN és a VeriSign közzé tette implementációs javaslatait,[38] 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.[39] 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.[40] 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.[41] 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á.[41] 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.[42] 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.[43][44] Az országkód szerinti legfelső szintű tartományok 2010 májusától írathatják alá kulcsaikat.[45] 2011 novemberére a legfelső szintű domének több mint 25%-a már alá volt írva DNSSEC-kel.[46] Bevezetés2010. 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.[47][48][49] 2010 májusára mind a tizenhárom gyökérkiszolgáló megkezdte a DURZ terjesztését.[42] 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.[37] TLD-szintű bevezetésA 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 Validation2006 márciusában az Internet Systems Consortium bevezette a DNSSEC Lookaside Validation registryt (kb. DNSSEC kiegészítő ellenőrzési adatbázis).[50] 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.[51] 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,[52] 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.[53] 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éseA .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.[54] 2017 decemberében a .hu aldomain-ok 19%-a DNSSEC-cel védett.[55] DNSSEC-támogatás resolverekbenSzá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,[56][57] és 2012. január 11-én sikerült befejezniük.[58] 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.[59] Ezeknek a klienseknek mintegy a fele a Google nyilvános DNS-resolverét használta. Google Public DNSA 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[60] azon kliensek számára, melyek explicit módon beállították a lekérdezésben a DNSSEC OK (DO) kapcsolót.[59] 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.[61] EszközökA DNSSEC bevezetése szerver- és kliensoldali szoftvertámogatást is igényel. A DNSSEC-et támogató eszközök közé tartoznak:
Jegyzetek
Források
Fordítás
További információk
Kapcsolódó szócikkek |
Portal di Ensiklopedia Dunia
