Skip to end of metadata
Go to start of metadata
Tämän sivun sisältö:
 
 

Johdanto

Tämä dokumentti on selvitys DNSSEC-validoinnin käyttöönoton vaikutuksista resolverinimipalveluun.

DNSSEC-validoinnin avulla resolvoiva DNS-palvelin voi varmistua nimipalvelutietojen eheydestä. Validoiva resolveri käyttää hyväkseen nimipalveluun lisättyjä DNSSEC-tietueita (RRSIG, DNSKEY, DS, NSEC, NSEC3) nimipalvelutietojen eheyden tarkistamiseen. DNSSEC-tietueet sisältävät mm. tietueiden allekirjoituksia (RRSIG), allekirjoitusavaimia (DNSKEY), luottamusdelegointeja (DS) ja autentikoitua tietoa puuttuvista tietueista (NSEC, NSEC3).

DNSSEC-tietueiden vastaanottaminen

Tehdessään DNS-kyselyjä validoiva resolveri tekee kyselyjä EDNS0-laajennuksen avulla. Nimipalvelukyselyihin lisätään OPT-kenttä, jossa kerrotaan että resolveri pystyy vastaanottamaan yli 512 tavun DNS-vastauksia. OPT-kenttään määritellään päälle myös DNSSEC OK-bitti (DNSSEC DO), joka kertoo auktoritatiiviselle nimipalvelimelle että kyselijä ymmärtää ja haluaa vastaanottaa DNSSEC-tietueet. Auktoritatiivinen palvelin ei lähetä DNSSEC-tietueita ellei DNSSEC OK-bitti ole kyselyssä päällä.

On huomattava, että useat rekursiiviset nimipalvelimet lisäävät kyselyihinsä oletusarvoisesti DO-bitin, vaikka niitä ei olisi konfiguroitu suorittamaan DNSSEC-validointia (kts. esimerkiksi RIPE Labsin artikkeli). Käytännössä siis myös monet sellaiset rekursiiviset nimipalvelimet, jotka eivät edes yritä tehdä DNSSEC-validointia, vastaanottavat auktoritatiivisilta nimipalvelimilta DNSSEC-tietueita.

Kun DNSSEC OK-bitti on päällä, auktoritatiivinen nimipalvelin palauttaa kaikkien allekirjoitettujen tietueiden mukana RRSIG-allekirjoitukset. Lisäksi kaikkien delegointien (NS-tietueet) mukana lähetetään luottamusdelegoinnit (DS-tietue), ja NXDOMAIN-vastauksien (tietuetta ei löydy) mukana tietueiden puuttumisen todentavat NSEC- ja NSEC3-tietueet ja niiden RRSIG-allekirjoitukset. Validoiva resolveri joutuu lisäksi hakemaan allekirjoitusten todentamiseen tarvittavat allekirjoitusavainten julkiset osat (DNSKEY) erillisillä DNS-kyselyillä.

Luottamusketjut

Validointia varten resolveriin on määriteltävä yksi tai useampia luottamusankkureita. Luottamusankkuri määrittelee julkisen avaimen jolla tehtyihin allekirjoituksiin luotetaan. Luottamusankkuri on mahdollista määrittää syöttämällä resolverille itse julkinen avain (DNSKEY), tai syöttämällä resolverille julkisen avaimen kryptografinen tiiviste (DS).

Koska nimipalvelun juuri on allekirjoitettu, jatkossa riittää että resolvoivaan nimipalvelimeen määritellään luottamusankkuriksi juuren allekirjoittamisessa käytetty julkinen avain. Tällöin luotetaan juureen, ja kaikkiin juuresta lähteviin luottamusketjuihin (DS).

Tyypillisesti jokaisessa DNS-vyöhykkeessä (zone) on kaksi avainta (DNSKEY) jolla DNS-tietueita allekirjoitetaan: KSK (key signing key) ja ZSK (zone signing key). KSK:lla allekirjoitetaan kaikki vyöhykkeen avaimet (DNSKEY-tietueet) ja ZSK:lla muut tietueet. Tämä tehdään allekirjoitusavainten muuttamisen helpottamiseksi. Erottelu ZSK:n ja KSK:n välillä tehdään DNSKEY-tietueeseen määriteltyjen lippujen avulla. ZSK:lla on arvo 256, ja KSK:lla 257.

Myös juuressa on ZSK ja KSK. Resolveriin luottamusankkuriksi määritellään siis nimenomaan KSK:n julkinen osa (DNSKEY) tai sen tiiviste (DS). Luottamusankkurin avulla voidaan validoida juuren KSK ja KSK:n avulla DNSKEY-tietueet. DNSKEY-tietueiden (ja siellä olevan ZSK:n) avulla voidaan puolestaan validoida muut juuren RRSIG-allekirjoitukset.

Myös juuressa olevat DS-tietueet on allekirjoitettu. Juuressa fi-domainille määritelty DS-tietue määrittää fi-TLD:n KSK:n tiivisteen. Tiivisteen avulla voidaan validoida fi-TLD:n KSK ja KSK:n avulla fi-TLD:n DNSKEY-tietueet, jne.

Esimerkki validoivasta resolvoinnista

Oletetaan että validoivaan resolveriin on määritelty juuren luottamusankkuri DS-tietueena ja että resolverin välimuisti on tyhjä. Resolveri vastaanottaa DNS-pyynnön jossa kysytään www.funet.fi:n AAAA -tietuetta (IPv6-osoite). Resolveri tekee kaikki nimipalvelukyselyt EDNS0 DNSSEC OK-bitti päällä. Tässä esimerkissä kaikki DNS-vyöhykkeet on allekirjoitettu.

  1. Resolveri hakee juuren NS-tietueet joltakin hints-tietoihin määritellyltä juurinimipalvelimelta. Resolveri vastaanottaa NS-tietueet ja niiden RRSIG-allekirjoituksen. Tämän lisäksi resolveri saa myös juurinimipalvelinten A- ja AAAA-tietueet (ilman allekirjoituksia).
  2. Resolveri hakee juuren DNSKEY-tietueet. Resolveri vastaanottaa DNSKEY-tietueet ja niiden RRSIG-allekirjoituksen.
  3. Resolveri validoi DNSKEY-tietueisiin määritellyn KSK-avaimen eheyden nimipalvelimen konfiguraatioon määritellyn luottamusankkurin (DS-tietue) avulla.
  4. Resolveri tarkistaa juuren DNSKEY-tietueiden RRSIG-allekirjoituksen juuren KSK:n avulla.
  5. Resolveri tarkistaa juuren NS-tietueiden allekirjoituksen juuren ZSK:n avulla. Nyt resolverilla on välimuistissaan validoitu tieto juuren nimipalvelimista ja juuren ZSK:sta.
  6. Resolveri kysyy www.funet.fi:n AAAA-tietuetta joltain juurinimipalvelimelta. Resolveri saa vastaukseksi fi-vyöhykkeen NS- ja DS-tietueet, ja DS-tietueiden allekirjoituksen (delegoivia/ei-auktoritatiivisiä NS-tietueita ei allekirjoiteta!). Tämän lisäksi resolveri saa myös fi-TLD:n nimipalvelinten A- ja AAAA-tietueet ilman allekirjoituksia.
  7. Resolveri validoi fi-vyöhykkeen DS-tietueen RRSIG-allekirjoituksen juuren ZSK:n avulla.
  8. Resolveri kysyy www.funet.fi:n AAAA-tietuetta uudelleen joltain fi-TLD:n nimipalvelimelta. Resolveri vastaanottaa funet.fi:n NS- ja DS-tietueet, DS-tietueiden RRSIG-allekirjoituksen ja funet.fi:n nimipalvelinten A- ja AAAA-tietueet.
  9. Resolveri pyytää fi:n DNSKEY-tietueet, ja saa vastauksena DNSKEY:t ja niiden RRSIG-allekirjoituksen.
  10. Resolveri validoi fi:n KSK:n juuresta saadun luottamusdelegoinnin (DS) avulla.
  11. Resolveri validoi fi:n DNSKEY-tietueet fi:n KSK:n avulla.
  12. Resolveri validoi funet.fi:n DS-tietueen fi:n ZSK:n avulla.
  13. Resolveri kysyy www.funet.fi:n AAAA-tietuetta joltain funet.fi:n nimipalvelimista. Resolveri vastaanottaa www.funet.fi:n AAAA-tietueen ja sen RRSIG-allekirjoituksen. Resolveri vastaanottaa myös funet.fi:n NS-tietueet , NS-tietueiden RRSIG-allekirjoituksen ja funet.fi:n nimipalvelinten A- ja AAAA-tietueet ja niiden RRSIG-allekirjoitukset (olettaen että nimipalvelimet ovat funet.fi-vyöhykkeessä).
  14. Resolveri kysyy joltain www.funet.fi:n nimipalvelimista funet.fi:n DNSKEY-tietueita. Resolveri vastaanottaa DNSKEY-tietueet ja niiden RRSIG-allekirjoituksen.
  15. Resolveri validoi funet.fi:n KSK:n fi-TLD:stä saadun luottamusdelegoinnin (DS) avulla.
  16. Resolveri validoi funet.fi:n DNSKEY-tietueet funet.fi:n KSK:n avulla.
  17. Resolveri validoi www.funet.fi:n AAAA-tietueen, funet.fi:n NS-tietueiden ja funet.fi:n nimipalvelinten A- ja AAAA-tietueiden allekirjoitukset funet.fi:n ZSK:n avulla.

Yhteenvetona edellisen esimerkin luottamusketju lähtien nimipalvelimeen konfiguroidusta luottamusankkurista ja päättyen www.funet.fi:n AAAA-tietueeseen on seuraava:

  1. luottamusankkuri (juuren DS-tietue)
  2. juuren KSK
  3. juuren DNSKEY-tietueiden RRSIG-allekirjoitus
  4. juuren ZSK
  5. fi-vyöhykkeen DS-tietueen RRSIG-allekirjoitus (juuressa)
  6. fi-vyöhykkeen DS-tietue (juuressa)
  7. fi-vyöhykkeen KSK
  8. fi-vyöhykkeen DNSKEY-tietueiden RRSIG-allekirjoitus
  9. fi-vyöhykkeen ZSK
  10. funet.fi-vyöhykkeen DS-tietueen RRSIG-allekirjoitus (fi-vyöhykkeessä)
  11. funet.fi-vyöhykkeen DS-tietue (fi-vyöhykkeessä)
  12. funet.fi-vyöhykkeen KSK
  13. funet.fi-vyöhykkeen DNSKEY-tietueiden RRSIG-allekirjoitus
  14. funet.fi-vyöhykkeen ZSK
  15. www.funet.fi AAAA-tietueen RRSIG-allekirjoitus
  16. www.funet.fi AAAA-tietue

Validoinnin tuomat muutokset tilanteeseen jossa validointia ei tehdä

Tässä on selostettu validoimmin tärkeimmät erot tilanteeseen, jossa validointia ei tehdä.

DNS-pakettien koko kasvaa

Validointi lisää resolverin vastaanottamien DNS-pakettien kokoa. Vastauspaketit ovat suurempia mm. RRSIG-allekirjoitusten ja DS-tietueiden vuoksi. Esimerkiksi fi-vyöhykkeen NS-tietueet mahtuvat 478 tavun pakettiin kun EDNS0 DNSSEC OK-bitti ei ole päällä, mutta DNSSEC päälle kytkettynä kyselyyn tullut vastaus on 3081 tavua.

Näin suuret DNS-vastaukset eivät mahdu normaaliin Ethernet MTU:hun (1500 tavua), joten vastauksia joudutaan fragmentoimaan. Resolverin palomuuri on konfiguroitava niin ettei fragmentteja estetä.

Joissain tapauksissa suuret DNS-vastaukset eivät tule perille, esimerkiksi palomuurien tai väärin konfiguroitujen auktoritatiivisten nimipalvelimien vuoksi. Tällöin validoiva resolveri tekee kyselyn uudelleen TCP:n välityksellä. Resolverin palomuurin on sallittava DNS-kyselyt myös TCP:llä (porttiin 53).

Resolverin kuormitus ja resolvoinnin viiveet kasvavat

Validointi lisää resolverin kuormitusta. RSA-allekirjoitusten varmistaminen on kohtuullisen työlästä vielä nykyaikaisillekin palvelimille. Validoiva resolveri kuluttaa myös enemmän muistia, koska myös DNSSECin uusia ylimääräisiä tietueita on pidettävä välimuistissa. Vaihtoehtoisesti validoiva resolveri pitää tietueita välimuistissaan vähemmän aikaa, jos resolverin välimuistin koko on kiinteästi rajattu.

Daniel Migaultin testeissä DNSSEC-validoinnin käyttöönotto tiputti hitaan Pentium-III 1GHz -nimipalvelimen suorituskyvyn noin 3000 kyselystä/sek noin 900 kyselyyn/sek (Unbound) tai 1100 kyselystä/sek noin 500 kyselyyn/sek (Bind9). Vaikutus suorituskykyyn on on siis merkittävä, Unboundin tapauksessa -63% ja Bindin tapauksessa -54%. Validoiva Unbound on kuitenkin lähes yhtä suorituskykyinen kuin Bind9 ilman validointia.

Samoissa testeissä validoinnin laskettiin lisäävän DNS-kyselyn viiveitä 215% (Unbound) tai 35% (Bind9). Validoivan Unboundin viiveet olivat kuitenkin 25% pienempiä kuin Bind9:n ilman validointia. Viiveitä kasvattaa mm. se että validoiva resolveri joutuu hakemaan DNSKEY-tietueet erikseen. Viiveen lisääntymiseen vaikuttaa merkittävästi kiertoviive resolvereiden ja auktoritatiivisten nimipalvelinten välillä.

Kuormituksen kasvamisesta aiheutuvan riskin minimoimiseksi validointi kannattaisi ottaa käyttöön mahdollisimman aikaisessa vaiheessa. Tällöin resolvereiden kuormitus nousee tasaisemmin sitä mukaa kun DNSSEC-allekirjoittaminen yleistyy maailmalla. Jos validointi otettaisiin käyttöön vasta sitten kun koko DNS-hierarkia on allekirjoitettu, kuormituksen nousun kertavaikutukset olisivat huomattavasti suuremmat.

Resolvoinnin viiveitä pystyy pienentämään käyttämällä Bindin sijaan suorituskykyisempää Unboundia, ja siinä prefetch-optiota. Prefetch-option avulla Unbound pyrkii pitämään eniten käytetyt DNS-tietueet aina välimuistissaan. Tällöin myös eniten käytettyjen DNS-tietueiden validointia ei tarvitse tehdä DNS-kyselijän odottaessa vastausta.

Resolverin kellonajan täsmällisyys muuttuu kriittisen tärkeäksi

Koska RRSIG-allekirjoituksissa on aina määritelty allekirjoituksen voimassaolon alkamis- ja päättymisajat, validoivan resolverin kello on oltava oikeassa ajassa. Jos resolverin kello on selkeästi väärässä ajassa, palvelin voi hyväksyä vanhoja tai hylätä voimassa olevia allekirjoituksia. Resolverin kello tulee siis olla synkronoitu johonkin hyvään aikalähteeseen ja kellonajan synkronointia tulisi valvoa.

Jos aikalähteenä käytetään NTP:tä, NTP-infrastruktuurin tulee olla riittävän turvallinen. Huono tietoturva NTP-palvelussa voisi aiheuttaa sen että hyökkääjä saisi muutettua validoivan resolverin väärään kellonaikaan. Väärä kellonaika estäisi pahimmillaan koko verkon toiminnan resolvoinnin estyessä. [AR]

Vaikutukset resolverin loppukäyttäjille

Validoiva resolveri aiheuttaa hyvin vähän muutoksia loppukäyttäjille (stub-resolvereille). Jos käyttöjärjestelmän stub-resolveri ei merkitse DNSSEC OK-bittiä DNS-kyselyihin (suurin osa nykyisistä käyttöjärjestelmistä) validoivan resolverin toiminta näkyy korkeintaan pienenä viiveiden nousuna sellaisissa DNS-kyselyissä jotka eivät löydy suoraan resolverin välimuistista.

Jos DNS-kyselyn tekijä ei eksplisiittisesti ilmoita tukevansa DNSSECiä, validoiva resolveri ei lähetä vastauksissa mitään DNSSECiin liittyvää tietoa. Validoiva resolveri validoi kuitenkin kaikki DNS-tietueet kuten ennenkin, joten loppukäyttäjä saa validoinnin ansiosta parempaa DNS-tietoturvaa ilman käyttöjärjestelmämuutoksia. Validoinnin epäonnistuessa resolveri vastaa DNSSEC-tuettomille kyselijöille SERVFAIL -vastauksella.

SERVFAIL-vastaus indikoi nimipalveluongelmaa, johon stub-resolverit reagoivat tekemällä saman kyselyn toisen resolverin kautta. Jos muita resolvereita ei ole konfiguroitu käyttöjärjestelmän verkkoasetuksiin, tai jos kaikki resolverit vastaavat SERVFAIL-virheellä, käyttöjärjestelmän TCP/IP-pino palauttaa DNS:ää käyttävälle ohjelmistolle tiedon että nimeä ei löydy [RFC 1035, Comcast FAQ].

Jos loppukäyttäjän käyttöjärjestelmä tukee DNSSEC-nimipalvelukyselyitä, validoiva resolveri kertoo validoinnin onnistumisesta merkitsemällä DNS-vastauksiin AD-bitin (Authenticated Data) päälle. Validoinnin epäonnistuessa resolveri vastaa kuitenkin SERVFAIL-virheellä kuten muillekin stub-resolvereille. DNSSECiä tukeva stub-resolveri voi halutessaan validoida DNS-tietueet itse, merkitsemällä DNS-pyyntöihin CD-bitin (Checking Disabled) päälle. Tällöin resolveri lähettää DNS-tietueet vaikka niiden validointi epäonnistuisi.

Nominet on tutkinut DNSSECin toimivuutta kuluttajille myytävien verkkolaitteiden kanssa. Vain noin 25% testatuista laitteista toimi oikein jos loppukäyttäjän laite teki DNS-kyselyitä EDNS0 DNSSEC OK-bitti päällä. Tällä hetkellä (11/2010) ei ole tiedossa käyttöjärjestelmiä joiden stub-resolveri laittaisi DNSSEC OK-bitin oletuksena päälle.

Validointi tuo lisäturvaa kaikille resolveria käyttäville loppukäyttäjille. Validoivasta resolverista hyötyvät myös sellaiset käyttäjät, joiden laitteet eivät vielä tue DNSSECiä. Näille käyttäjille validoiva resolveri näyttäytyy normaalina nimipalvelimena, joka validoinnin epäonnistuessa estää väärän DNS-tiedon kulkemisen perille. Validoiva resolveri tuo periaatteessa lisäturvaa ainoastaan auktoritatiivisten nimipalvelinten ja resolverin väliselle osuudelle verkosta. Loppukäyttäjien ja validoivan resolverin välinen osuus verkosta on edelleen altis DNS-hyökkäyksille loppukäyttäjän suuntaan.

Funetin runkoverkossa käytettävät uRPF-suodatukset estävät kaiken Funetin ulkopuolelta ja Funetin sisältä tulevat IP-osoiteväärennökset. Loppukäyttäjän laitteen huijaaminen ei siis onnistu Funetin sisältä. Funetiin kytkeytyneen organisaation sisäisestä verkosta loppukäyttäjän stub-resolveria vastaan olisi mahdollista hyökätä, mutta vain sellaisissa tapauksissa joissa uRPF-suodatusta ei käytetä organisaation sisäisessä verkossa. Jos organisaation sisäisessä verkossa käytetään uRPF-suodatuksia kattavasti, ainoastaan loppukäyttäjän paikallisesta Ethernet-VLANista pystyy yrittämään nimipalveluväärennöksiä.

Resolverin välimuistin myrkytyksen vaikutukset

DNSSEC ei estä resolverin välimuistin myrkyttämistä kaikissa tilanteissa, koska kaikkia DNS-tietueita ei allekirjoiteta. Erityisesti ylemmän tason DNS-vyöhykkeissä määritellyt NS-tietueet, tai lisätietoina annettavat nimipalvelinten A- ja AAAA-tietueet ovat allekirjoittamattomia.

Tämä aiheuttaa sen, että delegoivia NS-tietueita on edelleen mahdollista väärentää myrkyttämällä resolverin välimuistia (cache poisoning). Hyökkäys on tosin huomattavasti vaikeampaa tehdä, koska vyöhykkeiden NS-tietueita tarvitsee kysyä vain harvoin.

Jos välimuistin myrkytys onnistuu, ja resolveri alkaa käyttämään vääriä nimipalvelimia allekirjoitetulle DNS-vyöhykkeelle, kaikki kyseisen vyöhykkeen nimipalvelukyselyt epäonnistuvat. Välimuistin myrkytys aiheuttaa käytännössä palveluneston. Jos resolveri ei validoisi DNS-tietueita, palvelunestoa ei tapahtuisi, vaan DNS-nimet kääntyisivät hiljaa hyökkääjän haluamaan paikkaan.

Näistä kahdesta palvelunesto on selvästi pienempi haitta. On parempaa että onnistunut DNS-hyökkäys näkyy, kuin että nimet kääntyvät hiljaa vääriin osoitteisiin.

Riippuvuus muuttuvasta nimipalvelutiedosta

DNSSECin käyttöönoton myötä nimipalvelutietojen luonne muuttuu merkittävästi. Auktoritatiivisilla nimipalvelimilla oleva tieto vaatii jatkuvaa päivittämistä sitä mukaa kun allekirjoituksia ja avaimia uusitaan. Allekirjoitusjärjestelmien monimutkaisuus, ohjelmistojen suhteellisen nuori ikä ja ylläpitäjien kokemattomuus onkin aiheuttanut ongelmia maailmalla. Joidenkin DNS-vyöhykkeiden allekirjoitukset ovat mm. vanhentuneet.

Myös inhimilliset virheet ovat aiheuttaneet ongelmia allekirjoitetuissa vyöhykkeissä. Jos ylävyöhykkeessä oleva DS-delegointi ei vastaa vyöhykkeeseen itseensä määriteltyä KSK:ta, luottamusketju katkeaa ja validointi katsoo että tieto on väärennettyä.

Ongelmat auktoritatiivisissä nimipalvelimissa ja allekirjoitusjärjestelmissä vaikuttavat myös validoivaan DNS-resolveriin. Allekirjoitusongelmien tapahtuessa validoiva resolveri voi hylätä kaikki virheelliset DNS-tietueet. Tällöin virheellinen vyöhyke (pahimmassa tapauksessa kokonainen TLD) katoaa resolverin ja sen käyttäjien näkökulmasta verkosta. DNSSECiin liittyviä vikoja (mm. väärät avaimet, vanhentuneet allekirjoitukset) on tapahtunut ainakin uspto.gov, .be, .cz, .bg, .pt ja .uk -vyöhykkeille. Validoinnin käyttöönotto voi siis lisätä viallisen DNS-tiedon vaikutuksia käyttäjille.

Ongelmien havaitsemiseksi, ainakin validoivan resolvointipalvelun alkuvaihella tulee valvoa juuren ja kaikkien TLD:ien DNSSEC-toimivuutta. Valvottavat vyöhykkeet voidaan valita esimerkiksi ICANNin TLD DNSSEC Report-sivun pohjalta.

Luottamusankkurin päivitystarve

Validoivan resolverin luottamusankkurit täytyy pitää ajan tasalla. Tyypillisesti resolveriin tarvitsee määritellä ainoastaan juuren luottamusankkuri, joten riittää että se on kunnossa. Näillä näkymin juuren KSK:n eliniäksi on suunniteltu 5 vuotta. Ongelmatilanteissa KSK voidaan uusia tarvittaessa nopeammin. KSK:n muuttuminen vaatii sen, että resolverin käyttämä luottamusankkuri muutetaan. Luottamusankkuri täytyy muuttaa ennen kuin vanhalla KSK:lla tehdyt allekirjoitukset poistetaan juuresta. Jos luottamusankkuria ei päivitetä, vanhalla avaimella tehtyjen allekirjoitusten poistumisen jälkeen kaikki DNS-kyselyt epäonnistuvat, koska juureen ei luoteta.

RFC 5011 kuvaa menetelmän jonka avulla validoiva resolveri voi päivittää luottamusankkurit automaattisesti niiden vaihtuessa. Luottamus uusiin luottamusankkureihin luodaan vanhan luottamusankkurin avulla. Uusi luottamusankkuri allekirjoitetaan vanhalla luottamusankkurilla vähintään 30 päivän ajan, jonka jälkeen resolveri voi luottaa uuteen luottamusankkuriin. Vanha luottamusankkuri poistetaan käytöstä laittamalla KSK:n Revoke-bitti päälle. Unbound versiosta 1.4 lähtien ja Bind versiosta 9.7 lähtien tukevat RFC 5011:ssä määriteltyä luottamusankkurin päivitysmenetelmää.

Automaattinen päivitysmenetelmä ei ole täysin aukoton, joten juuren luottamusankkurin päivittymistä on valvottava myös muilla keinoin. Juuren KSK-avaimia tulisi valvoa, ja muutokset niissä tulisi raportoida validoivan resolverin ylläpitäjille. Ylläpitäjät voivat sitten varmistaa että automaattinen luottamusankkurin päivitys onnistuu.

Jos juuren kaikki luottamusankkurit poistetaan käytöstä Revoke-bitin avulla, resolveri toimii niin kuin luottamusankkuria ei olisi koskaan konfiguroitu. Tällöin nimipalvelu toimii, mutta resolveri ei tee validointia. Jos taas jokin vanhoista luottamusankkureista jäisi resolverin konfiguraatioon, resolverin toiminta estyisi sitten kun vanhalla luottamusankkurilla tehdyt allekirjoitukset poistuvat juuresta.

Ohjelmistojen tuki validoinnille

Nimipalvelinohjelmistot

Suosituimmista nimipalvelinohjelmistoista ainakin Unbound ja Bind tukevat validointia. Koska DNSSEC-validointia tekevä ohjelmakoodi on suhteellisen tuoretta, on siinä myös enemmän vikoja. Tästä syystä kannattaakin valita suhteellisen tuore versio nimipalvelinohjelmistosta ja seurata tietoa uusista korjauspäivityksistä.

  • Suositus Bind-versioksi: 9.7.5 tai uudempi (tukee RFC 5011:tä)
  • Suositus Unbound-versioksi: 1.4.16 tai uudempi.

Käyttöjärjestelmien stub-resolverit

Tällä hetkellä ei ole tiedossa käyttöjärjestelmiä jotka osaavat validoida itse.

Validoinnin käyttöönotto hallitusti

Tähän on hahmoteltu askelia joita tarvitaan validoinnin hallittuun käyttöönottoon kahdesta nimipalvelimesta koostuvassa resolverinimipalvelussa.

  1. Suurten UDP-fragmenttien toimivuuden varmistaminen resolveripalvelimille (IPv4 ja IPv6).
  2. Nimipalvelinohjelmistojen päivittäminen.
  3. Juuren luottamusankkurin selvittäminen ja varmistaminen.
  4. Valvonnan ja tilastoinnin päivittäminen (ks. alempana).
  5. Palvelinten ajan NTP-synkronoinnin varmistaminen (mahdollisesti myös NTP-infrastruktuurin auditointi).
  6. Validoinnin konfigurointi käyttöön ensimmäiselle resolveripalvelimelle.
    • Jos validoinnissa tai resolverin toiminnassa on jotain ongelmia, stub-resolverit käyttävät automaattisesti toista resolveripalvelinta.
    • Validointi otetaan käyttöön enemmän kuormitetulle palvelimelle, jotta mahdollisimman suuri osa resolvoinnista kulkisi validoinnin läpi ja mahdolliset ongelmat havaittaisiin mahdollisimman pian.
  7. Tilastoinnin seuraaminen. Erityisesti kaikki aikaisemmasta poikkeava tulisi havaita.
  8. 1-2kk pilottikäytön jälkeen validointi otetaan käyttöön myös toisella resolveripalvelimella.

Valvonnan muutostarpeet

Ennen validoinnin käyttöönottoa validoivan resolverin valvontaa pitää parantaa ainakin seuraavasti:

  • Kellonajan synkronoinnin valvonta.
  • Juuren ja tärkeimpien TLD:iden DNSSEC-allekirjoitusten validoitavuuden valvonta. (esim. SOA-tietueen toimivuus)
  • Juuren luottamusankkurin ja avainten päivittymisen valvonta.
  • Validointivirheistä varoittaminen. Varoituskynnys voisi olla aluksi pienikin.
  • Muista DNS-virheistä (mm. SERVFAIL) varoittaminen. Varoituskynnys voi olla pieni.
  • Tilastoinnin parantaminen. Mm. validointiongelmat, tietuetyypit ym. pitäisi tilastoida. Esimerkkejä.

Juuren luottamusankkurin selvittäminen

CSC:llä selvitettiin juuren luottamusankkuria ja sen oikeellisuutta syksyllä 2011 kun valmisteltiin DNSSEC-validoinnin käyttöönottoa ns-cache-palvelussa. Selvityksen mukaan juuren luottamusankkuri on seuraava:

. IN DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5

Juuren DNSSEC-luottamusankkuri varmistettiin seuraavista lähteistä (suluissa miten tieto on varmistettu kryptografisesti):

  • data.iana.org (SSL-varmenne, GnuPG-luottamusketjut)
  • juuren avaintenluontiseremoniaan osallistuneet henkilöt (GnuPG-luottamusketjut)
  • juurinimipalvelinten antamat tiedot kahden eri operaattorin verkosta eri aikoina (Elisan DNSSEC-validoiva resolveri)

Koko selvityksen aikana ei löytynyt yhtään ristiriitaista lähdettä. Kaikista lähteistä saatu DS-tietue oli sama. On siis kohtuullinen varmuus siitä että luottamusankkuri on oikea.

Käyttöönottotilanne maailmalla

Funetin ns-cache-palvelussa validointi otettiin käyttöön tammikuussa 2012.

TeliaSonera otti DNSSEC-validoinnin käyttöön Ruotsissa kesäkuussa 2007. Aluksi heillä oli konfiguroituna resolvereihin ainoastaan .se:n luottamusankkuri. Juuren allekirjoittamisen jälkeen he ovat ottaneet käyttöön juuren luottamusankkurin. He eivät ole joutuneet disabloimaan validointia kertaakaan sen käytön aikana.

TeliaSoneralle on kuitenkin tullut joiltain asiakkailta valituksia siitä että jokin tietty osoite ei toimi, ja että toisen operaattorin verkosta osoite toimii. He ovat osoittaneet asiakkailleen .SE:n operaattorin IIS:n DNSCheck-työkalulla että vika verkkotunnuksen nimipalvelutiedoissa, mikä on toistaiseksi riittänyt selitykseksi.

Terena 2010-konferenssin DNSSEC Workshopissa SURFnet ja SWITCH kertoivat omista kokemuksistaan DNSSEC-validoinnin kanssa. SURFnet otti validoinnin käyttöön vuonna 2009. Vuoden 2010 keväällä noin 1-2% kaikista DNS-vastauksista pystyttiin validoimaan. SURFnetillä oli ollut ongelmia Red Hat Enterprise Linux 5:n ip6tablesin kanssa. Heidän kokeissaan ip6tablesin käyttäminen oli rikkonut IPv6-fragmentit. Sveitsiläisillä oli myös ollut ongelmia fragmenttien kanssa.

Suuri yhdysvaltalainen kaapelioperaattori Comcast on ilmoittanut ottavansa käyttöön DNSSEC-validoinnin. Heidän tavoitteenaan on ottaa DNSSEC käyttöön kaikissa resolvereissa joita heidän asiakkaat käyttävät. Comcast aikoo reagoida DNSSEC-ongelmiin samalla tavalla kuin muihinkin DNS-ongelmiin. Eli he ottavat yhteyttä verkkotunnuksen omistajiin ja pyytävät korjaamaan viat. Comcastilla on yli 14 miljoonaa Internet-asiakasta, joten he ovat merkittävä toimija tällä alueella. Comcastin käyttöönoton myötä ainakin suosituimmissa yhdysvaltalaisissa palveluissa mahdolliset DNSSEC-ongelmat huomataan nopeasti, koska vaikutus on suuri.

Elisa on ottanut validoinnin käyttöön kuluttajaliittymiensä DNS-resolvereissa. Tämä havaittiin 9.10.2010 tutkittaessa verkkotunnusten allekirjoituksia. Elisa ei ole virallisesti tiedottanut asiasta.

Yhteenveto

Validoinnin käyttöönotto DNS-resolverissa tuo palveluun uusia kriittisiä riippuvuuksia. Validoinnin käyttöönotto vaatii myös päivityksiä valvontakäytäntöihin.

Loppukäyttäjille validoinnin tuomat muutokset ovat parhaassa tapauksessa täysin näkymättömiä. Myös DNSSECiä ymmärtämättömät laitteet ja käyttöjärjestelmät pääsevät hyötymään validoivan resolverin tuomasta lisäturvasta.

Validointi tulee ottaa käyttöön hallitusti. Validoinnin käyttöönotto aikaisessa vaiheessa tuo etuja esimerkiksi ennakoitavamman palvelinkuormituksen myötä, mutta validointi aiheuttaa myös uusia riskejä. Jos DNSSEC-allekirjoitukset hajoavat jossain suuressa DNS-vyöhykkeessä, estyy vyöhykkeen käyttäminen kokonaan validoivan resolverin käyttäjiltä.

Lisätietoa ja viitteitä

Tässä on viitteitä ja hyödyllisiä linkkejä lisätietoja varten. Voit ottaa yhteyttä myös Funetin hostmasteriin kaikissa DNSSECiin liittyvissä asioissa (katso yhteystiedot).