DNSSEC

Kokeneet kirjoittajat eivät ole vielä tarkistaneet sivun nykyistä versiota, ja se voi poiketa merkittävästi 16. heinäkuuta 2021 tarkistetusta versiosta . tarkastukset vaativat 5 muokkausta .

DNSSEC ( Eng.  Domain Name System Security Extensions ) on joukko IETF -laajennuksia DNS - protokollalle , jonka avulla voit minimoida IP-osoitteiden huijaamiseen liittyvät hyökkäykset toimialuenimiä selvitettäessä . Sen tarkoituksena on tarjota DNS-asiakkaille (englanninkielisten termien ratkaiseja) aitoja vastauksia DNS-kyselyihin (tai autenttista tietoa puuttuvien tietojen tosiasiasta) ja varmistaa niiden eheys. Se käyttää julkisen avaimen salausta. Tietojen saatavuutta ja pyyntöjen luottamuksellisuutta ei taata. DNS-suojauksen varmistaminen on ratkaisevan tärkeää yleisen Internet-turvallisuuden kannalta.

Kuvaus

Alun perin DNS ( Domain Name System ) -järjestelmää ei kehitetty turvallisuustarkoituksiin, vaan skaalautuvien hajautettujen järjestelmien luomiseen. Ajan myötä DNS-järjestelmästä tulee entistä haavoittuvampi. Hyökkääjät ohjaavat helposti käyttäjien pyynnöt symbolisilla nimillä valepalvelimille ja pääsevät siten käsiksi salasanoihin, luottokorttien numeroihin ja muihin luottamuksellisiin tietoihin. Käyttäjät itse eivät voi tehdä asialle mitään, koska useimmissa tapauksissa he eivät edes epäile, että pyyntö on uudelleenohjattu - selainrivin merkintä ja itse sivusto ovat täsmälleen samat kuin käyttäjä odottaa näkevänsä ne. DNSSEC on yritys suojata samalla kun se on taaksepäin yhteensopiva.

DNSSEC on suunniteltu suojaamaan asiakkaita väärennetyiltä DNS-tiedoilta, kuten DNS-välimuistin myrkytyksen aiheuttamilta tiedoilta . Kaikki DNSSEC:n vastaukset on digitaalisesti allekirjoitettu. Kun digitaalista allekirjoitusta varmennetaan, DNS-asiakas varmistaa tietojen oikeellisuuden ja eheyden.

DNSSEC ei salaa tai muuta tiedonhallintaa, ja se on yhteensopiva nykyisen DNS-järjestelmän ja sovellusten aiempien versioiden kanssa. DNSSEC voi myös varmentaa DNS CERT - tietueeseen tallennettuja tietoja , kuten yleiskäyttöisiä salausvarmenteita . RFC 4398 kuvaa näiden sertifikaattien jakamista, myös sähköpostitse, mikä mahdollistaa DNSSEC:n käytön maailmanlaajuisesti jaettuna allekirjoitusavainvarmenteiden varastona.

DNSSEC ei tarjoa tietosuojaa; erityisesti kaikki DNSSEC-vastaukset on todennettu mutta ei salattu. DNSSEC ei suojaa suoraan DoS -hyökkäyksiltä, ​​vaikka se suojaa jollakin tavalla epäsuorasti. Muita standardeja (ei-DNSSEC) käytetään tarjoamaan suuri määrä dataa, joka lähetetään DNS-palvelimien välillä.

DNSSEC-spesifikaatio ( DNSSEC-bis ) kertoo nykyisen DNSSEC-protokollan. Katso RFC 4033 , RFC 4034 ja RFC 4035 .

Historia

Aluksi verkkotunnusjärjestelmässä ei ollut mekanismeja, jotka suojelisivat palvelinvastauksen tietojen korvaamista, koska sen kehityshetkellä (1980-luvun alussa) nykyaikaisen Internetin turvallisuusuhat eivät olleet merkityksellisiä. Samaan aikaan asiakkaat arvioivat saamansa tiedon oikeellisuuden pelkästään kaksitavuisen pyyntötunnisteen perusteella. Siten hyökkääjän piti iteroida yli 65536 arvoa "myrkyttääkseen välimuistin". Tämä tarkoitti, että DNS-järjestelmän tiedot ovat vioittuneet (tahallisesti tai virheen vuoksi), ja DNS-palvelin tallentaa ne välimuistiin suorituskyvyn optimoimiseksi (välimuistista tulee "myrkytys") ja alkaa palvella näitä ei-aitoja tietoja asiakkailleen. Vuonna 1990 Steve Bellovin tunnisti  vakavia tietoturvapuutteita . Tämän alan tutkimus on alkanut ja se on ollut täydessä vauhdissa raportin julkaisemisesta vuonna 1995 [1] .

IETF julkaisi DNSSEC RFC 2065 :n ensimmäisen painoksen vuonna 1997. Yritykset toteuttaa tämä spesifikaatio johtivat uuteen spesifikaatioon RFC 2535 vuonna 1999. Suunnitelmissa oli ottaa DNSSEC käyttöön IETF RFC 2535 :n pohjalta .

Valitettavasti IETF RFC 2535 -spesifikaatiossa oli vakavia ongelmia koko Internetin skaalauksessa. Vuoteen 2001 mennessä kävi selväksi, että tämä eritelmä ei sovellu suuriin verkkoihin. Normaalin toiminnan aikana DNS-palvelimet eivät usein olleet synkronoituja vanhempiensa kanssa (hierarkian ylemmät toimialueet). Tämä ei yleensä ollut ongelma, mutta kun DNSSEC on käytössä, synkronoiduilla tiedoilla voi olla tahaton DoS-vaikutus. Suojattu DNS on paljon laskentaintensiivisempi, ja helpommin kuin "klassinen" DNS, se voi viedä kaikki laskentaresurssit.

DNSSEC:n ensimmäinen versio vaati kuuden viestin viestintää ja suuren määrän dataa muutosten toteuttamiseksi lapselle (kaikki lapsen DNS-vyöhykkeet on siirrettävä kokonaan vanhemmalle, vanhempi tekee muutokset ja lähettää ne takaisin lapselle ). Lisäksi julkisen avaimen muutoksilla voi olla tuhoisa vaikutus. Jos esimerkiksi ".com"-vyöhyke vaihtaisi avaimensa, 22 miljoonaa tietuetta olisi lähetettävä (koska kaikki seuraajien kaikki tietueet oli päivitettävä). Näin ollen RFC 2535 :n muodossa olevaa DNSSEC: tä ei voitu skaalata Internetin kokoon.

Nämä monimutkaisuudet puolestaan ​​johtivat uusien spesifikaatioiden ( RFC 4033 , RFC 4034 , RFC 4035 ) syntymiseen DNSSEC:n (DNSSEC-bis) perustavanlaatuisilla muutoksilla, joiden uusi versio poisti edellisen toteutuksen pääongelman ja vaikka uudessa määrittelyssä asiakkaiden on tehtävä lisätoimenpiteitä avainten tarkistamiseksi, se osoittautui varsin sopivaksi käytännön käyttöön.

Vuonna 2005 ilmestyi nykyinen DNSSEC-versio, jonka kanssa kaikki työskentelevät. Merkittävä tapahtuma tapahtui vuonna 2008, kun Dan Kaminsky osoitti maailmalle, että kätkö voidaan myrkyttää 10 sekunnissa. DNS-ohjelmistotoimittajat ovat vastanneet valitsemalla satunnaisesti kyselyn lähtevän portin kyselytunnuksen lisäksi. Matkan varrella alkoi kiistaa DNSSEC:n käyttöönotosta.

DNSSEC-muutos, nimeltään DNSSEC-bis (nimi annettiin erottamaan DNSSEC-bis alkuperäisestä DNSSEC-lähestymistavasta RFC 2535 :ssä ) käyttää DS-periaatetta ( delegation signer )  tarjotakseen lisäkerroksen epäsuoraa delegointia siirrettäessä vyöhykkeitä vanhemmalta lapselle. . Uudessa lähestymistavassa julkista avainta vaihdettaessa päätoimialueen ylläpitäjälle lähetetään vain yksi tai kaksi viestiä kuuden sijaan: perillinen lähettää tiivistelmän (sormenjälki, hash) uudesta julkisesta avaimesta vanhemmalle. Vanhempi yksinkertaisesti tallentaa jokaisen lapsen julkisen avaimen tunnisteen. Tämä tarkoittaa, että vanhemmalle lähetetään hyvin pieni määrä dataa sen sijaan, että lapsen ja vanhemman välillä vaihdettaisiin valtava määrä dataa.

DNS-tietojen allekirjoittaminen ja vahvistaminen luo ylimääräisiä lisäkustannuksia, mikä vaikuttaa negatiivisesti verkon ja palvelimen suorituskykyyn. Esimerkiksi DNSSEC-vyöhyke (joukko tietyn tason verkkotunnuksia, jotka sisältyvät tiettyyn toimialueeseen) on keskimäärin 7-10 kertaa suurempi kuin itse DNS-järjestelmä. Allekirjoitusten luominen ja tarkistaminen kuluttaa huomattavasti CPU-aikaa. Allekirjoitukset ja avaimet vievät suuruusluokkaa enemmän tilaa levyltä ja RAM-muistista kuin itse tiedot.

Kuinka se toimii

DNSSEC:n toimintaperiaate perustuu digitaalisten allekirjoitusten käyttöön . Järjestelmänvalvojalla on tietue verkkotunnuksen ja IP-osoitteen vastaavuudesta. DNSSEC asettaa jokaisen niistä tiukasti erityiseen, tiukasti määritellyn merkkijonon, joka on digitaalinen allekirjoitus, mukaisesti. Digitaalisen allekirjoituksen pääominaisuus on, että allekirjoituksen aitouden varmentamiseen on olemassa avoimia, julkisesti saatavilla olevia menetelmiä, mutta allekirjoituksen luominen mielivaltaisille tiedoille edellyttää allekirjoituksen salaisen avaimen olevan saatavilla. Siksi jokainen järjestelmän osallistuja voi tarkistaa allekirjoituksen, mutta käytännössä vain se, jolla on salainen avain, voi allekirjoittaa uuden tai muuttuneen tiedon.

Teoriassa mikään ei estä hakkeria laskemasta salaista avainta ja poimimasta allekirjoitusta, mutta käytännössä riittävän monimutkaisen ja pitkän avaimen kohdalla tällaista toimintoa ei voida suorittaa kohtuullisessa ajassa olemassa olevilla laskentatyökaluilla ja matemaattisilla algoritmeilla.

Digitaalisen allekirjoituksen laskeminen ei ole vaikeaa salaisella avaimella. Tällainen on epäsymmetristen julkisen avaimen salausjärjestelmien työ, jotka ovat digitaalisten allekirjoitusten algoritmien taustalla.

Oletetaan, että käyttäjä siirtyy wikipedia.org-sivustolle. Seuraavaa tapahtuu:

  1. Käyttäjä pyytää verkkotunnusta ratkaisijalta;
  2. Ratkaisija pyytää wikipedia.org-osoitetta DNS-palvelimelta (esimerkiksi paikallisten palvelimien välimuistissa ei ollut tietoa toimialueesta ja pyyntö saapui palveluntarjoajan palvelimelle);
  3. Jos palveluntarjoajan palvelimien välimuistissa ei ole tietoa, pyyntö ohjataan juuripalvelimelle, asetetaan myös DO-bitti, joka ilmoittaa, että DNSSEC on käytössä;
  4. Juuripalvelin ilmoittaa, että abcnet-palvelin on vastuussa organisaatiovyöhykkeestä. Palvelin lähettää sitten joukon NS-tietueita org-vyöhykkeelle, KSK-tiivisteet org-vyöhykkeelle (DS-tietueet) ja allekirjoituksen (RRSIG-tietue) NS- ja DS-tietueista;
  5. Ratkaisija vahvistaa vastaanotetun ZSK:n varmistamalla, että juurivyöhykkeen KSK:n tekemä allekirjoitus täsmää. Ratkaisija varmistaa sitten RRSIG-tietueen sisältämien juurialueen DS-tietueiden digitaalisen allekirjoituksen. Jos kaikki on oikein, palvelin luottaa vastaanotettuihin tiivistelmiin ja tarkistaa heidän avullaan alemman tason - organisaatiovyöhykkeen - DNSKEY-tietueen allekirjoituksen;
  6. Nyt saatuaan organisaatiovyöhykkeestä vastaavan palvelimen osoitteen (server abcnet), ratkaiseja välittää saman pyynnön sille;
  7. Abcnet-palvelin ilmoittaa, että wikipedia.org-vyöhykkeestä vastaavalla palvelimella on osoite d.org. Se lähettää myös organisaatiovyöhykkeen allekirjoitusavainjoukon (ZSK), joka on allekirjoitettu organisaatiovyöhykkeen yksityisellä KSK:lla, ja wikipedia.org-vyöhykkeen KSK-tiivistelmän, joka on allekirjoitettu organisaatioalueen ZSK:lla;
  8. Ratkaisija vertaa juuripalvelimelta saatua tiivistettä siihen, mitä se on itse laskenut abcnet-palvelimelta saadusta organisaatiovyöhykkeen KSK:sta, ja jos se täsmää, se alkaa luottaa tähän KSK:han. Tämän jälkeen ratkaisija tarkistaa organisaatiovyöhykkeen avainten allekirjoitukset ja alkaa luottaa organisaatiovyöhykkeen ZSK:han. Ratkaisija tarkistaa sitten wikipedia.org-vyöhykkeen KSK:n. Kaikkien näiden tarkistusten jälkeen ratkaisijalla on wikipedia.org-vyöhykkeen KSK:n tiivistelmä (DS) ja sen d.org-palvelimen osoite, johon wikipedia.org-vyöhykkeen tiedot on tallennettu;
  9. Lopuksi ratkaiseja kutsuu wikipedia.org-sivuston d.org-palvelinta ja asettaa siten jonkin verran, että se käyttää DNSSEC:tä.
  10. D.org-palvelin ymmärtää, että wikipedia.org-vyöhyke on päällä ja lähettää ratkaisejalle vastauksen, joka sisältää wikipedia.org-vyöhykkeen allekirjoitusavainjoukon (ZSK), joka on allekirjoitettu wikipedia.org-vyöhykkeellä KSK ja osoitteen, joka on allekirjoitettu wikipedialla. org-vyöhyke ZSK-sivusto wikipedia.org;
  11. Lisäksi, kuten kohdassa 7, ratkaisija tarkistaa wikipedia.org-vyöhykkeen KSK:n, wikipedia.org-vyöhykkeen ZSK:n ja wikipedia.org-sivuston osoitteen;
  12. Jos tarkistus kohdassa 10 onnistuu, ratkaiseja palauttaa käyttäjälle vastauksen, joka sisältää wikipedia.org-sivuston osoitteen ja vahvistuksen, että vastaus on varmistettu (AD-bittisarja).

Jos jotain ei voida vahvistaa, ratkaiseja palauttaa servfail-virheen.

Näin muodostettu luottamusketju pelkistyy juuriverkkotunnukseen ja juurivyöhykeavaimeen.

Delegation of Signing ( DS ) -tietue sisältää hajautusarvon perillisen verkkotunnuksesta ja sen KSK:sta. DNSKEY -tietue sisältää avaimen julkisen osan ja sen tunnisteet (käytetty tunnus, tyyppi ja hash-funktio).

KSK (Key Signing Key) tarkoittaa Key Signing Key (Long-Term Key) ja ZSK (Zone Signing Key) tarkoittaa Zone Signing Key (Long-Term Key). KSK:n avulla varmistetaan ZSK, jota käytetään juurivyöhykkeen allekirjoittamiseen. Root Zone ZSK:n on luonut PTI ( ICANNin IANA - toiminnallinen jaosto ), joka on teknisesti vastuussa DNS-juurivyöhykkeen levittämisestä. ICANNin menettelyn mukaisesti Root Zone ZSK päivitetään neljä kertaa vuodessa.

Juurivyöhykkeen allekirjoitus

Jotta kaikki DNSSEC:n avulla siirretyt tiedot voidaan täysin todentaa, DNS:n juurivyöhykkeeltä (.) vaaditaan luottamusketju. Oikein allekirjoitetun juurivyöhykkeen käyttöönotto kaikilla DNS-juuripalvelimilla voi aiheuttaa nykyaikaisen Internetin romahtamisen, joten IETF teki yhteistyötä ICANNin kanssa vaiheittaisen menettelyn toteuttamiseksi allekirjoitetun juurivyöhykkeen ja avainten jakelumekanismin toteuttamiseksi . Toimenpide kesti yli 8 kuukautta, ja se sisälsi vaiheittaisen johdannon DNS-palvelimiin juurivyöhykkeestä ensimmäisenä, allekirjoitettuna virheellisellä sähköisellä allekirjoitusavaimella . Tämä vaihe oli tarpeen palvelimien testaamiseksi kuormitettuina, taaksepäin yhteensopivuuden säilyttämiseksi vanhempien ohjelmistojen kanssa ja mahdollisuuden palauttaa aikaisempaan kokoonpanoon.

Kesäkuuhun 2010 mennessä kaikki juuripalvelimet toimivat oikein vyöhykkeellä, joka oli allekirjoitettu virheellisellä avaimella. Heinäkuussa ICANN järjesti kansainvälisen konferenssin, jossa käsiteltiin sähköisten allekirjoitusten avainten luomismenettelyä, jonka juurivyöhyke allekirjoitti myöhemmin.

15.7.2010 juurivyöhykkeen allekirjoitus tapahtui ja allekirjoitetun vyöhykkeen käyttöönotto palvelimilla aloitettiin. 28. heinäkuuta ICANN ilmoitti [2] saaneensa tämän prosessin päätökseen. Juurivyöhyke allekirjoitettiin digitaalisesti ja levitettiin DNS-järjestelmässä.

31. maaliskuuta 2011 allekirjoitettiin Internetin suurin vyöhyke (90 miljoonaa verkkotunnusta) - .com [3] .

Avaininfrastruktuuri

ICANN on valinnut mallin, jossa vyöhykkeen allekirjoittaminen hoidetaan Internet-yhteisön edustajien (Trusted Community képviselő, TCR) valvonnassa. Edustajat valittiin niiden joukosta, jotka eivät liittyneet DNS-juurialueen hallintaan. Valitut edustajat toimivat Crypto Officers (CO) ja Recovery key shareholders (RKSH). CO:ille annettiin fyysiset avaimet ZSK EDS -avaimen luomista varten, ja RKSH:illa on hallussaan älykortit, jotka sisältävät salauslaitteiston sisällä käytetyn avaimen (KSK) osia. Eräät tiedotusvälineet ovat tulleet siihen johtopäätökseen, että CO:n tai RKSH:n läsnäoloa edellyttäviä toimenpiteitä suoritetaan verkon hätätilanteissa [4] . ICANNin menettelyjen mukaisesti CO:t ovat kuitenkin mukana joka kerta, kun ZSK-avain luodaan, jopa 4 kertaa vuodessa, ja RKSH ei todennäköisesti koskaan tai jos CO-avaimet katoavat tai juurivyöhyke on vaarantunut. [5] .

Nykyinen tila

Lokakuusta 2013 lähtien juurivyöhykkeellä on 81 ccTLD:tä ja 13 yleistä DNSSEC-allekirjoitettua verkkotunnusta (ilman IDN:itä) , mikä tarjoaa luottamusketjun toisen tason verkkotunnuksille. Vuonna 2011 DNSSEC:n (NSEC3 opt-out) avulla allekirjoitettiin Venäjään liittyvä .su -vyöhyke ja lokakuun 2012 lopussa aloitettiin siinä käyttäjien luomien DS-tietueiden julkaiseminen. [6] Vuoden 2012 lopussa allekirjoitettiin venäläinen verkkotunnus .ru ja sen DS-tietueet julkaistiin juurivyöhykkeellä [7] .

Juurivyöhykkeen KSK:n muuttaminen

11. lokakuuta 2018 tapahtui ensimmäinen Root Zone KSK -kierto sitten Root Zone Signingin vuonna 2010. Alunperin lokakuulle 2017 suunniteltu avainten kierto viivästyi ICANNin toimesta, kun kävi selväksi, että huomattava määrä (noin 2 %) ratkaisijoita oli käyttämällä samaa avainta DNSSEC-allekirjoitusketjun validointiin. Vuoden aikana otettiin käyttöön joitakin teknisiä ratkaisuja Bind-, PowerDNS-, Knot- ja muihin DNS-palvelinpaketteihin, toteutettiin laaja kampanja tiedottaakseen suurelle yleisölle avainten vaihdosta ja sen seurauksena syyskuussa 2018 ICANN Hallitus päätti ottaa käyttöön avainkierron. Avainten vaihdossa ei ollut merkittäviä ongelmia.

Käyttöönoton ongelmat ja puutteet

DNSSEC:n käyttöönotto on viivästynyt huomattavasti seuraavista syistä:

  1. Taaksepäin yhteensopivan standardin kehittäminen, joka voidaan skaalata Internetin kokoon;
  2. Keskeisten toimijoiden väliset erimielisyydet siitä, kenen pitäisi omistaa huipputason verkkotunnuksia (.com, .net);
  3. DNS-palvelimien ja asiakkaiden on tuettava DNSSEC:tä;
  4. Päivitettyjen DNS-ratkaisujen, jotka voivat toimia DNSSEC:n kanssa, on käytettävä TCP:tä.
  5. Jokaisen asiakkaan on hankittava vähintään yksi luotettava julkinen avain, ennen kuin se voi aloittaa DNSSEC:n käytön.
  6. Lisääntynyt verkon kuormitus pyyntöjen vakavan (6-7 kertaa) lisääntyneen liikenteen vuoksi;
  7. Palvelimen prosessorin lisääntynyt kuormitus allekirjoitusten luomisen ja tarkistamisen vuoksi, joten jotkin alitehoiset DNS-palvelimet on ehkä vaihdettava;
  8. Lisääntyneet tallennusvaatimukset tietojen käsittelemiselle allekirjoitetuiksi tiedoiksi vie paljon enemmän tilaa;
  9. Sekä palvelin- että asiakasosien ohjelmistoja on luotava, testattava ja jalostettava, mikä vaatii aikaa ja testausta koko Internetin mittakaavassa;
  10. Stub-selvittäjät eivät ole suojattuja välimuistin myrkytykseltä - validointi tapahtuu rekursiivisen palvelimen puolella, asiakas saa vain vastauksen AD-bittiasetuksilla;
  11. DNS-vahvistushyökkäyksen vaara on kasvanut jyrkästi.

Suurin osa näistä ongelmista on ratkaistu teknisen Internet-yhteisön toimesta.

DNSSEC-ohjelmisto

Palvelinpuoli

Kaksi yleisintä DNS-palvelintoteutusta, BIND ja NSD  , tukevat DNSSEC:iä (10 juuripalvelimesta 13:sta käyttää BIND:tä, loput 3 NSD:tä). Tukea on myös PowerDNS- , Unbound- ja eräille muille DNS-palvelimille.

Asiakaspuoli

Koska DNSSEC-laajennusta käyttäviä palvelimia oli hyvin vähän, myös DNSSEC-tuella varustettuja loppukäyttäjäohjelmistoja luotiin hyvin vähän. Microsoftin käyttöjärjestelmissä on kuitenkin jo integroitu DNSSEC. Windows Server 2008  - RFC 2535 , Windows 7 ja Windows Server 2008 R2 - DNSSEC - bis:n nykyinen versio.

Windows XP ja Windows Server 2003 tukevat RFC 2535 :tä , mutta ne pystyvät tunnistamaan vain DNSSEC-palvelimien paketit, joten niiden ominaisuudet päättyvät tähän.

Erityisesti mainitaan DNSSEC-Tools- projekti , joka on joukko sovelluksia, lisäosia ja laajennuksia, joiden avulla voit lisätä DNSSEC-tuen Firefox -selaimeen, Thunderbird - sähköpostiohjelmaan , proftpd- , ncftp- FTP - palvelimiin ja joihinkin muihin sovelluksiin. [8] .

DNSSEC:n käyttö vaatii ohjelmiston sekä palvelin- että asiakaspuolella.

Muistiinpanot

  1. ↑ "Domainnimijärjestelmän käyttäminen järjestelmän murtautumiseen" Arkistoitu 26. helmikuuta 2008 Wayback Machinessa , kirjoittanut Steve Bellovin , 1995   (linkki ei ole käytettävissä)
  2. ↑ DNSSEC Root Signing Announcement . Haettu 30. heinäkuuta 2010. Arkistoitu alkuperäisestä 7. elokuuta 2010.
  3. ↑ Suojauslaajennusten käyttöönotto .comin ylätason verkkotunnuksessa
  4. ↑ Kuusi ohjelmoijaa jakoi "avaimet Internetin uudelleenkäynnistämiseksi" . Haettu 5. lokakuuta 2010. Arkistoitu alkuperäisestä 23. elokuuta 2010.
  5. ↑ DNSSEC juurivyöhykkeelle . Haettu 5. lokakuuta 2010. Arkistoitu alkuperäisestä 28. lokakuuta 2011.
  6. ↑ DNSSEC RU-CENTERissä (linkki ei saatavilla) . Haettu 5. marraskuuta 2012. Arkistoitu alkuperäisestä 8. marraskuuta 2012. 
  7. ↑ Kaavio .RU:n ja .РФ:n allekirjoitettujen verkkotunnusten määrästä . Haettu 24. maaliskuuta 2013. Arkistoitu alkuperäisestä 10. kesäkuuta 2015.
  8. ↑ DNSSEC-laajennus DNS:ään turvallisuuden parantamiseksi . Käyttöpäivä: 31. maaliskuuta 2013. Arkistoitu alkuperäisestä 24. maaliskuuta 2013.
  9. ↑ DNSSEC Windows Serverissä . Haettu 17. marraskuuta 2009. Arkistoitu alkuperäisestä 29. heinäkuuta 2016.

Linkit

RFC:t