Sambaza na ubadilishe hoja za dns. Reverse majina ya vikoa (reverse DNS) na nafasi yao katika uendeshaji wa seva ya barua

Rashid Achilov

Kuunda maeneo ya DNS

Mfumo wa Jina la Kikoa ni aina ya "mfumo wa neva" wa Mtandao. Ni shukrani kwake kwamba unapoandika , unafika kwenye tovuti ya gazeti la "Msimamizi wa Mfumo", na si mahali pengine. Jinsi ya kuunda, kusanidi na kuendesha seva ya DNS kwa biashara ndogo?

Muundo wa DNS

Hivi sasa, mtandao ni mtandao mkubwa unaojumuisha mamilioni ya nodi ziko kote ulimwenguni. Ili ombi lililofanywa kutoka kwa kompyuta moja kufikia lengo lililo kwenye kompyuta nyingine, lengo hili lazima kwanza libainishwe. Unaweza, bila shaka, kutaja anwani ya IP moja kwa moja. Ikiwa unamjua, bila shaka. Lakini hapa inawezekana kufanya makosa kwa urahisi sana - habari kuhusu wapi anwani unayohitaji inaweza kuwa tayari imebadilika, na katika hali nzuri zaidi, utaona ujumbe ambao anwani haikupatikana, na katika hali mbaya zaidi, utakuwa. jipate kwenye tovuti ambayo haina uhusiano wowote na kile kilichohitajika. Itakuwa ya kuaminika zaidi na rahisi kugeukia mfumo unaohifadhi mawasiliano kati ya majina ya ishara kama vile www.site na anwani za IP zinazolingana nazo katika wakati huu(kwa upande wetu 217.144.98.99). DNS ni mfumo kama huo. Kwa kuwa uendeshaji wa mtandao mzima unategemea utendakazi wake wenye mafanikio, mfumo huu unafanya kazi kwa kanuni ya hifadhidata iliyosambazwa - kuna seva 13 "zinazojulikana", pia huitwa seva za "mizizi", zilizo na habari kuhusu seva, zilizo na habari. kuhusu seva nk Kama nyumba ambayo Jack alijenga.

Mtandao wote wa Mtandao, ambao unaelezewa na eneo "." (dot) imegawanywa katika kinachojulikana kama TLDs (Vikoa vya Kiwango cha Juu - vikoa ngazi ya juu), kusambazwa kimatendo au kijiografia. Pia kuna neno kikoa cha msingi - "kikoa cha msingi", au "kikoa cha ngazi ya kwanza", lakini neno hili linatumika mara chache sana. Usambazaji wa kijiografia unafanywa kwa mujibu wa ISO 3166, ambayo huweka kanuni za barua mbili na tatu kwa nchi zote duniani. Ugawaji kwa misingi ya utendaji unafanywa kama inavyohitajika ili kuunda TLD mpya. Ikumbukwe hapa kwamba masuala yote kuhusu TLDs yanashughulikiwa na ICANN (Shirika la Mtandao la Majina na Nambari Zilizotolewa), na ni chombo hiki kinachoamua kama kuunda TLD mpya.

Seva za mizizi zenyewe zina viungo tu vya seva zilizo na taarifa kuhusu maeneo ya ngazi ya pili, ambayo nayo huwa na taarifa kuhusu seva zilizo na taarifa kuhusu maeneo ya ngazi ya tatu, n.k. Mara nyingi, uongozi huishia katika eneo la tatu au la nne. Lakini si kwa sababu kuna aina fulani ya kizuizi hapa. Kukumbuka tu majina changamano si rahisi kuliko anwani za IP.

Kwa hivyo, mchakato wa kutafuta habari, sema, kuhusu seva ya wavuti www.granch.ru, itaonekana kama hii:

Mteja huwasiliana na seva yake ya DNS, anwani ambayo iliwekwa na msimamizi wa mfumo na ombi "Niambie anwani inayolingana. jina www.granch.ru".
Seva ya DNS inajua anwani za seva ambazo inapaswa kuanza kutafuta ikiwa habari iliyoombwa haijahifadhiwa kwenye kashe yake, kwa hiyo inageuka kwa mmoja wao.
Seva ya mizizi inamtuma anwani ya seva inayohusika na zone.ru
Seva ya DNS inafikia seva ya zone.ru
Seva ya zone.ru inamtumia anwani ya seva ambayo inawajibika kwa eneo la nafaka ndani ya eneo lake.
Seva ya DNS inafikia seva ya eneo la granch.ru.
Na mwishowe, seva ya eneo la granch.ru inamwambia anwani inayolingana na jina www. Katika kesi hii itakuwa 81.1.252.58.

Utaratibu huu unaonyeshwa kwenye Mtini. 1, ambapo nambari zinaonyesha mlolongo wa maombi.

Jinsi ya kuunganisha habari yako katika muundo wa DNS?

Kabla ya kujiunga na mfumo wowote, unahitaji kuwa na wazo fulani la wapi na jinsi ya kujiunga.

Tunaipachika wapi?

Seva tofauti zinawajibika kwa TLD tofauti, na ikiwa maeneo ya kijiografia Kama sheria, seva moja (kwa usahihi zaidi, shirika moja) inawajibika, basi vikoa vya kufanya kazi vinaweza kujibiwa, kwa ujumla, na idadi isiyo na kikomo ya wanaoitwa wasajili, ambayo ni, kampuni ambazo zimeingia makubaliano maalum na ICANN ambayo walifanya. itasajili majina katika baadhi ya vikoa vinavyofanya kazi. Maelezo mafupi kikoa cha kazi na anwani ya msajili wake imetolewa katika .

Ikiwa kuna wasajili kadhaa, basi anwani ya moja kuu inatolewa (kwa mfano, VeriSign kwa domain.com). Vikoa vya .gov na .mil vimehifadhiwa kwa ajili ya serikali ya Marekani na mashirika ya kijeshi ya Marekani pekee, na uhifadhi wa .gov umerasimishwa na RFC - RFC 2146 inayolingana. Orodha kamili TLD zote za kijiografia zilizopo kwa sasa, zinazoonyesha msajili wa kikoa na taarifa muhimu ya mawasiliano, zinaweza kutazamwa ndani. Ingawa ikiwa, sema, katika zone.com unaweza kuchagua kutoka kwa orodha kubwa, basi kwa zones.ru na.su RUTSENTR, hakuna chaguzi.

Kuna mambo kadhaa ya kuzingatia hapa. Kwa kweli, zone.su ni ya hali ambayo haipo ya Umoja wa Kisovieti, ingawa bado inaendelea kuhudumiwa na iko wazi kwa usajili. Usajili huko ni ghali kabisa - $100 kwa usajili au usaidizi kwa mwaka.

Hakuna kipaumbele ambapo shirika moja au mtu ana kipaumbele juu ya mwingine wakati wa kusajili kikoa. Mfanyabiashara wa Marekani anayehusika katika utengenezaji wa madirisha ya plastiki alisajili kikoa hicho windows2000.com. Wakati Microsoft ilijaribu kufanya vivyo hivyo, ilishangaa kupata kwamba jina lilikuwa tayari limechukuliwa, na kampuni ilipaswa kulipa kiasi kikubwa. Kuna hata wazo la "cybersquatting" - mchakato wa kusajili vikoa kwa madhumuni ya kuziuza tena. RUTSENTR pia iliamua kuwa na mkono katika hili, na kulingana na sheria mpya, ambazo zilianzishwa mnamo Juni 1, 2006, vikoa vilivyotolewa vinawekwa kwa "mnada wa jina la kikoa" na kuhamishiwa kwa mzabuni wa juu zaidi. Majina hufanyika kwa "mnada" kwa mwaka mmoja; ikiwa hakuna mtu anayedai katika kipindi hiki, jina hutolewa kwa usajili wa bure.

Wakati TLD zilizoorodheshwa hapo juu ziliundwa, TLD .xxx pia ilipangwa kwa tovuti zenye mada za watu wazima. ICANN ilikataa pendekezo hili. Hivi majuzi ilipigiwa kura ya pili na ICANN ikakataa tena. Lakini TLD .tel ilionekana, iliyoundwa kwa ajili ya matumizi wakati huo huo kwenye kompyuta na vifaa vya simu.

Kuna RFC 1480, ambayo inaeleza sheria za kusajili majina katika kikoa cha .us. Sheria hizi ni ngumu sana na zinachanganya na zinahitaji kuundwa kwa majina kutoka viwango 6-7 kama vile Hamilton.High.LA-Unified.K12.CA.US

Je, tunaipachikaje?

Hapo awali, kila kitu kilikuwa ngumu zaidi. Ili kusajili zone.com, ilinibidi kujaza fomu nyingi za maandishi - na data ya shirika, na data ya watu wa mawasiliano... Fomu hizi zilitumwa kwa anwani maalum, ambapo majibu yalitoka - kukubaliwa au la. Kisha faili ya ukanda iliyozalishwa awali ilijaribiwa, na tena ujumbe ulitumwa kwa barua ikiwa majaribio yalifanikiwa au la.

Sasa kila kitu kimekuwa rahisi zaidi. Suluhisho zote za Mtandao na RUTSENTR zimepata miingiliano ya wavuti, kwa usaidizi ambao yote yaliyo hapo juu (isipokuwa, bila shaka, kuunda faili ya eneo) yanaweza kufanywa kwa kubofya chache kwa panya. Data yote inaweza kusahihishwa, kuongezwa au kufutwa wakati wowote. Hapo awali, ilikuwa ni lazima kuhitimisha makubaliano ya huduma na RUCENTER, lakini kuanzia Juni 1, 2006, sheria mpya zinaletwa, kulingana na ambayo ni ya kutosha kujiandikisha kwenye tovuti yao. Wasajili wa kigeni, kama sheria, gharama kadi za mkopo, lakini ikiwa kikoa hakiwezi kusajiliwa kwa sababu yoyote, fedha zitarejeshwa si mapema zaidi ya siku tatu baadaye.

Msajili atahitaji kutoa anwani ya IP na mask ya subnet ya seva ambayo itaendesha programu ya seva ya DNS na ambayo itakuwa na hifadhidata kuu ambayo utaunda na kuhariri inavyohitajika. Seva hii itaitwa seva ya msingi (seva kuu). Kwa kuongeza, utahitaji kutaja angalau anwani moja ya IP ya seva iliyo na nakala ya chelezo msingi katika kesi ya kushindwa kwa seva ya msingi. Seva kama hizo huitwa seva za sekondari (seva za watumwa). Ili usifikirie kwa muda mrefu juu ya mahali pa kuweka DNS ya sekondari, RUCENTER inatoa kuiweka kwenye tovuti yao. Gharama ya huduma za RUCENTER ni $15 kwa mwaka kwa kila kikoa katika kanda .ru, .net, .com, .org, $50 kwa kila kikoa katika kanda .biz, .info, $100 kwa kila kikoa katika zone .su na $5 kwa mwaka kwa msaada DNS ya sekondari katika eneo lolote (pamoja na wale ambao hawajasajiliwa nao).

Kwa nini hitaji la seva ya sekondari ya DNS ni lazima? Kwa kuwa uthabiti wa DNS ni muhimu sana kwa uthabiti wa Mtandao kwa ujumla, mtu au shirika linalosajili kikoa lazima likidhi masharti fulani kuhusu uthabiti wa DNS:

Lazima kuwe na angalau seva mbili zinazohudumia kikoa hiki.
Seva hizi lazima ziwe zinapatikana angalau saa 22 kwa siku.

Kulingana na sheria mpya, hakuna mahitaji ya uwekaji wa seva, ingawa hapo awali ilihitajika kuwa iko kwenye mitandao tofauti ya IP.

www.krokodil.ru

Kwa hiyo, hebu sema tunataka kuunda tovuti www.krokodil.ru (wakati wa kuandika makala hii ilikuwa bure), kujitolea kwa mamba ya kuzaliana nyumbani. Kuna uunganisho wa mstari wa kujitolea, mtandao wa darasa C, yaani 212.20.5.0 - 212.20.5.255 (safu hii kwa sasa ni ya bure) iliyotolewa na mtoa huduma. Mfano huu kwa kiasi fulani hauna sifa ya wakati wa sasa na uhaba wake wa anwani za IP, lakini ulichukuliwa mahususi ili kuzingatia uundaji wa eneo la kinyume. Chaguo la kuunganisha kupitia mtandao wa 212.20.5.0/31 pia litazingatiwa. Mtandao wa ndani wa ofisi yetu ya ufugaji wa mamba una kompyuta sita na utatenganishwa na wakala wa ngome ya mtandao, nk, inayotumia FreeBSD. Tutahitaji nini kutekeleza mipango yetu?

Kwanza kabisa, ninaona kuwa kuna chaguo ambazo hazihitaji ujuzi wowote wa DNS - kila kitu kinapangishwa kwenye tovuti ya mtoa huduma, kila kitu kinahudumiwa na mtoa huduma, hutolewa tu na interface ya mtandao. Huduma hii ni maarufu sana nje ya nchi, lakini iko katika mahitaji kidogo sana nchini Urusi. Maelezo yake ni zaidi ya upeo wa makala hii, kwa hiyo sitayazingatia.

Kwanza, tutahitaji programu ya seva ya DNS. Hadi sasa, programu moja tu inatekeleza seti inayohitajika ya kazi. Hii BIND seva ya DNS, inayosambazwa na ISC (Internet System Consortium Inc.), shirika lisilo la faida ambalo hutengeneza seva za BIND, DHCP, INN na NTP. Ikiwa haipo kwenye mfumo wako, unahitaji kuipakua na kuiweka. Meli za FreeBSD zilizo na BIND 9.3.2, kwa hivyo nakala hii itazingatia toleo hilo. Ikumbukwe kwamba kwa matoleo ya BIND 8.x, maelezo yafuatayo ya usanidi hayafai kabisa kwa sababu umbizo la faili za usanidi za BIND 8.x kimsingi ni tofauti na umbizo la faili za usanidi za BIND 9.x.

Pili, tutahitaji kusambaza anwani za IP zilizotolewa kwetu na kugawa anwani kompyuta za ndani. Kila kitu hapa ni rahisi sana: acha 212.20.5.1 iwe lango la mtoa huduma, 212.20.5.2 iwe anwani ya seva ya UNIX, 10.87.1.0/24 iwe subnet ya ndani, ambayo vituo vya kazi 1 hadi 6 vinapatikana, 254 iwe anwani. kiolesura cha ndani seva. Anwani zilizosalia zitahifadhiwa kwa upanuzi wa siku zijazo.

Tatu, utahitaji faili ya maelezo ya eneo iliyoandaliwa tayari ambayo itafafanua idadi ndogo ya anwani za nje: krokodil.ru - seva ya mizizi ya eneo, www.krokodil.ru, ftp.krokodil.ru, mail.krokodil.ru na ns.krokodil.ru . Jina ns (nameserver) ni karibu jina la jadi kwa kompyuta ambayo huduma ya DNS inaendesha, ingawa, bila shaka, hakuna mtu atakayekuzuia kuiita, kwa mfano jaws.krokodil.ru. Majina pia yatafafanuliwa kwa kompyuta kwenye mtandao wa ndani, kupatikana tu kutoka ndani: tooth1.krokodil.ru - tooth6.krokodil.ru.

Rekodi za DNS

Kuna idadi kubwa ya aina tofauti za rekodi ambazo zinaweza kuwekwa kwenye DNS. Upeo wa makala hii inaruhusu sisi kuzingatia tu muhimu zaidi kati yao, ili kupata habari kamili unapaswa kurejelea RFC zinazohusika: RFC 1033 na RFC 1035 zinafafanua miundo ya rekodi kuu, RFC 1122 umbizo la rekodi ya PTR, RFC 2782 umbizo la rekodi la SRV. Tutazingatia rekodi zile pekee zinazohitajika ili kutengeneza faili za eneo zinazohitajika kwa usajili wa kikoa:

Rekodi ya SOA inayobainisha mwanzo wa maelezo ya eneo.
Rekodi ya NS inayofafanua seva za majina za eneo.
Rekodi ambayo inaweka anwani ya IP kwa jina ( uongofu wa moja kwa moja).
Rekodi ya MX inayoelezea mipangilio ya uwasilishaji barua kwa kompyuta hii.
Rekodi ya CNAME inayobainisha majina mbadala.
Rekodi ya PTR, ambayo inabainisha mawasiliano kati ya jina na anwani ya IP (tafsiri ya kinyume), inatumiwa katika maelezo ya eneo la "reverse".

Umbizo la rekodi ya DNS ni la kawaida kwa aina zote za rekodi:

[jina] [darasa]<тип> <данные>

Jina- hii ni jina la kitu ambacho data inahusishwa;
ttl- maisha ya kitu;
Darasa- darasa la rekodi;
aina- aina ya rekodi;
data- data inayohusishwa na kitu hiki.

Jina linaweza kuchukua thamani yoyote, kwa hali ambayo inachukuliwa kuwa jina la kitu. Ikiwa jina linaisha na dot, basi inachukuliwa kuwa ina sifa kamili, vinginevyo jina la eneo linabadilishwa mwishoni mwa jina, ambalo linaweza kutajwa kwa njia mbili:

Kwa kubainisha jina la eneo katika maagizo ya $ORIGIN, kwa mfano:

$ORIGIN krokodil.ru

Kwa kubainisha jina la eneo katika maagizo ya eneo la faili ya usanidi ya BIND.

Herufi maalum "@" inaonyesha jina la eneo la sasa. Kumbuka kuwa maagizo ya $ORIGIN yanabatilisha maagizo ya eneo na hudumu hadi maagizo yanayofuata ya $ORIGIN yatakapotokea au hadi mwisho wa faili. Hadi agizo la kwanza la $ORIGIN lionekane, linazingatiwa kuwa limewekwa kwa thamani ya maagizo ya eneo katika faili ya usanidi ya BIND.

Ikiwa jina limetolewa, lazima lianze kwenye nafasi ya kwanza ya mstari.

TTL kawaida huachwa na kuwekwa duniani kote kwa maagizo ya $TTL. Maagizo ya $TTL ni ya lazima kwa BIND 9.x na kwa kawaida huwekwa mwanzoni mwa faili. Sehemu ya data ya agizo hili inabainisha muda wa maisha (kwa sekunde) wa kipengele ambacho kinaweza kubaki kwenye akiba na kuchukuliwa kuwa cha kutegemewa. Katika mfano huu, ni siku mbili (saa 48).

$ TTL 172800

Darasa la kuingia linaweza kuwa mojawapo ya maadili yafuatayo:

KATIKA- kurekodi rasilimali za mtandao.
CH- rekodi ya rasilimali za ChaosNet - isiyojulikana kabisa Mtumiaji wa Kirusi mtandao unaotumika kwenye mashine za Alama.
H.S.- Rekodi ya rasilimali ya Hesiod - BIND itifaki ya huduma.

Aina ya rekodi ni mojawapo ya aina zilizoorodheshwa hapo juu.

Tafadhali kumbuka kuwa jina, ttl na sehemu za darasa zinaweza kuachwa. Katika kesi hii, thamani iliyofafanuliwa ya mwisho inachukuliwa kama maadili yao (katika kesi hii, kubainisha @ itakuwa ufafanuzi sahihi), na ikiwa thamani haikufafanuliwa popote, basi kwa uwanja wa darasa thamani ya chaguo-msingi "IN" ni. imekubaliwa, kwa nyanja zingine husababisha ujumbe wa makosa.

Mbali na maingizo, faili ya eneo inaweza kuwa na amri. Kuna amri nne kwa jumla: $TTL, $ORIGIN, $INCLUDE na $GENERATE. Ufafanuzi wa amri ya $GENERATE hutolewa katika nyaraka za programu ya BIND, pamoja na ndani na, amri ya $INCLUDE inafanya kazi kulingana na spelling yake - inajumuisha faili maalum katika faili ya sasa.

Kumbuka: ishara ";" (semicolon) ni alama ya maoni.

Rekodi ya SOA

Ingizo hili linafafanua mwanzo wa eneo. Eneo lolote lazima lianze na ingizo la SOA. Kuonekana kwa ingizo lingine la SOA moja kwa moja humaliza eneo la kwanza na huanza la pili. Fomati ya rekodi ya SOA imeonyeshwa hapa chini. Kwa kweli, rekodi ya SOA hutaja eneo na kuweka chaguo-msingi zake.

2005122001; Nambari ya serial

3600 ; Jaribu tena kila saa

172800); Angalau siku 2

Hebu tuangalie mfano. Ishara ya @ katika sehemu ya jina inamaanisha kuwa ni muhimu kuchukua jina la eneo lililobainishwa hapo awali na maagizo ya $ORIGIN. Darasa la rekodi ni IN, aina ya rekodi ni SOA. SOA ndio ingizo pekee ambalo lina orodha changamano ya vigezo.

Kigezo cha kwanza ni anwani ya seva kuu ya jina la eneo. Katika mfano huu, hii ni krokodil.ru. Kigezo cha pili ni anwani ya barua pepe ya mtu anayehusika na eneo hili. Tafadhali kumbuka kuwa anwani imeandikwa kama "username.domain" na sio "username@domain".

Kigezo cha pili ni orodha ya maadili iliyoambatanishwa kwenye mabano. Kinadharia, inawezekana kuiandika kwa mstari mmoja, lakini katika mazoezi sijaona hii popote; fomu ya nukuu iliyotolewa katika mfano inatumika kila mahali. Orodha hiyo ina vipengele vitano:

Nambari ya serial ya eneo. Kigezo hiki kinacheza sana jukumu muhimu katika kusambaza sasisho lililofanywa kwenye seva ya msingi, kwenye seva zake zote za upili. Lazima kuwe na njia fulani ya kufahamisha seva ya pili kwamba data kwenye seva ya msingi imebadilika. Ikiwa seva ya msingi imewashwa upya, hutuma ARIFA YA DNS kwa seva zote za upili. Baada ya kupokea arifa hii, seva ya pili inaomba nambari ya serial - ikiwa seva ya msingi ina nambari ya serial ya juu kuliko seva ya pili, seva ya pili inatoa amri ya kusasisha eneo. Kwa kuongeza, seva ya pili hufanya ukaguzi wa nambari za serial mara kwa mara kwa madhumuni sawa. Kwa hivyo, unapaswa kukumbuka sheria moja rahisi: ukirekebisha ukanda, ongeza nambari ya serial! Kitendo cha kawaida kati ya wasimamizi wa DNS ni kuunda nambari ya serial kama ifuatavyo: YYYYMMDDv, ambapo:
- YYYY,MM,DD- mwaka wa sasa (tarakimu 4), mwezi na siku, mtawaliwa
- v- toleo la eneo la siku. Ikiwa mabadiliko kadhaa yanafanywa kwa siku, nambari hii inaongezwa kwa moja kwa mfululizo.
Thamani ya kipindi cha sasisho ambacho baada ya hapo seva ya mtumwa lazima iwasiliane na bwana na kuangalia ikiwa nambari ya serial ya eneo imebadilika. Ikiwa nambari ya serial imebadilika, seva ya mtumwa itapakua data mpya. Katika mfano huu, sekunde 10800 (saa 3).
Muda ambao seva ya mtumwa itajaribu kuwasiliana na bwana ikiwa jaribio la kupata nambari mpya ya serial itashindwa. Katika mfano huu, sekunde 3600 (saa moja).
Muda ambao seva za watumwa zitatoa maombi ya eneo fulani katika tukio la kutokuwepo kwa seva kuu kwa muda mrefu. Mfumo unapaswa kufanya kazi hata kama seva kuu haifanyi kazi kwa muda mrefu, hivyo thamani ya parameter hii imewekwa kwa sekunde 1,728,000 (siku 20).
Wakati wa kuweka akiba ya majibu hasi. Katika mfano huu, sekunde 172800 (siku 2).

Ingizo la NS

Ingizo hili linabainisha majina ya seva zinazotumia eneo, i.e. akiongoza msingi wake. Majina ya seva za msingi na zote za upili yanapaswa kuorodheshwa hapa. Kwa kawaida ingizo hili hufuata mara moja ingizo la SOA. Thamani moja imeingizwa kwenye uwanja wa data - jina au anwani ya IP ya seva ya eneo la DNS, bila kujali ni bwana au mtumwa. Majina yote yaliyoainishwa hapa lazima yawe na sifa kamili, yaani, imalize na kipindi!

KATIKA NS ns.krokodil.ru.

KATIKA NS ns4.nic.ru.

Mfano hapo juu unaelezea kwanza seva kuu ya ukanda wetu ns.krokodil.ru, na kisha seva ya mtumwa - node ya RU CENTER ns4.nic.ru.

Rekodi A

Rekodi ya aina A ndio yaliyomo kuu ya faili katika eneo la ubadilishaji wa moja kwa moja, au eneo la "moja kwa moja", ambayo ni, kutoa jina la kompyuta kwa anwani yake. Imeundwa kwa kila kompyuta. Kwa urahisi wa kusomeka, rekodi hizi kwa kawaida huwekwa katika makundi katika mpangilio wa kupanda wa anwani za IP, na pia huwekwa katika makundi na rekodi za MX zinazolingana na anwani fulani ya IP, ingawa hii bila shaka haihitajiki. Katika uwanja wa jina jina lililopewa anwani ya IP limeingizwa, kwenye uwanja wa data - anwani ya IP ambayo jina limepewa. Wakati anwani ina majina ya ziada, jina lililopewa anwani na rekodi A huitwa jina la msingi.

jino1 KATIKA A 10.87.1.1

jino2 KATIKA A 10.87.1.2

jino3 KATIKA A 10.87.1.3

jino4 KATIKA A 10.87.1.4

jino5 KATIKA A 10.87.1.5

jino6 KATIKA A 10.87.1.6

Mfano huu unaelezea ugawaji wa anwani za IP kwa kompyuta kwenye mtandao wa ndani, ambao una anwani 10.87.1.0/24. Kwa kompyuta za mtandao wa ndani, kama sheria, hakuna haja ya kuunda yoyote maingizo ya ziada, isipokuwa uwezekano wa CNAME.

Rekodi ya CNAME

Rekodi ya CNAME ni fursa ya ziada DNS. Inakuruhusu kugawa zaidi ya jina moja kwa anwani moja ya IP. Katika uwanja wa jina, jina la ziada lililopewa anwani ya IP limeingizwa, kwenye uwanja wa data - jina kuu lililotolewa hapo awali na rekodi ya aina A, au jina lingine la ziada lililopewa rekodi ya CNAME. Katika kesi hii, jina katika uwanja wa data ya rekodi inaitwa canonical (kwa hiyo jina la rekodi - Jina la Canonical). Anwani moja ya IP inaweza kupewa idadi isiyo na kikomo ya majina ya ziada kupitia rekodi za CNAME, lakini aina nyingine za rekodi lazima zitumie jina lililotolewa na rekodi A badala ya rekodi ya CNAME. Ifuatayo ni mfano wa mgawo sahihi na usio sahihi wa majina ya ziada.

Haki:

ns KATIKA A 10.87.1.1

jina1 KATIKA CNAME ns

KATIKA MX 10 ns

Si sahihi:

ns KATIKA A 10.87.1.254

jina1 KATIKA CNAME ns

KATIKA MX 10 jina1

Rekodi za CNAME zinaweza kuelekezana, lakini zisizidi viwango saba, ya nane lazima ziwe rekodi inayoelekeza kwa jina lililopewa rekodi ya aina A. Katika fasihi, kuna pendekezo la kutumia rekodi za aina nyingi badala ya kugawa nyingi. majina ya ziada kwa anwani. Kuhusu hili, tunaweza kusema kwamba hatua hii imetajwa katika RFC 2219 kwa suala la "hakuna mapendekezo kamili juu ya suala hili, kila mtu lazima ajiamulie mwenyewe kile kinachofaa zaidi kwao." CNAME nyingi ni rahisi kusimamia, rekodi nyingi za A ni rahisi kushughulikia kwa sababu uelekezaji kwingine hutokea.

Rekodi ya MX

Rekodi ya MX ni sehemu kuu ya pili ya faili ya eneo. Ingizo hili linamaanisha " Barua pepe Exchanger", na inakusudiwa kuonyesha anwani za IP au majina ya kompyuta zinazopokea barua kwa nodi iliyofafanuliwa katika sehemu ya jina. Sehemu hii inaweza kuwa tupu, jina lililohitimu kikamilifu au kiasi. Ikiwa sehemu ya jina haina chochote au jina ambalo halijatimiza masharti kamili limebainishwa, basi jina litaongezwa kutoka kwa maagizo ya $ORIGIN. Kuzalisha rekodi za MX katika kesi ngumu, wakati eneo kubwa na mpango mkubwa wa kupokea barua unasanidiwa, ni kabisa. kazi isiyo ya kawaida, ambayo inaunganishwa kwa karibu na kazi ya programu zinazotumia itifaki ya SMTP kutoa barua, kwa hiyo tutazingatia kesi rahisi tu - barua zote zinapokelewa na seva ya UNIX. Thamani mbili zimeingizwa kwenye uwanja wa data - kipaumbele na jina au anwani ya IP ya kompyuta inayopokea barua iliyotumwa kwa kompyuta hii. Anwani moja ya IP kwa ujumla inaweza kuwa na idadi isiyo na kikomo ya rekodi za MX zinazohusiana nayo, na zote zinapaswa kuwa na vipaumbele tofauti. Barua hupitishwa kulingana na kipaumbele - wakala wa barua hupanga maingizo ili kuongeza kipaumbele na kujaribu kuwasilisha barua kwa njia hiyo. Hebu tuchukulie kuwa tumekubaliana na msimamizi wa nodi ya behemot.ru kwamba tunaweza kutumia seva yake kama nodi ya usafiri ambayo itapokea barua zetu kwa madhumuni ya kuwasilisha kwa wapokeaji wake wakati muunganisho umerejeshwa. Kisha maelezo ya seva ya krokodil.ru yataonekana kama hii:

krokodil.ru. KATIKA A 212.20.5.2

KATIKA MX 10 krokodil.ru.

KATIKA MX 50 behemot.ru.

www KATIKA CNAME krokodil.ru.

barua KATIKA CNAME krokodil.ru.

ftp KATIKA CNAME krokodil.ru.

Huu ni mfano wa kina na unaonyesha mara moja matumizi ya rekodi za MX, A na CNAME. Hapa sisi:

Tunatoa jina la krokodil.ru kwa anwani 212.20.5.2.
Tunaonyesha barua iliyotumwa kwa anwani kama vile [barua pepe imelindwa], itakubali (kwa mpangilio huu):
seva krokodil.ru;
seva behemot.ru.
Tunafafanua majina ya ziada www.krokodil.ru, mail.krokodil.ru na ftp.krokodil.ru. Tafadhali kumbuka kwamba majina yote upande wa kulia yana sifa kamili, yaani, yanaisha na dot. Hili lisipofanywa, thamani ya maagizo ya sasa ya $ORIGIN itabadilishwa kiotomatiki mwishoni mwa jina. Katika kesi hii, hii inaweza kusababisha kuonekana kwa majina kama www.krokodil.ru.krokodil.ru.

Rekodi ya PTR

Hii ni aina maalum sana ya rekodi. Katika mfano wetu, sisi "hasa" tulichukua subnet kamili kuzingatia kesi ya kazi "ya kawaida" na rekodi za PTR. Kesi na mtandao wa 212.20.5.0/31 itajadiliwa baadaye kidogo.

Rekodi ya PTR imeundwa ili kufanya tafsiri ya kinyume cha majina kwa anwani za IP. Mabadiliko kama haya hutumiwa sana katika programu mbalimbali, ambayo hutoa ufikiaji kwa baadhi ya rasilimali za mtandao: hukagua uwiano wa tafsiri za mbele na za kinyume na zinaweza kukataa ufikiaji ikiwa rekodi ya PTR hailingani au haipo. Eneo lililo na rekodi za PTR linaitwa eneo la kutafsiri kinyume, au eneo la "reverse".

Rekodi za PTR hazina uhusiano na A, MX, CNAME, na rekodi zingine zinazoelezea ubadilishaji wa moja kwa moja. Hii ilifanyika kwa makusudi ili kutumia seti sawa ya moduli za programu kwa mabadiliko yote mawili. Hapa, hata hivyo, tunakabiliwa na aina ifuatayo ya utata - jina la kikoa lililohitimu kikamilifu la fomu www.krokodil.ru. "huongeza kipimo" kutoka kushoto kwenda kulia (yaani, nodi hupanuliwa unapopitia maandishi ya jina kutoka kushoto kwenda kulia), na anwani ya IP 212.20.5.2 ni kutoka kulia kwenda kushoto. Ili kuunganisha moduli za programu, mkataba ufuatao ulipitishwa: anwani zote za IP ni majina yaliyojumuishwa katika TLD maalum in-addr.arpa. "Kanda" katika kikoa hiki ni nyati ndogo, na jina la eneo limeandikwa kama anwani ya IP ikisomwa nyuma. Kwa hivyo, "jina" la ukanda wetu wa kinyume litakuwa 5.20.212.in-addr.arpa kwa ukanda wa kinyume ulio na maelezo ya mtandao wa nje na 1.87.10.in-addr.arpa kwa ukanda wa nyuma ulio na maelezo ya mtandao wa ndani.

Kama vile kutumia jina la kikoa lazima ulisajili, ili kutumia tafsiri ya kinyume lazima usajili "eneo" la kinyume na mratibu wa eneo la kinyume. Tofauti na maeneo ya uongofu wa moja kwa moja, kuna mratibu mmoja tu, na usajili naye ni bure. Usajili wa maeneo ya nyuma unashughulikiwa na RIPE NCC. Taarifa zote kuhusu kusajili eneo la nyuma zimetolewa.

Kwa nini unahitaji kusajili eneo la nyuma? Seva ya kiwango cha juu katika ukanda wa in-addr.arpa lazima ijue kwamba ili kutekeleza ombi la kutafsiri kinyume, ni lazima iwasiliane na seva kama hiyo, katika hali hii 212.20.5.2 yetu. Bila shaka, hakuna haja ya kusajili eneo la nyuma la subnet ya ndani popote.

Rekodi ya PTR yenyewe inaonekana rahisi sana - sehemu ya mwisho ya anwani ya IP imeingia kwenye uwanja wa jina, na jina la tafsiri ya moja kwa moja iliyohitimu kikamilifu imeingia kwenye uwanja wa data. Ninakuvutia kwa jambo la mwisho - jina lililoingizwa kwenye uwanja wa data lazima liwe na sifa kamili, kwani rekodi za PTR zenyewe zinafafanua uhusiano kati ya anwani ya IP na jina, haziwezi kupokea habari kutoka popote kuhusu ni eneo gani tafsiri ya moja kwa moja isiyo na sifa kamili. jina linapaswa kupewa.

$ORIGIN 1.87.10.in-addr.arpa

1 KATIKA PTR tooth1.krokodil.ru.

2 KATIKA PTR tooth2.krokodil.ru.

3 KATIKA PTR tooth3.krokodil.ru.

4 KATIKA PTR tooth4.krokodil.ru.

5 KATIKA PTR tooth5.krokodil.ru.

6 KATIKA PTR tooth6.krokodil.ru.

Katika mfano hapo juu, tulibainisha ubadilishaji wa kinyume cha kompyuta kwenye mtandao wa ndani. Kwa seva tutaandika mstari mmoja (in mfano halisi Maagizo ya $ORIGIN hayahitaji kubainishwa, yanatolewa tu ili kuweka wazi ni eneo gani tunazungumza):

$ORIGIN 5.20.212.in-addr.arpa

2 KATIKA PTR krokodil.ru

Ikumbukwe hapa kwamba rekodi za CNAME hazitumiwi kutaja mechi nyingi za kinyume, hivyo wakati wa kuuliza "jina gani linalingana na anwani 212.20.5.2," matokeo yatakuwa krokodil.ru daima, bila kujali idadi ya aliases iliyowekwa kwa ajili yake.

Je, itakuwa tofauti vipi wakati mtoa huduma anatenga block 212.20.5.0/31 badala ya subnet kamili? Kutoka kwa mtazamo wa kutengeneza rekodi zote isipokuwa PTR, hakuna chochote. Utaratibu wa kuunda eneo la moja kwa moja na usajili wake hautegemei idadi ya anwani, hasa kwa kuwa katika hali nyingi hakuna haja ya anwani nyingi. Walakini, kwa suala la rekodi za PTR kuna tofauti. Kuelekea kurahisisha. Au labda sivyo, kulingana na mtoaji. Na iko katika ukweli kwamba kumbukumbu:

lango.krokodil.ru. KATIKA A 212.20.5.1

krokodil.ru. KATIKA A 212.20.5.2

itakuwa kwenye seva yako na kusimamiwa na wewe, lakini maingizo:

1 KATIKA lango la PTR.krokodil.ru.

2 KATIKA PTR krokodil.ru.

lazima iundwe na mtoa huduma, kwa sababu uwezo wa kujiandikisha eneo la nyuma mwenyewe na kusimamia mwenyewe hutolewa tu ikiwa una mtandao wa angalau darasa la C. Hii, kwa upande mmoja, inafanya kazi iwe rahisi - huna. haja ya kujiandikisha na RIPE, lakini kwa upande mwingine, inachanganya mabadiliko katika kumtaja seva lazima kuwasiliana na mtoa huduma kila wakati.

Muundo wa faili

BIND yenyewe, bila shaka, haijali rekodi ziko katika mpangilio gani au zimeumbizwa vipi. Hii ni muhimu tu kwa wale ambao watadumisha ukanda, haswa ikiwa mabadiliko yatafanywa mara kwa mara. Hapa nitaelezea usambazaji wa kanda na faili kama inavyotumika katika maeneo ambayo ninadumisha. Kwa kweli, hii sio agizo pekee linalowezekana, na labda sio bora zaidi. Lakini inafanya kazi.

Kanda za nje na za ndani

BIND 8.x ilikuwa na kasoro moja kubwa sana - haikuruhusu matokeo ya habari kutofautishwa kulingana na mambo yoyote - ilikuwa muhimu ama kuonyesha kile ambacho hakikuwa cha lazima au kuficha kile kilichohitajika. Hakuna kabisa haja ya wateja wa nje kujua kuhusu kuwepo kwa kompyuta kwenye mtandao wa ndani, lakini kwa kuwa hapakuwa na njia ya kutenganisha habari, kompyuta yoyote inaweza kuanzisha muundo wa mtandao wa ndani kupitia maswali ya DNS. BIND 9.x haina kikwazo hiki - hukuruhusu kusambaza maombi kwenye "mionekano" kwa kutumia Orodha za Udhibiti wa Ufikiaji (ACLs). Mionekano inaweza kuwa na majina ya kiholela, kwa kawaida huunda mwonekano wa ndani ambao unaridhishwa na wateja kwenye mtandao mdogo wa ndani, na mwonekano wa nje ambao unaridhishwa na wengine wote. Kumbuka hapa kuwa hii ni eneo moja, inaonyeshwa tofauti - kama sheria, faili za ukanda wa nje zina habari tu ambayo wateja wa nje wanahitaji - kuhusu seva ya nje, kuhusu njia za utoaji wa barua, nk na faili za ukanda wa ndani zinaonyesha. topolojia nzima ya mtandao. Kwa kuongeza, ikiwa eneo la nyuma linaambatana, basi ni muhimu kugawanya habari kuhusu anwani za uongofu wa reverse kwenye faili kwa njia ile ile.

Kwa hiyo, turudi kwenye mfano wetu.

Muundo wa faili utakuwa kama ifuatavyo. Tuna eneo la moja kwa moja krokodil.ru na eneo la nyuma 5.20.212.in-addr.arpa. Kwa kuongeza, ukanda wa nyuma 0.0.127.in-addr.arpa lazima uwepo ili kuhakikisha tafsiri sahihi ya kinyume cha mwenyeji 127.0.0.1. Ukanda huu unahitajika ili kuzuia BIND isijaribu kuuliza seva za mizizi kujihusu, jambo ambalo hutokea wakati 127.0.0.1 inaelekeza kwa "localhost." Rekodi ya ubadilishaji wa moja kwa moja 127.0.0.1 localhost.krokodil.ru itaandikwa kwa faili ya ubadilishaji wa moja kwa moja ya eneo la ndani. Ili sio kupakia mtandao na uhamisho wa data isiyo na maana, rekodi tofauti za SOA hutumiwa kwa maeneo ya nje na ya ndani - rekodi katika maeneo ya nje hubadilika mara chache sana, na katika maeneo ya ndani mara nyingi kabisa. Kwa hivyo tunayo faili zifuatazo:

localhost.rev- faili ya eneo la ubadilishaji 0.0.127.in-addr.arpa. Faili hii inapatikana kwa uwakilishi wa ndani pekee.
zone212.rev- faili ya eneo la ubadilishaji 5.20.212.in-addr.arpa.
zone10.rev- faili ya eneo la ubadilishaji wa ndani 1.87.10.in-addr.arpa.
direct-krokodil-ru.int- faili ya ndani ya eneo la uongofu wa moja kwa moja krokodil.ru.
moja kwa moja-krokodil-ru.ext- faili ya ukanda wa uongofu wa moja kwa moja wa nje krokodil.ru.
krokodil-ru-int.soa- faili iliyo na rekodi za SOA na NS kwa maeneo ya ndani.
krokodil-ru-ext.soa- faili iliyo na rekodi za SOA na NS kwa maeneo ya nje.

Licha ya orodha kubwa, faili ni fupi sana, kwa hivyo zinawasilishwa hapa kwa ukamilifu, isipokuwa maoni.

Wacha tuandike kidokezo kimoja kuhusu jina la mwenyeji. RFC 1912 inataja haswa kuweka faili za kutatua hadi 127.0.0.1 na localhost. Katika mfano wetu, eneo la mwenyeji hutii RFC 1912, ingawa katika maisha halisi inawezekana kabisa kukumbana na azimio la jina 127.0.0.1 localhost.domain.tld na azimio linalolingana la kinyume.

Faili ya Localhost.rev. Hutumia rekodi moja ya SOA pamoja na eneo la ubadilishaji wa ndani:

$ INGIZA /etc/namedb/krokodil-ru-int.soa

1 IN PTR mwenyeji wa ndani.

Faili zone212.rev:

1 KATIKA lango la PTR.krokodil.ru.

2 KATIKA PTR krokodil.ru.

Faili zone10.rev:

$ INGIZA /etc/namedb/krokodil-ru-int.soa

1 KATIKA PTR tooth1.krokodil.ru.

2 KATIKA PTR tooth2.krokodil.ru.

3 KATIKA PTR tooth3.krokodil.ru.

4 KATIKA PTR tooth4.krokodil.ru.

5 KATIKA PTR tooth5.krokodil.ru.

6 KATIKA PTR tooth6.krokodil.ru.

Faili direct-krokodil-ru.int:

$ INGIZA /etc/namedb/krokodil-ru-int.soa

krokodil.ru. KATIKA A 10.87.1.254

KATIKA MX 10 krokodil.ru.

www KATIKA CNAME krokodil.ru.

barua KATIKA CNAME krokodil.ru.

wakala KATIKA CNAME krokodil.ru.

ftp KATIKA CNAME krokodil.ru.

ns KATIKA CNAME krokodil.ru.

mwenyeji. KATIKA A 127.0.0.1

jino1 KATIKA A 10.87.1.1

jino2 KATIKA A 10.87.1.2

jino3 KATIKA A 10.87.1.3

jino4 KATIKA A 10.87.1.4

jino5 KATIKA A 10.87.1.5

jino6 KATIKA A 10.87.1.6

Faili direct-krokodil-ru.ext:

$ INGIZA /etc/namedb/krokodil-ru-ext.soa

krokodil.ru. KATIKA A 212.20.5.2

KATIKA MX 10 krokodil.ru.

KATIKA MX 50 behemot.ru.

www KATIKA CNAME krokodil.ru.

barua KATIKA CNAME krokodil.ru.

ftp KATIKA CNAME krokodil.ru.

lango KATIKA A 212.20.5.1

Faili krokodil-ru-int.soa:

@ IN SOA krokodil.ru. hostmaster.krokodil.ru. (

2006051202 ; Nambari ya serial

10800 ; Onyesha upya kila masaa 3

3600 ; Jaribu tena kila saa

1728000; Muda wake unaisha kila baada ya siku 20

172800); Angalau siku 2

KATIKA NS krokodil.ru.

Faili krokodil-ru-ext.soa:

$ TTL 172800

@ IN SOA korkodil.ru. hostmaster.krokodil.ru. (

2005122001; Nambari ya serial

10800 ; Onyesha upya kila masaa 3

3600 ; Jaribu tena kila saa

1728000; Muda wake unaisha kila baada ya siku 20

172800); Angalau siku 2

KATIKA NS krokodil.ru.

KATIKA NS ns4.nic.ru.

Hitimisho

Jinsi ya kuunda, kusanidi na kuendesha seva ya DNS kwa biashara ndogo? Kwa kweli, sio ngumu kama inavyoonekana mwanzoni - inatosha kupitia njia hii mara moja, vitendo zaidi vitatokea "moja kwa moja".

Maombi

Vikoa vya kiwango cha juu

Hapo awali, kulingana na RFC 920, orodha ya TLDs zinazofanya kazi ilijumuisha tu .com, .gov, .mil, .edu, .org, ambayo kwa mtiririko huo iliwakilisha biashara, serikali, kijeshi, taasisi za elimu na mashirika yasiyo ya faida. Baadaye, orodha hii ilipanuka kwa kiasi fulani - mnamo 1985, TLD .net iliongezwa, ikiwakilisha mashirika ya wasambazaji. huduma za mtandao, na mwaka wa 1988 - TLD .int, inayowakilisha mashirika ya kimataifa. Mnamo 2001-2002, haijulikani kwa mtumiaji wa Kirusi TLDs .aero, .biz, .cat, .coop, .jobs, .mobi, .museum, .name, .pro na .travel ziliongezwa kwenye orodha hii. Zaidi maelezo ya kina inatolewa ndani. Vikoa vya kijiografia vinasambazwa mara moja na kwa wote. Ingawa hii haimaanishi kuwa huwezi kusajili kikoa chako nayo. Vikoa vingi vya kijiografia ambavyo vinapatana na vifupisho "vinavyojulikana" vinavutia sana. Kwa mfano, .md (Moldova) inavutia sana kwa taasisi za matibabu na wakazi wa Maryland, Marekani; .tv (Tuvalu) - kwa tovuti zinazohusiana na televisheni; .tm (Turkmenistan) inaambatana na tahajia ya kifupi cha "Trade Mark", na .nu (Niue - kuna koloni la kisiwa kama hicho) - kwa tovuti katika mtindo wa "uchi".

http://www.ripe.net.

http://www.ripe.net/rs/reverse/rdns-project/index.html.

Nemeth E, Snyder G, Seabass S, Hayne TR. UNIX: Mwongozo wa Msimamizi wa Mfumo. Kwa wataalamu/Trans. kutoka kwa Kiingereza – St. Petersburg: Peter; K .: BV Publishing Group, 2002 - 928 pp.: mgonjwa.

Cricket Liu, Paul Albitz, DNS na BIND, Toleo la Tatu, 1998 (O'Reilly, ISBN 1-56592-512-2).

Mfumo wa Jina la Kikoa ndio msingi mtandao wa kisasa. Watu hawataki kujisumbua kwa kukumbuka seti ya nambari 63.245.217.105, lakini wanataka kompyuta iwaunganishe kwenye nodi maalum kwa kutumia jina mozilla.org. Hivi ndivyo seva za DNS hufanya: hutafsiri maombi ya watu katika muundo wa dijiti ambao wanaweza kuelewa. Hata hivyo, katika baadhi ya matukio, anwani ya IP ya kinyume → ubadilishaji wa jina la DNS inaweza kuhitajika. Majina kama haya yatajadiliwa hapa chini.

Ni ya nini?

Upatikanaji wa r iliyosanidiwa kwa usahihi Anwani ya DNS na ni muhimu kabisa kutuma ujumbe kutoka kwako seva mwenyewe barua ya kampuni. Takriban seva zote za barua zitakataa ujumbe mwanzoni mwa kipindi ikiwa anwani ya IP ya seva yako haina ingizo katika ukanda wa DNS wa kinyume. Sababu ya kushindwa kwa seva ya barua pepe ya mbali itaonyeshwa kama ifuatavyo:
550-"Anwani ya IP haina rekodi ya PTR (anwani ya jina) katika DNS, au wakati rekodi ya PTR haina rekodi inayolingana ya A (jina la kushughulikia). Pls angalia na urekebishe rekodi yako ya DNS."

au
550-Hakuna PTR inayolingana ya anwani yako ya IP (IP-anwani), ambayo inahitajika 550. Samahani, kwaheri.

au kwa urahisi
550 IP yako haina Rekodi ya PTR

Nambari 550 katika visa vyote vitatu ni msimbo wa kawaida wa posta Seva ya SMTP a, kuripoti hitilafu kubwa ambayo inazuia kazi zaidi ndani ya kipindi hiki cha barua. Ni lazima kusema kwamba kwa ujumla makosa yote ya mfululizo wa 500 ni muhimu na haiwezekani kuendelea kutuma barua baada ya kuonekana. Maandishi yanaelezea sababu ya kukataa kwa undani zaidi na inasema kwamba msimamizi wa seva ya barua ya mpokeaji ameisanidi ili kuangalia ikiwa seva ya barua inayotuma ina kiingilio katika ukanda wa nyuma wa DNS (rDNS) na ikiwa haipo, mpokeaji. seva inalazimika kukataa muunganisho wa mtumaji (makosa ya mfululizo wa SMTP- 5XX).

Jinsi ya kuanzisha na kutumia?

Mmiliki pekee wa kizuizi kinacholingana cha anwani za IP ambazo eneo hili linalingana ndiye ana haki ya kusanidi ukanda wa DNS wa kinyume. Kama sheria, mmiliki huyu ndiye mtoaji, ambaye anamiliki mfumo wake wa uhuru. Pata maelezo zaidi kuhusu kusajili yako mfumo wa uhuru(AS) na kizuizi cha anwani ya IP kinaweza kusomwa katika nakala hii. Kwa kifupi, kusajili ukanda wa reverse DNS, operator wa kuzuia anwani ya IP lazima ajiandikishe katika yake akaunti ya kibinafsi kwenye tovuti ya RIPE, kitu cha aina ya "kikoa", taja anwani ya seva za DNS ambazo zitasaidia eneo la rDNS na kusanidi usaidizi wa eneo kama 3.2.1.in-addr.arpa juu yao. Kielelezo, rekodi ya PTR, inawajibika kwa rasilimali katika ukanda wa nyuma. Hapa ndipo maombi huenda ili kutatua anwani ya IP kuwa jina la mwenyeji.

Ikiwa wewe si mmiliki mwenye furaha wa mfumo wa uhuru, kisha kuanzisha rDNS kwa anwani ya IP au anwani za seva ya barua kwako huanza na kuishia na ombi kwa huduma ya usaidizi ya mtoa huduma au mwenyeji. Katika visa vyote viwili, jina la anwani ya IP ya seva ya barua, na haswa seva ya barua ya kampuni, inapaswa kutolewa kwa maana.

Mifano ya majina mazuri kwa seva ya barua:

mail.domain.ru
mta.domain.ru
mx.domain.ru

Mifano ya majina mabaya:

mwenyeji-192-168-0-1.domain.ru
mteja192-168-0-1.domain.ru
vpn-dailup-xdsl-clients.domain.ru

na kadhalika. Majina kama haya yana uwezekano mkubwa wa kuchujwa kama yalivyopewa kompyuta za mteja, ambayo seva ya barua haiwezi kusakinishwa, kwa hiyo barua taka hutumwa kutoka kwao.

Unaweza na unapaswa kutumia maswali kwa mafanikio kubadilisha kanda za DNS mara tu baada ya kuanzisha seva ya barua. Ili kufanya hivyo, unahitaji tu kufanya mpangilio mdogo KWA. Katika seva tofauti za barua, kusanidi ukaguzi wa rDNS hufanywa kwa njia tofauti:

kwa hivyo kwa seva ya barua ya Postfix unahitaji kuwezesha chaguo
kataa_mteja_asiyejulikana

katika seva nyingine maarufu ya barua pepe Exim
thibitisha = reverse_host_lookup

Seva ya Kubadilishana ya MS
Katika snap-in ya Seva ya Exgange, nenda kwenye sehemu ya Seva, kisha chagua seva katika orodha iliyopanuliwa, chagua Itifaki, kisha itifaki ya SMTP, chagua seva ya SMTP kwenye dirisha la kulia na bonyeza-click na uchague kutoka kwenye orodha ya Mali. Ifuatayo, kichupo cha Uwasilishaji → Fanya ukaguzi wa kubadilisha DNS kwenye ujumbe unaoingia

Sasa ujumbe wote kutoka kwa anwani za IP ambazo hazina rekodi ya DNS ya nyuma (rekodi za aina ya PTR) zitakataliwa, na mtiririko wa barua taka utapungua kwa kiasi kikubwa. Labda hii ndiyo njia rahisi zaidi, yenye ufanisi zaidi na inayotumia rasilimali kidogo kati ya mbinu zote za kuchuja barua taka: kuangalia upya kwa DNS kunapunguza idadi kubwa ya barua taka zinazotumwa kutoka kwa kompyuta zilizoambukizwa za watumiaji wa kawaida wanaounda botnets za watumaji taka.

Wakati wa kuchapisha upya makala, kusakinisha kiungo kilichoonyeshwa kwenye faharasa kwa chanzo - tovuti inahitajika!

Misingi

Rekodi ya nyuma ya eneo la DNS ni nini?

Hoja za kawaida za DNS huamua anwani ya IP isiyojulikana kwa jina la mpangishi anayejulikana. Hii ni muhimu wakati, kwa mfano, kivinjari kinahitaji kuanzisha muunganisho wa TCP na seva kwa kutumia URL iliyoingia kwenye uwanja wa anwani.

Forum.hetzner.de --> 213.133.106.33

Reverse DNS inafanya kazi kwa upande mwingine - hoja huamua jina la mwenyeji ambalo ni la anwani ya IP.

213.133.106.33 --> dedi33.your-server.de

Kama unavyoona, sio lazima majina ya wapangishi wa mbele na nyuma yawe sawa!

Je, madhumuni ya rekodi ya ukanda wa DNS kinyume ni nini?

traceroute haionyeshi tu anwani za IP, bali pia majina ya wapangishi yanayosomeka na binadamu. Hii inafanya kuwa rahisi sana kutambua makosa.
Idadi kubwa ya seva za barua hukubali tu ujumbe ikiwa anwani ya IP ya mtumaji ina rekodi ya DNS ya kinyume.
Rekodi za kubadilisha DNS zinaweza kutumika katika rekodi za SPF (Mfumo wa Sera ya Mtumaji; teknolojia inayozuia barua taka na virusi kutumwa kutoka kwa barua pepe bandia).

Utafutaji wa nyuma hufanyaje kazi kitaalam kwenye seva za DNS?

Fanya mazoezi

Ninawezaje kugawa majina mengi kwa anwani yangu ya IP ikiwa vikoa tofauti vimepangishwa kwenye seva yangu?

Hili haliwezekani. Jina moja tu limepewa kila anwani ya IP.

Kwa kuongezea, haijalishi ni maeneo gani ya nyuma yaliyosajiliwa kwa seva. Ili kufikia tovuti, kivinjari kinahitaji tu kufanya ubadilishaji wa moja kwa moja (Jina --> IP). Kunaweza, bila shaka, kuwa na majina mengi, kama vile rekodi nyingi za A au rekodi nyingi za CNAME zinazoelekeza kwenye rekodi A.

Ili seva za barua zifanye kazi, si lazima kuwa na majina mengi ya seva pangishi kwa kila anwani ya IP. Rekodi ya DNS ya kinyume lazima ilingane na jina la mpangishaji la seva ya SMTP (rejelea mipangilio ya seva inayolingana ya SMTP).

Ikiwa vikoa vingi vinadhibitiwa kupitia anwani ya IP (kesi ya kawaida), unaweza kutumia jina lisiloegemea upande wowote ambalo halihusishwi na vikoa vya watumiaji. Vichungi vya barua taka huangalia tu ikiwa rekodi ya DNS ya kinyume inalingana na jina katika jibu la amri ya HELO. Hii haina athari majina ya vikoa na anwani za posta katika barua zinazotumwa.

Rekodi ya nyuma ya DNS lazima ilingane na jina la seva ya barua au iwe kulingana na anwani ya IP.
Rekodi ya nyuma ya DNS lazima pia isuluhishe "sambaza" kwa anwani sawa ya IP.
Rekodi ya DNS ya kinyume haipaswi kuwa sawa na inayozalishwa kiotomatiki, kama vile "162-105-133-213-static.hetzner.de", kwa vile majina kama hayo mara nyingi hukadiriwa vibaya na vichujio vya barua taka.
Jina lililopewa lazima liwepo. Tafadhali usitumie majina ya vikoa ambayo hayapo.

Mfano wa kiingilio kizuri:

Srv01.grossefirma.de --> 213.133.105.162 213.133.105.162 --> srv01.grossefirma.de > telnet 213.133.105.162 25 220 srvs readyTPa.de

Niliweka PTR kwenye seva yangu ya DNS. Kwa nini hii haifanyi kazi?

Seva yako ya DNS inawajibika tu kwa utatuzi wa mbele.

Mmiliki wa kizuizi cha anwani ya IP (km Hetzner Online GmbH) ana jukumu la kudumisha seva za DNS zilizoidhinishwa kwa maingizo ya kinyume.

Rekodi za kubadili DNS zinaweza tu kuundwa kwa kutumia kitendakazi sambamba cha jopo la Roboti ( menyu ya kushoto-> "Seva" -> bofya kwenye seva -> "IPs" -> bofya kwenye sehemu ya maandishi karibu na anwani ya IP).

Maandishi ya seva yangu ni tofauti na HELO ya seva yangu ya barua. Je, hili ni tatizo?

Mfano: Badilisha rekodi ya DNS kwa anwani ya IP ya seva "www.grossefirma.de". Kwa kujibu amri ya HELO, seva ya barua hujibu kwa "mail.grossefirma.de".

Baadhi ya vichungi vya barua taka huainisha barua pepe kutoka kwa watumaji kama vile "spam". Utofauti huo lazima urekebishwe. Rekodi ya DNS ya kinyume na jina la seva ya barua lazima liwe sawa. Katika mfano hapo juu wanaweza kuwa, kwa mfano, "srv01.grossefirma.de". Jina "www.grossefirma.de" linaweza kuelekezwa kwa srv01.grossefirma.de bila matokeo yoyote kwa kutumia rekodi ya CNAME.

Upimaji wa kina wa rekodi za DNS unaweza kufanywa kwa kutumia

Kuendelea mada ya ujenzi wa tovuti, hebu tuzungumze juu ya kipengele muhimu kama uendeshaji wa mfumo wa jina la kikoa - DNS. Masuala mengi yanayohusiana na uwekaji wa awali, pamoja na uhamisho wa tovuti kati ya seva tofauti na mwenyeji. Kuelewa jinsi mfumo wa jina la kikoa unavyofanya kazi hurahisisha kudhibiti vikoa vyako na tovuti zinazohusiana na huduma zingine.

Jina la kikoa ni nini? Kwa wengi, hii ni sawa na anwani ya tovuti, kwa mfano, www.tovuti. Kwa kuandika anwani hii, una uhakika kabisa kwamba utaishia kwenye tovuti hii na si mahali pengine. Wakati huo huo, jina la kikoa linaweza kuteua sio tovuti tu, bali pia seva ya barua pepe, seva fupi ya ujumbe, au huduma nyingine ya mtandao na mtandao. Majina ya vikoa yanajumuishwa katika kanda za kikoa, ambazo ziko ndani ya kila mmoja kwa mpangilio wa hali ya juu.

Kwa maana ya jumla, kikoa ni jina la ishara ambalo hukuruhusu kushughulikia kwa njia ya kipekee nafasi ya majina inayojiendesha kwenye Mtandao. Na sio tu anwani, lakini pia kuruhusu mteja yeyote kupata haraka node inayohitajika, bila hata kuwa na wazo kidogo kuhusu eneo lake. Sio kutia chumvi kusema kwamba mfumo wa DNS ndio msingi mtandao wa kisasa mtandao kwa namna ambayo sote tunaijua na tumeizoea.

Mfumo wa DNS ni wa kimataifa na una safu kali. Fikiria mchoro ufuatao:

Kiwango cha juu cha uongozi ni kikoa cha mizizi, kinachoonyeshwa na nukta, ambayo ina taarifa kuhusu vikoa vya ngazi ya kwanza, k.m. ru, com, org Nakadhalika. Kazi ya eneo la mizizi inahakikishwa na seva 13 za mizizi ziko ulimwenguni kote na kuiga data zao kila wakati. Kwa kweli, kuna seva nyingi za mizizi, lakini vipengele vya itifaki vinakuwezesha kutaja nodes 13 tu za kiwango cha juu, hivyo scalability na uvumilivu wa makosa ya mfumo huhakikishwa na vioo vya kila seva ya mizizi.

Vikoa vya kiwango cha kwanza tunazifahamu kanda za kikoa na inaweza kusimamiwa na mashirika ya kitaifa na kimataifa na kuwa na masharti yao ya matumizi. Kila eneo la kikoa cha ngazi ya kwanza hukuruhusu kuweka idadi isiyo na kikomo ya vikoa vya kiwango cha pili, ambavyo vinajulikana kwa kila mtumiaji wa Mtandao kama anwani za tovuti.

Kwa upande mwingine, vikoa vya kiwango cha pili pia ni kanda za kikoa na hukuruhusu kuweka vikoa vya kiwango cha tatu, ambamo, kama vile kwenye mwanasesere wa kiota, unaweza kuweka vikoa vya nne, tano, n.k. viwango. Ili kuwa na uwezo wa kutambua bila shaka nodes ziko katika kanda tofauti, dhana jina la kikoa lililohitimu kikamilifu (FQDN, Jina la Kikoa Lililohitimu Kamili), ambayo inajumuisha majina yote ya vikoa vya mzazi katika daraja la DNS. Kwa mfano, kwa tovuti yetu FQDN itakuwa: tovuti. Vivyo hivyo, kumalizia na kitone kinachoonyesha eneo la mizizi.

Hii ni sana hatua muhimu. Katika matumizi ya kila siku, ni kawaida kukataa kipindi cha ufuatiliaji, lakini katika rekodi za DNS kutokuwepo hatua ya mwisho inamaanisha kuwa jina hili la kikoa ni la eneo la kikoa la sasa, i.e. Seva ya DNS itaongeza kwa jina hili eneo lake la kikoa na kanda zote za kiwango cha juu hadi mzizi.

Kwa mfano, kwenye seva yetu katika ukanda tovuti tunaongeza rekodi ya aina ya CNAME ambayo itaelekeza seva ya mtu wa tatu, sema, barua ya Yandex. Ingizo sahihi linapaswa kuonekana kama hii:

Barua pepe CNAMEdomain.mail.yandex.net.

Katika hali hii, jina la barua si FQDN na litapanuliwa hadi mail.tovuti., ikiwa tunasahau kuweka kipindi mwishoni mwa jina la kikoa cha Yandex, basi jina hili pia halitachukuliwa kuwa FQDN na lazima likamilike kwa jina kamili la kikoa. Ifuatayo ni ingizo lisilo sahihi:

Barua pepe KWA CNAME domain.mail.yandex.net

Ni ngumu kugundua tofauti na jicho lisilofunzwa, lakini badala ya kiolesura cha wavuti cha Yandex, muundo huu utatutuma kwa anwani ambayo haipo: domain.mail.yandex.net.site.

Kitu kimoja zaidi. Rekodi zote za eneo la kikoa huingizwa na wasimamizi wa eneo kwenye seva zao za DNS, rekodi hizi zinajulikanaje kwa mfumo wa DNS? Baada ya yote, hatujulishi seva za DNS za kiwango cha juu kwamba tumebadilisha rekodi yoyote.

Ukanda wowote wa DNS una rekodi kuhusu nodi za wanachama na kanda za watoto pekee. Taarifa kuhusu nodi katika eneo la chini ya mkondo huhifadhiwa kwenye seva zake. Hii inaitwa uwakilishi na hukuruhusu kupunguza mzigo kwenye seva za mizizi na kutoa uhuru unaohitajika kwa wamiliki wa kanda za kikoa cha watoto.

Kwa hivyo ulinunua kikoa, wacha tuseme mfano.org, baada ya hapo lazima uikabidhi, i.e. bainisha seva za majina (seva za DNS) ambazo zitakuwa na rekodi za eneo hili la faili. Hizi zinaweza kuwa seva zako mwenyewe au huduma za umma, kwa mfano, Yandex DNS.

Katika kesi hii, katika eneo la kikoa org kiingilio kitaongezwa:

Mfano KATIKA NS dns1.yandex.net.

Ambayo itaonyesha kuwa rekodi zote za eneo hili ziko kwenye seva dns1.yandex.net. Kulingana na sheria, kila eneo la kikoa lazima liwe na angalau seva mbili za NS ziko ndani subnets tofauti. Kwa mazoezi, mara nyingi hufanya kazi na seva moja, wakinunua anwani mbili za IP kutoka kwa safu tofauti.

Sasa hebu tuangalie jinsi utafutaji wa rekodi ya DNS tunayohitaji hutokea na kwa nini rekodi iliyofanywa kwenye seva yako inaruhusu wageni kutoka popote duniani kufikia tovuti yako.

Wacha tuseme mtumiaji anataka kutembelea rasilimali maarufu ya Soko la Yandex, anaandika jina la tovuti linalolingana kwenye upau wa anwani wa kivinjari na bonyeza kitufe cha Ingiza. Ili kuonyesha yaliyomo kwenye ukurasa kwa mtumiaji, kivinjari lazima kitume ombi kwa seva ya wavuti inayohudumia tovuti, na kwa hili unahitaji kujua anwani yake ya IP. Kwa hiyo, kivinjari huwasiliana na mteja wa DNS ili kujua ni anwani gani inayofanana na jina la kikoa lililowekwa na mtumiaji.

Kwa upande wake, mteja wa DNS huangalia maingizo kwenye faili ya majeshi, kisha kwenye cache ya ndani na, bila kupata maingizo muhimu huko, hupitisha ombi kwa seva ya DNS iliyotajwa katika mipangilio ya mtandao. Hii ina uwezekano mkubwa kuwa seva mbadala ya DNS ya ndani kama vile dnsmasq au seva ya DNS ya biashara ya karibu. Suluhisho hizi kawaida sio seva kamili za mfumo wa DNS wa ulimwengu na sio sehemu yake, hutumikia eneo la kawaida tu na ombi la DNS, kwa hivyo ombi kama hilo, ikiwa data haiko kwenye kashe, huhamishiwa kwa hali ya juu. -level DNS seva, kwa kawaida seva ya mtoaji.

Baada ya kupokea ombi, seva ya mtoa huduma itaangalia rekodi mwenyewe, basi kashe yake mwenyewe, na ikiwa matokeo yanapatikana, itaripoti kwa mteja, vinginevyo seva italazimika kuamua kujirudia- tafuta katika mfumo wa kimataifa wa DNS. Ili kuelewa vizuri utaratibu wa mchakato huu, tumeandaa mchoro ufuatao:

Kwa hivyo, mteja hutuma ombi la DNS kwa seva ya mtoa huduma ili kujua anwani ya kikoa market.yandex.ru, seva ya mtoaji haina habari kama hiyo, kwa hivyo inawasiliana na moja ya seva za mizizi, ikipitisha ombi kwake. Seva ya mizizi pia haina rekodi zinazohitajika, lakini inajibu kuwa inajua seva inayohusika na eneo hilo ru - a.dns.ripn.net. Pamoja na jina hili, seva ya mizizi inaweza kuripoti anwani yake ya IP mara moja (na katika hali nyingi itafanya), lakini haiwezi kufanya hivyo ikiwa haina habari kama hiyo, kwa hali ambayo, kabla ya kuwasiliana na seva hii, utahitaji fanya moja zaidi swali la kujirudia, ili tu kuamua jina lake.

Baada ya kujua anwani ya seva inayohusika na eneo la ru, seva ya mtoaji itatuma ombi kwake, lakini seva hii pia haina rekodi zinazohitajika, lakini itaripoti eneo hilo ni nini. yandex seva inajibu ns1.yandex.ru Na Lazima atatoa anwani yake. Vinginevyo, kujirudia hakutaweza kukamilika, kwani eneo hilo yandex seva iliyo katika eneo inajibu yandex. Ili kufanya hivyo, katika ukanda wa juu, pamoja na rekodi ya NS kuhusu seva za jina zinazohudumia ukanda, a. "zilizounganishwa" A-rekodi, ambayo hukuruhusu kujua anwani ya seva kama hiyo.

Hatimaye, kwa kutuma ombi kwa seva inayohudumia eneo yandex, seva ya mtoa huduma itapokea anwani ya kikoa kinachohitajika na kuripoti kwa mteja. Pia itaweka matokeo yanayotokana na akiba kwa muda uliobainishwa na thamani ya TTL kwenye rekodi ya SOA ya kikoa hiki. Kwa mazoezi, kwa kuwa maswali ya kujirudia ni ghali sana, muda wa kuhifadhi kumbukumbu kwa watoa huduma unaweza kupuuza thamani za TTL za kikoa na kufikia maadili kutoka saa mbili hadi nne hadi siku kadhaa au hata wiki.

Sasa hebu tuangalie jambo moja zaidi. Hoja zinaweza kuwa za kujirudia au zisizojirudia. Ombi la kurudia hutoa kwa kupata jibu tayari, i.e. Anwani za IP au ujumbe ambao kikoa haipo, haijakabidhiwa, nk. Ombi lisilojirudia hutoa jibu tu kuhusu eneo ambalo seva iliyotolewa inawajibika au hurejesha hitilafu.

Kwa kuwa hoja zinazojirudia zinatumia rasilimali nyingi, seva nyingi za DNS huchakata maswali yanayojirudia bila kujirudia. Au wanaweza kufanya hivi kwa kuchagua, kwa mfano, seva za DNS za mtoaji hufanya maswali ya kujirudia tu kwa wateja wao, na mengine bila kujirudia.

Kwa upande wetu, mteja alituma ombi la kujirudia kwa seva ya mtoa huduma, ambayo, kwa upande wake, ilituma maombi yasiyo ya kujirudia mpaka ikapata seva inayohitajika, ambayo ilitoa jibu linalohitajika. Wakati huo huo, sio tu matokeo ya ombi la mtumiaji, lakini pia matokeo ya maombi ya kati yanawekwa kwenye kashe ya seva ya mtoaji, ambayo inaruhusu maombi kama haya kutekelezwa bila kujirudia au kwa idadi ndogo ya maombi. .

Kwa mfano, ikiwa mtumiaji, baada ya kutembelea Soko la Yandex, anaamua kutumia huduma ya barua, seva itatuma ombi mara moja kwa ns1.yandex.ru, kwani tayari inajua ni seva gani iliyo na rekodi za eneo hilo yandex.

Kutoka kwa nadharia hadi mazoezi

Unapotununua kikoa kutoka kwa msajili, utaulizwa kuikabidhi, i.e. taja seva za DNS ambazo eneo la kikoa litapatikana. Hizi zinaweza kuwa seva za msajili (kawaida bila malipo), seva za mwenyeji, huduma za DNS za umma au seva zako za jina; ikiwa iko katika eneo la kikoa sawa, basi utahitaji pia kutaja anwani za IP. Kwa mfano, hivi ndivyo dirisha la uwakilishi wa kikoa linavyoonekana kwa msajili mmoja anayejulikana:

Niweke nini hasa hapo? Inategemea wapi na jinsi gani utakaribisha tovuti yako. Ikiwa unatumia mwenyeji wa pamoja, basi rekodi zote muhimu zinaundwa na mhudumu moja kwa moja, unapoongeza tovuti yako kwenye jopo la udhibiti wa mwenyeji, unachohitaji ni kukabidhi kikoa kwa seva ya NS ya mwenyeji, i.e. zionyeshe kwenye dirisha hili. Njia hii inafaa kwa Kompyuta kutokana na unyenyekevu wake, lakini pia kuna upande wa chini: uwezo wa kudhibiti eneo la DNS kwa upande wa mtumiaji haipo au ni ndogo. Kwa kuongeza, kwenye mwenyeji wa pamoja, anwani ya IP ya tovuti inaweza kubadilishwa na wasimamizi bila kumjulisha mtumiaji, hivyo ikiwa hutaki kutumia seva ya NS ya mwenyeji, basi suala hili lazima lijadiliwe kwa msaada wa kiufundi.

Ikiwa unahamisha tovuti kwa mhudumu mwingine, basi utahitaji kuhamisha tovuti na kubadilisha seva za jina la mhudumu wa zamani kwenye seva za mpya kwenye msajili. Lakini kumbuka kwamba taarifa katika kache ya seva za DNS haijasasishwa mara moja, lakini angalau baada ya thamani ya kikoa cha TTL kumalizika, hivyo kwa muda fulani tovuti yako bado inaweza kupatikana kwenye anwani ya zamani. Ikiwa unahitaji kufanya kazi naye kwa haraka, basi unaweza, bila kusubiri masasisho ya DNS-akiba ya mtoa huduma wako, ongeza kwenye faili wenyeji kuingia na maudhui yafuatayo:

1.2.3.4 mfano.com

Wapi 1.2.3.4 Na mfano.com ipasavyo, anwani mpya ya IP na jina la kikoa chako.

Ikiwa una VPS yako mwenyewe au unataka kudhibiti kabisa eneo la kikoa, basi unapaswa kutumia seva za msajili au huduma za umma. Kuunda seva yako ya jina, kwa maoni yetu, sio wazo linalofaa isipokuwa ufanye mwenyeji wako mwenyewe.

Katika kesi hii, unahitaji kuunda angalau rekodi mbili za A ambazo zitaelekeza kwa seva ya wavuti inayohudumia tovuti katika kikoa hiki:

@ KATIKA A 1.2.3.4
www KATIKA A 1.2.3.4

Tabia ya mbwa katika rekodi za DNS inaashiria kikoa chenyewe, na unapaswa pia kuunda rekodi ya kikoa kidogo cha www ili watumiaji wanaoandika anwani ya tovuti kwa www pia waweze kuipata.

Hatutazingatia kuongeza maingizo kwa barua pepe, unaweza kusoma kuhusu hili katika makala yetu:

Wakati wa kuhamisha tovuti, utahitaji tu kubadilisha anwani za IP katika rekodi za A na usubiri sasisho. Maelezo ya DNS. Kawaida, huu ndio wakati mbaya zaidi - kila kitu kinaonekana kufanywa, lakini huwezi kubadilisha chochote, unaweza kungojea tu. Lakini ikiwa unafuata mapendekezo fulani, basi mchakato huu inaweza kufanywa bila maumivu na bila kutambuliwa na wageni iwezekanavyo.

Kwanza kabisa, badilisha thamani ya TTL kwenye rekodi ya SOA. Kwa chaguo-msingi, ni sawa na saa kadhaa na huo ndio muda ambao utahitaji kusubiri kuingia kwako kwenye kashe ya seva ya DNS kusasishwa. Ili kujua thamani ya sasa ya TTL, unaweza kuendesha amri kwa kutaja jina la kikoa unachotaka:

Nslookup -typr=soa tovuti

Kwa upande wetu ni masaa 4:

Kwa hiyo, angalau masaa 4 (thamani ya TTL ya zamani) kabla ya uhamisho uliopangwa, kubadilisha thamani ya TTL kwa thamani ya chini, kwa mfano, 900 (dakika 15). Kisha weka tovuti yako katika hali ya kusoma tu na uhamishe hadi seva mpya. Tovuti haipaswi kuzimwa au kuhamishwa kwa matengenezo; inaweza na inapaswa kubaki kupatikana. Lakini lazima uzuie watumiaji kubadilisha na kuongeza habari, i.e. kupiga marufuku usajili, kutoa maoni, kuweka maagizo, nk. Pia, hakikisha umechapisha ilani mahali panapoonekana kuhusu kazi ya kiufundi na takriban tarehe ya kukamilika.

Ili kufanya kazi na seva mpya bila kubadilisha rekodi za DNS, ongeza mstari unaohitajika faili ya majeshi. Baada ya kuweka tovuti kwenye tovuti mpya na kuhakikisha kuwa iko operesheni ya kawaida badilisha rekodi za DNS, sasa ndani ya dakika 15 watumiaji wa kwanza wataanza kutembelea tovuti yako kwenye seva mpya. Utendaji wa seva ya zamani unahitaji kudumishwa kwa muda zaidi, haswa hadi wiki, kwa kuwa sio watoa huduma wote wanaotumia thamani ya TTL kutoka kwenye rekodi ya SOA kusasisha kashe; mipangilio yako mwenyewe inaweza kutumika kupunguza mzigo kwenye vifaa.

Baada ya uhamiaji uliofanikiwa, thamani ya TTL inapaswa kuongezwa kwa maadili yake ya awali ili sio kuunda mzigo usiohitajika kwenye seva za jina.

Tumezingatia mpango rahisi zaidi, lakini kwa mazoezi, pamoja na tovuti, kuna kawaida mtandao wa ofisi, wengi ambao rasilimali zao zinapaswa pia kupatikana kutoka nje. Fikiria mchoro ufuatao:

Tuna seva za umma za tovuti na barua pepe na mtandao wa ofisi ambao tumetenga kikoa kidogo ofisi. Ikiwa hakuna maswala maalum na barua na seva ya wavuti, basi kuna chaguzi na eneo la ofisi. Kwa kawaida, ukanda wa ndani huhudumiwa na DNS yake mwenyewe na hauna muunganisho wa ukanda wa mama. Kwa ukanda wa mfumo wa kimataifa wa DNS office.example.com haipo, lakini mwenyeji wa jina moja lipo. Hii inahesabiwa haki ikiwa mtandao wa biashara uko nyuma ya NAT na nodi zake zina anwani za kijivu tu, na ufikiaji kutoka nje unafanywa tu kwa lango ambalo bandari zinazolingana kutoka kwa nodi za ndani zinatumwa.

Katika hilo kesi ya DNS rekodi za eneo mfano.com inaweza kuonekana kama hii:

@ KATIKA A 1.2.3.4
www KATIKA A 1.2.3.4
barua KATIKA A 1.2.3.5
ofisi KATIKA A 5.6.7.8

Lakini ugumu fulani hutokea; ndani ya mtandao, wateja hugeukia huduma za mtandao Na majina ya ndani: corp.office.example.com au rdp.office.example.com, ambayo inaelekeza kwa anwani za ndani za "kijivu." Walakini, nje mtandao wa ndani Haiwezekani kusuluhisha anwani ya IP ya majina kama hayo kwa sababu hakuna eneo la kimataifa la DNS lililo na majina hayo. Utaratibu unaoitwa Split-DNS hukuruhusu kutoka katika hali hii, ambayo hukuruhusu kutoa matokeo tofauti kulingana na msimamo wa mteja.

Katika mtandao wa ndani, maombi ya DNS ya wateja yanahudumiwa na seva ya ndani, ambayo ina rekodi zinazolingana, maombi nje yake yatatumwa kwa seva inayohudumia eneo mfano.com. Wakati huo huo, kila kitu rasilimali za ushirika, ambazo zinawakilishwa na seva mbalimbali kwenye mtandao wa ndani, zinapatikana kutoka nje kwa anwani moja: office.example.com. Kwa hivyo, ni wakati wa kukumbuka jina la utani au rekodi ya CNAME. Ingizo hili huruhusu majina ya ziada ya mnemonic au lakabu kuhusishwa na jina halisi la mpangishaji. Tafadhali kumbuka kuwa kutumia lakabu katika maingizo mengine haikubaliki. Kwa upande wetu, tunapaswa kuongeza maingizo yafuatayo:

Corp.office IN CNAME office.example.com.
rdp.office KATIKA CNAME office.example.com.

Sasa mteja, bila kujali eneo lake, anaweza kutumia jina sawa ili kufikia rasilimali, lakini matokeo yatakuwa tofauti. Kwenye mtandao wa ndani itapokea anwani halisi ya seva na kuunganisha moja kwa moja, na nje yake itaelekezwa kwenye lango la mtandao.

Pia, rekodi za aina za CNAME zinaweza kutumika kuelekeza kwingine nje ya eneo la kikoa linalotumika. Hali kuu - Rekodi ya CNAME lazima ielekeze kwa jina halisi katika umbizo la FQDN.

Matumizi mengine ya lakabu ni kufupisha anwani. Wacha tuseme, kama seva ya barua kwa kikoa kizima mfano.com tunataka kutumia seva ambayo iko katika ofisi ya Moscow na ina anwani mail.office.msk.example.com, lazima ukubali, haionekani kuvutia sana. Itakuwa rahisi zaidi kuwa na anwani kama mail.example.com, hakuna kitu rahisi zaidi, ongeza kiingilio kifuatacho:

Barua KWA CNAME mail.office.msk.example.com.

Lakini kumbuka kuwa katika rekodi zingine za rasilimali unapaswa kutumia tu majina halisi, kwa hivyo rekodi hii itakuwa sahihi:

Example.com. KATIKA MX 10 barua

Njia sahihi itakuwa:

Example.com. KATIKA MX 10 mail.office.msk

Hatimaye, hebu tuzungumze kuhusu ujumbe wa kanda za kikoa. Katika mfano hapo juu, tuliangalia hali ambapo ndani ya kikoa mgawanyiko tofauti umetengwa vikoa vyao wenyewe, kwa kuwa kila mgawanyiko una miundombinu yake, ni mantiki kuwakabidhi usimamizi wa kanda zao za kikoa. Kwa kusudi hili katika ukanda mfano.com NS na rekodi inayohusika inapaswa kuwekwa kwa kila eneo. Kwa mfano:

Msk IN NS ns1.msk.example.com.
msk KATIKA NS ns2.msk.example.com.

ns1.msk KATIKA A 1.2.3.4
ns2.msk KATIKA A 5.6.7.8

Sasa tunapopata anwani, tuseme mail.office.msk.example.com seva za majina ya eneo mfano.com itaonyesha jina na anwani ya seva inayohudumia eneo msk.example.com. Hii inaruhusu wasimamizi wa kanda kufanya mabadiliko yanayohitajika wenyewe bila kuathiri utendakazi wa eneo kuu au kuwasiliana na wasimamizi wake kwa suala lolote linalohitaji kubadilisha rekodi.

Lebo:

Tafadhali wezesha JavaScript kutazama

Kwa operesheni sahihi Ni muhimu kwa seva ya barua kuwa na eneo lililowekwa vizuri. Mipangilio ya DNS zone inarejelea shughuli za maandalizi kabla ya kupeleka seva ya barua na utendaji wa mfumo wa barua pepe moja kwa moja unategemea.

Mipangilio isiyo sahihi inaweza kusababisha barua kushindwa kutumwa kwa seva yako ya barua pepe au seva za wapokeaji kukataa barua zako. Kwa kweli, ikiwa rekodi za eneo lako hazina habari kuhusu seva ya barua, barua inapaswa kutumwa wapi? Hadi kijijini kwa babu? Unaweza, bila shaka, kuuliza mtoa huduma wako kusanidi eneo la DNS, lakini ni bora kufanya hivyo mwenyewe.

Tunahitaji nini? Anwani maalum ya IP (tuseme 11.22.33.44), ambayo lazima uipate kutoka kwa mtoa huduma wako. Jina la kikoa (kwa mfano example.com) linaweza kusajiliwa na msajili yeyote au mshirika wao. Wakati wa kujiandikisha na mshirika, angalia ikiwa anatoa ufikiaji wa usimamizi wa eneo la DNS, vinginevyo utalazimika kutumia wakati wa ziada, mishipa na pesa kuhamisha kikoa kwa msajili.

Ikiwa tayari una kikoa na, uwezekano mkubwa, tovuti inafanya kazi juu yake, angalia ikiwa inawezekana Usimamizi wa DNS eneo kutoka kwa paneli ya mtoa huduma mwenyeji, vinginevyo ni bora kuhamisha kikoa kwa msajili; ili kufanya hivyo, wasiliana na usaidizi wa mtoa huduma.

Kwa hivyo, tuna kikoa. Je, eneo lake la DNS lina rekodi gani? Kwanza, hii ni rekodi ya SOA - maelezo ya eneo. Hatutachambua rekodi zote kwa undani, hii ni zaidi ya upeo wa makala yetu, lakini kuwa nayo wazo la jumla kuhusu wao ni muhimu. Pia kunapaswa kuwa na rekodi mbili za NS zinazoelekeza kwa seva za majina ( Seva za DNS) ikitumikia kikoa hiki, hizi zitakuwa seva za msajili au mtoaji mwenyeji.

Rekodi ya kwanza kuongezwa itakuwa rekodi A au rekodi ya jina. Inapaswa kuelekeza kwa anwani ya IP ya seva yako ikiwa utaamua kuwasilisha maombi yote kwa kikoa mwenyewe au kwa anwani ya IP ya mtoa huduma mwenyeji ikiwa utaamua kupangisha tovuti yako. Wakati wa kupangisha tovuti na mwenyeji, kikoa kwa kawaida hukabidhiwa kwa seva yake ya DNS (rekodi zinazolingana za NS zimesajiliwa) na rekodi A itaundwa kiotomatiki wakati wa kuegesha kikoa.

Chaguo hili ni la kawaida, lakini ikiwa ni lazima, unaweza kuunda rekodi A mwenyewe kila wakati. Ingizo hili linaonekana kama:

mfano.com. KATIKA A 22.11.33.44

Katika mfano wetu, 22.11.33.44 ni anwani ya mtoa huduma wetu mwenyeji ambapo tovuti iko. Zingatia nukta iliyo mwisho wa jina, hii inaonyesha kuwa jina ni kamili; kwa kukosekana kwa nukta, jina linachukuliwa kuwa la jamaa na jina la kikoa kutoka kwa SOA linaongezwa kwake. Unaweza kuangalia kiingilio na amri kuangalia.

Ili seva ya barua ifanye kazi, unahitaji kuunda rekodi ya MX, ambayo inapaswa kuelekeza kwenye seva yetu ya barua. Ili kufanya hivyo, wacha tuunda rekodi:

mfano.com. KATIKA MX 10 mail.example.com.

Unaweza pia kuandika kwa urahisi:

mfano.com. KATIKA MX 10 barua

Example.com itaongezwa kiotomatiki kwa jina hili (bila nukta mwishoni). Nambari ya 10 huamua kipaumbele cha seva; chini ni, kipaumbele cha juu. Kwa njia, eneo la DNS linaweza kuwa tayari na rekodi ya MX kama:

mfano.com. KATIKA MX 0 example.com.

Kwa kawaida, ingizo hili huundwa kiotomatiki na mtoa huduma mwenyeji wakati wa kupangisha tovuti; inahitaji kufutwa.

Sasa hebu tuunde rekodi A kwa mail.example.com

mail.example.com. KATIKA A 11.22.33.44

Sasa barua zote za kikoa cha example.com zitatumwa kwa mwenyeji wa barua na anwani 11.22.33.44, i.e. seva yako ya barua, wakati huo huo tovuti ya example.com itaendelea kufanya kazi kwenye seva ya mtoa huduma saa 22.11.33.44.
Swali linaweza kutokea: kwa nini huwezi kutaja mara moja anwani ya IP ya seva ya barua katika rekodi ya MX? Kimsingi inawezekana, watu wengine hufanya hivyo, lakini haizingatii vipimo vya DNS.

Unaweza pia kutengeneza lakabu kwa seva ya barua kama pop.example.ru Na smtp.example.ru. Kwa nini hii ni muhimu? Hii itawawezesha mteja kutotegemea vipengele vya miundombinu yako, baada ya kutaja mipangilio mara moja. Hebu tuseme kwamba kampuni yako imekua na kutenga seva tofauti ya barua ili kuwahudumia wateja wa nje. barua1, unachohitaji ni kubadilisha rekodi mbili za DNS, wateja hawatagundua kuwa wanafanya kazi na seva mpya. Ili kuunda lakabu, rekodi za aina ya CNAME hutumiwa:

Ingiza IN CNAME mail.example.com.
smtp KATIKA CNAME mail.example.com.

Katika hatua hii, kusanidi eneo la mbele la DNS kunaweza kuzingatiwa kuwa kamili; jambo la kufurahisha zaidi linabaki - eneo la nyuma. Ukanda wa nyuma unasimamiwa na mtoa huduma aliyekupa anwani ya IP na huwezi kuidhibiti mwenyewe (isipokuwa wewe ni mmiliki wa kizuizi cha anwani za IP). Lakini unahitaji kuongeza angalau kiingilio kimoja kwenye eneo la nyuma. Kama tulivyoandika katika nakala iliyotangulia, seva nyingi za barua huangalia rekodi za PTR (rekodi za eneo la reverse) kwa seva ya kutuma, na ikiwa hazipo au hazilingani na kikoa cha mtumaji, barua hiyo itakataliwa. Kwa hivyo, muulize mtoa huduma wako akuongezee ingizo kama hili:

44.33.22.11.in-addr.arpa. KATIKA PTR mail.example.com.

Kuonekana kwa kushangaza kidogo, sivyo? Wacha tuangalie muundo wa rekodi ya PTR kwa undani zaidi. Kwa azimio la kubadilisha jina, kikoa maalum cha kiwango cha juu cha in-addr.arpa kinatumika. Hii inafanywa ili kutumia mifumo ya programu sawa kwa ubadilishaji wa jina la mbele na la nyuma. Ukweli ni kwamba majina ya mnemonic yameandikwa kutoka kushoto kwenda kulia, na anwani za IP zimeandikwa kutoka kulia kwenda kushoto. Kwa hivyo mail.example.com. inamaanisha kuwa barua pepe ya mwenyeji iko katika mfano wa kikoa, ambacho kiko katika kikoa cha kiwango cha juu com., 11.22.33.44 inamaanisha kuwa seva pangishi 44 iko kwenye subnet 33, ambayo ni sehemu ya subnet 22, mali ya mtandao 11. Kuweka akiba utaratibu sare Rekodi za PTR zina anwani ya IP ya nyuma iliyoambatishwa na kikoa cha kiwango cha juu cha in-addr.arpa.

Unaweza pia kuangalia rekodi za MX na PTR kwa amri kuangalia kutumia parameter ya ziada -aina=MX au -aina=PTR

Na bila shaka, hatupaswi kusahau kwamba mabadiliko yoyote katika Kanda za DNS hazitokei mara moja, lakini kwa muda wa saa kadhaa au hata siku, muhimu kwa mabadiliko kueneza katika mfumo wa kimataifa wa DNS. Hii inamaanisha kuwa ingawa seva yako ya barua itaanza kufanya kazi saa 2 baada ya kufanya mabadiliko, mshirika wako anaweza asikutumie barua kwa muda mrefu zaidi.