Sarjanumeron muutoksetEdit
Vyöhykkeen siirron johdanto-osa perustuu sarjanumeroon ja vain sarjanumeroon sen määrittämiseksi, ovatko vyöhykkeen tiedot muuttuneet ja tarvitaanko varsinaista tiedonsiirtoa. Joidenkin DNS-palvelinpakettien osalta ylläpitäjät ylläpitävät SOA-resurssitietueiden sarjanumeroita käsin. Jokaisessa tietokannan muokkauksessa tehdään kaksi muutosta, toinen muutettavaan tietueeseen ja toinen vyöhykkeen sarjanumeroon. Prosessi vaatii tarkkuutta: ylläpitäjä saattaa unohtaa muuttaa sarjanumeron tai muuttaa sen väärin (pienentää sitä). RFC 1912 (kohta 2.2 SOA-tietueet) suosittelee käyttämään numerona arvoa YYYYMMDDnn (YYYY=vuosi, MM=kuukausi, DD=päivä, nn=revision numero). Tämä ei ylity ennen vuotta 4294.
Jotkut DNS-palvelinpaketit ovat ratkaisseet tämän ongelman rakentamalla sarjanumeron automaattisesti levyllä olevan tietokantatiedoston viimeisimmän muutoksen aikaleimasta. Näin on esimerkiksi djbdns:ssä. Käyttöjärjestelmä varmistaa, että viimeisimmän muutoksen aikaleima päivitetään aina, kun järjestelmänvalvoja muokkaa tietokantatiedostoa, jolloin sarjanumero päivittyy automaattisesti ja järjestelmänvalvojien ei tarvitse tehdä kahta muokkausta (kahdessa eri paikassa) jokaista yksittäistä muutosta varten.
Tietokantojen replikoinnin malli, jota varten sarjanumeron tarkistus (ja itse vyöhykkeensiirto) on suunniteltu, eli se, että yksi keskitetty DNS-palvelin pitää hallussaan tietokannan ensisijaista versiota ja muut DNS-palvelimet pitävät hallussaan pelkkiä tietokantakopioita, ei yksinkertaisesti sovi yhteen monien nykyaikaisten DNS-palvelinpalvelinpakettien malliin. Nykyaikaiset DNS-palvelinpaketit, joissa on kehittyneitä tietokantoja, kuten SQL-palvelimet ja Active Directory, mahdollistavat sen, että ylläpitäjät voivat tehdä päivityksiä tietokantaan useissa eri paikoissa (tällaiset järjestelmät käyttävät usean pääkäyttäjän replikointia), ja tietokannan oma replikointimekanismi huolehtii replikoinnista kaikille muille palvelimille. Tämä paradigma ei yksinkertaisesti sovi yhteen ainoaan, keskitettyyn, monotonisesti kasvavaan numeroon, johon muutokset kirjataan, ja on siten suurelta osin yhteensopimaton vyöhykesiirron kanssa. Nykyaikaiset DNS-palvelinpaketit, joissa on kehittyneet tietokantapohjat, luovat usein ”shim”-sarjanumeron, joka simuloi yhden keskitetyn paikan olemassaoloa, jossa päivitykset tehdään, mutta tämä on parhaimmillaankin epätäydellistä.
Tästä ja useista myöhemmin esitetyistä syistä johtuen DNS-palvelimet, jotka käyttävät tällaisia kehittyneitä tietokantojen taustapäätteitä, käyttävät yleensä harvoin vyöhykesiirtoa tietokantareplikointimekanismina, ja käyttävät sen sijaan yleensä huomattavasti parempia hajautettuja tietokantareplikointimekanismeja, joita taustapäätteet itse tarjoavat.
Sarjanumerovertailut Muokkaa
Sarjanumerovertailuissa käytetään RFC 1982:n määrittelemää sarjanumeroaritmetiikkaa. Tätä ei kuitenkaan määritelty selkeästi RFC 1034:ssä, minkä vuoksi kaikki asiakkaat eivät suorita sarjanumeron tarkistusta johdanto-osassa samalla tavalla. Jotkin asiakkaat tarkistavat vain, että palvelimen antama sarjanumero poikkeaa asiakkaan tiedossa olevasta sarjanumerosta tai on nollasta poikkeava. Toiset asiakkaat tarkistavat, että palvelimen antama sarjanumero on tietyllä alueella asiakkaan jo tunteman sarjanumeron sisällä. Toiset asiakkaat tekevät vielä jälkimmäisen tarkistuksen ja tarkistavat lisäksi, että palvelimen antama sarjanumero ei ole nolla.
Useita resurssitietueita Muokkaa
Alun perin varsinaisessa tiedonsiirrossa kukin yhden verkkotunnuksen ja -tyypin resurssitietueiden sarja siirrettiin erillisessä vastaussanomassa palvelimelta asiakkaalle. Tämä on kuitenkin tehotonta, ja joissakin DNS-palvelinohjelmistoissa on toteutettu optimointeja, joiden tarkoituksena on mahdollistaa DNS-protokollan vastauksen pakkausmekanismin avulla tiedonsiirron kokonaiskaistanleveysvaatimusten vähentäminen, esim:
- suorittaa ”lisäosioiden käsittelyä” sisällyttääkseen kaikki ”liimaavat” resurssitietueet samaan vastaukseen NS-, SRV- tai MX-resurssitietueiden kanssa
- kerätä kaikki yhteen verkkotunnukseen liittyvät resurssitietueet yhteen ja lähettää ne, jos ne sopivat, yhteen vastaukseen
Jotkut asiakkaat on kirjoitettu odottamaan vain alkuperäistä vastemuotoilua, ja ne eivät onnistuisi suorittamaan tiedonsiirtoa, jos tällaiset optimoinnit olisi käytetty. Useissa DNS-palvelinpaketeissa on näin ollen konfigurointiasetus, jonka avulla ylläpitäjät voivat määrittää ”yhden vastausmuodon” vastausten käytön niille asiakkaille, jotka sitä vaativat.
Tietojen paljastuminenMuokkaa
DNS-vyöhykkeen sisältämät tiedot voivat olla arkaluonteisia käyttöturvallisuuden kannalta. Tämä johtuu siitä, että palvelimen isäntänimien kaltaisista tiedoista voi tulla julkista tietoa, jota voidaan käyttää organisaatiota koskevien tietojen selvittämiseen ja joka voi jopa tarjota suuremman hyökkäyspinnan. Kesäkuussa 2017 Venäjän ylätason verkkotunnuksista vastaava rekisterinpitäjä otti vahingossa käyttöön DNS-vyöhykesiirrot AXFR:n kautta, mikä johti siihen, että 5,6 miljoonaa tietuetta paljastui vahingossa.
Yhdysvaltalaisen Pohjois-Dakotan oikeusistuimen mukaan vyöhykesiirron suorittaminen luvattomana ulkopuolisena saadakseen tietoja, jotka eivät ole julkisesti saatavilla, rikkoo Pohjois-Dakotan lakia vuonna 2008.