Rashid Achilov
DNS-vyöhykkeiden luominen
Domain Name System on eräänlainen Internetin "hermojärjestelmä". Hänen ansiostaan pääset "Järjestelmänvalvoja"-lehden verkkosivuille kirjoittamalla, etkä jonnekin muualle. Kuinka luoda, määrittää ja käyttää DNS-palvelinta pienyritykselle?
DNS-rakenne
Tällä hetkellä Internet on valtava verkko, joka sisältää miljoonia solmuja ympäri maailmaa. Jotta yhdeltä tietokoneelta tehty pyyntö saavuttaisi toisella tietokoneella sijaitsevan tavoitteen, tämä tavoite on ensin määritettävä. Voit tietysti määrittää IP-osoitteen suoraan. Jos tunnet hänet, tietysti. Mutta tässä on mahdollista tehdä erittäin helposti virhe - tieto siitä, missä tarvitsemasi osoite on jo muuttunut, ja parhaassa tapauksessa näet viestin, että osoitetta ei löytynyt, ja pahimmassa tapauksessa saat löytää itsesi sivustolta, jolla ei ole mitään tekemistä sen kanssa, mitä tarvitaan. On luotettavampaa ja helpompaa kääntyä järjestelmään, joka tallentaa vastaavuuden symbolisten nimien, kuten www.site, ja niitä vastaavien IP-osoitteiden välillä. tällä hetkellä(meidän tapauksessamme 217.144.98.99). DNS on tällainen järjestelmä. Koska koko Internetin toiminta riippuu sen onnistuneesta toiminnasta, tämä järjestelmä toimii hajautetun tietokannan periaatteella - "tuttuja" palvelimia on 13, niitä kutsutaan myös "juuripalvelimiksi", jotka sisältävät tietoja palvelimista, sisältävät tietoa palvelimista jne. Kuten Jackin rakentama talo.
Koko Internet-verkko, jota kuvaa vyöhyke "." (piste) on jaettu niin kutsuttuihin TLD:ihin (Top Level Domains - domains). huipputasoa), jaettu joko toiminnallisesti tai maantieteellisesti. On myös termi ensisijainen verkkotunnus - "ensisijainen verkkotunnus" tai "ensimmäisen tason verkkotunnus", mutta tätä termiä käytetään paljon harvemmin. Maantieteellinen jakelu tapahtuu ISO 3166 -standardin mukaisesti, joka määrittää kaksi- ja kolmikirjaimisen koodit kaikille maailman maille. Toiminnallinen allokointi suoritetaan tarpeen mukaan uuden aluetunnuksen luomiseksi. Tässä yhteydessä on huomattava, että kaikki aluetunnukset liittyvät kysymykset käsitellään ICANNissa (Internet Corporation for Assigned Names and Numbers), ja tämä elin päättää uuden TLD:n luomisesta.
Pääpalvelimet itsessään sisältävät vain linkkejä palvelimille, jotka sisältävät tietoja toisen tason vyöhykkeistä, jotka puolestaan sisältävät tietoja palvelimista, jotka sisältävät tietoja kolmannen tason vyöhykkeistä jne. Useimmissa tapauksissa hierarkia päättyy kolmanteen tai neljänteen vyöhykkeeseen. Mutta ei siksi, että tässä on jonkinlainen rajoitus. Yksinkertaisesti monimutkaisten nimien muistaminen ei ole helpompaa kuin IP-osoitteiden.
Siten tiedonhakuprosessi, esimerkiksi web-palvelimesta www.granch.ru, näyttää tältä:
- Asiakas ottaa yhteyttä DNS-palvelimeensa, jonka osoitteen järjestelmänvalvoja on asettanut pyynnöllä "Kerro minulle vastaava osoite nimi www.granch.ru".
- DNS-palvelin tietää niiden palvelimien osoitteet, joista sen pitäisi aloittaa haku, jos pyydettyä tietoa ei ole tallennettu sen välimuistiin, joten se kääntyy jommankumman puoleen.
- Juuripalvelin lähettää hänelle zone.ru:sta vastaavan palvelimen osoitteen
- DNS-palvelin käyttää zone.ru-palvelinta
- Zone.ru-palvelin lähettää hänelle sen palvelimen osoitteen, joka vastaa hänen vyöhykkeensä grainch-vyöhykkeestä.
- DNS-palvelin käyttää vyöhykkeen gratch.ru palvelinta.
- Ja lopuksi vyöhykkeen gratch.ru palvelin kertoo hänelle nimeä www vastaavan osoitteen. Tässä tapauksessa se on 81.1.252.58.
Tämä prosessi on kuvattu kuvassa. 1, jossa numerot osoittavat pyyntöjen järjestyksen.
Kuinka integroida tietosi DNS-rakenteeseen?
Ennen kuin liityt mihinkään järjestelmään, sinulla on oltava käsitys siitä, mihin ja miten liittyä.
Mihin upotamme sen?
Eri palvelimet vastaavat eri TLD:istä ja jos maantieteelliset verkkotunnukset Pääsääntöisesti yksi palvelin (tarkemmin sanottuna yksi organisaatio) on vastuussa, jolloin toiminnallisiin verkkotunnuksiin voi vastata yleisesti ottaen rajoittamaton määrä ns. rekisterinpitäjiä, eli yrityksiä, jotka ovat tehneet ICANNin kanssa erityissopimuksen rekisteröi nimiä joissakin toiminnallisissa verkkotunnuksissa. Lyhyt kuvaus toiminnallinen verkkotunnus ja sen rekisterinpitäjän osoite on annettu kohdassa .
Jos rekisterinpitäjiä on useita, annetaan pääosoitteen osoite (esimerkiksi VeriSign for domain.com). .gov- ja .mil-verkkotunnukset on varattu yksinomaan Yhdysvaltain hallitukselle ja amerikkalaisille sotilasorganisaatioille, ja .gov-tunnuksen varaus on virallistettu vastaavalla RFC-RFC 2146:lla. Täysi lista Kaikki tällä hetkellä olemassa olevat maantieteelliset aluetunnukset, joista käy ilmi verkkotunnuksen rekisteröijä ja tarvittavat yhteystiedot, ovat nähtävissä. Vaikka esimerkiksi zone.com-sivustossa voit valita valtavasta luettelosta, zones.ru- ja.su RUTSENTR -sivustoille ei ole vaihtoehtoja.
Tässä on useita huomioitavia kohtia. Itse asiassa zone.su kuuluu olemattomalle Neuvostoliiton valtiolle, vaikka sitä kuitenkin edelleen huolletaan ja se on avoinna rekisteröinnille. Rekisteröityminen sinne on melko kallista - 100 dollaria rekisteröintiä tai tukea vuodessa.
Ei ole olemassa prioriteettia, jonka mukaan yksi organisaatio tai henkilö on etusijalla toiseen verkkotunnusta rekisteröidessään. Yksi amerikkalainen liikemies, joka harjoitti muovi-ikkunoiden tuotantoa, rekisteröi verkkotunnuksen windows2000.com. Kun Microsoft yritti tehdä samaa, se yllättyi huomatessaan, että nimi oli jo otettu ja yrityksen oli maksettava iso summa. On jopa käsite "cybersquatting" - verkkotunnusten rekisteröintiprosessi niiden myöhempää jälleenmyyntiä varten. Myös RUTSENTR päätti osallistua tähän ja uusien sääntöjen mukaan, jotka otetaan käyttöön 1.6.2006, vapautuneet verkkotunnukset laitetaan "verkkotunnushuutokauppaan" ja siirretään eniten tarjoavalle. Nimet pidetään "huutokaupassa" vuoden ajan, jos kukaan ei vaadi niitä tänä aikana, nimi vapautetaan ilmaiseksi rekisteröitäväksi.
Kun yllä luetellut TLD:t luotiin, TLD .xxx suunniteltiin myös aikuisille suunnatuille sivustoille. ICANN hylkäsi tämän ehdotuksen. Siitä äänestettiin äskettäin, ja ICANN hylkäsi sen uudelleen. Mutta TLD .tel ilmestyi, suunniteltu käytettäväksi samanaikaisesti tietokoneissa ja mobiililaitteissa.
On olemassa RFC 1480, joka kuvaa säännöt nimien rekisteröimiseksi .us-verkkotunnuksessa. Nämä säännöt ovat erittäin hankalia ja hämmentäviä ja vaativat nimien luomista 6-7 tasolta, kuten Hamilton.High.LA-Unified.K12.CA.US
Kuinka upotamme sen?
Aiemmin kaikki oli paljon monimutkaisempaa. Rekisteröityäkseni zone.comin minun piti täyttää monia tekstilomakkeita - organisaation tiedoilla ja tiedoilla yhteyshenkilöt... Nämä lomakkeet lähetettiin sitten erityisiin osoitteisiin, joista vastaukset tulivat - hyväksytty tai ei. Valmiiksi muodostettu vyöhyketiedosto testattiin sitten, ja taas lähetettiin postitse viesti, jossa ilmoitettiin onnistuiko testaus vai ei.
Nyt kaikesta on tullut paljon yksinkertaisempaa. Sekä Network Solutions että RUTSENTR ovat hankkineet verkkorajapinnat, joiden avulla kaikki edellä mainitut (paitsi tietysti vyöhyketiedoston luominen) voidaan tehdä muutamalla hiiren napsautuksella. Kaikki tiedot voidaan korjata, täydentää tai poistaa milloin tahansa. Aiemmin oli tarpeen tehdä palvelusopimus RUCENTERin kanssa, mutta 1.6.2006 alkaen otetaan käyttöön uudet säännöt, joiden mukaan riittää rekisteröityminen heidän verkkosivuillaan. Ulkomaiset rekisterinpitäjät, yleensä kustannukset luottokortit, mutta jos verkkotunnusta ei jostain syystä voida rekisteröidä, rahat palautetaan aikaisintaan kolmen päivän kuluttua.
Rekisterinpitäjän on annettava sen palvelimen IP-osoite ja aliverkon peite, joka käyttää DNS-palvelinohjelmaa ja sisältää päätietokannan, jonka luot ja muokkaat tarpeen mukaan. Tätä palvelinta kutsutaan ensisijaiseksi palvelimeksi (pääpalvelimeksi). Lisäksi sinun on määritettävä vähintään yksi IP-osoite palvelimelle, joka sisältää varmuuskopio tukiasema ensisijaisen palvelimen vian varalta. Tällaisia palvelimia kutsutaan toissijaisiksi palvelimiksi (orjapalvelimia). Jotta et miettiisi pitkään toissijaisen DNS:n sijoittamista, RUCENTER tarjoaa sen sijoittamista sivustoonsa. RUCENTER-palveluiden hinta on 15 dollaria vuodessa per verkkotunnus alueilla .ru, .net, .com, .org, 50 dollaria per verkkotunnus vyöhykkeillä .biz, .info, 100 dollaria per verkkotunnus vyöhykkeellä .su ja 5 dollaria vuodessa. tukea varten toissijainen DNS millä tahansa (mukaan lukien ne, joita ei ole rekisteröity) vyöhykkeellä.
Miksi toissijaisen DNS-palvelimen vaatimus on pakollinen? Koska DNS:n vakaus on erittäin tärkeää koko Internetin vakaudelle, verkkotunnuksen rekisteröivän henkilön tai organisaation on täytettävä tietyt DNS:n vakautta koskevat ehdot:
- Tässä verkkotunnuksessa on oltava vähintään kaksi palvelinta.
- Näiden palvelimien on oltava käytettävissä vähintään 22 tuntia vuorokaudessa.
Uusien sääntöjen mukaan palvelimien sijoittamiselle ei ole vaatimuksia, vaikka aiemmin vaadittiin, että ne sijaitsevat eri IP-verkoissa.
www.krokodil.ru
Oletetaan siis, että haluamme luoda verkkosivuston www.krokodil.ru (tämän artikkelin kirjoitushetkellä tämä oli ilmainen), joka on omistettu krokotiilien kasvattamiseen kotona. Palveluntarjoajalta on varattu oma linjayhteys, luokan C verkko, nimittäin 212.20.5.0 – 212.20.5.255 (tämä alue on tällä hetkellä ilmainen). Tämä esimerkki on hieman epätyypillinen nykyajalle IP-osoitteiden puutteen vuoksi, mutta se on otettu nimenomaan käänteisen vyöhykkeen luomisen harkitsemiseksi. Myös mahdollisuutta liittyä 212.20.5.0/31-verkon kautta harkitaan. Krokotiilien kasvatustoimistomme sisäinen verkko koostuu kuudesta tietokoneesta ja se erotetaan FreeBSD:tä käyttävästä Internet-palomuurivälityspalvelimesta jne. Mitä tarvitsemme toteuttaaksemme suunnitelmamme?
Ensinnäkin huomautan, että on vaihtoehtoja, jotka eivät vaadi DNS-tuntemusta - kaikki on palveluntarjoajan sivustolla, palveluntarjoaja palvelee kaikkea, sinulle tarjotaan vain verkkokäyttöliittymä. Tämä palvelu on erittäin suosittu ulkomailla, mutta sillä on hyvin vähän kysyntää Venäjällä. Sen kuvaus ei kuulu tämän artikkelin piiriin, joten en ota sitä huomioon.
Ensinnäkin tarvitsemme DNS-palvelinohjelman. Tähän mennessä vain yksi ohjelma toteuttaa vaaditut toiminnot. Tämä BIND DNS-palvelin, jakelija ISC (Internet System Consortium Inc.), voittoa tavoittelematon organisaatio, joka kehittää BIND-, DHCP-, INN- ja NTP-palvelimia. Jos sitä ei ole järjestelmässäsi, sinun on ladattava ja asennettava se. FreeBSD toimitetaan BIND 9.3.2:n kanssa, joten tämä artikkeli keskittyy tähän versioon. On huomattava, että seuraavat konfiguraatiokuvaukset ovat täysin sopimattomia BIND 8.x:n versioille, koska BIND 8.x -määritystiedostojen muoto eroaa olennaisesti BIND 9.x -asetustiedostojen muodosta.
Toiseksi meidän on jaettava meille osoitetut IP-osoitteet ja osoitettava osoitteet sisäiset tietokoneet. Kaikki täällä on erittäin yksinkertaista: olkoon 212.20.5.1 palveluntarjoajan yhdyskäytävä, 212.20.5.2 UNIX-palvelimen osoite, 10.87.1.0/24 sisäinen aliverkko, jossa työasemat 1-6 sijaitsevat, 254 on osoite sisäinen käyttöliittymä palvelin. Loput osoitteet varataan tulevaa laajennusta varten.
Kolmanneksi tarvitset valmiiksi valmistetun vyöhykkeen kuvaustiedoston, joka määrittää pienen määrän ulkoisia osoitteita: krokodil.ru - vyöhykkeen juuripalvelin, www.krokodil.ru, ftp.krokodil.ru, mail.krokodil.ru ja ns.krokodil.ru . Nimi ns (nimipalvelin) on melkein perinteinen nimi tietokoneille, joissa DNS-palvelu toimii, vaikka kukaan ei tietenkään estä sinua kutsumasta sitä, esimerkiksi jaws.krokodil.ru. Nimet määritetään myös sisäisen verkon tietokoneille, joihin pääsee vain sisältä: tooth1.krokodil.ru – tooth6.krokodil.ru.
DNS-tietueet
DNS:ään voidaan sijoittaa melko suuri määrä erilaisia tietueita. Tämän artikkelin laajuus antaa meille mahdollisuuden tarkastella vain tärkeimpiä niistä saadaksemme täydelliset tiedot Asiaankuuluviin RFC:ihin tulee viitata: RFC 1033 ja RFC 1035 määrittelevät master-tietuemuodot, RFC 1122 PTR-tietueformaatit, RFC 2782 SRV-tietueformaatit. Otamme huomioon vain ne tietueet, joita tarvitaan verkkotunnuksen rekisteröintiin vaadittavien vyöhyketiedostojen luomiseen:
- SOA-tietue, joka määrittää vyöhykkeen kuvauksen alun.
- NS-tietue, joka määrittää vyöhykkeen nimipalvelimet.
- A-tietue, joka yhdistää IP-osoitteen nimeen ( suora muuntaminen).
- MX-tietue, joka kuvaa tämän tietokoneen postin toimitusasetukset.
- CNAME-tietue, joka määrittää vaihtoehtoiset nimet.
- PTR-tietuetta, joka määrittää nimen ja IP-osoitteen vastaavuuden (käänteinen käännös), käytetään "käänteisen" vyöhykkeen kuvauksessa.
DNS-tietuemuoto on yhteinen kaikille tietuetyypeille:
[nimi] [luokka]<тип> <данные>
- Nimi– tämä on sen kohteen nimi, johon tiedot liittyvät;
- ttl– esineen käyttöikä;
- Luokka– ennätysluokka;
- tyyppi– tietueen tyyppi;
- tiedot– tähän kohteeseen liittyvät tiedot.
Nimellä voi olla mikä tahansa arvo, jolloin sitä pidetään kohteen nimenä. Jos nimi päättyy pisteeseen, sitä pidetään täysin kelvollisena, muuten vyöhykkeen nimi korvataan nimen lopussa, joka voidaan määrittää kahdella tavalla:
- Esimerkiksi määrittämällä vyöhykkeen nimi $ORIGIN-direktiivissä:
$ORIGIN krokodil.ru
- Määrittämällä vyöhykkeen nimi BIND-määritystiedoston vyöhykedirektiivissä.
Erikoismerkki "@" osoittaa nykyisen vyöhykkeen nimen. Huomaa, että käsky $ORIGIN ohittaa vyöhykekäskyn ja kestää kunnes seuraava $ORIGIN-käsky tulee näkyviin tai tiedoston loppuun. Kunnes ensimmäinen $ORIGIN-käsky tulee näkyviin, sen katsotaan olevan asetettu vyöhykekäskyn arvoon BIND-määritystiedostossa.
Jos nimi annetaan, sen on aloitettava rivin ensimmäisestä paikasta.
TTL jätetään yleensä pois ja asetetaan globaalisti $TTL-direktiivillä. $TTL-käsky on pakollinen BIND 9.x:lle ja asetetaan yleensä aivan tiedoston alussa. Tämän direktiivin tietokenttä määrittää elementin eliniän (sekunteina), jonka aikana se voi pysyä välimuistissa ja olla luotettava. Tässä esimerkissä se on kaksi päivää (48 tuntia).
172 800 TTL
Aloitusluokka voi olla jokin seuraavista arvoista:
- IN– Internet-resurssien tallennus.
- CH– kirjaa ChaosNet-resursseista – täysin tuntematon venäläinen käyttäjä Symbolics-koneissa käytetty verkko.
- H.S.– Hesiod-resurssitietue – BIND-palveluprotokolla.
Tietuetyyppi on yksi yllä luetelluista tyypeistä.
Huomaa, että nimi-, ttl- ja luokkakentät voidaan jättää pois. Tässä tapauksessa viimeksi määritetty arvo otetaan niiden arvoiksi (tässä tapauksessa @:n määrittäminen on oikea määritelmä), ja jos arvoa ei ole määritelty missään, niin luokkakentän oletusarvo "IN" on hyväksytty, muille kentille se johtaa virheilmoitukseen.
Merkintöjen lisäksi vyöhyketiedosto voi sisältää komentoja. Komentoja on yhteensä neljä: $TTL, $ORIGIN, $INCLUDE ja $GENERATE. $GENERATE-komennon kuvaus on annettu BIND-ohjelman dokumentaatiossa sekä ja, $INCLUDE-komento toimii oikeinkirjoituksensa mukaan - se sisältää määritetyn tiedoston nykyisessä tiedostossa.
Huomautus: merkki ";" (puolipiste) on kommenttimerkki.
SOA Record
Tämä merkintä määrittää vyöhykkeen alun. Kaikki vyöhykkeet on aloitettava SOA-merkinnällä. Toisen SOA-merkinnän ilmestyminen lopettaa automaattisesti ensimmäisen vyöhykkeen ja aloittaa toisen. SOA-tietueen muoto näkyy alla. Itse asiassa SOA-tietue nimeää vyöhykkeen ja asettaa sille joitain oletusasetuksia.
2005122001 ; Sarjanumero
3600 ; Yritä uudelleen tunnin välein
172800); Vähintään 2 päivää
Katsotaanpa esimerkkiä. @-merkki nimikentässä tarkoittaa, että on tarpeen ottaa vyöhykkeen nimi, joka on aiemmin määritelty $ORIGIN-direktiivissä. Tietueluokka on IN, tietuetyyppi on SOA. SOA on ainoa merkintä, jolla on näin monimutkainen parametriluettelo.
Ensimmäinen parametri on vyöhykkeen päänimipalvelimen osoite. Tässä esimerkissä tämä on krokodil.ru. Toinen parametri on tästä vyöhykkeestä vastaavan henkilön sähköpostiosoite. Huomaa, että osoite on kirjoitettu muodossa "käyttäjänimi.verkkotunnus" eikä "käyttäjänimi@verkkotunnus".
Toinen parametri on suluissa oleva arvoluettelo. Teoriassa se on mahdollista kirjoittaa yhdelle riville, mutta käytännössä en ole nähnyt tätä missään, esimerkissä annettua merkintämuotoa käytetään kaikkialla. Luettelo koostuu viidestä osasta:
- Alueen sarjanumero. Tämä parametri toimii erittäin hyvin tärkeä rooli tehdyn päivityksen jakamisessa ensisijainen palvelin, kaikilla sen toissijaisilla palvelimilla. On oltava jokin tapa ilmoittaa toissijaiselle palvelimelle, että ensisijaisen palvelimen tiedot ovat muuttuneet. Jos ensisijainen palvelin on käynnistetty uudelleen, se lähettää DNS NOTIFY:n kaikille toissijaisille palvelimille. Tämän ilmoituksen saatuaan toissijainen palvelin pyytää sarjanumeroa - jos ensisijaisella palvelimella on suurempi sarjanumero kuin toissijaisella palvelimella, toissijainen palvelin antaa vyöhykkeen päivityskomennon. Lisäksi toissijainen palvelin suorittaa määräajoin sarjanumerotarkistuksia samaa tarkoitusta varten. Siksi sinun tulee muistaa yksi yksinkertainen sääntö: jos korjaat vyöhykkeen, lisää sarjanumeroa! Yleinen käytäntö DNS-järjestelmänvalvojien keskuudessa on muodostaa sarjanumero seuraavasti: VVVVKKDDv, jossa:
- VVVV,KK,PP– kuluva vuosi (4 numeroa), kuukausi ja päivä, vastaavasti
- v– päivän vyöhykeversio. Jos päivässä tehdään useita muutoksia, tämä luku kasvaa yhdellä peräkkäin.
Kukaan ei tietenkään pakota sinua noudattamaan tällaista käytäntöä. Esimerkiksi Windowsin DNS-palvelimet eivät noudata sitä, vaan yksinkertaisesti numeroivat sen 1, 2, 3 jne. - Päivitysjakson arvo, jonka jälkeen orjapalvelimen on otettava yhteyttä isäntään ja tarkistettava, onko vyöhykkeen sarjanumero muuttunut. Jos sarjanumero on muuttunut, orjapalvelin lataa uusia tietoja. Tässä esimerkissä 10 800 sekuntia (3 tuntia).
- Aika, jonka jälkeen orjapalvelin yrittää ottaa yhteyttä isäntään, jos yritys hankkia uusi sarjanumero epäonnistuu. Tässä esimerkissä 3600 sekuntia (yksi tunti).
- Aika, jonka orjapalvelimet palvelevat tietyn vyöhykkeen pyyntöjä, jos pääpalvelin on pitkään poissa. Järjestelmän pitäisi toimia vaikka pääpalvelin ei toimi pitkään aikaan, joten tämän parametrin arvoksi asetetaan 1 728 000 sekuntia (20 päivää).
- Negatiivisen vastauksen välimuistin aika. Tässä esimerkissä 172800 sekuntia (2 päivää).
NS sisäänkäynti
Tämä merkintä määrittää vyöhykettä tukevien palvelimien nimet, ts. johtamassa tukikohtaansa. Ensisijaisten ja kaikkien toissijaisten palvelimien nimet tulee luetella tässä. Tyypillisesti tämä merkintä seuraa välittömästi SOA-merkintää. Tietokenttään syötetään yksi arvo - DNS-vyöhykepalvelimen nimi tai IP-osoite riippumatta siitä, onko se isäntä vai orja. Kaikkien tässä määritettyjen nimien on oltava täydellisiä, eli niiden tulee päättyä pisteeseen!
IN NS ns.krokodil.ru.
IN NS ns4.nic.ru.
Esitetyssä esimerkissä kuvataan ensin alueemme ns.krokodil.ru pääpalvelin ja sitten orjapalvelin - RU CENTER -solmu ns4.nic.ru.
Levy A
Tyypin A tietue on tiedostojen pääsisältö suorassa muunnosvyöhykkeessä tai yksinkertaisesti "suorassa" vyöhykkeessä, eli se antaa tietokoneen nimen sen osoitteen perusteella. Se on koottu jokaiselle tietokoneelle. Luettavuuden helpottamiseksi nämä tietueet ryhmitellään yleensä IP-osoitteiden nousevaan järjestykseen, ja ne ryhmitellään myös tiettyä IP-osoitetta vastaavien MX-tietueiden kanssa, vaikka tämä ei tietenkään ole pakollista. Nimikenttään syötetään IP-osoitteelle määritetty nimi, tietokenttään IP-osoite, jolle nimi on määritetty. Kun osoitteella on muita nimiä, A-tietueen osoitteelle antamaa nimeä kutsutaan ensisijaiseksi nimeksi.
hammas1 IN A 10.87.1.1
hammas2 IN A 10.87.1.2
hammas3 IN A 10.87.1.3
hammas4 IN A 10.87.1.4
hammas5 IN A 10.87.1.5
hammas6 IN A 10.87.1.6
Tämä esimerkki kuvaa IP-osoitteiden määrittämistä sisäisen verkon tietokoneille, joiden osoite on 10.87.1.0/24. Sisäisen verkon tietokoneille ei yleensä tarvitse muodostaa mitään lisämerkintöjä, CNAME mahdollista poikkeuksena.
CNAME-tietue
CNAME-tietue on lisämahdollisuus DNS. Sen avulla voit määrittää useamman kuin yhden nimen yhdelle IP-osoitteelle. Nimikenttään syötetään IP-osoitteelle määritetty lisänimi, tietokenttään - tyypin A tietueen aiemmin antama päänimi tai muu CNAME-tietueen antama lisänimi. Tässä tapauksessa tietueen tietokentässä olevaa nimeä kutsutaan kanoniseksi (siis tietueen nimi - Canonical Name). Yhdelle IP-osoitteelle voidaan määrittää rajoittamaton määrä muita nimiä CNAME-tietueiden kautta, mutta muuntyyppisten tietueiden on käytettävä A-tietueen antamaa nimeä CNAME-tietueen sijaan. Alla on esimerkki lisänimien oikeasta ja virheellisestä määrittämisestä.
Oikea:
ns IN A 10.87.1.1
nimi1 IN CNAME ns
IN MX 10 ns
Väärin:
ns IN A 10.87.1.254
nimi1 IN CNAME ns
IN MX 10 nimi1
CNAME-tietueet voivat osoittaa toisiinsa, mutta korkeintaan seitsemän tasoa, kahdeksannen on oltava tietue, joka osoittaa A-tyypin tietueen nimeen. Kirjallisuudessa suositellaan useiden tyypin A tietueiden käyttöä useiden määrittämisen sijaan osoitteeseen lisää nimiä. Tämän osalta voimme sanoa, että tämä kohta mainitaan RFC 2219:ssä sanoilla "tässä asiassa ei ole ehdottomia suosituksia, jokaisen on päätettävä itse, mikä on hänelle parasta". Useita CNAME-tiedostoja on helpompi hallita, useita A-tietueita on helpompi käsitellä, koska uudelleenohjauksia tapahtuu vähemmän.
MX-tietue
MX-tietue on vyöhyketiedoston toinen pääelementti. Tämä merkintä tarkoittaa " Mail vaihtaja", ja se on tarkoitettu osoittamaan nimikentässä kuvatun solmun postia vastaanottavien tietokoneiden IP-osoitteet tai nimet. Tämä kenttä voi olla tyhjä, täysin tai osittain tarkennettu nimi. Jos nimikenttä on tyhjä tai epätäydellinen nimi on määritetty, niin nimeä täydennetään $ORIGIN-direktiivistä. MX-tietueiden luominen monimutkaisissa tapauksissa, kun konfiguroidaan melko suuri vyöhyke laajalla postin vastaanottojärjestelmällä, on melko ei-triviaali tehtävä, joka on kiinteästi kietoutunut postin toimittamiseen SMTP-protokollaa käyttävien ohjelmien työhön, joten tarkastelemme vain yksinkertaisinta tapausta - UNIX-palvelin vastaanottaa kaiken sähköpostin. Tietokenttään syötetään kaksi arvoa - prioriteetti ja sen tietokoneen nimi tai IP-osoite, johon sähköposti lähetetään tämä tietokone. Yhteen IP-osoitteeseen voi yleensä liittää rajoittamaton määrä MX-tietueita, ja niillä kaikilla tulisi olla eri prioriteetit. Posti reititetään prioriteetin mukaan - postiagentti lajittelee tietueet kasvavaan prioriteettiin ja yrittää toimittaa postia tällä tavalla. Oletetaan, että olemme sopineet behemot.ru-solmun järjestelmänvalvojan kanssa, että voimme käyttää hänen palvelintaan siirtosolmuna, joka vastaanottaa sähköpostimme ja toimittaa sen vastaanottajille, kun yhteys palautuu. Sitten krokodil.ru-palvelimen kuvaus näyttää tältä:
krokodil.ru. IN A 212.20.5.2
IN MX 10 krokodil.ru.
IN MX 50 behemot.ru.
www IN CNAME krokodil.ru.
posti CNAME krokodil.ru.
ftp IN CNAME krokodil.ru.
Tämä on kattava esimerkki ja näyttää välittömästi MX-, A- ja CNAME-tietueiden käytön. Tässä olemme:
- Annamme nimen krokodil.ru osoitteeseen 212.20.5.2.
- Ilmoitamme, että posti lähetetään osoitteisiin, kuten [sähköposti suojattu], hyväksyy (tässä järjestyksessä):
- palvelin krokodil.ru;
- palvelin behemot.ru.
- Määrittelemme lisänimiä www.krokodil.ru, mail.krokodil.ru ja ftp.krokodil.ru. Huomaa, että kaikki oikealla puolella olevat nimet ovat täydellisiä, eli ne päättyvät pisteeseen. Jos näin ei tehdä, nykyisen $ORIGIN-direktiivin arvo korvataan automaattisesti nimen lopussa. Tässä tapauksessa tämä johtaisi sellaisten nimien ilmestymiseen kuin www.krokodil.ru.krokodil.ru.
PTR Record
Tämä on hyvin erityinen levytyyppi. Esimerkissämme otimme "erityisesti" koko aliverkon ottaaksemme huomioon "normaalin" työn PTR-tietueiden kanssa. Tapausta 212.20.5.0/31-verkon kanssa käsitellään hieman myöhemmin.
PTR-tietue on suunniteltu suorittamaan nimien käänteinen kääntäminen IP-osoitteiksi. Tällaisia muunnoksia käytetään erittäin laajasti erilaisia ohjelmia, jotka tarjoavat pääsyn joihinkin verkkoresursseihin: ne tarkistavat myötä- ja käänteisten käännösten johdonmukaisuuden ja voivat estää pääsyn, jos PTR-tietue ei täsmää tai puuttuu. PTR-tietueita sisältävää vyöhykettä kutsutaan käänteismuunnosvyöhykkeeksi tai yksinkertaisesti "käänteisalueeksi".
PTR-tietueilla ei ole mitään yhteyttä A-, MX-, CNAME- ja muihin tietueisiin, jotka kuvaavat suoraa muuntamista. Tämä tehtiin tarkoituksella, jotta molemmissa muunnoksissa voitaisiin käyttää samaa ohjelmistomoduulisarjaa. Tässä kohtaa kuitenkin seuraavan tyyppinen monimutkaisuus - täysin hyväksytty verkkotunnus muotoa www.krokodil.ru. "lisää mittaa" vasemmalta oikealle (eli solmut suurenevat, kun siirryt nimitekstissä vasemmalta oikealle), ja IP-osoite 212.20.5.2 on oikealta vasemmalle. Ohjelmamoduulien yhtenäistämiseksi otettiin käyttöön seuraava käytäntö: kaikki IP-osoitteet ovat nimiä, jotka sisältyvät erityiseen TLD:hen in-addr.arpa. Tämän toimialueen "vyöhykkeet" ovat aliverkkoja, ja vyöhykkeen nimi kirjoitetaan taaksepäin luettuna IP-osoitteena. Siten paluuvyöhykkeemme "nimi" on 5.20.212.in-addr.arpa vastavyöhykkeelle, joka sisältää kuvauksen ulkoiselle verkolle ja 1.87.10.in-addr.arpa vastavyöhykkeelle, joka sisältää kuvauksen sisäinen verkko.
Aivan kuten käyttääksesi verkkotunnusta, sinun on rekisteröitävä se, jos haluat käyttää käänteistä käännöstä, sinun on rekisteröitävä käänteinen "alue" käänteisen alueen koordinaattorille. Toisin kuin suorilla muunnosvyöhykkeillä, siellä on vain yksi koordinaattori, ja rekisteröinti hänelle on ilmaista. Käänteisten vyöhykkeiden rekisteröinnin hoitaa RIPE NCC. Kaikki käänteisalueen rekisteröintitiedot on annettu kohdassa.
Miksi sinun on rekisteröitävä käänteinen vyöhyke? In-addr.arpa-vyöhykkeen ylimmän tason palvelimen on tiedettävä, että käänteisen käännöspyynnön suorittamiseksi sen on otettava yhteyttä sellaiseen palvelimeen, tässä tapauksessa 212.20.5.2. Sisäisen aliverkon käänteistä vyöhykettä ei tietenkään tarvitse rekisteröidä minnekään.
Itse PTR-tietue näyttää hyvin yksinkertaiselta - IP-osoitteen viimeinen osa syötetään nimikenttään ja täysin tarkennettu suora käännösnimi syötetään tietokenttään. Kiinnitän huomionne viimeiseen asiaan - tietokenttään syötetyn nimen on oltava täysin tarkennettu, koska PTR-tietueet itse määrittelevät IP-osoitteen ja nimen välisen suhteen, ne eivät voi saada tietoa mistään siitä, millä vyöhykkeellä epätäydellinen suora käännös nimi tulee antaa .
$ORIGIN 1.87.10.in-addr.arpa
1 IN PTR tooth1.krokodil.ru.
2 IN PTR tooth2.krokodil.ru.
3 IN PTR tooth3.krokodil.ru.
4 IN PTR tooth4.krokodil.ru.
5 IN PTR tooth5.krokodil.ru.
6 IN PTR tooth6.krokodil.ru.
Yllä olevassa esimerkissä määritimme käänteisen muunnoksen sisäisessä verkossa oleville tietokoneille. Kirjoitamme palvelimelle yhden rivin (in todellinen esimerkki$ORIGIN-direktiivejä ei tarvitse määritellä, ne annetaan vain selventämään, mistä vyöhykkeestä puhumme):
$ORIGIN 5.20.212.in-addr.arpa
2 IN PTR krokodil.ru
Tässä on huomattava, että CNAME-tietueita ei käytetä useiden käänteisten vastaavuuksien määrittämiseen, joten kun kysytään "mikä nimi vastaa osoitetta 212.20.5.2", tuloksena on aina krokodil.ru, riippumatta sille asetettujen aliasten määrästä.
Miten tilanne on erilainen, kun palveluntarjoaja varaa lohkon 212.20.5.0/31 täyden aliverkon sijaan? Kaikkien tietueiden paitsi PTR:n luomisen kannalta ei mitään. Suoran vyöhykkeen luomis- ja rekisteröintimenettely ei riipu osoitteiden lukumäärästä, varsinkin kun useimmissa tapauksissa ei tarvita monia osoitteita. PTR-tietueiden suhteen on kuitenkin eroa. Yksinkertaistamista kohti. Tai ehkä ei, riippuen palveluntarjoajasta. Ja se piilee siinä, että tietueet:
gate.krokodil.ru. IN A 212.20.5.1
krokodil.ru. IN A 212.20.5.2
on palvelimellasi ja sinun hallinnassasi, mutta merkinnät:
1 IN PTR gate.krokodil.ru.
2 IN PTR krokodil.ru.
on palveluntarjoajan muodostama, koska mahdollisuus rekisteröidä vastavyöhyke itse ja hallita sitä on mahdollista vain, jos sinulla on vähintään C-luokan verkko. Tämä toisaalta helpottaa työtä - et täytyy rekisteröityä RIPE:hen, mutta toisaalta se vaikeuttaa palvelimen nimeämisen muutoksia, on aina otettava yhteyttä palveluntarjoajaan.
Tiedoston rakenne
BIND itse ei tietenkään välitä missä järjestyksessä tietueet ovat tai miten ne on muotoiltu. Tämä on tärkeää vain niille, jotka ylläpitävät vyöhykettä, varsinkin jos siihen tehdään usein muutoksia. Tässä kuvaan vyöhykkeiden jakautumista tiedostoittain sellaisena kuin sitä käytetään ylläpitämilläni vyöhykkeillä. Tämä ei tietenkään ole ainoa mahdollinen tilaus, eikä ehkä paraskaan. Mutta se toimii.
Ulkoiset ja sisäiset vyöhykkeet
BIND 8.x:llä oli yksi äärimmäisen suuri haittapuoli - se ei sallinut tiedon tuottamista eri tekijöistä riippuen - oli tarpeen joko näyttää mikä oli tarpeetonta tai piilottaa mitä tarvittiin. Ulkoisten asiakkaiden ei todellakaan tarvitse tietää tietokoneiden läsnäolosta sisäisessä verkossa, mutta koska tietoja ei ollut mahdollista erottaa, mikä tahansa tietokone pystyi määrittämään sisäisen verkon rakenteen DNS-kyselyillä. BIND 9.x on vapaa tästä haitasta - sen avulla voit jakaa pyyntöjä "näkymien" välillä käyttämällä pääsynhallintaluetteloita (ACL). Näkymillä voi olla mielivaltaiset nimet, jotka yleensä luovat sisäisen näkymän, johon sisäisen aliverkon asiakkaat ovat tyytyväisiä, ja ulkoisen näkymän, jonka kaikki muut tyydyttävät. Muista tässä, että tämä on sama vyöhyke, se vain näytetään eri tavalla - pääsääntöisesti ulkoisen vyöhykkeen tiedostot sisältävät vain ulkoisten asiakkaiden tarvitsemat tiedot - ulkoisesta palvelimesta, postin toimituspoluista jne. ja sisäiset vyöhyketiedostot heijastavat koko verkon topologia. Lisäksi, jos käänteinen vyöhyke on mukana, on tarpeen jakaa tiedot käänteismuunnososoitteista tiedostoihin samalla tavalla.
Joten palataanpa esimerkkiimme.
Tiedoston rakenne on seuraava. Meillä on suora vyöhyke krokodil.ru ja käänteinen vyöhyke 5.20.212.in-addr.arpa. Lisäksi kääntövyöhykkeen vyöhykkeen 0.0.127.in-addr.arpa on oltava läsnä, jotta voidaan varmistaa localhost 127.0.0.1:n oikea käänteinen kääntäminen. Tätä vyöhykettä tarvitaan estämään BINDia yrittämästä kysellä juuripalvelimia itsestään, mikä tapahtuu, kun 127.0.0.1 osoittaa "localhost". Suora muunnostietue 127.0.0.1 localhost.krokodil.ru kirjoitetaan sisäiseen vyöhykkeen suoramuunnostiedostoon. Jotta verkkoa ei kuormitettaisi turhan tiedon siirtämisellä, ulkoisille ja sisäisille vyöhykkeille käytetään erilaisia SOA-tietueita - ulkoisten vyöhykkeiden tietueet muuttuvat erittäin harvoin ja sisäisillä vyöhykkeillä melko usein. Siksi meillä on seuraavat tiedostot:
- localhost.rev– käänteinen muunnosvyöhyketiedosto 0.0.127.in-addr.arpa. Tämä tiedosto on olemassa vain sisäiseen esitykseen.
- zone212.rev– käänteinen muunnosvyöhyketiedosto 5.20.212.in-addr.arpa.
- zone10.rev– sisäinen inversiovyöhyketiedosto 1.87.10.in-addr.arpa.
- direct-krokodil-ru.int– sisäinen suora muunnosvyöhyketiedosto krokodil.ru.
- direct-krokodil-ru.ext– ulkoinen suora muunnosvyöhyketiedosto krokodil.ru.
- krokodil-ru-int.soa– tiedosto sisäisten vyöhykkeiden SOA- ja NS-tietueilla.
- krokodil-ru-ext.soa– tiedosto, joka sisältää SOA- ja NS-tietueita ulkoisille vyöhykkeille.
Laajasta listasta huolimatta tiedostot ovat melko lyhyitä, joten ne on esitetty tässä kokonaisuudessaan kommentteja lukuun ottamatta.
Tehdään yksi huomautus paikallispalvelimen nimestä. RFC 1912 mainitsee erityisesti tiedostojen asetusten määrittämisen arvoon 127.0.0.1 ja localhost. Esimerkissämme localhost-vyöhyke noudattaa RFC 1912:ta, vaikka tosielämässä on täysin mahdollista kohdata nimen resoluutio 127.0.0.1 localhost.domain.tld ja vastaava käänteinen resoluutio.
Localhost.rev-tiedosto. Käyttää yhtä SOA-tietuetta sekä sisäistä inversiovyöhykettä:
$SISÄLTÄ /etc/namedb/krokodil-ru-int.soa
1 IN PTR localhost.
Tiedosto zone212.rev:
1 IN PTR gate.krokodil.ru.
2 IN PTR krokodil.ru.
Tiedosto zone10.rev:
$SISÄLTÄ /etc/namedb/krokodil-ru-int.soa
1 IN PTR tooth1.krokodil.ru.
2 IN PTR tooth2.krokodil.ru.
3 IN PTR tooth3.krokodil.ru.
4 IN PTR tooth4.krokodil.ru.
5 IN PTR tooth5.krokodil.ru.
6 IN PTR tooth6.krokodil.ru.
Tiedosto direct-krokodil-ru.int:
$SISÄLTÄ /etc/namedb/krokodil-ru-int.soa
krokodil.ru. IN A 10.87.1.254
IN MX 10 krokodil.ru.
www IN CNAME krokodil.ru.
posti CNAME krokodil.ru.
välityspalvelin IN CNAME krokodil.ru.
ftp IN CNAME krokodil.ru.
ns IN CNAME krokodil.ru.
paikallinen isäntä. IN A 127.0.0.1
hammas1 IN A 10.87.1.1
hammas2 IN A 10.87.1.2
hammas3 IN A 10.87.1.3
hammas4 IN A 10.87.1.4
hammas5 IN A 10.87.1.5
hammas6 IN A 10.87.1.6
Tiedosto direct-krokodil-ru.ext:
$SISÄLTÄ /etc/namedb/krokodil-ru-ext.soa
krokodil.ru. IN A 212.20.5.2
IN MX 10 krokodil.ru.
IN MX 50 behemot.ru.
www IN CNAME krokodil.ru.
posti CNAME krokodil.ru.
ftp IN CNAME krokodil.ru.
portti IN A 212.20.5.1
Tiedosto krokodil-ru-int.soa:
@ SOA:ssa krokodil.ru. hostmaster.krokodil.ru. (
2006051202; Sarjanumero
10800 ; Päivitä 3 tunnin välein
3600 ; Yritä uudelleen tunnin välein
1728000; Vanhenee 20 päivän välein
172800); Vähintään 2 päivää
IN NS krokodil.ru.
Tiedosto krokodil-ru-ext.soa:
172 800 TTL
@ SOA:ssa korkodil.ru. hostmaster.krokodil.ru. (
2005122001 ; Sarjanumero
10800 ; Päivitä 3 tunnin välein
3600 ; Yritä uudelleen tunnin välein
1728000; Vanhenee 20 päivän välein
172800); Vähintään 2 päivää
IN NS krokodil.ru.
IN NS ns4.nic.ru.
Johtopäätös
Kuinka luoda, määrittää ja käyttää DNS-palvelinta pienyritykselle? Itse asiassa se ei ole niin vaikeaa kuin aluksi näyttää - riittää, että käyt tämän polun läpi kerran, jatkotoimenpiteet tapahtuvat "automaattisesti".
Sovellus
Huipputason verkkotunnukset
Aluksi RFC 920:n mukaan toiminnallisten TLD-tunnusten luettelo sisälsi vain .com, .gov, .mil, .edu, .org, jotka edustivat vastaavasti kaupallista, hallitusta, sotilaallista oppilaitoksia ja voittoa tavoittelemattomat järjestöt. Myöhemmin tämä luettelo laajeni jonkin verran - vuonna 1985 lisättiin TLD .net, joka edustaa toimittajaorganisaatioita verkkopalvelut, ja vuonna 1988 - TLD .int, joka edustaa kansainvälisiä järjestöjä. Vuosina 2001-2002 tähän listaan lisättiin venäläiselle käyttäjälle käytännössä tuntemattomat TLD:t .aero, .biz, .cat, .coop, .jobs, .mobi, .museum, .name, .pro ja .travel. Lisää yksityiskohtaiset tiedot on annettu . Maantieteelliset verkkotunnukset jaetaan lopullisesti. Vaikka tämä ei tarkoita, että et voi rekisteröidä verkkotunnustasi sillä. Monet maantieteelliset alueet, jotka sattumalta osuvat yhteen "tuttujen" lyhenteiden kanssa, ovat erittäin houkuttelevia. Esimerkiksi .md (Moldova) on erittäin houkutteleva lääketieteelliset laitokset ja Marylandin asukkaat Yhdysvalloissa; .tv (Tuvalu) – televisioon liittyville verkkosivustoille; .tm (Turkmenistan) on sama kuin lyhenteen "Trade Mark" oikeinkirjoitus ja .nu (Niue - siellä on sellainen saarisiirtokunta) - "alaston"-tyylisille sivustoille.
Domain Name System on perusta moderni Internet. Ihmiset eivät halua vaivautua muistamaan numerosarjaa 63.245.217.105, vaan haluavat tietokoneen yhdistävän ne määritettyyn solmuun nimellä mozilla.org. Tätä DNS-palvelimet tekevät: ne kääntävät ihmisten pyynnöt digitaaliseen muotoon, jota he ymmärtävät. Joissakin tapauksissa voidaan kuitenkin tarvita käänteinen IP-osoite → DNS-nimen muunnos. Tällaisia nimiä käsitellään jäljempänä.
Mitä varten se on tarkoitettu?
Oikein konfiguroidun r:n saatavuus DNS-osoite ja sinun on ehdottomasti lähetettävä viestejä oma palvelin yrityksen posti. Lähes kaikki sähköpostipalvelimet hylkäävät viestin istunnon alussa, jos palvelimesi IP-osoitteessa ei ole merkintää käänteisessä DNS-vyöhykkeessä. Etäpostipalvelimen epäonnistumisen syy ilmoitetaan todennäköisesti seuraavasti:
550-"IP-osoitteella ei ole PTR-tietuetta (osoite nimeen) DNS:ssä tai kun PTR-tietueessa ei ole vastaavaa A-tietuetta (nimi osoitteeseen). Tarkista ja korjaa DNS-tietueesi."
tai
550 - IP-osoitteellesi (IP-osoitteellesi) ei ole vastaavaa PTR:ää, joka vaaditaan 550. Anteeksi, hei.
tai vain
550 IP-osoitteellasi ei ole PTR-tietuetta
Numero 550 on kaikissa kolmessa tapauksessa tavallinen postinumero SMTP-palvelin a, ilmoittaa kriittisestä virheestä, joka ylitsepääsemättömästi estää jatkotyön tämän sähköpostiistunnon aikana. On sanottava, että yleisesti ottaen kaikki 500-sarjan virheet ovat kriittisiä ja postin lähettämistä on mahdotonta jatkaa niiden ilmestymisen jälkeen. Tekstissä selitetään tarkemmin kieltäytymisen syy ja todetaan, että vastaanottajapostipalvelimen järjestelmänvalvoja on asettanut sen tarkistamaan, onko lähettävällä sähköpostipalvelimella merkintä käänteisessä DNS-vyöhykkeessä (rDNS) ja jos sitä ei ole, vastaanottaja palvelin on velvollinen kieltäytymään lähettäjältä yhteyden muodostamisesta (SMTP-5XX-sarjan virheet).
Kuinka asentaa ja käyttää?
Vain tämän vyöhykkeen vastaavan IP-osoitelohkon omistajalla on oikeus määrittää käänteinen DNS-vyöhyke. Yleensä tämä omistaja on palveluntarjoaja, joka omistaa oman autonomisen järjestelmänsä. Lisätietoja rekisteröinnistä autonominen järjestelmä(AS) ja IP-osoitelohko voidaan lukea tästä artikkelista. Lyhyesti sanottuna, rekisteröidäkseen käänteisen DNS-vyöhykkeen, IP-osoitelohkon operaattorin on rekisteröidyttävä omaan henkilökohtainen tili RIPE-verkkosivustolla "domain"-tyyppinen objekti, määritä rDNS-vyöhykettä tukevien DNS-palvelimien osoitteet ja määritä tuki vyöhykkeelle, kuten 3.2.1.in-addr.arpa. Osoitin, PTR-tyyppinen tietue, vastaa resursseista käänteisalueella. Täällä pyydetään ratkaisemaan IP-osoite isäntänimeksi.
Jos et ole itsenäisen järjestelmän onnellinen omistaja, rDNS:n määrittäminen IP-osoitteelle tai sähköpostipalvelinosoitteille alkaa ja päättyy pyynnöllä palveluntarjoajan tai isännöitsijän tukipalvelulle. Molemmissa tapauksissa postipalvelimen ja erityisesti yrityksen sähköpostipalvelimen IP-osoitteen nimi tulee antaa mielekkäästi.
Esimerkkejä hyvistä nimistä sähköpostipalvelimelle:
mail.domain.ru
mta.domain.ru
mx.domain.ru
Esimerkkejä huonoista nimistä:
isäntä-192-168-0-1.domain.ru
customer192-168-0-1.domain.ru
vpn-dailup-xdsl-clients.domain.ru
ja vastaavat. Tällaiset nimet suodatetaan erittäin todennäköisesti määritetyllä tavalla asiakastietokoneet, joihin ei voi asentaa sähköpostipalvelinta, joten niistä lähetetään roskapostia.
Voit ja pitäisi käyttää kyselyitä DNS-vyöhykkeiden kumoamiseen heti sähköpostipalvelimen käynnistämisen jälkeen. Tätä varten sinun tarvitsee vain tehdä pieni kokoonpano BY. Eri sähköpostipalvelimissa rDNS-tarkistus tehdään eri tavalla:
hylkää_tuntematon_asiakas
verify = reverse_host_lookup
Siirry Exgange Server -laajennuksessa Palvelimet-osioon, valitse palvelin laajennetusta luettelosta, valitse Protokollat ja sitten SMTP-protokolla, valitse oikeasta ikkunasta SMTP-palvelin ja napsauta hiiren kakkospainikkeella ja valitse Ominaisuudet-luettelosta. Seuraavaksi Toimitus-välilehti → Suorita käänteinen DNS-haku saapuville viesteille
Nyt kaikki viestit IP-osoitteista, joissa ei ole käänteistä DNS-tietuetta (PTR-tyyppiset tietueet), hylätään ja roskapostin virtaus vähenee merkittävästi. Ehkä tämä on yksinkertaisin, tehokkain ja vähiten resursseja vievä kaikista roskapostin suodatusmenetelmistä: käänteinen DNS-tarkistus katkaisee suurimman osan roskapostin roskapostista, joka lähetetään tavallisten käyttäjien saastuneilta tietokoneilta, jotka muodostavat roskapostittajien bottiverkkoja.
Kun julkaiset artikkelin uudelleen, sinun on asennettava aktiivinen indeksoitu hyperlinkki lähdesivustoon!
Perusasiat
Mikä on käänteinen DNS-vyöhyketietue?
Normaalit DNS-kyselyt määrittävät tuntemattoman IP-osoitteen tunnetulle isäntänimelle. Tämä on tarpeen esimerkiksi silloin, kun selaimen on muodostettava TCP-yhteys palvelimeen käyttämällä osoitekenttään syötettyä URL-osoitetta.
Forum.hetzner.de --> 213.133.106.33
Käänteinen DNS toimii toiseen suuntaan - kysely määrittää IP-osoitteeseen kuuluvan isäntänimen.
213.133.106.33 --> dedi33.your-server.de
Kuten näet, edelleenlähetys- ja paluupyyntöjen isäntänimien ei tarvitse olla samoja!
Mikä on käänteisen DNS-vyöhyketietueen tarkoitus?
- traceroute näyttää IP-osoitteiden lisäksi myös ihmisen luettavissa olevia isäntänimiä. Tämä tekee virheiden diagnosoinnista paljon helpompaa.
- Suuri määrä sähköpostipalvelimia hyväksyy viestejä vain, jos lähettäjän IP-osoitteessa on käänteinen DNS-tietue.
- Käänteisiä DNS-tietueita voidaan käyttää SPF-tietueissa (Sender Policy Framework; tekniikka, joka estää roskapostin ja virusten lähettämisen väärennetyistä sähköpostiosoitteista).
Kuinka käänteinen haku toimii teknisesti DNS-palvelimilla?
Harjoitella
Kuinka voin määrittää IP-osoitteelleni useita nimiä, jos palvelimellani on eri verkkotunnuksia?
Tämä on mahdotonta. Jokaiselle IP-osoitteelle on määritetty vain yksi nimi.
Lisäksi sillä ei ole väliä, mitkä käänteisalueet on rekisteröity palvelimelle. Päästäkseen sivustolle selaimen tarvitsee vain suorittaa suora muunnos (Nimi --> IP). A-tietueeseen viittaavia nimiä voi tietysti olla useita, kuten useita A-tietueita tai useita CNAME-tietueita.
Jotta postipalvelimet toimisivat, ei tarvitse olla useita isäntänimiä yhtä IP-osoitetta kohden. Käänteisen DNS-tietueen on vastattava SMTP-palvelimen isäntänimeä (katso vastaavan SMTP-palvelimen asetukset).
Jos useita verkkotunnuksia hallitaan IP-osoitteen kautta (melko yleinen tapaus), voit käyttää neutraalia nimeä, joka ei liity käyttäjän verkkotunnuksiin. Roskapostisuodattimet yksinkertaisesti tarkistavat, vastaako käänteinen DNS-tietue HELO-komennon vastauksessa olevaa nimeä. Tällä ei ole vaikutusta verkkotunnuksia ja postiosoitteet lähetetyissä kirjeissä.
- Käänteisen DNS-tietueen on vastattava postipalvelimen nimeä tai perustuttava IP-osoitteeseen.
- Käänteisen DNS-tietueen on myös ratkaistava "välitä" samaan IP-osoitteeseen.
- Käänteinen DNS-tietue ei saa olla samanlainen kuin automaattisesti luotu tietue, kuten "162-105-133-213-static.hetzner.de", koska roskapostisuodattimet arvioivat tällaiset nimet usein negatiivisesti.
- Annetun nimen on oltava olemassa. Älä käytä olemattomia verkkotunnuksia.
Esimerkki hyvästä merkinnästä:
Srv01.grossefirma.de --> 213.133.105.162 213.133.105.162 --> srv01.grossefirma.de > telnet 213.133.105.162 25 220 srv01.grossefirma.de ESMTP ready.
Asetin DNS-palvelimelleni PTR:n. Miksi tämä ei toimi?
DNS-palvelimesi on vastuussa vain edelleenlähetyksestä.
IP-osoitelohkon omistaja (esim. Hetzner Online GmbH) on vastuussa valtuutettujen DNS-palvelimien ylläpidosta käänteisiä syöttöjä varten.
Käänteisiä DNS-tietueita voidaan luoda vain käyttämällä vastaavaa robottipaneelitoimintoa ( vasen valikko-> "Palvelimet" -> napsauta palvelinta -> "IP:t" -> napsauta IP-osoitteen vieressä olevaa tekstikenttää).
Palvelimeni takaisinkirjoitus on erilainen kuin sähköpostipalvelimeni HELO. Onko tämä ongelma?
Esimerkki: Käänteinen DNS-tietue palvelimen IP-osoitteelle "www.grossefirma.de". Vastauksena HELO-komentoon postipalvelin vastaa "mail.grossefirma.de".
Jotkut roskapostisuodattimet luokittelevat tällaisten lähettäjien sähköpostit "roskapostiksi". Tällaiset epäjohdonmukaisuudet on korjattava. Käänteisen DNS-tietueen ja postipalvelimen nimen on oltava samat. Yllä olevassa esimerkissä ne voivat olla esimerkiksi "srv01.grossefirma.de". Nimi "www.grossefirma.de" voidaan ohjata osoitteeseen srv01.grossefirma.de ilman seurauksia CNAME-tietueen avulla.
DNS-tietueiden yksityiskohtainen testaus voidaan suorittaa käyttämällä
Jatkamme verkkosivustojen rakentamisen aihetta, puhutaanpa niin tärkeästä näkökulmasta kuin verkkotunnusjärjestelmän - DNS - toiminnasta. Monet alkuperäiseen sijoittamiseen liittyvät ongelmat sekä sivustojen siirrot välillä eri palvelimia ja isännöinti. Verkkotunnusjärjestelmän toiminnan ymmärtäminen tekee omien verkkotunnustesi ja niihin liittyvien sivustojen ja muiden palveluiden hallinnasta helppoa.
Mikä on verkkotunnus? Monille tämä on synonyymi verkkosivuston osoitteelle, esimerkiksi www.sivusto. Kirjoittamalla tämän osoitteen olet vakaasti varma, että päädyt tälle sivustolle etkä jonnekin muualle. Samanaikaisesti verkkotunnus voi merkitä verkkosivuston lisäksi myös sähköpostipalvelinta, lyhytsanomapalvelinta tai muuta Internet- ja verkkopalvelua. Domainnimet sisältyvät toimialuevyöhykkeisiin, jotka sijaitsevat toistensa sisällä hierarkkisessa järjestyksessä.
Yleisesti ottaen verkkotunnus on symbolinen nimi, jonka avulla voit yksilöllisesti osoittaa itsenäisen nimitilan Internetissä. Eikä vain osoite, vaan myös mahdollistaa asiakkaan löytää nopeasti tarvittava solmu ilman pienintäkään käsitystä sen sijainnista. Ei ole liioiteltua sanoa, että DNS-järjestelmä on perusta moderni verkko Internet siinä muodossa, jossa me kaikki tiedämme ja olemme tottuneet siihen.
DNS-järjestelmä on globaali ja sillä on tiukka hierarkia. Harkitse seuraavaa kaaviota:
Hierarkian ylin taso on pisteellä merkitty juuriverkkotunnus, joka sisältää tietoa ensimmäisen tason toimialueista, esim. ru, com, org jne. Juurivyöhykkeen työn takaa 13 juuripalvelinta, jotka sijaitsevat ympäri maailmaa ja kopioivat jatkuvasti tietojaan keskenään. Itse asiassa juuripalvelimia on enemmän, mutta protokollaominaisuuksien avulla voit määrittää vain 13 huipputason solmua, joten järjestelmän skaalautuvuus ja vikasietoisuus varmistetaan jokaisen juuripalvelimen peilien avulla.
Ensimmäisen tason verkkotunnukset ovat meille tuttuja domain-alueet ja niitä voivat hallinnoida sekä kansalliset että kansainväliset organisaatiot ja niillä on omat käyttöehdot. Jokaiselle ensimmäisen tason verkkoaluevyöhykkeelle voit sijoittaa rajattoman määrän toisen tason verkkotunnuksia, jotka ovat jokaiselle Internetin käyttäjälle tuttuja verkkosivustojen osoitteina.
Toisen tason verkkotunnukset puolestaan ovat myös verkkoaluealueita, ja niihin voidaan sijoittaa kolmannen tason verkkotunnuksia, joihin voit sijoittaa, kuten sisäkkäiseen nukeen, neljännen, viidennen jne. tasot. Jotta eri vyöhykkeillä sijaitsevat solmut voidaan tunnistaa yksiselitteisesti, käsite täysin hyväksytty verkkotunnus (FQDN, Fully Qualified Domain Name), joka sisältää kaikki DNS-hierarkian ylätason verkkotunnusten nimet. Esimerkiksi sivustomme FQDN on: verkkosivuilla. Juuri näin, päättyen juurivyöhykettä osoittavaan pisteeseen.
Tämä on erittäin tärkeä kohta. Jokapäiväisessä käytössä on tapana hylätä loppujakso, mutta DNS kirjaa poissaoloa viimeinen kohta tarkoittaa, että tämä verkkotunnus kuuluu nykyiseen verkkoaluevyöhykkeeseen, ts. DNS-palvelin lisää tähän nimeen oman toimialuealueensa ja kaikki ylemmän tason vyöhykkeet juureen asti.
Esimerkiksi palvelimellamme vyöhykkeellä verkkosivuilla lisäämme CNAME-tyyppisen tietueen, joka osoittaa kolmannen osapuolen palvelin, sano, Yandex-posti. Oikean merkinnän pitäisi näyttää tältä:
MailIN CNAMEdomain.mail.yandex.net.
Tässä tapauksessa sähköpostin nimi ei ole FQDN ja se laajennetaan mail.site., jos unohdamme laittaa pisteen Yandex-verkkotunnuksen nimen loppuun, tätä nimeä ei myöskään pidetä FQDN:nä ja se on täydennettävä koko verkkotunnuksen nimellä. Seuraava on virheellinen merkintä:
Mail IN CNAME domain.mail.yandex.net
Eroa on vaikea havaita kouluttamattomalla silmällä, mutta Yandex-sähköpostin verkkokäyttöliittymän sijaan tämä malli lähettää meidät olemattomaan osoitteeseen: domain.mail.yandex.net.site.
Vielä yksi asia. Alueen ylläpitäjät syöttävät kaikki verkkoalueen vyöhykkeen tietueet omilla DNS-palvelimillaan. Miten nämä tietueet tulevat DNS-järjestelmän tiedoksi? Emmehän me ilmoita ylemmän tason DNS-palvelimille, että olemme muuttaneet tietueita.
Mikä tahansa DNS-vyöhyke sisältää tietueita vain jäsensolmuistaan ja alialueistaan. Tietoa alavirran vyöhykkeen solmuista tallennetaan sen omille palvelimille. Tätä kutsutaan delegoimiseksi, ja sen avulla voit vähentää juuripalvelimien kuormitusta ja tarjota tarvittavan autonomian alatason verkkoaluealueiden omistajille.
Joten ostit esimerkiksi verkkotunnuksen esimerkki.org, jonka jälkeen sinun on delegoitava se, ts. määritä nimipalvelimet (DNS-palvelimet), jotka sisältävät tämän tiedostovyöhykkeen tietueita. Nämä voivat olla joko omia palvelimia tai julkisia palveluita, esimerkiksi Yandex DNS.
Tässä tapauksessa toimialueen vyöhykkeellä org lisätään merkintä:
Esimerkki IN NS dns1.yandex.net.
Tämä osoittaa, että kaikki tämän vyöhykkeen tietueet sijaitsevat palvelimella dns1.yandex.net. Sääntöjen mukaan jokaisella toimialuevyöhykkeellä on oltava vähintään kaksi NS-palvelinta eri aliverkoissa. Käytännössä he tyytyvät usein yhteen palvelimeen ja ostavat sille kaksi IP-osoitetta eri alueilta.
Katsotaanpa nyt, kuinka tarvitsemamme DNS-tietueen haku tapahtuu ja miksi palvelimellesi tehty tietue mahdollistaa vierailijoiden pääsyn sivustollesi kaikkialta maailmasta.
Oletetaan, että käyttäjä haluaa käydä suositussa Yandex Market -resurssissa, hän kirjoittaa vastaavan sivuston nimen selaimen osoiteriville ja painaa Enter-painiketta. Jotta sivun sisältö voidaan näyttää käyttäjälle, selaimen on lähetettävä pyyntö sivustoa palvelevalle web-palvelimelle, jota varten sinun on tiedettävä sen IP-osoite. Siksi selain ottaa yhteyttä DNS-asiakkaaseen selvittääkseen, mikä osoite vastaa käyttäjän syöttämää verkkotunnusta.
DNS-asiakas puolestaan tarkistaa merkinnät hosts-tiedostossa, sitten paikallisessa välimuistissa ja, koska se ei löydä sieltä tarvittavia merkintöjä, välittää pyynnön verkkoasetuksissa määritetylle DNS-palvelimelle. Tämä on todennäköisesti paikallinen välimuistin DNS-välityspalvelin, kuten dnsmasq, tai paikallinen yrityksen DNS-palvelin. Nämä ratkaisut eivät yleensä ole globaalin DNS-järjestelmän täysivaltaisia palvelimia eivätkä ole osa sitä, palvelevat vain paikallista vyöhykettä ja tallentavat DNS-pyyntöjä välimuistiin, joten tällainen pyyntö, jos tietoja ei ole välimuistissa, siirretään ylempään -tason DNS-palvelin, yleensä palveluntarjoajan palvelin.
Saatuaan pyynnön palveluntarjoajan palvelin tarkistaa omia äänitteitä, sitten oma välimuisti, ja jos tulos löytyy, raportoi sen asiakkaalle, muuten palvelin joutuu turvautumaan rekursio- Etsi globaalista DNS-järjestelmästä. Tämän prosessin mekanismin ymmärtämiseksi paremmin olemme laatineet seuraavan kaavion:
Joten asiakas lähettää DNS-pyynnön palveluntarjoajan palvelimelle saadakseen selville verkkotunnuksen osoitteen market.yandex.ru, palveluntarjoajan palvelimella ei ole tällaisia tietoja, joten se ottaa yhteyttä johonkin pääpalvelimista ja välittää pyynnön sille. Myöskään juuripalvelimella ei ole tarvittavia tietueita, mutta se vastaa tietävänsä vyöhykkeestä vastaavan palvelimen ru - a.dns.ripn.net. Tämän nimen ohella juuripalvelin voi välittömästi ilmoittaa IP-osoitteensa (ja useimmissa tapauksissa ilmoittaa), mutta se ei välttämättä tee tätä, jos sillä ei ole tällaisia tietoja, jolloin sinun on tehtävä tämä ennen yhteydenottoa tähän palvelimeen. enemmän yksi rekursiivinen kysely, vain määrittääkseen hänen nimensä.
Saatuaan selville ru-vyöhykkeestä vastaavan palvelimen osoitteen, palveluntarjoajan palvelin lähettää pyynnön sille, mutta tällä palvelimella ei myöskään ole tarvittavia tietueita, mutta se ilmoittaa, mikä vyöhyke on yandex palvelin vastaa ns1.yandex.ru Ja Välttämättä antaa osoitteensa. Muuten rekursiota ei voida suorittaa loppuun, koska vyöhyke yandex vyöhykkeellä sijaitseva palvelin vastaa yandex. Tätä varten ylemmällä vyöhykkeellä vyöhykettä palvelevia nimipalvelimia koskevan NS-tietueen lisäksi "linkitetty" A-tietue, jonka avulla voit selvittää tällaisen palvelimen osoitteen.
Lopuksi lähettämällä pyyntö vyöhykettä palvelevalle palvelimelle yandex, palveluntarjoajan palvelin vastaanottaa vaaditun toimialueen osoitteen ja raportoi sen asiakkaalle. Se myös sijoittaa tuloksena saadun tuloksen välimuistiin tämän toimialueen SOA-tietueen TTL-arvon määrittämäksi ajaksi. Käytännössä, koska rekursiiviset kyselyt ovat erittäin kalliita, palveluntarjoajien tietueiden välimuistiin kuluva aika voi jättää huomiotta verkkotunnuksen TTL-arvot ja saavuttaa arvot kahdesta neljään tunnista useisiin päiviin tai jopa viikkoon.
Katsotaan nyt vielä yksi kohta. Kyselyt voivat olla rekursiivisia tai ei-rekursiivisia. Rekursiivinen pyyntö mahdollistaa valmiin vastauksen saamisen, ts. IP-osoitteet tai viestit, että verkkotunnusta ei ole olemassa, sitä ei ole delegoitu jne. Ei-rekursiivinen pyyntö antaa vastauksen vain siitä vyöhykkeestä, josta annettu palvelin on vastuussa, tai palauttaa virheen.
Koska rekursiiviset kyselyt vaativat melko paljon resursseja, useimmat DNS-palvelimet käsittelevät rekursiiviset kyselyt ei-rekursiivisesti. Tai he voivat tehdä tämän valikoivasti, esimerkiksi palveluntarjoajan DNS-palvelimet suorittavat rekursiivisia kyselyitä vain asiakkailleen ja loput ei-rekursiivisesti.
Meidän tapauksessamme asiakas lähetti rekursiivisen pyynnön palveluntarjoajan palvelimelle, joka puolestaan lähetti ei-rekursiivisia pyyntöjä peräkkäin, kunnes löysi tarvittavan palvelimen, joka antoi vaaditun vastauksen. Samanaikaisesti käyttäjän pyynnön tulosten lisäksi myös välipyyntöjen tulokset sijoitetaan palveluntarjoajan palvelimen välimuistiin, jolloin seuraavat tällaiset pyynnöt voidaan suorittaa ei-rekursiivisesti tai vähimmäismäärällä pyyntöjä .
Esimerkiksi, jos käyttäjä Yandex Marketissa käynnin jälkeen päättää käyttää postipalvelua, palvelin lähettää välittömästi pyynnön ns1.yandex.ru, koska se tietää jo, mikä palvelin sisältää vyöhykkeen tietueita yandex.
Teoriasta käytäntöön
Kun ostat verkkotunnuksen rekisterinpitäjältä, sinua pyydetään delegoimaan se, ts. määritä DNS-palvelimet, joissa toimialuevyöhyke sijaitsee. Nämä voivat olla rekisteripalvelimia (yleensä ilmaisia), isäntäpalvelimia, julkisia DNS-palveluita tai omia nimipalvelimia, jos se sijaitsee samalla toimialueen vyöhykkeellä, sinun on myös määritettävä IP-osoitteet. Esimerkiksi yhden tunnetun rekisteröijän verkkotunnuksen delegointiikkuna näyttää tältä:
Mitä sinne oikein pitäisi laittaa? Se riippuu siitä, missä ja miten isännöit sivustoasi. Jos käytät jaettua isännöintiä, niin isännöitsijä luo kaikki tarvittavat tietueet automaattisesti, kun lisäät sivustosi hosting-ohjauspaneeliin, sinun tarvitsee vain delegoida verkkotunnus isännöitsijän NS-palvelimelle, ts. ilmoittaa ne tässä ikkunassa. Tämä menetelmä sopii hyvin aloittelijoille yksinkertaisuutensa vuoksi, mutta siinä on myös haittapuoli: kyky hallita DNS-vyöhykettä käyttäjän puolella puuttuu tai on minimaalinen. Lisäksi jaetussa isännöinnissä järjestelmänvalvojat voivat muuttaa sivuston IP-osoitetta ilmoittamatta siitä käyttäjälle, joten jos et halua käyttää isännöitsijän NS-palvelinta, tästä asiasta kannattaa ehdottomasti keskustella teknisen tuen kanssa.
Jos siirrät sivuston toiselle isännöitsijälle, sinun on siirrettävä sivusto ja vaihdettava vanhan isännöitsijän nimipalvelimet uuden palvelimen palvelimiksi rekisterinpitäjässä. Muista kuitenkin, että DNS-palvelimien välimuistissa olevat tiedot eivät päivity heti, vaan ainakaan sen jälkeen, kun TTL-verkkotunnuksen arvo on vanhentunut, joten sivustosi saattaa olla vielä jonkin aikaa käytettävissä vanhasta osoitteesta. Jos sinun on työskenneltävä hänen kanssaan kiireellisesti, voit tehdä sen odottamatta DNS-päivitykset-palveluntarjoajan välimuisti, lisää tiedostoon isännät merkintä seuraavalla sisällöllä:
1.2.3.4 esimerkki.fi
Jossa 1.2.3.4 Ja esimerkki.fi vastaavasti uusi IP-osoite ja verkkotunnuksesi nimi.
Jos sinulla on oma VPS tai haluat hallita kokonaan verkkotunnusvyöhykettä, sinun tulee käyttää rekisterinpitäjän palvelimia tai julkisia palveluita. Oman nimipalvelimen luominen ei mielestämme ole kannattavaa, ellet tee omaa isännöintiäsi.
Tässä tapauksessa sinun on luotava vähintään kaksi A-tietuetta, jotka osoittavat tämän toimialueen sivustoa palvelevaan verkkopalvelimeen:
@ IN A 1.2.3.4
www IN A 1.2.3.4
DNS-tietueiden koiramerkki ilmaisee itse toimialueen, ja sinun tulee myös luoda tietue www-aliverkkotunnukselle, jotta myös käyttäjät, jotka kirjoittavat sivuston osoitteen www-tunnuksella, voivat käyttää sitä.
Emme harkitse merkintöjen lisäämistä sähköpostiin, voit lukea tästä artikkelistamme:
Kun siirrät sivustoa, sinun tarvitsee vain muuttaa A-tietueiden IP-osoitteita ja odottaa päivitystä DNS-tiedot. Yleensä tämä on epämiellyttävin hetki - kaikki näyttää olevan tehty, mutta et voi muuttaa mitään, voit vain odottaa. Mutta jos noudatat joitain suosituksia, niin tämä prosessi voidaan suorittaa mahdollisimman kivuttomasti ja vierailijoiden huomaamatta.
Ensinnäkin, muuta TTL-arvoa SOA-tietueessa. Oletuksena se on useita tunteja, ja juuri sen verran joudut odottamaan DNS-palvelimen välimuistin merkinnän päivittämistä. Voit selvittää nykyisen TTL-arvon suorittamalla komennon määrittämällä haluamasi verkkotunnuksen:
Nslookup -typr=soa-sivusto
Meidän tapauksessamme se on 4 tuntia: 
Siksi vähintään 4 tuntia (vanha TTL-arvo) ennen suunniteltua siirtoa vaihda TTL-arvo pienempään arvoon, esimerkiksi 900 (15 minuuttia). Aseta sitten sivustosi vain luku -tilaan ja siirrä se siihen uusi palvelin. Sivustoa ei saa sammuttaa tai siirtää huoltoa varten, ja sen tulee olla käytettävissä. Mutta sinun on estettävä käyttäjiä muuttamasta ja lisäämästä tietoja, esim. kieltää rekisteröityminen, kommentoiminen, tilausten tekeminen jne. Muista myös laittaa näkyvälle paikalle ilmoitus aiheesta tekninen työ ja arvioitu valmistumispäivä.
Jos haluat työskennellä uuden palvelimen kanssa muuttamatta DNS-tietueita, lisää vaadittu rivi kohtaan hosts-tiedosto. Kun olet sijoittanut sivuston uudelle sivustolle ja varmistanut, että se on normaali toiminta muuta DNS-tietueita, nyt 15 minuutin kuluessa ensimmäiset käyttäjät alkavat vierailla sivustollasi uudella palvelimella. Vanhan palvelimen toimivuutta on ylläpidettävä jonkin aikaa, mieluiten viikon ajan, koska kaikki palveluntarjoajat eivät käytä SOA-tietueen TTL-arvoa välimuistin päivittämiseen. Omia asetuksiasi voidaan käyttää laitteiston kuormituksen vähentämiseen .
Onnistuneen siirron jälkeen TTL-arvo tulee nostaa aikaisempiin arvoihinsa, jotta nimipalvelimia ei kuormitettaisi tarpeettomasti.
Olemme pohtineet yksinkertaisinta mallia, mutta käytännössä nettisivujen lisäksi on yleensä toimistoverkko, jonka resursseista moniin tulisi päästä käsiksi myös ulkopuolelta. Harkitse seuraavaa kaaviota:
Meillä on julkiset palvelimet verkkosivuille ja sähköpostille sekä toimistoverkko, jolle olemme osoittaneet aliverkkotunnuksen toimisto. Jos sähköpostin ja verkkopalvelimen kanssa ei ole erityisiä ongelmia, toimistoalueen kanssa on vaihtoehtoja. Tyypillisesti paikallista vyöhykettä palvelee oma DNS, eikä sillä ole yhteyttä äitivyöhykkeeseen. Globaalille DNS-järjestelmävyöhykkeelle office.example.com ei ole olemassa, mutta samanniminen isäntä on olemassa. Tämä on perusteltua, jos yritysverkko on NAT:n takana ja sen solmuissa on vain harmaita osoitteita ja pääsy ulkopuolelta tapahtuu vain yhdyskäytävälle, johon vastaavat portit sisäisistä solmuista välitetään.
Tässä DNS:n tapauksessa vyöhykkeen ennätykset esimerkki.fi voi näyttää tältä:
@ IN A 1.2.3.4
www IN A 1.2.3.4
posti A 1.2.3.5
toimisto IN A 5.6.7.8
Mutta verkoston sisällä syntyy monimutkaisuutta, jonka puoleen asiakkaat kääntyvät verkkopalvelut Tekijä: sisäiset nimet: corp.office.example.com tai rdp.office.example.com, jotka osoittavat sisäisiin "harmaisiin" osoitteisiin." Kuitenkin ulkopuolella paikallinen verkko Tällaisten nimien IP-osoitetta ei ole mahdollista selvittää, koska niitä sisältävää globaalia DNS-vyöhykettä ei ole. Split-DNS-niminen mekanismi antaa sinun päästä ulos tästä tilanteesta, jonka avulla voit antaa erilaisia tuloksia asiakkaan sijainnin mukaan.
Paikallisessa verkossa asiakkaiden DNS-pyyntöjä palvelee paikallinen palvelin, jolla on vastaavat tietueet, sen ulkopuoliset pyynnöt lähetetään vyöhykettä palvelevalle palvelimelle esimerkki.fi. Samalla kaikki yritysten resursseja, joita edustavat useat paikallisen verkon palvelimet, ovat käytettävissä ulkopuolelta yhdestä osoitteesta: office.example.com. Siksi on aika muistaa lempinimi tai CNAME-tietue. Tämä merkintä sallii muiden muistonimien tai aliaksien liittämisen todelliseen isäntänimeen. Huomaa, että aliasten käyttäminen muissa merkinnöissä ei ole hyväksyttävää. Meidän tapauksessamme meidän pitäisi lisätä seuraavat merkinnät:
Corp.office IN CNAME office.example.com.
rdp.office CNAME:ssa office.example.com.
Nyt asiakas voi sijainnistaan riippumatta käyttää samaa nimeä käyttääkseen resursseja, mutta tulokset ovat erilaisia. Paikallisessa verkossa se vastaanottaa oikean palvelimen osoitteen ja muodostaa yhteyden suoraan, ja sen ulkopuolella se ohjataan verkkoyhdyskäytävään.
CNAME-tyyppisiä tietueita voidaan myös käyttää uudelleenohjaamiseen hyväksytyn toimialuealueen ulkopuolelle. Pääehto on CNAME-tietue on osoitettava oikeaan nimeen FQDN-muodossa.
Toinen aliasten käyttötapa on lyhentää osoite. Oletetaan, että koko verkkotunnuksen sähköpostipalvelimena esimerkki.fi haluamme käyttää palvelinta, joka sijaitsee Moskovan toimistossa ja jolla on osoite mail.office.msk.example.com, sinun on myönnettävä, se ei näytä kovin houkuttelevalta. Olisi paljon kätevämpää saada sellainen osoite mail.example.com, ei ole mitään yksinkertaisempaa, lisää seuraava merkintä:
Mail IN CNAME mail.office.msk.example.com.
Muista kuitenkin, että muissa resurssitietueissa tulee käyttää vain oikeita nimiä, joten tämä tietue on virheellinen:
Esimerkki.fi. MX 10 postissa
Oikea tapa olisi:
Esimerkki.fi. IN MX 10 mail.office.msk
Lopuksi puhutaan verkkoaluealueiden delegoinnista. Yllä olevassa esimerkissä tarkasteltiin tilannetta, jossa toimialueen sisällä eri divisioonille on allokoitu omat aliverkkotunnuksensa, koska jokaisella divisioonalla on oma infrastruktuurinsa, on järkevää delegoida omien toimialuealueidensa hallinta niille. Tätä tarkoitusta varten vyöhykkeellä esimerkki.fi NS ja siihen liittyvä A-tietue tulee sijoittaa jokaiselle vyöhykkeelle. Esimerkiksi:
Msk IN NS ns1.msk.example.com.
msk IN NS ns2.msk.example.com.
ns1.msk IN A 1.2.3.4
ns2.msk IN A 5.6.7.8
Oletetaan nyt, kun käytät osoitetta mail.office.msk.example.com vyöhykkeen nimipalvelimet esimerkki.fi näyttää vyöhykettä palvelevan palvelimen nimen ja osoitteen msk.example.com. Näin vyöhykkeen ylläpitäjät voivat tehdä tarvittavat muutokset itse vaikuttamatta päävyöhykkeen toimintaan tai ottamalla yhteyttä sen ylläpitäjiin tietueiden muuttamista vaativissa ongelmissa.
Tunnisteet:
varten oikea toiminta On tärkeää, että sähköpostipalvelimella on oikein määritetty vyöhyke. DNS-asetukset vyöhyke viittaa valmistelutoimiin ennen sähköpostipalvelimen käyttöönottoa ja sähköpostijärjestelmän suorituskyky riippuu suoraan siitä.
Väärät asetukset voivat johtaa siihen, että postia ei voida toimittaa postipalvelimellesi tai vastaanottajapalvelimet hylkäävät sähköpostisi. Todellakin, jos vyöhyketietueet eivät sisällä tietoja sähköpostipalvelimesta, minne posti tulee lähettää? Kylään isoisälle? Voit tietysti pyytää palveluntarjoajaasi määrittämään DNS-vyöhykkeen, mutta on parempi tehdä se itse.
Mitä me tarvitsemme? Oma IP-osoite (oletetaan 11.22.33.44), joka sinun on hankittava palveluntarjoajaltasi. Verkkotunnus (esimerkiksi example.com) voidaan rekisteröidä mille tahansa rekisteröijälle tai heidän kumppanilleen. Kun rekisteröidyt kumppanin kanssa, tarkista, tarjoaako hän pääsyn DNS-vyöhykkeen hallintaan, muuten joudut käyttämään ylimääräistä aikaa, hermoja ja rahaa verkkotunnuksen siirtämiseen rekisterinpitäjälle.
Jos sinulla on jo verkkotunnus ja sillä todennäköisesti toimii verkkosivusto, tarkista, onko se mahdollista DNS-hallinta vyöhykkeestä isännöintipalveluntarjoajan paneelista, muuten on parempi siirtää verkkotunnus rekisterinpitäjälle tätä varten, ota yhteyttä palveluntarjoajan tukeen.
Meillä on siis verkkotunnus. Mitä tietueita sen DNS-vyöhyke sisältää? Ensinnäkin tämä on SOA-tietue - vyöhykkeen kuvaus. Emme analysoi kaikkia tietueita yksityiskohtaisesti, tämä ei kuulu artikkelimme soveltamisalaan, mutta on yleinen ajatus niistä on välttämätöntä. Lisäksi pitäisi olla kaksi NS-tietuetta, jotka osoittavat nimipalvelimiin ( DNS-palvelimet) palvelevat tätä verkkotunnusta, nämä ovat rekisterinpitäjän tai isännöintipalveluntarjoajan palvelimia.
Ensimmäinen lisättävä tietue on A-tietue tai nimitietue. Sen pitäisi osoittaa palvelimesi IP-osoitteeseen, jos päätät palvella kaikki pyynnöt verkkotunnuksessasi, tai isännöintipalveluntarjoajan IP-osoitteeseen, jos päätät isännöidä verkkosivustoasi. Kun isännöidään verkkosivustoa isännöitsijällä, verkkotunnus yleensä delegoidaan sen DNS-palvelimelle (vastaavat NS-tietueet rekisteröidään) ja A-tietue luodaan automaattisesti, kun verkkotunnus pysäköidään.
Tämä vaihtoehto on yleisin, mutta tarvittaessa voit aina luoda A-tietueen itse. Tämä merkintä näyttää tältä:
esimerkki.fi. A 22.11.33.44
Esimerkissämme 22.11.33.44 on palveluntarjoajamme osoite, jossa sivusto sijaitsee. Kiinnitä huomiota nimen lopussa olevaan pisteeseen, tämä osoittaa, että nimi on absoluuttinen, jos pistettä ei ole, nimeä pidetään suhteellisena ja siihen lisätään SOA:n verkkotunnus. Voit tarkistaa merkinnän komennolla nslookup.
Jotta postipalvelin toimisi, sinun on luotava MX-tietue, jonka pitäisi osoittaa postipalvelimeemme. Tätä varten luodaan tietue:
esimerkki.fi. IN MX 10 mail.example.com.
Voit myös kirjoittaa yksinkertaisesti:
esimerkki.fi. MX 10 postissa
Esimerkki.com lisätään automaattisesti tähän nimeen (ilman pistettä lopussa). Numero 10 määrittää palvelimen prioriteetin, mitä pienempi se on. Muuten, DNS-vyöhyke voi jo sisältää MX-tietueen, kuten:
esimerkki.fi. IN MX 0 example.com.
Yleensä isännöintipalveluntarjoaja luo tämän merkinnän automaattisesti, kun se on poistettava.
Luodaan nyt A-tietue osoitteelle mail.example.com
mail.example.com. 11.22.33.44
Nyt kaikki example.com-verkkotunnuksen viestit lähetetään sähköpostipalvelimelle osoitteella 11.22.33.44, ts. sähköpostipalvelimesi, ja samaan aikaan example.com-sivusto jatkaa toimintaansa palveluntarjoajan palvelimella 22.11.33.44.
Voi herää kysymys: miksi et voi heti määrittää sähköpostipalvelimen IP-osoitetta MX-tietueessa? Periaatteessa se on mahdollista, jotkut ihmiset tekevät sen, mutta se ei noudata DNS-määrityksiä.
Voit myös tehdä aliaksia sähköpostipalvelimelle, kuten pop.example.ru Ja smtp.example.ru. Miksi tämä on välttämätöntä? Näin asiakas ei voi olla riippuvainen infrastruktuurisi ominaisuuksista, koska se on määrittänyt asetukset kerran. Oletetaan, että yrityksesi on kasvanut ja varannut erillisen sähköpostipalvelimen palvelemaan ulkoisia asiakkaita. posti1, sinun tarvitsee vain muuttaa kaksi DNS-tietuetta, asiakkaat eivät huomaa työskentelevänsä uuden palvelimen kanssa. Aliaksien luomiseen käytetään CNAME-tyyppisiä tietueita:
Avaa CNAME mail.example.com.
smtp CNAME:ssa mail.example.com.
Tässä vaiheessa eteenpäin suuntautuvan DNS-vyöhykkeen määrittämistä voidaan pitää valmiina, mielenkiintoisin asia on edelleen - käänteinen vyöhyke. Käänteistä vyöhykettä hallinnoi palveluntarjoaja, joka on antanut sinulle IP-osoitteen, etkä voi hallita sitä itse (ellet ole IP-osoitteiden lohkon omistaja). Mutta sinun on lisättävä vähintään yksi merkintä käänteisalueelle. Kuten kirjoitimme edellisessä artikkelissa, monet postipalvelimet tarkistavat lähettävän palvelimen PTR-tietueet (käänteisaluetietueet), ja jos ne puuttuvat tai eivät vastaa lähettäjän toimialuetta, kirje hylätään. Pyydä siksi palveluntarjoajaasi lisäämään sinulle tällainen merkintä:
44.33.22.11.in-addr.arpa. PTR:ssä mail.example.com.
Hieman oudon näköinen, eikö? Katsotaanpa PTR-tietuerakennetta tarkemmin. Käänteiseen nimenselvitykseen käytetään erityistä ylätason verkkotunnusta in-addr.arpa. Tämä tehdään, jotta voidaan käyttää samoja ohjelmistomekanismeja eteenpäin ja taaksepäin nimen muuntamiseen. Tosiasia on, että muistonimet kirjoitetaan vasemmalta oikealle ja IP-osoitteet oikealta vasemmalle. Joten mail.example.com. tarkoittaa, että isäntäposti on toimialueen esimerkissä, joka on ylätason verkkotunnuksessa com., 11.22.33.44 tarkoittaa, että isäntä 44 on aliverkossa 33, joka on osa aliverkkoa 22, verkostoon kuuluvia 11. Säästää yhtenäinen järjestys PTR-tietueet sisältävät taaksepäin suunnatun IP-osoitteen, johon on liitetty ylätason verkkotunnus in-addr.arpa.
Voit myös tarkistaa MX- ja PTR-tietueet komennolla nslookup käyttämällä lisäparametri -type=MX tai -type=PTR
Eikä tietenkään pidä unohtaa, että kaikki muutokset DNS-vyöhykkeet eivät tapahdu välittömästi, vaan useiden tuntien tai jopa päivien kuluessa, jotka ovat välttämättömiä muutosten leviämiseksi maailmanlaajuisessa DNS-järjestelmässä. Tämä tarkoittaa, että vaikka sähköpostipalvelimesi alkaa toimia 2 tunnin kuluttua muutosten tekemisestä, kumppanisi ei välttämättä lähetä sinulle sähköpostia pidempään aikaan.
