Az interneten használt név szerver programok túlnyomó többsége a Bind (Berkely Internet Name Domain) szoftver valamilyen változata. Ezért amikor name szerver programról lesz szó, erre fogunk gondolni.
A DNS és a nyilvános kulcsú titkosítás fogalmairól összefoglaló található például
ezeken a web lapokon:
http://www.iif.hu/~pasztor/dnslap.html illetve
http://www.iif.hu/projektek/titk/alairbev.html
+-----------------------------------+
| Fejrész |
+-----------------------------------+
| Kérdés |
+-----------------------------------+
| Válasz rekordok szekciója |
+-----------------------------------+
| Autoritás rekordok szekciója |
+-----------------------------------+
|Más (additional) rekordok szekciója|
+-----------------------------------+
A kérdések és válaszok egyaránt ilyen formában épülnek fel. A kérdéseknél a válasz természetesen üres, a válasz rekordok megismétlik a kérdést. Az autoritás rekordokban rendszerint az illető domain névhez tartozó SOA és NS rekordok vannak a válaszban. Az 'additional' szekcióban lehetnek például az NS rekordok A rekordjai.
A sikeres DNS támadás utat nyithat újabb visszaéléseknek. Például ha a pc.kliens.vala.hol gépről jelszóval akarták elérni szerver.vala.hol-t, akkor a DNS hamisítás utján gonosz.vala.hol gazdái be tudnak jutni a szerver.vala.hol gépre.
acl csakti {
193.225.12.54;
192.1.2.0/24;
};
Ha autoritatív szerverek vagyunk valamire, akkor korlátozzuk a zóna transzfert: csak azoknak a gépeknek engedjük meg, hogy egy-egy zónát egészében letöltsenek, amelyeknek valóban szükséges:
allow-transfer {
csakti;
};
Korlátozzuk azt is, hogy ki használhatja szerverünket 'látás'-ra: mely gépek számára végzünk rekurzív feloldást.
allow-query {
csaknektek;
};
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flagek | protokoll | algoritmus |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /
/ publikus kulcs /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
Flag-ek mező egyes bitjei megmondják, hogy:
A protokoll mező határozza meg, hogy milyen protokollal használatos a kulcs. A lehetséges értékek többsége még definiálatlan. Lefoglalt érték - a DNSSEC használaton kívül - a TLS (Transport Layer Security, RFC2246), az elektronikus levelezés és az IPSEC (IP csomagok digitális aláírása, RFC2401).
Az algoritmus mező eddig lefoglalt értékei tartalmazzák a következőket: RSA/MD5, Diffie-Hellman, DSA. Azt, hogy az ilyen kulcsokat hogyan kell tárolni a DNS rekordokban, külön dokumentumok definiálják: RFC2537, RFC2539, RFC2536. Mód van olyan kulcsok tárolására is, ahol kulcs forma definiálását is indirekt módon, a KEY rekordban tárolt domain név alapján lehet megtudni.
Minden DNSSEC-et beszélő rekurzív (látó) név szerver konfigurációjának fontos része, hogy mely kulcso(ka)t tekint hitelesnek indulásakor. KEY rekordok éppen úgy aláírhatók mint bármi más rekord, ezért az elfogadott kulccsal aláírt kulcsot és aztán az azzal aláírt rekordokat is hitelesnek fogadhat el a szerver. Kézenfekvő egy delegált zónához tartozó kulcsot az 'apuka' zóna kulcsával hitelesíteni.
A SIG rekord struktúrája:
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| aláírt rekord típusa | algoritmus | címkék |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| eredeti TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| aláírás lejárta |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| aláírás kelte |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| kulcs részlet | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ aláíró +
| /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/
/ /
/ aláírás /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Az aláírt rekord 'típus'-a határozza meg az RRset-et, amire az aláírás vonatkozik. Az algoritmus kódja a KEY rekordnak megfelelő. A cimkék mező tartalmazza az aláírt rekord cimkéinek (a domain név ponttal elválasztott részeinek) számát. Az eredeti TTL mező az aláírt rekord TTL mezőjét tartalmazza. Erre azért van szükség, mert amikor egy név szerver az aláírt rekordot megkapja, nem biztos, hogy az eredeti TTL-t látja (például, ha egy DNS válasz ragadvány részében kapta).
Az 'aláírás kelte' és az 'aláírás lejárta' másodpercekben adják meg az időpontokat GMT szerint, az 1970 január 1-e, 0 óra 0 perctől eltelt időt számolva.
Ha egy zónában nem történik változás, csak új aláírások kerülnek bele - például azért, mert a régiek lejártak -, akkor ez magával hozza a zóna SOA rekordjában a serial number változását, és ezzel a zóna frissítését secondary-knál.
A 'kulcs részlet' arra szolgál, hogy az aláíró kulcsra vonatkozóan egy gyors ellenőrzést lehessen végezni. Ez azért célszerű, mert a digitális aláírás ellenőrzése számításigényes feladat, és jobb vele takarékoskodni.
A 'aláíró' mező a domain nevet tartalmazza, amihez az aláíró KEY rekord tartozik.
Az 'aláírás' mező képzésekor nem csak az RRset-be tartozó rekordo(ka)t kell venni, hanem magának ennek a rekordnak az aláírás nélküli részét is. Ha ez nem így lenne, akkor könnyen hamisítás áldozatává válhatnának SIG rekordok.
A SIG rekord definíciójában nem csak RRset-ek, hanem DNS válaszok (pl. zóna transzferek) és kérdések digitális aláírására is gondoltak. Ezt a 'típus' mezőben levő 0 jelzi. A SIG rekordok használatának ez a módja azonban valószínűleg nem terjed el. Erre a célra hatékonyabb a TSIG rekordok használata. Ha SIG-gel aláírt tranzakció hitelessége nem pótolja a tranzakcióban küldött egyes elemek hitelességének, a DNS rekordok aláírásainak az ellenőrzését.
A SIG rekordokat a válaszoló név szerver elsősorban a válasz 'additional' ragadvány részében küldi. Delegálási pontoknál az NS rekordok RRset-je két zónának is része. Az ilyen rekordokat csak a 'gyerek' zónában kell aláírni.
Ha egy TTL még nem jár le, de lejárt az aláírás érvényessége, a rekordot el kell dobni. Ha egy aláírás érvényessége még nem jár le, de lejár a SIG rekord TTL-je, a rekordot el kell dobni.
Az RFC2535 azt ajánlja, hogy az aláírás érvényességi ideje a TTL 4-16 szorosa legyen.
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| a sorrendben következő név /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| bit map az ebből a domainból létező típusokról /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Az NXT rekordot típikusan a DNS válaszok 'autoritatív szekció' ragadvány részében küldik, amikor a válasz rész üres, és a hiba kód: ilyen nincs (NXDOMAIN). Megjegyzendő, hogy az RFC1035 csak SOA és NS rekordok küldését engedélyezte az 'autoritatív szekcióban'. A DNSSEC óta SIG és NXT rekordok is lehetnek itt.
Az NXT rekord bevezetésének hátrányos mellékhatása, hogy hiába tiltott egy zóna letöltése valahonnan (Bind allow-transfer opció), a zóna 'letapogatható' olyan kérdésekkel, melyekre NXT rekordok jönnek válaszul.
Egy 'látó' név szerver által megtudott adatok a TTL mellett DNSSEC szerint újabb tulajdonságokkal rendelkeznek:
A hibás adatot, a szerver eldobja. A többi állapotban levő adatot cache-eli, és megfelelő módon továbbítja a hozzá érkező kérdésekre.
Az AD bittel jelezheti a rezolvernek egy rekurzív szerver, hogy a válaszában küldött adatokat digitális aláírások segítségével ellenőrizte és jónak találta. A CD bittel jelezheti a rezolver, hogy ellenőrizetlen válaszokat is elfogad. Érdemes megjegyezni, hogy milyen haszna van itt az eredeti definíció azon kikötésének, hogy a használatlan bitek értékét nem tetszőlegesen, hanem 0-nak kell megadni. Ilyen módon a régi, nem DNSSEC szerint működő szerverekkel éppen zökkenőmentesen tudnak együttműködni a DNSSEC szerinti szerverek: a régi szerverek által kapott adat automatikusan jelzi, hogy nem ellenőrizték a hitelességet, a régi kliensek kérdéseikre pedig sose kaphatnak olyan választ, ami később hamisnak bizonyul, csak bizonytalan, vagy hiteles adatot.
A TSIG arra való, hogy DNS tranzakciók hitelesítve közlekedjenek két szereplő között.
A DNSSEC-ben is van mód zóna transzferek, egy-egy kérés vagy válasz digitális aláírására. Nehézséget okoz azonban, hogy az alkalmazott technológia nyilvános kulcsú titkosítás, ami idő és erőforrásigényes. Az egyik biztosítandó pont viszont egy rezolver (pl. egy PC) és egy hozzá közel álló név szerver közti kommunikáció Ilyen esetben nem tételezhetünk fel nagy teljesítményt, viszont sok-sok tranzakciót. Ezért célszerű szimmetrikus kulcsú titkosítást bevezetni. Éppen ezt teszi a TSIG: a DNS üzenetből egy elektronikus ujjlenyomatot képez, és ezt titkosítja szimmetrikus kulcsú titkosítással.
A rekordot mindig a DNS üzenet 'additional' ragadvány részének utolsó elemeként kell küldeni. A DNS üzenetek rendszerint UDP csomagban utaznak, aminek hossza rövidnek bizonyulhat. Ilyenkor a válaszoló szerver a DNS üzenet fejrészében egy bittel (TC, truncated) jelzi, hogy az üzenet hosszabb lenne, de nem fért a rendelkezésre álló csomagba, mire a kérdező TCP kapcsolaton megismétli a kérdést. Baj lenne, ha az éppen levágott rész a TSIG rekord lenne. Ezért ilyen esetben inkább más rekordot kell levágni az 'authority' vagy az 'additional' szekcióból, beállítani a TC bitet, és a csonkítatlan TSIG pszeudorekorddal a végén elküldeni a választ.
A rekord egyik paramétere tartalmazza a algoritmus nevét, ami az ellenőrző kód kiszámítására szolgál. Szerepel a rekordban két idő adat: az TSIG rekord aláírásának az ideje és egy idő intervallum kiszámítására szolgáló érték, aminek hatása a TTL-hez hasonló: ezen időn belül fogadja el a vevő a TSIG rekordot, illetve azt az adatot, amit az hitelesít.
A TSIG által használt ujjlenyomat kiszámításánál szerepel az egész DNS üzenet, amire vonatkozik, de nem csak ez: magából a TSIG rekordból is magának az ujjlenyomatnak és annak hosszának kivételével minden. Ilyen módon azt is magakadályozzák, hogy a TSIG-gel védett kommunikációt illetéktelenül 'visszajátsszák'.
A TSIG egyik szépsége, hogy nem csak válaszokra, hanem DNS kérdésekre is alkalmazható. Így biztosítható, hogy egy DNS szerver csak illetékesek manipulálatlan kérdéseire válaszoljon.
TCP üzenetekben gyakran sok DNS rekordot küldenek, például egy zóna transzfernél. Ilyenkor elvben minden egyes ilyen rekordhoz hozzá lehetne fűzni az 'additional' szekcióban TSIG hitelesítést. Az ajánlás szerint legalább minden századik rekordot ki kell egészíteni TSIG elemmel.