DNSSEC – elv és konfiguráció

Nyilvános kulcsú titkosításnál és digitális aláírásnál kulcspárokat használunk. Egy ilyen kulcspár egy titkos és egy nyilvános részből áll. A nyilvános részt minél szélesebb körben hozzáférhetővé kell tenni. Például a weben a https (TLS) protokollnál használt X.509 tanúsítványok ilyen nyilvános kulcsokat tartalmaznak. A nyilvános kulcsokhoz tartozó titkos kulcspárt nagy gondossággal, bizalmasan kell kezelni, hiszen aki ezt birtokolja, az olvashatja a kulcs tulajdonosának küldött titkosított tartalmakat, illetve digitálisan aláírhat ezzel a kulccsal.

A digitális aláírást és az aláírás ellenőrzését szemlélteti az 1. ábra:

Az internet DNS legfőbb, eredeti célja, hogy nevekhez IP címeket rendelhessünk. A név → IP cím hozzárendelés mellett azonban sok más információhoz is hozzájuthatunk a DNS rendszer használata által.

A névfeloldás folyamata három típusú komponens együttműködésével valósul meg. Ezek:

1. Az interneten használt valamennyi eszközben megtalálható stub rezolver;
2. Rendszerint a felhasználóhoz hálózati értelemben közel levő rekurzív névszerver, (más néven caching vagy látó névszerver);
3. A DNS osztott hierarchiájának megfelelő autoritatív névszerver, (más néven hiteles, vagy mutató névszerver).

A névfeloldás folyamatát szemlélteti a 2. ábra:

A DNS protokoll többnyire UDP felett az 53-as porton működik, az esetek egy részében TCP felett szintén az 53-as porton. Érdemes felidézni, hogy milyen is az üzenetek szerkezete.

A DNS üzenetek szerkezetét az 1987-ből származó RFC1035 írja le. A kérdés és válasz üzenetek szerkezete egyforma:

+---------------------+
|       Fejrész       |
+---------------------+
|       Kérdés        | the question for the name server
+---------------------+
|   Válasz rekordok   | RRs answering the question
+---------------------+
|  Autoritás rekordok | RRs pointing toward an authority
+---------------------+
|  Ráadás rekordok    | RRs holding additional information
+---------------------+

Fejrész (header) mindig van, és a válasz mindig tartalmazza a kérdést, amire vonatkozik. A válasz, autoritás (authority) és ráadás (additional) szekciók DNS rekordokat tartalmazhatnak, de lehetnek üresek is.

A fejrész szerkezete:

  0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                      ID                       |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR|   Opcode  |AA|TC|RD|RA|   Z    |   RCODE   |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|               Kérdések száma                  |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|               Válasz RR-ek száma              |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|               Autoritás RR-ek száma           |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|               Ráadás RR-ek száma              |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Az egyes mezők jelentése:

• ID: ennek segítségével lehet a kérdést és a választ párosítani
• QR: 0 ha kérdés, 1 ha válasz
• AA: A válasz autoritatív (Authoritative Answer)
• TC: A válasz csonkolt (Truncated)
• RD: Rekurziót kérek (Recursion Desired)
• RA: Rekurziót adok (Recursion Available)
• Rcode: a visszatérési érték: ha 0, siker

Amint látható, a fejrészből kiolvasható, hogy az üzenetben hány válasz, autoritás és ráadás rekord található.

Az egyes szekciókban vannak az úgynevezett RR-ek, resource rekordok. Ezek szerkezete:

                                1  1  1  1  1  1
  0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/                                               /
/                      NAME                     /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                      TYPE                     |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                     CLASS                     |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                      TTL                      |
|                                               |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                   RDLENGTH                    |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
/                     RDATA                     /
/                                               /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Az egyes mezők jelentése:

• NAME, TYPE, CLASS: a rekord „bal oldala”, típusa, osztálya
• TTL: Time To Live. Ennyi másodpercig kell a cache-ben tartani a rekordot (4 byte)
• RDLENGTH: a rekordhoz tartozó adat hossza byte-ban
• RDATA: a rekordhoz tartozó adat. Formátuma függ a rekord típusától

A 3. ábrán az látható, hogy egy imposztor autoritatív névszerver nevében válaszolhat, és hamis adatokat juttathat a rekurzív névszerver cache-ébe. A megfertőzött cache azután — attól függően, hogy milyen nagy felhasználói kört szolgál ki, és azok közül hányan kérik tőle a sikeresen megfertőzött nevet —, akár felhasználók tízezreit tévesztheti meg, és ezen felhasználók személyes adatai, kommunikációja, pénze mind a támadó kénye-kedvének vannak kitéve. Az ilyen támadáshoz szükséges, hogy a támadó a megszemélyesített autoritatív név szerver IP címét hamisítsa, és eltalálja a kérdésben szereplő paramétereket (UDP port, query ID). Ez nem lehetetlen külső (off-path) IP címről, de egészen triviális ha a támadó látja a támadni kívánt forgalmat (on-path), vagy abba bele is tud avatkozni (in-path).

A 4. ábrán arra látunk példát, hogy a rekurzív névszerver hamis választ ad. Ez történhet rosszindulatú behatolás következtében, de a névszerver üzemeltető/tulajdonos szándékából is — például 2003-ban a Verisign követett el ilyet, amit nagy felháborodás követett ³, ⁴, ⁵ .

Az 5. ábra azt a lehetőséget szemlélteti, amivel elsősorban internetszolgáltatók, illetve azok munkatársai, a munkatársak megbízói élhetnek: olyanok, akik valamiképpen hozzáférnek a DNS üzenetekhez miközben azok a hálózaton „utaznak”. Egy ilyen közbülső eszközben meg lehet tenni, hogy bizonyos kérdéseket továbbítás helyett (vagy mellett) eleve megválaszoljunk, hamis válaszokat küldjünk vissza a kérdezőnek. Ez a támadás lehet rosszindulatú behatolók műve, de gyakran politikusok is rendelnek el ilyen manipulációt. Így működik többek közt a „kínai nagy DNS fal”: a kínai hatóságok bizonyos általuk veszélyesnek ítélt internet neveket az internetezők elől elrejtenek, meghamisítanak.

A DNS delegáláshoz hasonlóan, a magasabb szinten aláírjuk a delegált zónában használt publikus kulcsot (pontosabban az abból képzett hash-t, a DS rekordot). Ilyen módon bizalmi lánc alakul ki: egy vagy több kiindulópontból, úgy nevezet trust anchor-ból digitális aláírások láncolatán át juthatunk el ahhoz az aláíráshoz ami egy-egy esetben a DNS információ hitelességét bizonyítja. Hasonlít ez ahhoz, ahogy például a webes böngészésnél az X.509 tanúsítványok láncolata hitelesít egy végső digitális aláírást, végső soron egy webhelyet. Nagy különbség, hogy a DNSSEC-nél nincs az X.509-hez hasonló PKI (Public Key Infrastucture), nincsenek CA-k (Certification Authority-k). DNSSEC esetén a rekurzív névszerverekbe be kell konfigurálni egy-vagy több nyilvános kulcsot, ezek lesznek a bizalmi lánc kiindulópontjai. Ha aláírt DNS rekorddal találkozunk, akkor az aláíró kulcs és egy trust anchor között folyamatos aláírt láncot kell találnunk.

A 6. ábra dnsviz.net-ről származik. Azt a bizalmi láncot mutatja, ami a gyökér zónához tartozó 19036 azonosítójú kulcstól kiindulva igazolja a c.fi rekordok hitelességét.

A gyökér zóna is DNSSEC-cel védett 2010. óta, a gyökérhez is tartozik DNSKEY rekord. DNSSEC-et támogató rekurzív névszervernél legalább ezt a trust anchor-t meg kell adni a rekurzív névszerver konfigurációjában, nem elég csak az NS rekordot. A gyökér DNSKEY rekordot (vagy bármilyen más trust anchort) nem szabad DNS segítségével letölteni, arra alternatív módszert kell alkalmazni. Például a 2010. óta a mai napig (2015. március) érvényes gyökér zónához tartozó kulcs letölthető a hálózatról. ⁶ A gyökér kulcs publikálásának kérdéséről külön dokumentum készült. ⁷

Aki a gyökér zóna titkos kulcsát birtokolja, az „mindent visz”, ezért a gyökér zónához tartozó kulcso(ka)t különös gonddal kezelik. ⁸

A DNSSEC autentikáció sikeres, ha igazolható aláírások és kulcsok láncolatával a kérdéses rekord (RRset) aláírása. A TLD-k évek óta sorban vezetik be a DNSSEC-et. A IANA folyamatosan figyelemmel kíséri és publikálja egyes országokhoz tartozó ccTLD-k DNSSEC státuszát. ⁹

Ha egy DNSSEC-et használó rekurzív névszerver megtudott egy rekordot, akkor megnézi a rekordhoz (RRset-hez) tartozó aláírást is, autentikálja az RRset-et. Az autentikáció eredményeként egy rekord lehet:

• Secure: a bizalmi lánc szerint autentikált
• Insecure: a bizalmi lánc megszagad a trust anchor és a rekord között
  • Autentikált bizonyíték van arra, hogy hiányzik egy DS rekord
• Bogus: a bizalmi lánc azt mutatja, hogy:
  • Az aláírás hibát jelez
  • Hiányzik az aláírás
  • Az aláírás lejárt
  • Nem szupportált mezőt, algoritmust talált az ellenőrzés
• Indeterminate: nincs olyan trust anchor, ami a rekord fölött lenne

Amíg a DNSSEC nincs a nevek többségénél bevezetve, addig a nevek többsége insecure-nak mutatkozik. Ha a gyökér zónához tartozó trust anchort helyesen bekonfiguráltuk, akkor indeterminate nem lehet egy rekord sem.

A dig klasszikus DNS nézegető program, a dnsutils csomag része, természetesen támogatja a DNSSEC-et. Erre szolgál a +dnssec kapcsoló. Ennek hatására bebillenti a kérdésben a DO bitet, vagyis a válaszban DNSSEC rekordokat is vár. A DNSSEC rekordokat barátságosan mutatja. Az időket YYYYMMDDHHMM formában, a kulcsokat base64-ben. Tudja mutatni az ellenőrzés teljes folyamatát a +sigchase kapcsoló segítségével. Miután a gyökérhez tartozó DNSKEY kulcsot a /var/tmp/keys.key fájlban elhelyeztük, kipróbálhatjuk a következő példát, ami a .hu SOA rekordjának ellenőrzését mutatja:

dig +sigchase -t soa hu. +trusted-key=/var/tmp/keys.key

;; RRset to chase:
hu.			3105	IN	SOA	a.hu. hostmaster.nic.hu. 2017082910 3600 900 259200 3600


;; RRSIG of the RRset to chase:
hu.			3105	IN	RRSIG	SOA 8 1 3600 20170926142622 20170829073111 22155 hu. GHvklEqBXChL8ap+xXnFvAkQ2bJVh/oYrDw2ig241cJTOSGh8IXerx39 vfUTWoXho41ujygaZWBWrYVAHJGempOLBi/LcbRjxr8M7rbkvC3blezC HOAeZxVYfn6Y/gAIqiH/WKa1pD6pXXkkhZAfKAboIfPntNtME+KrYIJX JAA=



Launch a query to find a RRset of type DNSKEY for zone: hu.

;; DNSKEYset that signs the RRset to chase:
hu.			1996	IN	DNSKEY	257 3 8 AwEAAcVWW5q+UNb2uxqiAWfSPhf1asbK36lfE/aCnwjhbrxnEi1R5Hc/ dIkYozJqf1Gw+AqoJFZxFSOz+RZIo7dzDT5gDkWn6O1/BujIvL8wSTYT WCRtNUK/ItY/1SOry+extSSMG2h1JmCAMDWpPUq0EEUdKorM8JnHEoBU 4Otig8ApOrkYq7pT8NzDphhNoWHa/wpBHeijuD3OZ5T9OROyz12JYOXM Q1efMP3Z0A8Bx1KTn7+a4my53JGbx+ozyAQa9L28mzrrbTZ9uRer6Y+5 KQVO+ACujx5Z/T0NI0Ng5A7PbIeXE+0sqwvghlkx6Lk71F0w9bldQPDI 9kPQqxEzWTM=
hu.			1996	IN	DNSKEY	256 3 8 AwEAAcXYFurf8AVHzDyNTp8GxAwJMXy+lJyzDMrusT283Tqnm390NDnr 40bzXRHEsUJIs/4I8viylTWkVirqVWcGIlAx81M+2Lp99cetb1kPuyKf nVRSzfFFFYZPWlYoFes6ZZa6nzH2kqIRtF+fUDhKeKknSU9F2bDTfnMc RD4Wl8mj


;; RRSIG of the DNSKEYset that signs the RRset to chase:
hu.			1996	IN	RRSIG	DNSKEY 8 1 3600 20170915195751 20170818143102 20056 hu. a86rscJYrJQVmjzay5j6ArOT07CWpMY+bsXGG4DNHoHz+QfwpZclEyAt FqKaiA2intT5Y5XcafF60OT7uqbsI2R3QO6LSW63pTvb/ggfbCAIFJOO MFF4lATqYsR7aU7zZSmycyaTFdC0B+UoVBtzW1I4LdXZ57IBtKO7K80x CSPhhV4lNjCAA1JuNaNRKBnf42vl57h7jshDKQ3uQxRHMPxOVA57KEWb egnqVUy8mY1DXOMgGz+V/xCgv5/3JEgkV1hGJhPejHEGQiqoETmeysTR 8ueYeEw1tAoqmgK0CAzHRu6NMgokXkG2cHWfAs16yGFcLd9awilz/q+M tE+tNw==



Launch a query to find a RRset of type DS for zone: hu.

;; DSset of the DNSKEYset
hu.			80601	IN	DS	20056 8 2 93FDCE134B52B1BBFDCADDAD9152B0F2CA6E9DEE09150DF624661C6B 9A5B74DA


;; RRSIG of the DSset of the DNSKEYset
hu.			80601	IN	RRSIG	DS 8 1 86400 20170911050000 20170829040000 15768 . Ovv3xYJ4O55FfO91F1aVrjeU+upSEb6IyVNqH4V+U0+hNfs9S07wk5B5 6yRqef/5NZoMjsk8S0Z6TzuZfPtbeo+L/ZIFqnCym6UWF8g64lyPiA+e MmpMyNx4K40WIULYBdHx/vLueiczCUFlkf3/X5HZl628A2IUCL0H7pYW G61J6W4+iHN4jKvYfyIsPBMTydBoYj8yZSFujggc7QhhQXs2lKlR7xMj 1q7wQaRZPciOtmyYfhaxowJXdWhA7hufcnbTVj1xexOuc/BLBGfu+PRi AI/pSIiZ0MRnTLMfHStHFFBAZlSHZgaJdGkf/eZGof+SmztTHxpRMxjG qdMBGw==




;; WE HAVE MATERIAL, WE NOW DO VALIDATION
;; VERIFYING SOA RRset for hu. with DNSKEY:22155: success
;; OK We found DNSKEY (or more) to validate the RRset
;; Now, we are going to validate this DNSKEY by the DS
;; OK a DS valids a DNSKEY in the RRset
;; Now verify that this DNSKEY validates the DNSKEY RRset
;; VERIFYING DNSKEY RRset for hu. with DNSKEY:20056: success
;; OK this DNSKEY (validated by the DS) validates the RRset of the DNSKEYs, thus the DNSKEY validates the RRset
;; Now, we want to validate the DS :  recursive call


Launch a query to find a RRset of type DNSKEY for zone: .

;; DNSKEYset that signs the RRset to chase:
.			167001	IN	DNSKEY	256 3 8 AwEAAYvxrQOOujKdZz+37P+oL4l7e35/0diH/mZITGjlp4f81ZGQK42H NxSfkiSahinPR3t0YQhjC393NX4TorSiTJy76TBWddNOkC/IaGqcb4er U+nQ75k2Lf0oIpA7qTCk3UkzYBqhKDHHAr2UditE7uFLDcoX4nBLCoaH 5FtfxhUqyTlRu0RBXAEuKO+rORTFP0XgA5vlzVmXtwCkb9G8GknHuO1j VAwu3syPRVHErIbaXs1+jahvWWL+Do4wd+lA+TL3+pUk+zKTD2ncq7Zb JBZddo9T7PZjvntWJUzIHIMWZRFAjpi+V7pgh0o1KYXZgDUbiA1s9oLA L1KLSdmoIYM=
.			167001	IN	DNSKEY	257 3 8 AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq QxA+Uk1ihz0=
.			167001	IN	DNSKEY	257 3 8 AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3 +/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kv ArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF 0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+e oZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfd RUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwN R1AkUTV74bU=


;; RRSIG of the DNSKEYset that signs the RRset to chase:
.			167001	IN	RRSIG	DNSKEY 8 0 172800 20170910000000 20170820000000 19036 . ES4pdPYAEK+5DBYW9SiHE4AAm8fTRjMjeWGH5x2lxkxtHM4PEpdN8vNE /pJ8hq3vMhHVgD2cMevcVQbdwr55ML/kkVdMDY3YJwTnLWQ2m8XtRxK5 rrMHYY1lL/Xn1rFKWN/X0AYBIioZ3e6Q5TIfzoKAThz9sbKlTJTVR/W6 4+AS40D+nsXeAZuWUSjdDV7n0alE8uInJf4t5fQxYb4ElPyJQSwBK24X zDpUTlMqyIMMhVCWoUsaxLbN5uqP5SaY3xMlvZT90CVW2wMitdZLvygL 7c6ljB631Luv+rSuS8ZYpztKbLX4S1EF7h0u6hPUlj/fwsW1dubF3EbV qVfs5Q==



Launch a query to find a RRset of type DS for zone: .
;; NO ANSWERS: no more

;; WARNING There is no DS for the zone: .



;; WE HAVE MATERIAL, WE NOW DO VALIDATION
;; VERIFYING DS RRset for hu. with DNSKEY:15768: success
;; OK We found DNSKEY (or more) to validate the RRset
;; Ok, find a Trusted Key in the DNSKEY RRset: 19036
;; VERIFYING DNSKEY RRset for . with DNSKEY:19036: success

;; Ok this DNSKEY is a Trusted Key, DNSSEC validation is ok: SUCCESS

A drill az Nlnetlabs terméke. A program neve arra utal, hogy ha még mélyebbra akarunk hatolni, nem elég ásni, fúrni kell :-). Az ldnsutils debian csomag része. A drill alkotóinak kifejezetten DNSSEC nézegetés volt a célja. Látványos a -S (sigchase) kapcsoló:

drill -t ns -k /var/tmp/keys.key -S info.hu

;; Number of trusted keys: 2
;; Chasing: info.hu. NS


DNSSEC Trust tree:
info.hu. (NS)
|---info.hu. (DNSKEY keytag: 1395 alg: 8 flags: 256)
    |---info.hu. (DNSKEY keytag: 20527 alg: 8 flags: 257)
    |---info.hu. (DS keytag: 20527 digest type: 2)
        |---hu. (DNSKEY keytag: 22155 alg: 8 flags: 256)
            |---hu. (DNSKEY keytag: 20056 alg: 8 flags: 257)
            |---hu. (DS keytag: 20056 digest type: 2)
                |---. (DNSKEY keytag: 15768 alg: 8 flags: 256)
                    |---. (DNSKEY keytag: 19036 alg: 8 flags: 257)
;; Chase successful

A népszerű DNS szerverek mai változatai általában támogatják a DNSSEC-et: A Bind a legnépszerűbb DNS szerver, az ISC terméke rekurzív és autoritatív funkcióban is használható DNSSEC-cel. Az Nlnetlabs termékei különválasztják az autoritatív funkciót (NSD) és a rekurzív funkciót (Unbound). Mindkét program támogatja a DNSSEC-et. A Powerdns nagyrabecsült régi tagja a DNS szerverek családjának. Itt szintén két program valósítja meg az autoritatív és a rekurzív funkciót. Az autoritatív névszerver támogatja a DNSSEC-et, a rekurzív név szerverhez pedig egy kiegészítés, validator készül. ¹⁰ Az autoritatív névszerverek családjában új, igen figyelemreméltó program a Knot és a Yadifa. Mindkettő kezdetektől fogva támogatja a DNSSEC-et. D.J. Bernstein munkája a DJBDNS vélhetőleg sose fogja támogatni.

Ha hibát keresünk, meg akarunk érteni valamilyen hálózati jelenséget, nagy segítséget jelentenek a tcpdump és a wireshark programok.

A tcpdump felismeri a DNSSEC-cel kapcsolatos rekordokat a wireshark a DNSSEC üzenetek szerkezetét is barátságosan, olvasmányosan tárja elénk. Például az idő adatokat úgy írja ki, ahogy azt ki szoktuk mondani. Ezt szemlélteti a 7. ábra.

A nyílt rekurzív névszerverek általában veszélyt jelentenek, de vannak gondosan kezelt, felügyelt nyílt rekurzív szerverek. Ezeknek például az lehet a célja, hogy alternatívát jelentsenek, ha nem tudunk rekurzív névszervert, vagy hogy teszteljük a DNS/DNSSEC beállításokat, és működést.

A DNS-OARC (DNS Operations, Analysis, and Research Center) mindenki által használható nyílt validáló rekurzív névszervert (Open DNSSEC Validating Resolver) üzemeltet. A konfiguráció és az IP címek:

A sokak által használt Google publikus rekurzív DNS szerverek 2013. júliusa óta alapértelmezésben DNSSEC-et használnak:

A DNSSEC működésével kapcsolatban igen sok webhely áll segítségünkre. Nagyon látványos a dnsviz.net szolgáltatása. Ez nem csak lekérdezi a DNS rekordokat, hanem egy rajzon megjeleníti az aktuális DNSSEC fát. Pirossal jelzi, ha hiba van. Tanulságos kipróbálni például a szándékosan hibásan konfigurált www.dnssec-failed.org és sigfail.verteiltesysteme.net neveket.

A dnssec.net DNSSEC-cel kapcsolatos információk gyűjtőhelye, a dnssec-deployment.org-ot pedig kifejezetten DNSSEC terjedésével kapcsolatos információknak szánták.

A DNSSEC-ről az első RFC 1997-ből származik (RFC2065). Az elképzelést azóta többször átdolgozták, bővítették. Jelenleg az irányadó legfőbb RFC-k: RFC4033 - RFC4035. Újabb RFC-k bővítik, kiegészítik az DNSSEC ajánlást:

• RFC4641: DNSSEC Operational Practices
• RFC5011: Automated Updates of DNS Security (DNSSEC) Trust Anchors
• RFC7344: Automating DNSSEC Delegation Trust Maintenance
• RFC6698: The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA
• RFC6781: DNSSEC Operational Practices, Version 2

EDNS0, azaz Extended DNS (RFC2671, melyet az RFC6891 felülbírált) kibővíti a DNS üzenet fejrészét. Ez úgy válik valóra, hogy bevezet egy pszeudorekordot: OPT (options). Az OPT rekord sose jelenik meg tényleges DNS rekordként, arra szolgál, hogy a DNS fejrészt „folytatni lehessen”. A rekord opciókat tartalmaz, melyeknek szerkezete: Code, Length, Data. Az OPT pszeudorekord Class paramétere egy különösen fontos opció, az UDP size. A DNS üzenet hossza eredetileg legfeljebb 512 byte-ban volt korlátozva. A DNSSEC-cel jelentősen megnő az üzenetek hossza, ezért ebben a mezőben a csomag küldője közölheti, hogy mekkora UDP csomagokat képes fogadni. Jellemző értékek: 1024, 2048, 4096. Érdemes tudni, hogy nagy UDP csomag IP fragmentálást eredményez, ami nem feltétlenül kívánatos.

Az EDNS0 segítségével új flag-ek bevezetése válik lehetővé. Az OPT pszeudorekordban kapott helyet a DO bit.

A DNSSSEC működéshez a következő flag-ek bevezetése szükséges:

• DO (Dnssec Ok)

Ez a flag kérdésben használatos. Jelentése: kérem a DNSSEC rekordokat is.

• CD (Checking Disabled)

Ez a flag is kérdésben használatos. Azt jelenti: te ne ellenőrizz, majd én. Ilyenkor tehát a validáló rekurzor visszaadja az olyan rekordot is, amiknek a digitális aláírása hibás. Ez például akkor hasznos, ha a stub rezolver oldalán akarunk DNSSEC ellenőrzést végezni. Akkor is jó hasznát vehetjük, ha debugolunk: miért nem oldja fel a DNSSEC rekurzív névszerverünk a kérdezett nevet? A CD flag-et a drill -o CD, illetve a dig +cdflag opciókkal lehet kérni.

• AD (Authenticated Data)

Az AD bit válaszban használatos. Az a jelentése, hogy a rekurzív névszerver ellenőrizte és rendben találta DNSSEC szerint a választ. Az AD bit ellentétes az AA bittel, többet jelent mint az AA. Az AD bitet rekurzív névszerverek, az AA bitet autoritatív névszerverek adják vissza.

RR-set DNS rekordok egy olyan halmaza, ami egy zóna összes olyan rekordját tartalmazza, amiknek bal oldala (name), típusa (type) és osztálya (class) megegyezik.¹¹

Például ez a négy rekord két RR set:

ppke.hu. SOA	ns.ppke.hu. hostmaster.ppke.hu. 2010110901 7200 3600 604800 86400
ppke.hu. NS	apa.btk.ppke.hu.
ppke.hu. NS	ns2.iif.hu.
ppke.hu. NS	ns.ppke.hu.

A két RR-set közül az egyikben egyedül a SOA rekord van, a másikban pedig a három NS rekord. DNSSEC-nél soha nem egyes rekordokat, hanem mindig RR-seteket írunk alá.

A DNSKEY rerkord az aláírásnál használt kulcspár nyilvános részének tárolására szolgál. A titkos párját lehetőleg még a DNS szerveren sem tároljuk: a célszerű gyakorlat az, hogy az aláírt zóna más gépen keletkezzen mint ahol szolgáltatjuk. A DNSKEY rekord szerkezete:

                      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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |              Flags            |    Protocol   |   Algorithm   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 /                                                               /
 /                            Public Key                         /
 /                                                               /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Az egyes DNSKEY mezők:

A flags mezőben a 7-es bitnek (decimális 256) állnia kell, ha DNS rekordok aláírására használt rekordról van szó, azaz gyakorlatilag mindig áll.

A Protocol mező értéke gyakorlatilag mindig 3 (egyelőre?).

Az Algorithm mező tartalmazza a kulccsal használt algoritmus kódját. Meghatározza, hogy hogyan kell értelmezni a ,Public Key' mezőt. Az RFC4034 óta újabb algoritmusokat tettek megadhatóvá, ezekről szól az RFC5702. A mindenkori érvényes lista elérhető itt: http://www.iana.org/assignments/dns-sec-alg-numbers. Érdemes tudni, hogy a SHA1 algoritmus sérülékenynek bizonyul, elavult.

A Public key tartalmazza a nyilvános kulcsot. Ez bináris adat, a segédprogramok base 64-ben írják ki.

Vegyük észre, hogy nincs a kulcsnak lejárati ideje! Ez szokatlan azoknak, akik eddig például X.509 kulcsokat láttak. Persze a kulcs használója bármikor rendelkezheet úgy, hogy kulcsot cserél, de ez tisztán eljárásrend (policy) kérdése, magának a kulcsnak a lejárati idő nem része.

Íme egy példa DNSKEY rekordokra, pontosabban egy RR-set-re:

$drill -t dnskey fi.
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 25555
;; flags: qr rd ra ; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; fi.  IN      DNSKEY

;; ANSWER SECTION:
fi.     3600    IN      DNSKEY  256 3 8 AwEAAZ71W+kyJ02KogLDTW2fXJWmirTuSsuX455BtQNKc+/zAI74whZq4sYEL+GsEZ2BcT0AOnHDXz0vSa6pY9GDIclgmHLoEkaIGZibiX/rLAT+Y8XZoIiCcodTJJgBnSho8qGpt2qzK8lf0glvyY2STp0ZhFZ4fyQRN8ov9Od5Q2jR ;{id = 34239 (zsk), size = 1024b}
fi.     3600    IN      DNSKEY  256 3 8 AwEAAb6XCtPWud5ROpcxj91zCJszffNqneOB3vitEDGf8NghhOBUY03RUJvKq8SasiJNqiBK1RvFZzwmJZChGGsdXRmxWqVtq9oB1a0T6kqgOtxBZ1XLhwvXDPsStS7ycQ9HN+UH39kmppQX63AjmL+q+saXmd1U2T7fn7MJPrVapRej ;{id = 25800 (zsk), size = 1024b}
fi.     3600    IN      DNSKEY  257 3 8 AwEAAYZ4Afrzb41QsPqOrYn3hfQWSF5FvXsTY3cvM0SGFnzF4CxAldYpiWYgcd2J0LbWu15YuSxX5hjKULExuuQCbVqRB9ZB7NtdxVFcKZ5tkdC1RaSsbFW0O1EyVBbHO8Q2za95H9SILgv/7fCRW2pNcoOHppxZUDvpz/PsUeu3iKhDhq4IMU+jumnQlHgvyL6DVCXgKHWpFQzXNc9hkPEwALkrhsgKWatxONqRZdRHkXG2mmafD24CCFZvVcFDFGNlf3huvsZLGMbhnLbaPHp1delDqRZJdF6NSScVDGuyZvQ2XqnM8eh5WybVJPbb5tX8mXNeAZ/D8kHedDOHFxDNGD0= ;{id = 45899 (ksk), size = 2048b}

Az RRSIG egy-egy RR-set (nem rekord!) aláírására szolgál. A DNSKEY RR-setet is aláírjuk. Az RRSIG rekord szerkezete:

                   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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Type Covered           |  Algorithm    |     Labels    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Original TTL                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Signature Expiration                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Signature Inception                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Key Tag            |                               /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         Signer's Name         /
/                                                               /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/                                                               /
/                            Signature                          /
/                                                               /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Az egyes RRSIG rekord mezők:

A Type covered mutatja az aláírt RR-set típusát.

Az Algorithm az aláírásnál használt algoritmus. Erről — ahogy azt a DNSKEY rekordnál is említettük a http://www.iana.org/assignments/dns-sec-alg-numbers/ címen lehet aktuális információt nyerni.

A Labels mező az aláírt rekordban szereplő 'label'-ek száma. ¹² Kiderül belőle, hogy wildcard aláírásról van-e szó. Például ha van *.example.com A rekord, és a kérdés a valami.example.com, akkor a visszaadott A rekordban Labels = 2 lesz, és az ellenőrzést ennek megfelelően a *.example.com-al kell folytatni.

Original TTL: az aláíráskor ennyi (volt) az aláírt rekord TTL értéke.

Signature Expiration és Inception 32 bites mezők, amik az aláírás érvényességének végét és kezdetét jelzik, az 1970. január elseje 0 óra után eltelt másodpercekkel kifejezve. A segédprogramok könnyebben érthető formában írják ki.

Key tag: 16 bites mező, ami a kulcs azonosítására szolgál. A nyilvános kulcsból keletkezik, úgy, hogy annak 16 bites darabjait összeadjuk. Értékeke tehát egy 65536-nál kisebb szám. Előfordulhat (bár nem valószínű), hogy két különböző kulcshoz ugyanaz a key tag tartozik.

Signer's name: az aláíró kulcs (DNSKEY) bal oldala.

Signature a tényleges aláírás. Bináris adat, a segédprogramok base64-ben írják ki.

Példa RRSIG rekordra:

ns1.stockholm.se.       3600    IN      RRSIG   A 5 3 3600
            20101219110002 20101119110002 54123 stockholm.se. prI7cdXdJLg3kLsYPi6vavi9UFlGq7pKNbjlF3x42mYkt/0kqZyOK89Cgt9UqzjQUBzNYQdC8aYXbGkhm5SN5VvaPjIknQBdB4mroxaKoiTE5xUuN42PRIGJgTmUysh4DfraLcJ0ZS9ZxYitSutgYh7rRtyLvWSuJYOYHZQ4bsA=
            ;{id = 54123}

Ez a rekord az NSEC3 rekordoknál használt paramétereket tartalmazza. A zóna elején szereplő rekord, ennek alapján jönnek létre az egyes NSEC3 rakordok. Az NSEC3 rekordnál már megismert mezőket tartalmazza. A rekurzív névszervereknek nincs igazán dolguk ezzel a rekorddal. A rekord formátuma:

                   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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Hash Alg.   |     Flags     |          Iterations           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Salt Length  |                     Salt                      /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Ez a rekord nem más, mint az apuka zónában a gyerek DNSKEY-jéből képzett hash. Ennek az aláírásával valósul meg a bizalmi lánc. A DS rekordnak nem szabad a gyerek zónában előfordulni — ott a megfelelő DNSKEY rekord áll. A DNSKEY flag mezőjében a 15. bit (aminek helyi értéke 1) mutatja, hogy ebből a rekordból DS rekordot szándékozik képezni a gazdája. Ezt nevezik secure entry point-nak (SEP). A delegált zónára vonatkozó DS rekord autoritatív az apuka zónában, az NS rekord nem. Ezért a DS rekordot az apukában aláírjuk, az NS rekordot nem.

A rekord formátuma:

                   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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Key Tag             |  Algorithm    |  Digest Type  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/                                                               /
/                            Digest                             /
/                                                               /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

A key tag és algorithm mező a megfelelő DNSKEY rekordból származik. A digest type mező lehetséges értékei bővültek az RFC4034 óta. A SHA1 digest algoritmus elavult.

Példa DS rekordra:

praha.cz.               18000   IN      DS      28371 5 1 D0E13FEB1A9E1261E930338EC4C94934A19972A8

Elvben egyetlen kulcspár, egyetlen DNSKEY rekord elég egyetlen zónában. A gyakorlatban és az ajánlások szerint érdemes két fajta rekordot használni.

KSK, Key Signing Key az a rekord, amiből DS-t képzünk, aminek áll a SEP (1-es helyi értékű) bitje, rendszerint hosszabb, nagyobb biztonságot nyújtó kulcs és ritkán változik — jellemzően néhány évenként. A KSK-val általában csak a DNSKEY RR-set-et írjuk alá, így igazoljuk a láncban következő ZSK hitelességét. Az apuka zónában a KSK-ból képzett DS rekordot írják alá. A KSK változtatás nem egészen egyszerű feladat: az apuka zóna gazdájának a közreműködését is igényli.

ZSK, azaz Zone Signing Key szolgál arra, hogy a DNSKEY rekord kivételével a zóna rekordjait aláírjuk. Ebből nem képezünk DS rekordot, a SEP (1-es helyi értékű bit) értéke 0. Ezért ennek a kulcsnak a cseréje könnyen automatizálható, gyakran változhat — jellemzően néhány havonként. A kulcs mérete jellemzően kisebb, így gyorsabbak a kulccsal végzett kriptográfiai műveletek, és főleg kisebbek az aláírás rekordok. A kisebb rekordok kisebb DNS csomagokat eredményeznek, így jó esély van rá, hogy a DNSSEC válaszok egyetlen UDP csomagban elférnek.

Egy autentikált DNS rekord érvényességét sokféleképpen elvesztheti:

• Lejár a TTL
• Lejár az aláírás TTL-je
• Lejár az aláírás érvényességi ideje

A legkisebb számít: akármelyik jár le, a rekurzív névszerver már nem válaszol a cache-ből. Ha újra kérdezik, újra lekéri azt, ami hiányzik és ellenőriz.

Egy DNSSEC-cel védett zónában új kulcsra áttérni nem triviális feladat. Gondoskodni kell arról, hogy folyamatos legyen a működés:

• Új kulccsal ne kezdjünk el aláírni, mielőtt az el nem terjed aláírt DNSKEY RR-set-ben
• Ne vegyünk ki régi kulcsot, amíg még cache-elve érvényes aláírás lehet azzal
• KSK kulcs cserénél gondoskodjunk róla, hogy a megfelelő DS rekord megjelenjen az apuka zónában

Az RFC6781 (DNSSEC Operational Practices) hosszan tárgyalja a kulcs csere kérdését. Két módszert mutat be. ¹³

• Pre-publish módszer: az új kulcsot jó előre publikáljuk, akkor kezdjük el használni, ha már mindenütt jelen van (propagation delay + Max Zone TTL). ¹⁴ Ekkor a régi kulccsal történő aláírásokat felválthatjuk — egyszerre, vagy fokozatosan — az új kulcs aláírásaival. Amikor minden aláírás már az új kulccsal van jelen mindenhol, vagyis a cache-ekből régi RRSIG-ek kiürültek, akkor lehet a régi kulcsot kivenni a zónából. Ezt a módszert érdemes használni ZSK rollover-nél.

• Double signature módszer: az új kulccsal is aláírunk. Ilyenkor az új DNSKEY megjelenésekor azonnal elkezdhetünk aláírni vele. Ha KSK-ról van szó, akkor az új kulcshoz tartozó DS rekordot be kell tenni az apuka zónába. Megfelelő idő eltelte után a régi kulccsal történő aláírás(oka)t elhagyhatjuk. Amikor már semmilyen cache-ben nincs a régi kulccsal készült aláírás, akkor törölhetjük a kulcsot a zónából, KSK esetén ezek után az apuka zónából elhagyható a megfelelő DS rekord is.

ZSK-val kapcsolatban általában pre-publish, KSK-val kapcsolatban a double signature módszer használatos. Az OpenDNSSEC nagy segítségünkre van kulcs cseréknél: ZSK esetén teljesen automatikusan végrehajtja, KSK esetén pedig félig automatikusan: a DS rekord apukába történő elhelyezéséről külön kell gondoskodnunk, de nem engedi, hogy elrontsuk a dolgot: addig nem veszi teljes használatba az új rekordot, amíg egy erre szolgáló külön paranccsal nem hoztuk a tudomására, hogy a DS ott van az apuka zónában.

A rekurzív validáló (DNSSEC-et értő) névszerverekben az ellenőrzés archimédeszi pontja (pontjai) a trust anchor(ok), ahogy arról már fentebb szó volt. Ha egy ilyen DNSKEY változik, akkor az összes ezt használó rekurzív névszerverben kézzel kell beírni az újat — hacsak nem használunk RFC5011 szerinti automatikus trust anchor update-et.

Az RFC5011 alapgondolata, hogy a régi KSK-val alá lehet írni egy frissen generáltat. Ezzel az aláírással jelezheti egy KSK gazdája, hogy rollover-t hajt végre. Egy ideig mindkét KSK a zónában van. A rezolverek az új KSK-t is beteszik/betehetik trust anchor-nak. Egy idő után a régi KSK-t ki lehet venni a DNSKEY RRset-ből és a rezolvereknél a trust anchor-ok közül.

Felmerül azonban egy új gond. Ha két KSK közül akár csak az egyik egy imposztor birtokába jut, akkor azzal mindkét kulcsot érvénytelenné teheti. Ez ellen való védekezésül az RFC bevezet egy új DNSKEY flag-et: ez a revoke bit, a 8., aminek helyi értéke 512. Egy másik elv, hogy ha megjelenik egy új KSK, akkor azt egy ideig (AddPend, vagy Holddown time) nem veszi be trust anchornak a rekurzív név szerver.

Az RFC5011 szerinti kulcs állapotok:

                          NEXT STATE
        --------------------------------------------------
 FROM   |Start  |AddPend |Valid  |Missing|Revoked|Removed|
----------------------------------------------------------
Start   |       |NewKey  |       |       |       |       |
----------------------------------------------------------
AddPend |KeyRem |        |AddTime|       |       |       |
----------------------------------------------------------
Valid   |       |        |       |KeyRem |Revbit |       |
----------------------------------------------------------
Missing |       |        |KeyPres|       |Revbit |       |
----------------------------------------------------------
Revoked |       |        |       |       |       |RemTime|
----------------------------------------------------------
Removed |       |        |       |       |       |       |
----------------------------------------------------------

                        State Table

A 8. ábra mutatja, hogy ssh kommunikáció esetén a kliens és a szerver kölcsönösen digitális aláírással igazolják magukat.

Bizonyára sokan találkoztak már azzal a problémával, hogy ha szkriptekben akarunk ssh parancsot kiadni, akkor először kézzel kell a kliens oldalon kapcsolatot teremteni a szerverrel, hogy a szerver nyilvános kulcsa az .ssh/known-hosts fájlba bekerülhessen. Ezen a problémán is segít a DNSSEC.

Az RFC4255 bevezeti az SSHFP rekordot, ami egy szerver nyilvános SSH kulcsát tartalmazza. Az SSHFP rekordban és így a szerver ssh kulcsában megbízhatunk, ha DNSSEC-cel védett. Nem kell „kézzel” beavatkoznunk, ha új ssh kulccsal találkozunk például upgrade miatt. Szkriptekben is biztonsággal kiadhatunk távoli gépekre ssh parancsot. Az Openssh régen támogatja az SSHFP rekordot, feltéve, hogy az DNSSEC-cel védett.

Egy webhely (levelezőszerver, VPN kliens stb.) hitelességét X.509 szabvány szerinti tanúsítvány „igazolja”. ¹⁵ Az X.509 tanúsítványok egy aláírt nyilvános kulcsot tartalmaznak. A bizalmi lánc kiindulópontjai a CA-k: Certification Authority-k, a hivatásos tanúsítványkibocsátók. Minden böngésző (levelezőkliens stb.) konfigurációja tartalmazza a root CA tanúsítványok egy listáját, és a root tanúsítványok által közvetlenül vagy közvetve aláírt tanúsítványokat hitelesnek fogadja el a program. Tanúsítványkibocsátók hibázhatnak és lehetnek hanyagok. De ennél több is igaz: sokszor beigazolódott, hogy a tanúsítványkibocsátók kormányok és bűnözők hatására hamisítanak. Ilyen felfedezett eset például a Comodo ¹⁶, vagy a Diginotar ¹⁷ esete.

Ezen a problémán is tud segíteni a DNSSEC.

A DANE (DNS-based Authentication of Named Entities) arra szolgál, hogy DNSSEC aláírással igazoljuk az X.509 tanúsítvány hitelességét. Ilyen módon kiegészíthetjük, ellenőrizhetjük, helyettesíthetjük a CA-k információját. Ennek érdekében új DNS rekordot vezettek be, a TLSA rekordot ¹⁸. A TLSA rekord rugalmasan használható. Tartalma lehet:

• „Ez az én CA-m!”
• „Ez az én tanúsítványom, de ellenőrizd a szokásos módon is!”
• „Saját CA-t használok, ez az!”
• „Ez az én tanúsítványom!”

Egyre több programban van DANE implementáció: nem csak böngészők, hanem SMTP szerverek és SIP szerverek is támogatják.

Legfontosabb védekezés a hamisított IP címek kiszűrése. Ha ez megvalósulna, minden IP cím hamisításon alapuló támadás lehetetlenné válna. Erre vonatkozik a BCP38 (alias RFC2827), ennek a problémának tárgyalására jött létre a http://www.bcp38.info webhely. Hamisított IP címeket a csomagok forrásánál lehet megszűrni. Ezért fontos, hogy minden szolgáltató csak a saját hálózatába tartozó címekről jövő csomagokat engedjen ki a hálózatából. ¹⁹ Évek óta minden fórumon szorgalmazzák a BCP38 bevezetését, és nem is hiábavalóan, de nem teljes sikerrel: a BCP38 sok hálózatban nincs bevezetve.

Az autoritatív névszervereken tudunk védekezni a DNS-en alapuló erősítéses támadások ellen Response Rate Limiting (RRL) bevezetésével. RRL alkalmazásakor az autoritatív névszerver nem válaszol, ha ugyanazt a választ ugyanabba a hálózatba (CIDR) blokkba túl gyakran kellene adni. Hallgatás helyett TCP-re is tereli (alapértelmezésben minden második) ilyen kérdést oly módon, hogy egy rövid választ ad, melyben bebillenti a TC bitet. Az RRL-t az ártatlan felhasználók alig érzékelik, de a DNS erősítést meghiusítja. Az RRL-t több autoritatív névszerver program, például a Bind, az NSD, a Knot és a Yadifa is támogatja.

Első pillanatra a stub rezolver oldalán látszik a legegyszerűbbnek a DNSSEC bevezetése: adjunk meg DNSSEC-et tudó rekurzív névszervert a rezolver konfigurációban (pl. /etc/resolv.conf), és készen is vagyunk. A gyanakvó felhasználó azonban nem lehet teljesen nyugodt: a rekurzív névszerver és a stub rezolver között maradt egy támadási felület. Ezt szokták a „last mile” ²⁰ problémájának nevezni.

Erre megoldás lehet, ha a saját gépünkön futtatunk rekurzív névszervert, és 127.0.0.1-et adunk meg névszerverként. Ennek is vannak azonban hátrányai:

• A cache kevéssé lesz hatékony
• Az autoritatív névszerverekre nagyobb teher hárul, ha ez széles körben elterjed

Mindkét bajon sokat javít, ha forwarder-ként használjuk a régi névszervert. A gyakorlat azt mutatja, hogy nem érezhető lassulás a nevek feloldásában. Lokális gépen rekurzív névszervert - pl. Unbound-ot - telepíteni, üzemeltetni nem is nehéz akár unix, akár windows operációs rendszer alatt.

Egy másik megoldás lehet az utolsó szakaszon TSIG-et használni.

Nem egy weblap áll rendelkezésünkre, ha ellenőrizni akarjuk, hogy használunk-e DNSSEC-et. Például:

• http://dnssec-or-not.org
• http://dnssectest.sidn.nl/test.php

Ezeken a web helyeken más és más tartalom jelenik meg attól függően, hogy éppen használunk-e DNSSEC-et.

Rekurzív névszerverben néhány paraméter beállítása és a root-hoz tartozó trust anchor megadása jelenti a DNSSEC bevezetését. Két példát mutatunk be:

Autoritatív névszervernél két feladat áll előttünk: egyrészt létre kell hoznunk, és folyamatosan karban kell tartanunk a DNSSEC-cel védett zónát, másrészt szolgáltatni kell azt. A mai névszerver programok többsége lehetőséget ad az első feladat megoldására is, de azok helyett érdemes megfontolni az Opendnssec használatát. A második feladat megoldása nem nehéz. Az NSD és a Bind is alapértelmezésben támogatja a DNSSEC-et: értik a DO bitet, a kérdésekben és e bit hatására a DNSSEC rekordokat is szolgáltatni fogják.

A .hu alatt 2011. óta kísérleti rendszer működött. 2014. októberében élesítettük a DNSSEC konfigurációt, a .hu zóna alá van írva. 2015-ben bevezetjük a DNSSEC-cel védett delegálás lehetőségét. Ennek módja, hogy a regisztrátor a regisztrátori felületen a DNSSEC checkbox kiválasztásával kéri a domain DNSSEC delegálását. Ezek után a domain ellenőrzés során a regcheck procedúra:

• Az autoritatív DNS szerverből kiolvassa a DNSKEY rekordo(ka)t
• Ellenőriz
• Ha mindent rendben talál, képezi a DS rekordot/rekordokat

A .hu-ba nem csak a felolvasott NS rekordokat, hanem a DS rekordo(ka)t is beteszi. Ettől kezdve a delegált zóna DNSSEC-cel védett.

Az OpenDNSSEC egy könnyen kezelhető, konfigurálható DNSSEC megoldás. Szabad szoftver, folyamatosan fejlesztik. A fejlesztésében részt vesz több TLD: .se, .uk, .nl, és még több TLD használja, például a .hu is. Az OpenDNSSEC nem tartalmaz névszervert, csak a DNSSEC zóna előállítása a cél. Az OpenDNSSEC bármilyen névszerverrel együtt tud működni, akár váltogathatjuk a név szerver programokat anélkül, hogy az OpenDNSSEC konfiguráción bármit változtatnánk.

Az OpenDNSSEC a kulcskezelést PKCS#11 interfész-en végzi. A PKCS11 az RSA Labs-tól származó szabvány, melyet elsősorban különböző HSM-ek (Hardware Security Module)-ok támogatnak. Az OpenDNSSEC csapat szoftveres HSM-et fejlesztett, a softhsm-et.

Az OpenDNSSEC legkellemesebb tulajdonsága, hogy a felhasználó csak az eljárásrendet, a policy-t határozza meg, ezek után az OpenDNSSEC-re bízza a következő feladatokat:

• Kulcsok generálása
• Kulcsok használatbavétele, törlése
  • A kulcsok ugyan nem járnak le, de rendelkezünk lejáratról!
• Aláírások generálása, újragenerálása
• Zóna publikálás
• Naplózás

Nem megy automatikusan a KSK → DS → DS publikálás. Erre — pillanatnyilag — nincs automatizmus az OpenDNSSEC-ben. (Kétséges, hogy kívánatos lenne-e). Minden esetre az OpenDNSSEC ebben is segít: generálja a kulcsot amikor a policy megkívánja, és figyelmeztet, hogy juttassuk el az apuka zónába az új DS rekordot. Ha a DS rekord bekerült az apuka zónába, akkor egy paranccsal tudomására hozhatjuk, hogy az apuka átvette a DS-t:

ods-ksmutil key ds-seen -x  32701 --zone bioetika.hu

A 9. ábrán láthatjuk az OpenDNSSEC építőelemeit.

Az ábrán látható, hogy a KASP meghatározásán kívül lényegében csak arra van szükség, hogy megmondjuk honnan vegye az aláirandó nyers zónát és hova tegye az aláírt zónát. A zóna input és output is lehet egyszerű fájl, vagy pedig egy DNS zóna transzfer.

Az OpenDNSSEC működés szívében áll a Key and Signing Policy, a KASP. Több eljárásrendet (policy-t) tudunk definiálni, és egy policy meghatározásakor nem kell megmondani, hogy az melyik zónához, vagy zónákhoz tartozik. A kezelt zónák listáját külön kell megadnunk, és a zónákhoz rendelünk aztán policy-t. Több policy-t is definiálhatunk, de használhatjuk ugyanazt a policyt sok ezer zónával. A policy-ban eldöndentő kérdések:

• Milyen kulcsokat használjunk?
• Mennyi időnként cseréljük?
• NSEC vs. NSEC3?

Többször kell időt specifikálnunk ami az ISO 8601 szabvány szerint történik. Ez a szabvány időpont, ismétlődés, intervallum szabványos megadását írja le. Az OpenDNSSEC-ben csak az időtartam definiálása érdekes. Ez ilyen formában történik:

• P[n]Y[n]M[n]DT[n]H[n]M[n]S
• P jelenti, hogy időtartam-ot adunk meg (P eriódus)
• T választja el az órát a dátumtól

Vegyük észre, hogy M mást jelent T előtt mint T után. Jó tudni (de erre mindig figyelmeztet is), hogy az OpenDNSSEC-nél 1 év mindig 365 nap, 1 hónap mindig 31 nap.

A 10. ábrán láthatjuk az OpenDNSSEC aláírási időparamétereket.

Az inception offset mutatja, hogy mennyire „datálja vissza” a számítógép órájához képest az aláírások kezdetének idejét, a signature inception időt. Erre azért van szükség, mert ha az aláírás után nem sokkal valaki ellenőrzi azt, és az órája jelentősen hátrább jár mint a mienk, akkor azt találhatja, hogy a jövőben keletkezett az aláírás, és ezért nem fogadja el. Ez ellen véd ez a paraméter.

A jitter azt mondja meg, hogy egy bizonyos időszakra szóló aláírások időtartamai mennyire szóródjanak véletlenszerűen. Ha ugyanis egy időpontban sok azonos időtartamra szóló aláírás keletkezik, akkor azok megújítása, a rekordok ismételt aláírása egyszerre válik esedékessé. A jitter paraméter segítségével elnyújthatjuk ezt az újra aláírást, ilyen módon takarékoskodhatunk az erőforrásokkal.

A 11. ábra mutatja az aláírások újrafelhasználásával kapcsolatos paraméterek jelentését.

Az OpenDNSSEC Resign period időnként újra, és újra megnézi, hogy szükséges-e ismét aláírni egy-egy rekordot. Ha az aláírás lejárati ideje, az Expiration time még messze van, akkor változatlanul hagyja az aláírást. Nem várja meg azonban a lejárati időt, hanem akkor írja újra a rekordot, ha a pillantanyi idő már Refresh period-nál jobban megközelítette a lejárati időt.

Az OpenDNSSEC az egyes zónákhoz a policy-ban meghatározott módon kulcsokat generál. A kulcsok a következő állapotokban lehetnek:

• GENERATE
  • A kulcsot éppen legenerálta — nem szoktuk látni
• PUBLISH
  • A zónában ott a kulcs, de még nem terjedt el, még nem biztonságos vele aláírni

• READY
  • Már elkezdhetnénk használni a kulcsot
  • KSK esetén ilyenkor még a ds-seen paranccsal kell bíztatni, hogy ténylegesen használatba jusson

• ACTIVE
  • Az ilyen kulcsot használja aláírásra az OpenDNSSEC

• RETIRE
  • A kulcsot már nem használjuk aláírásra, de a világban még lehetnek ezzel a kulccsal aláírt rekordok

• DEAD
  • A kulcsot ki lehet venni a zónából

Az OpenDnssec rendelkezésre áll például a Debian disztribúciókban. Az opendnssec és a softhsm csomagok (és függőségeik) telepítése után néhány konfigurációs fájlt kell csak editálnunk és készen is vagyunk. A legfontosabb, hogy a konfigurálás előtt határozzuk meg, hogy milyen eljárásrend (policy) szerint akarjuk működtedni a DNSSEC zónáinkat. Ajánlatos a generált zónákat ellenőrizni mielőtt névszerverek szolgáltatnák. Erre igen hasznos eszköz a validns, amiből szintén van Debian csomag.

Az OpenDnssec nagy előnye, hogy ha egyszer végiggondoltuk, bekonfiguráltuk, akkor attól kezdve — éppen úgy, mint a DNSSEC nélküli DNS esetén — akár el is feledkezhetünk az egészről: a zónánk ugyan időről időre változni fog, új kulcsok, aláírások keletkeznek, de mindez megbízhatóan és automatikusan.