Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

 

Status
colourYellow
titleDRAFT

Section
Column
width33%
Panel
borderColor#66a4ae
titleBGColor#66a4ae
titleTämä sivu sisältää:

Table of Contents
maxLevel3

Column
 
Column
 

Ohjeita DNSSEC-käyttöönottoon

Tähän dokumenttiin on kerätty ohjeita ja hyviksi havaittuja käytäntöjä DNSSEC:n käyttöönottoon, ylläpitokäytäntöihin ja valvontaan liittyen. Ohjeet ja suositukset perustuvat yleisesti saatavilla oleviin dokumentteihin (esim. RFC-dokumentit) sekä CSC/Funetin omiin kokemuksiin ja havaintoihin. On kuitenkin syytä muistaa, että kaikki suositukset eivät välttämättä ole sellaisinaan sopivia jokaiseen ympäristöön, vaan kullekin ympäristölle ominaiset tekniset reunaehdot sekä toimintamalleihin liittyvät käytännöt on aina otettava huomioon.

Tämän dokumentin tarkoituksena ei ole antaa yksityiskohtaista selvitystä nimipalvelusta tai DNSSEC:n toimintaperiaatteista. Dokumentissa annetaan erittäin lyhyt johdanto DNSSEC:iin, mutta tarkemmat yksityiskohdat löytyvät muualta, oleellisesti aiheeseen liittyvistä RFC-dokumenteista.

Mikä DNSSEC ja miksi?

DNSSECin avulla voidaan varmistaa, että DNS-vastaus on peräisin oikealta auktoritatiiviselta nimipalvelimelta ja että vastaus ei ole muuttunut siirtotiellä. Tällä tavalla voidaan suojautua tehokkaasti erityisesti niin sanotuilta Man-in-the-Middle -hyökkäyksiltä, joita vastaan perinteinen DNS-protokolla ei anna kovin vahvaa suojaa. Vastausten todentaminen perustuu julkisen avaimen kryptografiaan; DNS-tietueet allekirjoitetaan vyöhykkeen haltijan yksityisellä allekirjoitusavaimella ja todennetaan sitä vastaavalla julkisella avaimella. Allekirjoitusavainten yksityinen osa on tyypillisesti vain vyöhykkeen omistajan/haltijan/ylläpitäjän hallussa ja sen julkinen osa julkaistaan nimipalvelussa erityisen DNSKEY-tietueen muodossa.

...

DNS on todistetusti erittäin toimiva ja ennen kaikkea skaalautuva tietokanta ja DNSSEC-allekirjoittaminen mahdollistaa perinteisen nimipalvelutiedon lisäksi myös kriittisemmän tiedon julkaisemisen DNS:ssa. Esimerkiksi SSH-avainten sormenjälkien julkaiseminen DNS:ssa on mielekästä, jos sormenjälkitietueet (SSHFP-tietueet) voidaan allekirjoittaa ja validoida DNSSEC:n avulla.

Validoinnin käyttöönotto

DNSSEC-validoinnin avulla resolvoiva DNS-palvelin voi varmistaa vastaanottamiensa DNS-tietueiden alkuperän ja eheyden tietuiden allekirjoitusten avulla. Tässä kappaleessa kerrotaan, miten DNSSEC-validointi otetaan käyttöön resolvoivalla nimipalvelimella ja mitä asioita pitää erityisesti huomioida.

Nimipalvelinohjelmisto

Jotta nimipalvelin pystyy tekemään DNSSEC-validointia, siinä pitää olla asennettuna DNSSEC-validointia tukeva nimipalvelinohjelmisto. Ainakin Bindin ja Unboundin tiedetään tukevan DNSSEC-validointia, mikäli käytössä on riittävän uusi versio ohjelmistosta (Bindin osalta suositus 9.7.5. tai uudempi, Unbound 1.4.16 tai uudempi). Yleisesti ottaen on suositeltavaa käyttää laajasti käytössä olevia nimipalvelinohjelmistoja, sillä niihin on yleensä saatavilla tukea esimerkiksi muulta käyttäjäyhteisöltä. Koska DNSSEC on tuotantokäytössä edelleen verrattain uusi tekniikka, on odotettavaa, että nimipalvelinohjelmistoista löytyy DNSSEC-spesifisiä ongelmia ja mahdollisesti haavoittuvuuksiakin. Tämän vuoksi on ensiarvoisen tärkeää seurata käytössä olevan nimipalvelinohjelmiston bugi- ja haavoittuvuustiedotteita.

...

Validoiva resolveri ilmaisee auktoritatiiviselle nimipalvelimelle halustaan vastaanottaa DNSSEC-tietueita erillisen EDNS0-tietueen ja erityisesti siinä olevan DNSSEC OK (DO) -bitin avulla. EDNS0-tietueen avulla resolveri voi myös signaloida auktoritatiiviselle nimipalvelimelle pystyvänsä vastaanottamaan alkuperäisessä DNS-standardissa määriteltyä 512 tavua suurempia UDP-vastauksia (DNSSEC kasvattaa vastausten kokoa siten, etteivät ne yleensä mahdu 512 tavuun). UDP-vastauksen maksimikoko määritellään yleensä nimipalvelinohjelmiston konfiguraatiossa (Unboundissa "edns-buffer-size" ja  Bindissa "edns-udp-size") ja suositeltava arvo sille on RFC6891:n suosituksen mukainen 4096 tavua, mikä on yleensä myös oletusarvo ohjelmistoissa. Jos resolverin palomuuri estää IP-fragmentit, kannattaa UDP-vastauksen maksimikoko konfiguroida Ethernet-verkoissa yleisesti käytössä olevaa 1500 tavun MTU:ta pienemmäksi (esim. 1480 tavua), jolloin fragmentoinnin tarpeen todennäköisyys pienenee. Lisää DNSSEC:n vaikutuksesta resolveripalvelimen palomuuraukseen myöhemmin tässä dokumentissa.

Luottamusankkuri

DNSSEC-validointi perustuu luottamusketjuihin, minkä vuoksi validoivalle nimipalvelimelle pitää konfiguroida ns. luottamusankkuri, joka toimii luottamusketjujen alkupisteenä. Luottamusankkuri on jonkun allekirjoitetun vyöhykkeen allekirjoitusavaimen julkinen osa (DNSKEY-tietue) tai siitä laskettu tiiviste (DS-tietue). Koska internetin juurivyöhyke on allekirjoitettu, on suositeltavaa konfiguroida juurivyöhykkeen julkinen avain tai sen tiiviste luottamusankkuriksi. Juuren luottamusankkurin voi hakea IANA:n verkkosivuilta ja ennen käyttöönottoa sen aitous tulisi todentaa jollain DNS(SEC):n ulkopuolisella mekanismilla, esimerkiksi PGP- luottamusverkostoja käyttäen. On myös hyvä varmistaa, että IANA:n sivuilta haettu luottamusankkuri vastaa nimipalvelusta löytyvää juurivyöhykkeen julkista avainta. Juuren DNSKEY-tietueen voi muuttaa DS-tiivisteeksi esimerkiksi LDNS-ohjelmistokirjastosta löytyvän ldns-key2ds -työkalun avulla (esim. "dig . dnskey > root.dnskey && ldns-key2ds -2 -n root.dnskey").

Tätä kirjoittaessa ei ole tiedossa, milloin juurivyöhykkeen julkinen avain tulee vaihtumaan, mutta ennemmin tai myöhemmin avain uusitaan. Tällöin myös validoivien resolvereiden luottamusankkurit pitää päivittää. RFC 5011:ssa on kuvattu mekanismi, jonka avulla validoiva resolveri voi päivittää luottamusankkurinsa automaattisesti. Koska vielä ei ole tiedossa, milloin ja erityisesti millä tavalla juurivyöhykkeen avain tullaan aikoinaan uusimaan ja miten edellä mainittu RFC5011-mekanismi käytännössä toimii, tulee juurivyöhykkeen avaimen vaihtumista valvoa myös muilla keinoin. On suositeltavaa rakentaa jonkinlainen valvontatyökalu, joka ilmoittaa validoivan resolverin ylläpitäjille, kun juurivyöhykkeen avain vaihtuu. Tällaisen työkalun voi toteuttaa yksinkertaisimmillaan cron-palvelussa ajettavana shell-skriptinä.

Palomuurit

DNSSEC-tietueet kasvattavat merkittävästi DNS-vastausten kokoa, minkä vuoksi ne eivät välttämättä mahdu enää alkuperäisessä DNS-standardissa määriteltyyn 512 tavuun. Nimipalvelimet signaloivat toisilleen kyvystään vastaanottaa 512 tavua suurempia UDP-vastausviestejä erityisen EDNS0-laajennuksen avulla. Jos resolveripalvelimen EDNS0-laajennuksen avulla signaloima UDP-vastauksen enimmäiskoko on suurempi kuin siirtotien MTU (Maximum Transmission Unit), auktoritatiivinen nimipalvelin joutuu lähettämään vastauksen fragmentoituna. Tämän vuoksi on tärkeää, että resolverin palomuuri on konfiguroitu sallimaan fragmentit.

...

Jos resolveripalvelimen edessä on palomuuri, on myös tärkeää varmistaa, ettei se suodata Path MTU Discoveryn (PMTUD) tarvitsemia ICMP-virheilmoituksia. Erityisen tärkeää tämä on IPv6:n osalta, sillä IPv6-reitittimet eivät tee pakettien fragmentointia vaan hylkäävät liian suuret paketit ja lähettävät lähettävälle koneelle ICMP-virheilmoituksen.

Valvonta

DNSSEC muuttaa nimipalvelun toimintaa merkittävällä tavalla ja voi tuoda mukanaan myös uudenlaisia ongelmia, minkä vuoksi on ensiarvoisen tärkeää valvoa DNSSEC:n toimintaa sekä sille keskeisiä osakokonaisuuksia. DNSSEC-validoinnin osalta ainakin seuraavia asioita olisi syytä valvoa:

...

Erityisen tärkeää on pystyä havaitsemaan nopeasti, mikäli validointivirheiden määrässä tapahtuu äkillinen merkittävä muutos. Validointivirheiden valvontaa toteutettaessa on syytä suunnitella tarkoin valvonnalle määriteltävät raja-arvot, jotta jatkuvat validointivirheet eivät aiheuta turhia hälytyksiä ja pahimmassa tapauksessa peitä alleen laajempia ongelmia. Funetin resolveripalvelun valvonnassa raja-arvot on asetettu siten, että valvonta hälyttää, kun validointivirheiden määrä ylittää 1/sekunti (normaalitilanteessa Funetin resolvereilla tapahtuu validointivirheitä muutama per minuutti).

Omien vyöhykkeiden DNSSEC-allekirjoittaminen

Allekirjoitusjärjestelmän arkkitehtuuri

Allekirjoitusjärjestelmä toteutetaan tyypillisesti siten, että allekirjoituspalvelin sijoitetaan loogisesti nimipalvelutietojen hallintajärjestelmän ja julkisten nimipalvelinten väliin. Allekirjoitusjärjestelmä on tällöin eräänlainen "bump in the wire" -tyyppinen komponentti, jolla ei ole mitään ulospäin julkiseen internetiin näkyviä rajapintoja. Käytännössä allekirjoitusjärjestelmä saa allekirjoittamattomat zone-tiedostot hallintajärjestelmältä esimerkiksi AXFR/IXRF-rajapintaa ("zone transfer") tai jotain muuta (esim. SSH/SCP) rajapintaa käyttäen, allekirjoittaa zone-tiedostot ja siirtää sen jälkeen allekirjoitetut versiot zone-tiedostoista julkisille nimipalvelimille esimerkiksi jotain edellä mainittua rajapintaa käyttäen. Jos nimipalvelutietojen hallintajärjestelmä tukee DNSSEC-allekirjoittamista, allekirjoittaminen voidaan toteuttaa myös sen avulla, mikä yksinkertaistaa järjestelmän kokonaisarkkitehtuuria huomattavasti. Sen sijaan julkisella nimipalvelimella allekirjoitustoiminnallisuutta ei ole järkevä toteuttaa, sillä tällöin yksityisten allekirjoitusavainten suojaaminen on haastavampaa kuin silloin, kun allekirjoittaminen ja avainten säilytys tapahtuu järjestelmässä, jolla ei ole ulospäin auki olevia rajapintoja.

...

Allekirjoitusjärjestelmän kahdentamisessa on muistettava varmistaa, että pää- ja vara-allekirjoituspalvelimella on aina samat avaimet käytettävissä. Jos avaimet on generoitu etukäteen, ne voidaan kopioida pääpalvelimelta varapalvelimelle järjestelmän käyttöönottovaiheessa, mutta jos avaimia generoidaan dynaamisesti tarpeen mukaan, on huolehdittava avainnipun synkronoinnista pääpalvelimelta varapalvelimelle. Avainten lisäksi myös vyöhykkeen allekirjoittamiseen liittyvä metatieto, joka sisältää mm. tiedon avainten uusimiseen liittyvistä ajoituksista, pitää olla synkronissa palvelinten välillä. Esimerkiksi OpenDNSSEC:ssa tämä tieto on ns. KASP-tietokannassa (Key and Signing Policy), joka on siis kahdennetuissa ympäristöissä pidettävä samansisältöisenä kummallakin palvelimella.

Allekirjoitusavaimet ja niiden hallinta

Koska DNSSEC perustuu julkisen avaimen kryptografiaan, on DNS-tietueiden allekirjoittamiseen käytettävän yksityisen avaimen luotettavuus koko järjestelmän perusta. Tämän vuoksi allekirjoitusjärjestelmää suunniteltaessa on syytä kiinnittää erityistä huomiota yksityisten avainten generointiin ja turvalliseen säilytykseen. Avainten generoinnissa eniten huomiota tulee kiinnittää siihen, että avaimet ovat mahdollisimman satunnaisia ja siten vaikeasti murrettavia. Avainten satunnaisuutta voidaan lisätä esimerkiksi käyttämällä erillistä ulkoista satunnaislukugeneraattoria, joita on saatavilla esimerkiksi USB-väylään kytkettävinä tikkuina. On myös mahdollista hyödyntää esimerkiksi uusimmista Intel-prosessoreista löytyvää RdRand-satunnaislukugeneraattoria, joka oleellisesti syöttää entropiaa käyttöjärjestelmän entropiavarastoon. Linux-palvelinten /dev/urandom -tiedostoa ei kannata käyttää entropialähteenä allekirjoitusavaimia generoitaessa, koska sen tuottamat satunnaisluvut eivät ole välttämättä riittävän satunnaisia.

...

Avainten uusiminen säännöllisin väliajoin pienentää niiden laskennallisen murtamisen todennäköisyyttä. Avainten uusimisen helpottamiseksi suositellaan käytettäväksi kahta eri avainparia: Key Signing Key -avaimella (KSK) allekirjoitetaan vain vyöhykkeen avaimet, kun taas Zone Signing Key:tä (ZSK) käytetään vyöhykkeen varsinaisten DNS-tietueiden allekirjoittamiseen. KSK-avaimen uusiminen edellyttää interaktiota delegoivan vyöhykkeen (parent-zone) kanssa, kun taas ZSK-avaimen voi uusia ilman toimenpiteitä delegoivan vyöhykkeen suuntaan. ZSK-avaimen uusiminen kannattaakin ehdottomasti jättää allekirjoitusohjelmiston tehtäväksi. Päivitysintervalliksi riittää ZSK-avaimen osalta esimerkiksi 4 kertaa vuodessa. KSK-avaimen uusimisessa on kahta koulukuntaa: joidenkin mielestä KSK-avainta ei kannata uusia kuin allekirjoitusjärjestelmää/algoritmia tms. uusittaessa, kun taas osa perustelee KSK-avaimen uusimista sillä, että vain tällä tavalla uusimisprosessi pysyy mielessä ja tulee säännöllisesti harjoiteltua. Jos KSK-avainta halutaan uusia säännöllisesti, 1-2 vuoden intervallia on yleensä pidetty sopivana. Jos KSK-avainta ei haluta uusia säännöllisesti, voi olla järkevä käyttää vahvempaa, esimerkiksi 4096-bittistä avainta.

Parametrien valinta

RFC6781:ssa ja RFC-draftissa draft-ietf-dnsop-dnssec-key-timing on annettu hyviä suosituksia DNSSEC:iin liittyvien allekirjoitus- ja aikaparametrien valintaan. DNSSEC-allekirjoitusjärjestelmän pystyttämistä suunnittelevan kannattaa perehtyä edellä mainittuihin dokumentteihin, mutta tässä kappaleessa korostetaan muutamia keskeisimpiä hyväksi havaittuja ohjenuoria ja huomioitavia asioita.

...

DNSSEC mahdollistaa myös negatiivisten vastausten todentamisen, eli käytännössä tiedon siitä että jotain kysyttyä nimeä tai tietuetta ei ole olemassa. Tämä tapahtuu erityisten NSEC-tietueiden avulla. NSEC-tietueilla on kuitenkin sellainen negatiivinen sivuvaikutus, että ne mahdollistavat vyöhykkeen kaikkien tietojen listaamisen triviaalisti. Vaikka nimipalvelussa oleva tieto on lähtökohtaisesti julkista, voi vyöhykkeen kaikkien tietojen listaamisen mahdollisuus olla joissain tilanteissa haitallista. Tämän vuoksi kannattaa käyttää NSEC:n sijaan NSEC3-tietueita. Poikkeuksena sellaiset vyöhykkeet, joissa on vain muutama julkinen tietue (esim. pelkkä www-tietue tai CNAME); näiden osalta NSEC3:n käyttäminen ei tuo juurikaan lisäarvoa NSEC:iin verrattuna. NSEC3:ssa on myös ns. OptOut-ominaisuus, mutta se on merkityksellinen lähinnä vain suurissa, pääasiassa delegointeja sisältävissä vyöhykkeissä. Tyypillisen toisen tason vyöhykkeen (esim. funet.fi) allekirjoittamisessa OptOut:n käyttäminen ei ole tarpeen.

DS-tietueiden päivitys

Jotta allekirjoitettu vyöhyke voidaan DNSSEC-validoida, vyöhykkeen KSK-avainta vastaava DS-tietue täytyy julkaista delegoivassa vyöhykkeessä ja allekirjoittaa delegoivan vyöhykkeen (ZSK-)avaimella. FI-päätteisten domainien osalta DS-tietue pitää siis julkaista fi.-juuressa, mikä tapahtuu Viestintäviraston verkkotunnusjärjestelmän kautta. Palveluntarjoajille on saatavilla Web Service -rajapinta tietojen päivittämisen automatisointia varten, mutta muiden on päivitettävä DS-tietueet manuaalisesti web-käyttöliittymän kautta. Koska tämä pitää tehdä kuitenkin vain käyttöönottovaiheessa ja KSK-avaimen uusimisen yhteydessä, ei tämän pitäisi aiheuttaa kohtuuttomasti lisävaivaa.

Käänteisvyöhykkeiden (reverse) osalta delegoiva vyöhyke on tyypillisesti Funetin ylläpidossa oleva vyöhyke, poislukien PA- tai legacy-osoiteavaruudet, joita vastaavan käänteisvyöhykkeen delegoiva vyöhyke on yleensä suoraan jonkun alueellisen osoiterekisterin (RIR, esim. RIPE tai Arin) ylläpidossa oleva käänteisvyöhyke. Funetin käänteisvyöhykkeitä ei ole vielä (lokakuussa 2013) allekirjoitettu, minkä vuoksi myös mahdollinen rajapinta DS-tietueiden päivittämistä varten puuttuu. Jos delegoiva vyöhyke on suoraan esim. jonkun RIR:n ylläpidossa, DS-tietueiden päivittäminen tapahtuu kyseisen RIR:n tarjoamien rajapintojen kautta. Esimerkiksi RIPE:n osalta DS-tietueita voi päivittää Webupdates-rajapinnan tai automaattisen sähköpostirajapinnan kautta. 

Valvonta

Jos valvonta on tärkeää DNSSEC-validoinnin osalta, se on jopa vielä tärkeämpää allekirjoitettujen vyöhykkeiden saatavuuden varmistamiseksi. DNSSEC-allekirjoitetun vyöhykkeen osalta tulisi valvoa ainakin seuraavia asioita:

...

On myös tärkeää tehdä muutamia tarkistuksia vyöhykkeen allekirjoittamisen jälkeen ennen sen päivittämistä julkisille nimipalvelimille. Erityisesti kannattaa tarkistaa, että allekirjoitetun vyöhykkeen tietueet validoituvat vyöhykkeen omia avaimia vasten (self-validation) ja että vyöhykkeen avaimet on allekirjoitettu KSK-avaimella, jota vastaava DS-tietue löytyy delegoivasta vyöhykkeestä. Esimerkiksi OpenDNSSEC:ssa tällaiset tarkistukset pystyy toteuttamaan melko suoraviivaisesti määrittelemällä konfiguraatioon NotifyCommand-optio, jonka avulla voidaan liipaista haluttu tarkistusskripti. Edellä mainittujen tarkistusten lisäksi tai osittain niiden toteuttamiseen voidaan käyttää myös valmiita saatavilla olevia työkaluja, kuten ValiDNS:aa.

Aiheeseen liittyviä RFC-dokumentteja

RFC 4033: DNS Security Introduction and Requirements

...

RFC 6891, Extension Mechanisms for DNS (EDNS(0))

 

Linkkejä DNSSEC testaustyökaluihin

https://www.dns-oarc.net/oarc/services/replysizetest

...