Je! ni eneo gani la kutazama mbele na la nyuma? Ukanda wa nyuma ni nini katika DNS. Rekodi ya PTR ni nini?

Rashid Achilov

Kuunda maeneo ya DNS

Kikoa Mfumo wa Jina- 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 bora kesi scenario utaona ujumbe ukisema kwamba anwani haikupatikana, na katika hali mbaya zaidi, utajikuta kwenye tovuti ambayo haina uhusiano wowote na kile ulichohitaji. 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 kwa sasa (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 na 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 kwa 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, kama sheria, seva moja (kwa usahihi zaidi, shirika moja) inawajibika kwa kikoa cha kijiografia, basi, kwa ujumla, idadi isiyo na kikomo ya wanaoitwa wasajili, ambayo ni, kampuni ambazo zina. iliyoingia katika mikataba maalum, inaweza kuwajibika kwa vikoa vya utendaji na ICANN kwamba wao ndio watakuwa wanasajili majina katika vikoa fulani vya utendaji. Maelezo mafupi ya kikoa cha kazi na anwani ya msajili wake imetolewa.

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 ya yote yaliyopo kwa sasa TLD za kijiografia zinazoonyesha msajili wa kikoa na maelezo muhimu ya mawasiliano yanaweza kupatikana katika. 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 inarejelea hali ambayo haipo Umoja wa Soviet(Umoja wa Kisovieti), ingawa 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 kujiandikisha zone.com, nililazimika kujaza fomu nyingi za maandishi - na data kwenye shirika, na data juu ya watu wa mawasiliano ... Fomu hizi zilitumwa kwa anwani maalum, kutoka ambapo majibu yalikuja - kukubalika 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, kadi za mkopo hutumiwa, lakini ikiwa kikoa hakiwezi kusajiliwa kwa sababu yoyote, pesa 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 usaidizi wa DNS ya pili katika ukanda wowote (pamoja na wale ambao hawajasajiliwa nao).

Kwa nini hitaji la seva ya sekondari ya DNS ni lazima? Kwa sababu utulivu DNS inafanya kazi 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, n.k. inayoendesha 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 ni seva ya BIND 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 kwa 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 ya seva ya kiolesura cha ndani. Anwani zilizosalia zitahifadhiwa kwa upanuzi wa siku zijazo.

Tatu, utahitaji faili ya maelezo ya eneo iliyotayarishwa awali ambayo itafafanua idadi kubwa ya anwani za nje: krokodil.ru - seva ya mizizi ya ukanda, 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 kifungu hiki unaturuhusu kuzingatia tu muhimu zaidi kati yao; kwa habari kamili, unapaswa kurejelea RFC zinazohusika: RFC 1033 na RFC 1035 zinafafanua fomati za msingi za rekodi, RFC 1122 - umbizo la rekodi ya PTR, RFC 2782 - umbizo la rekodi ya 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 A inayoweka anwani ya IP kwa jina (tafsiri ya moja kwa moja).
  • Rekodi ya MX inayoelezea mipangilio ya uwasilishaji wa barua ya 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, litazingatiwa thamani iliyopewa 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 katika mfano huu hizi 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. Maelezo ya amri ya $GENERATE yametolewa katika hati za programu ya BIND, na vile vile katika na, amri ya $INCLUDE inafanya kazi kulingana na tahajia yake - inajumuisha faili maalum kwa 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 kwa 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.
  • Kwa kweli, hakuna mtu atakayekulazimisha kufuata mazoezi kama hayo. Kwa mfano, seva za DNS katika Windows hazizingatii, lakini zihesabu tu 1, 2, 3, nk.
  • 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 rekodi zozote za ziada, isipokuwa CNAME inayowezekana.

Rekodi ya CNAME

Rekodi ya CNAME ni kipengele cha hiari cha 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 linawakilisha "Mail eXchanger", na linakusudiwa kuonyesha anwani za IP au majina ya kompyuta zinazokubali 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 unaanzishwa, ni kazi isiyo ya maana sana ambayo inaunganishwa kwa karibu na kazi ya programu zinazotumia. Itifaki ya SMTP kwa uwasilishaji wa barua, kwa hivyo tutazingatia kesi rahisi tu - barua zote hupokelewa 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. Uongofu huo hutumiwa sana katika programu mbalimbali ambazo hutoa upatikanaji wa rasilimali fulani za mtandao: huangalia mawasiliano ya uongofu wa mbele na wa nyuma na, ikiwa rekodi ya PTR hailingani au haipo, wanaweza kukataa ufikiaji. 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, utata unatungoja aina ifuatayo- 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 (katika mfano halisi hakuna haja ya kutaja maagizo ya $ORIGIN, wanapewa tu ili kuweka wazi ni eneo gani tunazungumzia):

$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 eneo hili ni sawa, linaonyeshwa kwa njia tofauti - kama sheria, faili za ukanda wa nje zina habari tu inayohitajika na wateja wa nje - kuhusu seva ya nje, kuhusu njia za kutuma barua, n.k., na faili za ukanda wa ndani zinaonyesha yote topolojia 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 itaenda "moja kwa moja".

Maombi

Vikoa vya kiwango cha juu

Hapo awali, kulingana na RFC 920, orodha ya TLDs zinazofanya kazi ilijumuisha .com, .gov, .mil, .edu, .org pekee, ambayo mtawalia iliwakilisha mashirika ya kibiashara, serikali, kijeshi, elimu na 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).
  • Rejea ya kihistoria: Mfumo wa Jina la Kikoa ulitengenezwa mnamo 1983 na Paul Mockapetris. Wakati huo huo, majaribio ya kwanza ya mafanikio ya DNS yalifanyika, ambayo baadaye ikawa moja ya vipengele vya msingi Mitandao ya mtandao. NA kwa kutumia DNS Iliwezekana kutekeleza utaratibu unaoweza kusambazwa na unaosambazwa ambao unapanga majina ya tovuti ya daraja la juu kwa anwani za IP za nambari.

    Mnamo 1983, Paul Mokapetris alifanya kazi kama mtafiti katika Taasisi ya Sayansi ya Habari. ISI), sehemu ya Chuo Kikuu cha Southern California School of Engineering ( USC) Msimamizi wake, Jon Postel, alipendekeza kwamba Paul aje na utaratibu mpya ambao ungeanzisha viungo kati ya majina ya kompyuta na anwani za mtandao - kuchukua nafasi ya saraka ya kati iliyokuwa ikitumika wakati huo ya majina ya waandaji na anwani, ambayo ilidumishwa na kampuni ya California ya SRI International.

    "Kila mtu alielewa kuwa mpango wa zamani haungeweza kufanya kazi milele," anakumbuka Mockapetris. "Ukuaji wa mtandao ulikuwa wa hali ya juu. Makampuni mapya zaidi na taasisi za utafiti zilijiunga na mtandao, ambao uliibuka kwa msingi wa mradi wa ARPANET ulioanzishwa na Pentagon.”

    Suluhisho la Mockapetris, DNS, lilikuwa hifadhidata iliyosambazwa ambayo iliruhusu mashirika yaliyojiunga na Mtandao kupata kikoa chao.

    "Mara tu shirika limeunganishwa kwenye mtandao, linaweza kutumia kompyuta nyingi kadri lilivyotaka na kuzitaja zenyewe," Mockapetris alisisitiza. Majina ya vikoa vya makampuni yalipokea kiambishi tamati .com, vyuo vikuu - .edu, na kadhalika.

    DNS iliundwa awali kusaidia rekodi milioni 50 na inaweza kupanuliwa kwa usalama hadi rekodi milioni mia kadhaa. Mockapetris anakadiria sasa kuna takribani majina bilioni 1 ya DNS, ikijumuisha karibu majina milioni 20 ya umma. Zingine ni za mifumo iliyo nyuma ya ngome. Majina yao hayajulikani kwa watumiaji wa kawaida wa mtandao.

    Mfumo mpya ulianzishwa hatua kwa hatua kwa miaka kadhaa. Kwa wakati huu, watafiti kadhaa walijaribu uwezo wake, na Mokapetris alisoma ISI matengenezo na kudumisha operesheni thabiti" seva ya mizizi", iliyojengwa kwenye fremu kuu za Vifaa vya Dijiti. Nakala za meza za mwenyeji zilihifadhiwa kwenye kila kompyuta iliyounganishwa kwenye Mtandao hadi mwaka wa 1986. Kisha mabadiliko makubwa ya kutumia DNS ilianza.

    Haja ya kuweka majina ya wapangishi wa mtandao kwenye anwani za IP

    Kompyuta na wengine vifaa vya mtandao Wakati wa kutuma pakiti kwa kila mmoja kwenye mtandao, hutumia anwani za IP. Hata hivyo, ni rahisi zaidi na rahisi zaidi kwa mtumiaji (binadamu) kukumbuka baadhi ya majina ya ishara ya nodi za mtandao kuliko nambari nne zisizo na maana. Hata hivyo, ikiwa watu watatumia majina ya wapangishaji badala ya anwani za IP katika mwingiliano wao na rasilimali za mtandao, basi lazima kuwe na utaratibu wa kupanga majina ya wapangishaji kwenye anwani zao za IP.

    Kuna njia mbili kama hizi - faili ya mwenyeji wa ndani kwa kila kompyuta na huduma ya jina la daraja la kati la DNS.

    Kwa kutumia local faili ya mwenyeji s na mifumo ya jina la kikoa cha DNS kwa azimio la jina la mwenyeji wa mtandao

    Katika hatua ya awali ya maendeleo ya mtandao, wakati idadi ya nodes katika kila mtandao ilikuwa ndogo, ilikuwa ya kutosha kuhifadhi na kudumisha hali ya sasa ya faili rahisi ya maandishi kwenye kila kompyuta, ambayo ilikuwa na orodha ya nodes za mtandao za mtandao fulani. Orodha imeundwa kwa urahisi sana - kila mstari wa faili ya maandishi una jozi "anwani ya IP - jina la mwenyeji wa mtandao". Kwenye mifumo ya familia ya Windows, faili hii iko kwenye %system root%\system32\drivers\etc folda (ambapo %system root% inaashiria folda ambayo mfumo wa uendeshaji umewekwa). Mara tu baada ya kusakinisha mfumo wa Windows, faili ya majeshi huundwa kwa kiingilio kimoja 127.0.0.1 localhost.

    Mitandao inapokua, weka maelezo ya kisasa na sahihi faili ya majeshi Inazidi kuwa ngumu. Ili kufanya hivyo, unahitaji kusasisha mara kwa mara yaliyomo kwenye faili hii kwenye nodi zote za mtandao. Mbali na hilo, ni rahisi sana teknolojia haikuruhusu kupanga nafasi ya majina katika muundo wowote. Kwa hivyo, kulikuwa na haja ya hifadhidata ya kati ya majina ambayo ingeruhusu majina kubadilishwa kuwa anwani za IP bila hifadhi orodha inayolingana kwenye kila kompyuta. Msingi kama huo ulikuwa DNS (Mfumo wa Jina la Kikoa), mfumo wa kutaja kikoa ambao ulianza kufanya kazi kwa wingi mnamo 1987.

    Kumbuka kuwa pamoja na ujio wa huduma ya DNS, umuhimu wa kutumia faili ya mwenyeji haujatoweka kabisa; katika hali nyingine, utumiaji wa faili hii unageuka kuwa mzuri sana.

    Huduma ya DNS: nafasi ya majina, vikoa

    DNS ni hifadhidata ya kihierarkia, ambayo huweka majina ya nodi za mtandao na huduma zao za mtandao kwa anwani za IP za nodi. Yaliyomo kwenye hifadhidata hii, kwa upande mmoja, inasambazwa kwa idadi kubwa ya seva za huduma za DNS, na kwa upande mwingine, zinasimamiwa serikali kuu. Katika msingi muundo wa hifadhidata wa kihierarkia DNS ni nafasi ya jina la kikoa, kitengo kikuu cha kimuundo ambacho ni kikoa kinachounganisha nodi za mtandao (majeshi), pamoja na vikoa vidogo. Mchakato wa kutafuta hifadhidata ya DNS kwa jina la seva pangishi ya mtandao na kulinganisha jina hilo na anwani ya IP inaitwa "suluhisho la jina la mwenyeji katika nafasi ya majina ya DNS."

    Huduma ya DNS ina sehemu kuu tatu:

      Nafasi ya majina ya DNS na rekodi za rasilimali zinazolingana (RR, rekodi ya rasilimali)- hii ni hifadhidata ya DNS iliyosambazwa yenyewe;

      Seva za majina ya DNS- kompyuta zinazohifadhi hifadhidata ya DNS na kujibu maombi Wateja wa DNS;

      Wateja wa DNS (wateja wa DNS, visuluhishi vya DNS)-kompyuta zinazotuma maswali kwa seva za DNS ili kupata rekodi za rasilimali.

    Nafasi ya majina.

    Nafasi ya majina ya DNS ni muundo wa daraja la mti unaoanzia kwenye mzizi, ambao hauna jina na unaonyeshwa na nukta ".". Muundo wa nafasi ya majina ya DNS unaonyeshwa vyema kwa kutumia mtandao kama mfano ( mchele. 4.8).

    Mchele. 4.8.

    Kwa vikoa vya kiwango cha 1 kuna aina 3 za majina:

      ARPA- jina maalum linalotumiwa kurekebisha azimio la DNS (kutoka anwani ya IP hadi jina kamili nodi);

      Majina ya kawaida ya kiwango cha 1- Majina 16 (ya sasa), ambayo madhumuni yake yametolewa meza 4.4;

      Majina ya herufi mbili kwa nchi- majina ya vikoa vilivyosajiliwa katika nchi zinazolingana (kwa mfano, ru - kwa Urusi, ua - kwa Ukraine, uk - kwa Uingereza, nk).

    Jedwali 4.4.

    Jina la kikoa

    Kusudi

    Jumuiya za anga

    Makampuni (bila kutaja nchi)

    Mashirika ya kibiashara, hasa nchini Marekani (kwa mfano, kikoa cha microsoft.com cha Microsoft Corporation)

    Vyama vya Ushirika

    Taasisi za elimu nchini Marekani

    Mashirika ya serikali ya Marekani

    Kikoa kwa mashirika yanayotoa taarifa yoyote kwa watumiaji

    mashirika ya kimataifa (kwa mfano, kikoa nato.int kwa NATO)

    Idara za kijeshi za Marekani

    Kikoa cha kimataifa kwa watu binafsi

    Kikoa cha watoa huduma za Mtandao na mashirika mengine ambayo yanasimamia muundo wa Mtandao

    Mashirika yasiyo ya faida na yasiyo ya kiserikali, hasa nchini Marekani

    Kikoa cha vyama vya kitaaluma (madaktari, wanasheria, wahasibu, n.k.)

    Mashirika ya kuajiri

    Waendeshaji watalii

    Ili kuweka nafasi ya jina moja kwa moja kwenye nafasi ya anwani ya IP, tumia kinachojulikana. rekodi za rasilimali (RR, rekodi ya rasilimali). Kila seva ya DNS ina rekodi za rasilimali kwa sehemu ya nafasi ya majina ambayo inawajibika ( yenye mamlaka). meza 4.5 ina maelezo ya aina zinazotumiwa sana za rekodi za rasilimali.

    Jedwali 4.5.

    Aina ya rekodi ya rasilimali

    Kazi ya kurekodi

    Maelezo ya matumizi

    Anwani ya Mwenyeji Anwani ya mwenyeji au nodi

    Huweka jina la mpangishaji kwa anwani ya IP (kwa mfano, kwa kikoa microsoft.com hadi kwa mwenyeji anayeitwa www.microsoft.com anwani ya IP imechorwa kwa kutumia ingizo lifuatalo: www A 207.46.199.60)

    Jina la Kanoni (pak)

    Huweka jina moja hadi jingine

    Kubadilishana kwa Barua pepe

    Hudhibiti uelekezaji wa barua pepe kwa itifaki ya SMTP

    Jina Seva ya Seva majina

    Huelekeza kwa seva za DNS zinazowajibika kwa kikoa mahususi na vikoa vidogo vyake

    Kielekezi

    Inatumika kubadilisha anwani za IP kwa majina ya wapangishaji katika kikoa cha in-addr.arpa

    Kuanza kwa Mamlaka Kuanzia eneo la kuingia

    Inatumika kubainisha seva ya msingi kwa eneo fulani na kuelezea sifa za eneo

    Kielekezi cha Kitambulisho cha Huduma kwa huduma

    Hutumika kupata seva zinazoendesha huduma maalum (kama vile vidhibiti vya Active Directory au seva za orodha ya kimataifa)

    Jina la kikoa lililohitimu kikamilifu (FQDN) lina majina kadhaa, yanayoitwa lebo, zilizotenganishwa na nukta. Lebo ya kushoto kabisa inahusu nodi moja kwa moja, lebo zilizobaki ni orodha ya vikoa kutoka kwa kikoa cha ngazi ya kwanza hadi kikoa ambacho nodi iko (orodha hii inatazamwa kutoka kulia kwenda kushoto).

    Seva za majina ya DNS.

    Seva za majina ya DNS (au seva za DNS) ni kompyuta zinazohifadhi sehemu hizo za hifadhidata ya nafasi ya majina ya DNS ambayo seva hizi zinawajibika, na kuendesha programu ambayo huchakata maombi ya utatuzi wa jina la mteja wa DNS na kutoa majibu kwa maombi yaliyopokelewa.

    Wateja wa DNS.

    Kiteja cha DNS ni nodi yoyote ya mtandao ambayo imewasiliana na seva ya DNS ili kutatua jina la mwenyeji kwa anwani ya IP au, kinyume chake, anwani ya IP kwa jina la mwenyeji.

    Huduma ya DNS: Vikoa na Kanda

    Kama ilivyoelezwa hapo juu, kila seva ya DNS inawajibika kuhudumia sehemu maalum ya nafasi ya majina ya DNS. Taarifa kuhusu vikoa vilivyohifadhiwa katika hifadhidata ya seva ya DNS imepangwa katika vitengo maalum vinavyoitwa kanda. Eneo ni kitengo cha msingi cha urudiaji wa data kati ya seva za DNS. Kila eneo lina idadi fulani ya rekodi za rasilimali kwa kikoa kinacholingana na, ikiwezekana, vikoa vyake vidogo.

    Mifumo ya familia ya Windows Server inasaidia aina zifuatazo za kanda:

      Msingi wa kawaida- nakala kuu ya eneo la kawaida; ndani tu nakala hii kanda zinaruhusiwa kufanya mabadiliko yoyote, ambayo yanarudiwa kwa seva zinazohifadhi maeneo ya ziada;

      Sekondari ya kawaida- nakala ya kanda kuu, inapatikana katika hali ya kusoma tu, iliyoundwa ili kuongeza uvumilivu wa kosa na kusambaza mzigo kati ya seva zinazohusika na eneo maalum; Mchakato wa kuiga mabadiliko kwenye rekodi za eneo unaitwa "uhamisho wa eneo" ( uhamisho wa eneo) (habari katika maeneo ya kawaida huhifadhiwa kwenye faili za maandishi, faili zinaundwa kwenye folda "% system root%\system32\dns", jina la faili kawaida huundwa kutoka kwa jina la ukanda na kuongeza kiendelezi cha faili " .dns"; neno "kawaida" linatumika tu kwenye mifumo ya familia ya Windows);

      Imeunganishwa ndani Saraka Inayotumika(Saraka Inayotumika-imeunganishwa)- taarifa zote za eneo huhifadhiwa kama ingizo moja katika hifadhidata ya Saraka Inayotumika (aina hizi za kanda zinaweza tu kuwepo kwenye seva za Windows ambazo ni vidhibiti vya kikoa cha Active Directory; katika kanda zilizounganishwa, haki za ufikiaji kwa maingizo ya kanda zinaweza kudhibitiwa kwa nguvu zaidi; mabadiliko ya maingizo ya ukanda kati ya matukio tofauti ya ukanda jumuishi hayatolewa kulingana na teknolojia uhamishaji wa eneo na huduma ya DNS, na kwa njia za kurudia za huduma ya Saraka ya Active);

      Ukanda wa stub (mbegu; Windows 2003 pekee) ni aina maalum ya ukanda ambayo, kwa sehemu fulani ya nafasi ya majina ya DNS, ina seti ya chini kabisa ya rekodi za rasilimali (rekodi ya awali ya eneo la SOA, orodha ya seva za majina zinazohusika na eneo hilo, na Aina chache. Rekodi za marejeleo ya seva za majina za eneo hilo). kanda).

    Wacha tuangalie uhusiano kati ya dhana ya kikoa na eneo kama mfano. Hebu tuchambue habari iliyotolewa mchele. 4.9.

    Mchele. 4.9.

    Katika mfano huu, nafasi ya majina ya DNS huanza na kikoa Microsoft.com, ambayo ina vikoa vidogo 3: sales.microsoft.com, it.microsoft.com Na edu.microsoft.com(vikoa katika takwimu vinaonyeshwa na ovals ndogo za usawa). Kikoa ni dhana ya kimantiki ambayo inahusiana tu na usambazaji wa majina. Dhana ya kikoa haina uhusiano wowote na teknolojia hifadhi habari kuhusu kikoa. Eneo- hii ni njia ya kuwasilisha taarifa kuhusu kikoa na vikoa vidogo katika uhifadhi wa seva hizo za DNS ambazo zinawajibika kwa kikoa na vikoa vidogo. Katika hali hii, ikiwa teknolojia ya kawaida ya eneo imechaguliwa kwa uhifadhi, basi uwekaji wa habari ya kikoa unaweza kutekelezwa kama ifuatavyo:

      rekodi zinazohusiana na kikoa Microsoft.com Na edu.microsoft.com, zimehifadhiwa katika ukanda mmoja katika faili "microsoft.com.dns" (katika takwimu ukanda unaonyeshwa na mviringo mkubwa unaoelekea);

      usimamizi wa kikoa sales.microsoft.com Na it.microsoft.com iliyokabidhiwa kwa seva zingine za DNS, faili zinazolingana "sales.microsoft.com.dns" na "it.microsoft.com.dns" zimeundwa kwa vikoa hivi kwenye seva zingine (kanda hizi zinaonyeshwa na ovals kubwa za wima).

    Ugawaji wa udhibiti ni uhamishaji wa jukumu la sehemu ya nafasi ya majina kwa seva zingine za DNS.

    Sambaza na ubadilishe maeneo ya utafutaji

    Kanda zilizojadiliwa katika mfano uliopita ni maeneo ya kuangalia mbele. Kanda hizi hutumiwa kutatua majina ya seva pangishi kwa anwani za IP. Aina za rekodi zinazotumiwa sana kwa hii ni A, CNAME, SRV.

    Kanda za kuangalia nyuma ( kuangalia nyuma maeneo), aina kuu ya kurekodi katika maeneo ya "nyuma" ni PTR. Ili kutatua tatizo hili, kikoa maalum kinachoitwa in-addr.arpa kiliundwa. Kwa kila mtandao wa IP katika kikoa kama hicho, vikoa vidogo vinavyolingana huundwa, vinavyoundwa kutoka kwa kitambulisho cha mtandao kilichoandikwa kwa mpangilio wa nyuma. Rekodi katika eneo kama hilo zitalingana na kitambulisho cha mwenyeji na jina kamili la FQDN la seva pangishi huyo. Kwa mfano, kwa mtandao wa IP 192.168.0.0/24, unahitaji kuunda eneo linaloitwa "0.168.192.in-addr.arpa". Kwa node yenye anwani ya IP 192.168.0.10 na jina host.company.ru, rekodi "10 PTR host.company.ru" lazima iundwe katika ukanda huu.

    Kanuni za hoja za DNS zinazojirudia na kujirudia

    Wote maombi, iliyotumwa na mteja wa DNS kwa seva ya DNS kwa azimio la jina, imegawanywa katika aina mbili:

      maswali ya kurudia (mteja hutuma seva ya DNS ombi, ambayo inakuhitaji utoe jibu bora zaidi bila kuwasiliana na seva zingine za DNS);

      maswali ya kujirudia (mteja hutuma swali kwa seva ya DNS ambamo huomba jibu la mwisho, hata kama seva ya DNS italazimika kutuma maswali kwa seva zingine za DNS; hoja zinazotumwa katika kesi hii kwa seva zingine za DNS zitakuwa za kurudia).

    Wateja wa kawaida wa DNS (kama vile vituo vya kazi vya watumiaji) kwa kawaida hutuma hoja zinazojirudia.

    Hebu tuangalie mifano ya jinsi mteja wa DNS na seva ya DNS huingiliana wakati wa kuchakata hoja zinazorudiwa na kujirudia.

    Wacha tuseme kwamba mtumiaji alizindua programu ya Kivinjari cha Mtandao na akaingiza anwani kwenye upau wa anwani http://www.microsoft.com. Kabla ya kivinjari kuanzisha kipindi cha HTTP na tovuti, kompyuta ya mteja lazima iamue anwani ya IP ya seva ya wavuti. Ili kufanya hivyo, sehemu ya mteja ya itifaki ya TCP/IP ya kituo cha kazi cha mtumiaji (kinachojulikana msuluhishi) kwanza huangalia akiba yake ya ndani ya majina yaliyotatuliwa hapo awali ili kujaribu kupata jina hapo www.microsoft.com. Ikiwa jina halipatikani, basi mteja hutuma ombi kwa seva ya DNS iliyobainishwa katika usanidi wa TCP/IP wa kompyuta hii (hebu tuite seva hii ya DNS "seva ya DNS ya ndani"), kwa azimio la jina www.microsoft.com kwa anwani ya IP ya nodi hii. Seva ya DNS basi huchakata ombi kulingana na aina ya ombi.

    Chaguo 1 (swali la kurudia).

    Ikiwa mteja alituma ombi la kurudia kwa seva (kumbuka kuwa wateja kawaida hutuma maombi ya kujirudia), basi ombi hilo linashughulikiwa kulingana na mpango ufuatao:

      Microsoft.com;

    ikiwa eneo kama hilo linapatikana, basi kiingilio cha node ya www kinatafutwa ndani yake; ikiwa rekodi inapatikana, matokeo ya utafutaji yanarejeshwa mara moja kwa mteja;

    www.microsoft.com katika kashe yake ya maswali ya DNS yaliyotatuliwa hapo awali;

    ikiwa jina lililotafutwa liko kwenye kashe, basi matokeo ya utaftaji yanarejeshwa kwa mteja; ikiwa seva ya ndani ya DNS haipati rekodi inayohitajika katika hifadhidata yake, basi anwani ya IP ya seva moja ya mizizi ya DNS inatumwa kwa mteja;

      mteja hupata anwani ya IP ya seva ya mizizi na kurudia ombi la azimio la jina kwake www.microsoft.com;

    seva ya mizizi haina eneo la "microsoft.com" kwenye hifadhidata yake, lakini inajua seva za DNS zinazohusika na eneo la "com", na seva ya mizizi hutuma mteja anwani ya IP ya mojawapo ya seva zinazohusika na eneo hili. ;

      mteja hupokea anwani ya IP ya seva inayohusika na eneo la "com" na kuituma ombi la azimio la jina www.microsoft.com;

    seva inayohusika na eneo la com haina kanda katika hifadhidata yake Microsoft.com, lakini anajua seva za DNS zinazohusika na eneo hilo Microsoft.com, na seva hii ya DNS hutuma mteja anwani ya IP ya mojawapo ya seva zinazohusika na eneo Microsoft.com;

      mteja hupokea anwani ya IP ya seva inayohusika na eneo Microsoft.com, na kuituma ombi la azimio la jina www.microsoft.com;

    seva inayohusika na eneo Microsoft.com, inapokea ombi hili, hupata katika hifadhidata yake anwani ya IP ya nodi ya www iliyoko katika eneo hilo Microsoft.com, na kutuma matokeo kwa mteja;

    mteja hupata anwani ya IP anayotafuta, huhifadhi ombi lililotatuliwa katika akiba yake ya ndani, na kupitisha anwani ya IP ya tovuti kwenye Kivinjari cha Mtandao (baada ya hapo Kivinjari huwasiliana na tovuti kupitia HTTP).

    Chaguo 2 ( swali la kujirudia).

    Ikiwa mteja alituma kwa seva swali la kujirudia, basi ombi linashughulikiwa kulingana na mpango ufuatao:

      Kwanza, seva ya ndani ya DNS hutafuta kati ya maeneo ambayo inawajibika kwa ukanda Microsoft.com; ikiwa eneo kama hilo linapatikana, basi kiingilio cha node ya www kinatafutwa ndani yake; ikiwa rekodi inapatikana, matokeo ya utafutaji yanarejeshwa mara moja kwa mteja;

    vinginevyo seva ya ndani ya DNS hutafuta jina lililoombwa www.microsoft.com katika kashe yake ya maswali ya DNS yaliyotatuliwa hapo awali; ikiwa jina lililotafutwa liko kwenye kashe, basi matokeo ya utaftaji yanarejeshwa kwa mteja;

      Ikiwa seva ya ndani ya DNS haipati rekodi inayohitajika katika hifadhidata yake, basi seva ya ndani ya DNS yenyewe hufanya mfululizo wa maswali ya kujirudia ili kutatua jina. www.microsoft.com, na ama anwani ya IP iliyopatikana au ujumbe wa hitilafu hutumwa kwa mteja.

    Utekelezaji wa huduma ya DNS katika mifumo ya familia ya Windows Server

    Kipengele kikuu cha huduma ya DNS katika familia ya mifumo ya Windows Server ni kwamba huduma ya DNS iliundwa ili kusaidia huduma ya saraka ya Active Directory. Ili kutekeleza kazi hii, masharti mawili lazima yakamilishwe:

      msaada wa huduma DNS yenye nguvu usajili (sasisho za nguvu);

      Usaidizi wa DNS kwa rekodi za SRV.

    Windows Server DNS inakidhi masharti yote mawili, na huduma za saraka ya Active Directory zinaweza tu kutekelezwa kwenye seva zinazotegemea Seva ya Windows.

    Wacha tuangalie mifano rahisi ya kudhibiti huduma ya DNS:

      kufunga huduma ya DNS;

      uundaji wa eneo kuu na la ziada la kutazama moja kwa moja;

      kuunda eneo la kuangalia nyuma;

      kufanya usajili wa nguvu wa nodi katika ukanda.

      mtandao una Seva mbili za Windows 2003;

      mfumo wa uendeshaji - muda mdogo wa siku 120 za Kirusi Toleo la Windows Toleo la Biashara ya Seva ya 2003;

      seva ya kwanza imewekwa kwenye PC na processor ya Intel Pentium-4 3GHz na RAM 512 MB, jina la seva - DC1, anwani ya IP - 192.168.0.1/24;

      seva ya pili inaendesha kama mfumo wa kawaida kwa kutumia Microsoft VirtualPC 2004, jina la seva -DC2, anwani ya IP - 192.168.0.2/24;

      jina la kikoa katika nafasi ya DNS na jina linalolingana katika huduma ya saraka ya Active Directory - world.ru (mtandao umetengwa kabisa na mitandao mingine, kwa hivyo katika mfano huu waandishi walikuwa huru kuchagua jina la kikoa; katika hali halisi ya taasisi fulani ya elimu, mwalimu anahitaji kusahihisha habari hii).

    Mapendekezo ya kina ya kuandaa mtandao wa masomo kozi hii(wote chini ya uongozi wa mwalimu katika kikundi kilichopangwa na wakati wa utafiti wa kujitegemea) zimewekwa katika maagizo ya kufanya mazoezi ya maabara mwishoni mwa mwongozo.

    Inasakinisha huduma ya DNS

    Kufunga huduma ya DNS (pamoja na vipengele vingine vya mfumo) ni rahisi sana kwa kutumia Mchawi wa Ufungaji wa Sehemu ya Windows:

      Fungua Jopo kudhibiti.

      Chagua kipengee "Ufungaji na uondoaji wa programu".

      Bofya kitufe "Kufunga Vipengee vya Windows".

      Chagua "Huduma za mtandao"-kifungo "Zaidi ya hayo"(chini ya hali yoyote batilisha uteuzi wa jina "Huduma za mtandao").

      Angalia huduma ya DNS.

    Mchele. 4.10.

    Ikiwa mfumo unakuuliza ueleze njia ya usambazaji wa mfumo, ingiza njia ya folda na usambazaji.

    Wacha tufanye kitendo hiki kwenye seva zote mbili.

    Kuunda Eneo la Msingi la Kutazama Mbele.

    Kwenye seva DC1 tutaunda eneo kuu la kawaida linaloitwa world.ru.

      Wacha tufungue koni ya DNS.

      Hebu tuchague sehemu "Maeneo ya Mtazamo wa Mbele".

      Wacha tuzindue mchawi wa uundaji wa eneo (aina ya eneo - "Msingi", sasisho za nguvu - kuruhusu, vigezo vingine - chaguo-msingi).

      Hebu tuingie jina la eneo - world.ru.

      Wacha turuhusu eneo hili kuhamishiwa kwa seva yoyote ya DNS (DNS Console - zone world.ru - Mali- Alamisho "Uhamisho wa Eneo"- Angalia "Ruhusu uhamishaji" Na "Kwa seva yoyote").

    Kuunda Eneo la Ziada la Kutazama Mbele.

    Kwenye seva ya DC2, tutaunda eneo la ziada la kawaida linaloitwa world.ru.

      Wacha tufungue koni ya DNS.

      Hebu tuchague sehemu "Maeneo ya Mtazamo wa Mbele"

      "Ziada", anwani ya IP ya seva kuu (ambayo eneo litanakiliwa) ni anwani ya seva ya DC1, vigezo vingine ni chaguo-msingi)

      Hebu tuingie jina la eneo - world.ru.

      Wacha tuangalie mwonekano wa eneo kwenye koni ya DNS.

    Inasanidi seva pangishi ili kutekeleza usajili thabiti wa DNS.

    Ili kukamilisha kazi hii, unahitaji kufanya idadi ya vitendo kwenye seva ya DNS na katika mipangilio ya mteja wa DNS.

    Seva ya DNS.

      Unda eneo linalofaa.

      Ruhusu masasisho yanayobadilika.

    Tayari tumefanya hivi.

    Mteja wa DNS.

      Bainisha katika mipangilio ya itifaki ya TCP/IP anwani ya seva ya DNS inayopendelewa - seva ambayo masasisho yanayobadilika yanaruhusiwa (kwa mfano wetu, seva ya DC1).

      Katika jina kamili la kompyuta, onyesha kiambishi sahihi cha DNS (katika mfano wetu - world.ru). Kwa hii; kwa hili - "Kompyuta yangu" - "Mali"- Alamisho "Jina la kompyuta"- Kitufe "Badilisha"- Kitufe "Zaidi ya hayo"- ingiza jina la kikoa world.ru kwenye uwanja tupu wa maandishi - kitufe "SAWA"(Mara 3)).

    Mchele. 4.11.

    Baada ya hayo, mfumo utakuhimiza kuanzisha upya kompyuta yako. Baada ya kuwasha tena seva ya DNS kwenye ukanda wa world.ru, rekodi za aina A zitaundwa kiotomatiki kwa seva zetu ( mchele. 4.12).

    Mchele. 4.12.

    Kuunda Eneo la Kutafuta Nyuma.

      Wacha tufungue koni ya DNS.

      Hebu tuchague sehemu "Maeneo ya Utafutaji wa Nyuma".

      Wacha tuzindue mchawi wa uundaji wa eneo (chagua: aina ya eneo - "Msingi", sasisho zenye nguvu - ruhusu, vigezo vingine - chaguo-msingi)

      Katika shamba "Msimbo wa mtandao (ID)" Hebu tuingie vigezo vya kitambulisho cha mtandao - 192.168.0.

      Hebu tuendeshe amri ya kulazimisha mteja kujiandikisha kwenye seva ya DNS - ipconfig /registerdns.

    Seva zetu zitajisajili na ukanda wa nyuma DNS ( mchele. 4.13):

    Ukanda ni hifadhidata iliyo na taarifa halali kuhusu eneo la nafasi ya majina ya DNS. Unaposakinisha seva ya DNS na kidhibiti cha kikoa, eneo la DNS linaundwa kiotomatiki ili kuauni kikoa cha Saraka Inayotumika. Ikiwa seva ya DNS ilisakinishwa kwenye kidhibiti cha kikoa, seva ya mwanachama wa kikoa, au seva inayojitegemea, maeneo lazima yaundwe na kusanidiwa mwenyewe.

    Somo hili linaelezea jinsi ya kuunda na kusanidi eneo na hutoa habari inayohitajika ili kusanidi ukanda kwa usahihi.

    Kuunda kanda

    Eneo DNS ni hifadhidata iliyo na rekodi ambazomajina yanayohusiana na anwani katika eneo lililoelezwa la nafasi ya majina ya DNS. Ingawakujibu maswali ya majina, seva ya DNS inaweza kutumia kachehabari kutoka kwa seva zingine, ameidhinishwa kujibu maombi tu ndanieneo linalodhibitiwa na ndani. Kwa wigo wowote wa nafasi ya majina ya DNS,inawakilishwa na jina la kikoa (kwa mfano, google .ru), kuna moja tuchanzo halali cha data ya eneo.
    Ikiwa unahitaji kuunda eneo jipya kwenye seva ya DNS, unaweza kutumia Mchawi wa Eneo Mpya katika Kidhibiti cha DNS. Ili kuzindua mchawi, bofya bonyeza kulia Bofya ikoni ya seva kwenye mti wa koni ya Meneja wa DNS na utumie amri ya Eneo Mpya.

    Mchawi wa Eneo Mpya una kurasa zinazofuata usanidi:

    Aina ya Eneo;

    Eneo la kurudia eneo, jumuishi V Saraka Inayotumika (Upeo Amilifu wa Kuiga Kanda ya Saraka);

    Eneo la Kutafuta Mbele au Nyuma;

    Jina la Eneo;

    Sasisho Inayobadilika (Sasisho Linalobadilika).

    Sehemu zifuatazo zinaelezea dhana za usanidi zinazohusiana na kurasa hizi tano za mchawi.

    Kuchagua aina ya eneo

    Kwenye ukurasa wa Aina ya Eneo la Mchawi wa Eneo Mpya, unaweza kuchagua kuunda eneo la msingi, eneo la pili, au eneo la mbegu. Kwa kuunda eneo la msingi au stub kwenye kidhibiti cha kikoa, unaweza kuhifadhi data ya eneo katika Saraka Inayotumika.

    * Maeneo kuu

    Aina ya kawaida ya eneo la DNS ni eneo la Msingi. Inatoa chanzo asili cha data ya kusoma/kuandika seva ya ndani ya DNS Mamlaka ya kujibu hoja za DNS kwa upeo wa nafasi ya majina ya DNS.

    Seva ya ndani ya DNS inayodhibiti eneo msingi hutumika kama chanzo kikuu cha data kuhusu eneo hilo. Seva huhifadhi nakala kuu ya data ya eneo katika faili ya ndani au huduma za kikoa ah Active Directory (Active Directory Domain Services, AD DS). Ikiwa eneo limehifadhiwa kwa faili badala ya Saraka Inayotumika, jina la faili chaguo-msingi ni jina_la_eneo.dns na huhifadhiwa kwenye folda ya %systemroot%\System 32\Dns kwenye seva.

    *Kanda za ziada

    Hutoa nakala iliyoidhinishwa, ya kusoma tu ya eneo msingi au eneo moja la ziada.

    Kanda za pili hutoa uwezo wa kupunguza kiasi cha trafiki ya hoja ya DNS katika maeneo ya mtandao ambapo data ya eneo inaulizwa sana na kutumika. Zaidi ya hayo, ikiwa seva inayodhibiti eneo msingi haipatikani, eneo la pili linaweza kutoa utatuzi wa jina hadi seva ya msingi ipatikane tena.

    Kanda chanzo ambazo kanda za ziada hupokea taarifa huitwa kanda kuu, na taratibu za kunakili data zinazohakikisha kuwa taarifa za eneo zinasasishwa mara kwa mara huitwa uhamishaji wa eneo. Eneo la bwana linaweza kuwa eneo kuu au eneo lingine la ziada. Eneo kuu linaweza kupewa eneo la ziada linaloundwa katika Mchawi wa Eneo Mpya. Kwa sababu eneo la pili ni nakala ya eneo la msingi linalodhibitiwa na seva nyingine, haiwezi kuhifadhiwa katika Saraka Inayotumika.

    * Kanda za stub

    Sawa na ukanda wa pili, lakini ina rekodi za rasilimali zinazohitajika ili kutambua seva za DNS zinazoidhinishwa katika eneo kuu. Maeneo ya Stub mara nyingi hutumiwa kuruhusu eneo la mzazi (kwa mfano, google .ru) kutumia orodha iliyosasishwa ya seva za majina zinazopatikana katika eneo la mtoto lililokabidhiwa (kwa mfano: translate .google .ru). Pia hutumikia kuboresha azimio la jina na kurahisisha usimamizi wa DNS.

    * Kuhifadhi maeneo ndaniInayotumikaOrodha

    Unapounda eneo la msingi au eneo la stub kwenye kidhibiti cha kikoa, kwenye ukurasa wa Aina ya Eneo la mchawi, unaweza kuchagua chaguo la kuhifadhi eneo katika Saraka Inayotumika. Data ya eneo iliyounganishwa ya Saraka Inayotumika inanakiliwa kiotomatiki hadi Saraka Inayotumika kulingana na mipangilio iliyochaguliwa kwenye ukurasa wa Upeo wa Urudiaji wa Eneo la Saraka Inayotumika. Shukrani kwa chaguo hili, hakuna haja ya kusanidi uhamisho wa eneo kwa seva za ziada.

    Kuunganisha eneo la DNS kwenye Saraka Inayotumika hutoa manufaa kadhaa. Kwanza, kwa sababu huduma za Active Directory hufanya urudiaji wa eneo, hakuna haja ya kusanidi utaratibu tofauti wa uhamishaji wa eneo la DNS kati ya seva za msingi na za upili. Urudiaji wa mitandao mingi kiotomatiki hutoa uvumilivu wa hitilafu na utendakazi ulioboreshwa kutokana na upatikanaji wa seva nyingi za msingi za kusoma/kuandika. Pili, Saraka Inayotumika hukuruhusu kusasisha na kuiga sifa za rekodi za rasilimali kwenye seva za DNS. Kwa sababu rekodi nyingi kamili za rasilimali hazihamishwi, mzigo kwenye rasilimali za mtandao wakati wa uhamishaji wa kanda hupunguzwa. Hatimaye, kanda zilizounganishwa za Saraka Inayotumika pia hutoa mahitaji ya hiari ya usalama ya usasishaji badilika, ambayo yanaweza kusanidiwa kwenye ukurasa wa Usasishaji Mwema wa Mchawi wa Eneo Mpya.

    KUMBUKA: Vidhibiti na maeneo ya vikoa vya kusoma pekee vilivyounganishwa na Saraka Inayotumika

    Kwenye vidhibiti vya jadi vya kikoa, nakala ya eneo hupewa ruhusa ya kusoma/kuandika. Kwenye vidhibiti vya vikoa vya kusoma pekee (RODCs), nakala ya eneo imepewa ruhusa ya kusoma tu.

    * Kanda za kawaida

    Unapounda eneo kwenye kidhibiti cha kikoa, chaguo la kuhifadhi eneo katika Saraka Inayotumika kwenye ukurasa wa Aina ya Kanda huchaguliwa kwa chaguo-msingi. Hata hivyo, unaweza kufuta kisanduku hiki cha kuteua na kuunda kinachojulikana kama eneo la kawaida. Kwenye seva ambayo si kidhibiti cha kikoa, unaweza kuunda maeneo ya kawaida pekee, na kisanduku cha kuteua kwenye ukurasa huu ni kijivu.

    Tofauti na eneo lililounganishwa la Saraka Inayotumika, eneo la kawaida huhifadhi data yake katika faili ya maandishi kwenye seva ya ndani ya DNS. Zaidi ya hayo, ukitumia maeneo ya kawaida, unaweza kusanidi nakala ya msingi pekee yenye ruhusa za kusoma na kuandika kwa data ya eneo. Nakala zingine zote za eneo (kanda za ziada) zimepewa ruhusa ya kusoma tu.

    Mfano wa kawaida wa eneo huchukua hatua moja ya kutofaulu kwa toleo linaloweza kuandikwa la eneo. Ikiwa ukanda kuu haupatikani kwenye mtandao, hakuna mabadiliko yanaweza kufanywa kwenye eneo hilo. Hata hivyo, maombi ya majina katika eneo yanaweza yasikatishwe huku maeneo ya ziada yakiwapo.

    Kuchagua upeo wa urudufishaji wa eneo uliojumuishwaInayotumikaOrodha

    Kwenye ukurasa wa Upeo wa Urudiaji wa Eneo la Saraka Inayotumika wa Mchawi wa Eneo Mpya, unaweza kuchagua vidhibiti vya kikoa kwenye mtandao wako ili kuhifadhi data ya eneo. Ukurasa huu unaonekana tu unapochagua chaguo la kuhifadhi eneo na Saraka Inayotumika. Chaguo za uteuzi wa upeo wa urudufishaji wa eneo huamua vidhibiti vya kikoa kati ya ambayo data ya eneo itaigwa.

    Ukurasa huu hutoa chaguzi zifuatazo:

    Uendelevu wa eneo kwa vidhibiti vyote vya kikoa, ambavyo pia ni seva za DNS, katika msitu mzima wa Saraka Inayotumika;

    Uendelevu wa eneo kwenye vidhibiti vyote vya kikoa ambavyo pia hutumika kama seva za DNS na kikoa cha ndani Saraka Inayotumika;

    Uhifadhi wa eneo kwenye vidhibiti vyote vya kikoa na kikoa cha Saraka ya Active ya ndani (inayotumika kwa utangamano na Windows 2000);

    Kuendelea kwa eneo kwenye vidhibiti vyote vilivyobainishwa vya kikoa na upeo wa ugawaji maalum Saraka inayotumika Orodha.

    Chaguzi hizi zimeelezewa kwa undani zaidi katika mada ya pili.

    Kuunda Kanda za Kutafuta Mbele na Nyuma

    Kwenye ukurasa wa Eneo la Kutafuta Mbele au Nyuma la Mchawi wa Eneo Mpya, lazima uchague aina ya ukanda utakaoundwa; Eneo la Kutafuta Mbele au Eneo la Kutafuta Nyuma.

    Katika maeneo ya utafutaji wa mbele, seva za DNS hupanga FQDN hadi anwani za IP. Katika maeneo ya kuangalia kinyume, seva za DNS hupanga anwani za IP kwa FQDN. Kwa hivyo, maeneo ya kuangalia mbele hujibu maombi ya kutatua FQDN kwa anwani za IP, na maeneo ya kuangalia nyuma hujibu maombi ya kutatua anwani za IP kwa FQDNs. Kumbuka kuwa maeneo ya kutafutia mbele yanaitwa kulingana na majina ya kikoa cha D NS ambayo ruhusa inatekelezwa, kwa mfano google .com. Maeneo ya kuangalia kinyume yamepewa majina kwa mpangilio wa kinyume wa okteta tatu za kwanza za nafasi ya anwani ambayo azimio la jina limetolewa, pamoja na lebo ya ziada ya in-addr.arpa. Kwa mfano, ukitatua majina ya subnet ya 192.168.1.0/24, eneo la kuangalia kinyume litaitwa 1.168.192.in-addr.arpa. Katika eneo la kutazama moja kwa moja kuingia tofauti hifadhidata inayolingana na jina la mwenyeji na anwani inaitwa rekodi nodi(A). Katika ukanda wa kuangalia kinyume, ingizo la hifadhidata la mtu binafsi ambalo hupanga anwani ya IP kwa jina la mwenyeji huitwa pointer au rekodi ya PTR.

    Kanuni ya uendeshaji wa utafutaji wangu wa mbele na wa nyuma unaonyeshwa kwenye takwimu.

    Eneo la Kutazama Moja kwa Moja

    Eneo la Kutazama Nyuma

    KUMBUKA: Mchawi wa Kuweka Seva ya DNS

    Unaweza kutumia Mchawi wa Kusanidi Seva ya DNS kuunda maeneo ya kutafutia mbele na nyuma kwa wakati mmoja. Ili kuanza mchawi, kwenye mti wa koni ya Meneja wa DNS, bofya kulia ikoni ya seva na uchague Sanidi Seva ya DNS.

    Kuchagua jina la eneo

    Kwenye ukurasa wa Jina la Eneo la Mchawi wa Eneo Mpya, unaweza kuchagua jina la eneo la kutazama mbele litakaloundwa. Maeneo ya kuangalia kinyume hupewa majina maalum kulingana na anuwai ya anwani za IP ambazo zinaidhinishwa.

    Ikiwa unaunda eneo la azimio la jina katika kikoa cha Saraka Inayotumika, ni bora kutaja jina la eneo linalolingana na jina la kikoa cha Saraka Inayotumika. Kwa mfano, ikiwa shirika lina vikoa viwili vya Active Directory vinavyoitwa google.ru na translate.google.ru, miundombinu ya utatuzi wa jina lazima iwe na kanda mbili zinazoitwa baada ya majina hayo ya vikoa.

    Ikiwa unaunda eneo la nafasi ya majina ya DNS ambayo haiko katika mazingira ya ActiveDirectory, lazima ubainishe jina la kikoa cha mtandao cha shirika, kama vile wikipedia .org.

    KUMBUKA: NyongezaSeva ya DNS kwa kila kidhibiti cha kikoa

    Ili kuongeza seva ya DNS kwa kidhibiti kilichopo cha kikoa, kwa kawaida huongeza nakala ya eneo msingi ili kutoa utatuzi wa jina kwenye kikoa cha Saraka Inayotumika iliyo kwenye majengo. Ili kufanya hivyo, unaunda eneo ambalo jina lake linalingana na jina la eneo lililopo kwenye kikoa cha Saraka Inayotumika. Ukanda mpya utajaa data kutoka kwa seva zingine za DNS kwenye kikoa.

    Inasanidi mipangilio ya sasisho inayobadilika

    Mteja Kompyuta za DNS wanaweza kusajili na kusasisha rekodi zao za rasilimali kwa kutumia seva ya DNS. Kwa chaguomsingi, viteja vya DNS vilivyo na anwani tuli za IP husasisha rekodi za seva pangishi (A au AAAA) na viashiria (PTR), huku viteja vya DNS ambavyo ni viteja vya DHCP vinasasisha rekodi za seva pangishi pekee. Katika mazingira ya kikundi cha kazi, seva ya DHCP husasisha maingizo ya faharasa kwa niaba ya mteja wa DHCP wakati wowote usanidi wa IP unasasishwa.

    Ili masasisho yanayobadilika ya DNS yafanikiwe, eneo ambalo wateja husajili au kusasisha rekodi lazima liwekewe mipangilio ili kukubali masasisho yanayobadilika. Kuna aina mbili za sasisho hili:

    Salamasasisha (Salamasasisho)

    Inakuruhusu kufanya usajili kutoka kwa kompyuta tu katika kikoa cha Saraka Inayotumika na kusasisha tu kutoka kwa kompyuta ambayo ilifanya usajili hapo awali.

    Si salamasasisho (Bila usalamasasisho)

    Inakuruhusu kusasisha kutoka kwa kompyuta yoyote.

    Kwenye ukurasa wa Usasishaji Mwelekeo wa Mchawi wa Eneo Mpya, unaweza kuruhusu masasisho salama, yasiyo salama, au kuzima masasisho kabisa ya eneo unalounda.

    Kuchambua Rekodi za Rasilimali Zilizojengwa

    Unapounda eneo jipya, aina mbili za rekodi zinaundwa kiotomatiki. Kwanza, eneo kama hilo daima linajumuisha rekodi ya awali ya eneo la SOA (Start Of Authority) ambayo inafafanua sifa za kimsingi za eneo. Kwa kuongeza, maeneo mapya yana angalau rekodi moja ya NS (Seva ya Jina) ambayo inabainisha jina la seva zinazoidhinishwa za eneo hilo. Ifuatayo inaelezea kazi za rekodi hizi mbili za rasilimali.

    Maingizo ya eneo la awali

    Wakati wa kupakia eneo, seva ya DNS hutumia rekodi ya eneo la SOA (Start Of Authority) ili kubainisha sifa za kimsingi na mamlaka za eneo hilo. Vigezo hivi pia vina sifa ya mzunguko wa uhamisho wa eneo kati ya seva kuu na za ziada. Kubofya mara mbili ingizo la SOA hufungua kichupo cha Kuanza kwa Mamlaka (SOA) cha kisanduku cha mazungumzo cha mali za eneo.

    Msururunambari (Nambari ya Ufuatiliaji)

    Sehemu hii ya maandishi kwenye kichupo cha Rekodi ya Eneo la Awali (SOA) ina nambari ya marekebisho ya faili ya eneo. Nambari iliyobainishwa hapa huongezeka kila wakati rasilimali inaporekodi katika mabadiliko ya eneo. Inaweza pia kuongezwa kwa mikono kwa kutumia kitufe cha Kuongeza.

    Ikiwa kanda zimesanidiwa kutekeleza uhamishaji wa eneo kwa seva moja au zaidi ya upili, seva hizo za upili huuliza mara kwa mara seva msingi kwa nambari ya serial ya eneo. Maombi haya yanaitwa ombi la SOA. Ikiwa ombi la SOA litapokea nambari ya serial ya eneo la msingi ambayo ni sawa na nambari ya serial ya eneo la pili, uhamishaji hautafaulu. Ikiwa nambari ya serial ya eneo kwenye seva kuu ni kubwa kuliko thamani inayolingana kwenye seva ya upili inayoomba, mwisho huanzisha uhamishaji wa eneo.

    KUMBUKA: Kuhamisha kanda kwenye seva kuu

    Kubofya kitufe cha Ongezeko huanzisha uhamishaji wa eneo.

    Msingiseva (MsingiSeva)

    KuwajibikaMtu anayewajibika

    Sehemu hii ndipo unapoingiza jina la Mtu Mwajibikaji (RP) ambalo linalingana na kisanduku cha barua cha kikoa cha msimamizi wa eneo. Jina lililowekwa katika sehemu hii lazima limalizike na kipindi. Jina chaguo-msingi ni hostmaster.

    Mudasasisho (Kipindi cha Kuonyesha upya)

    Thamani katika sehemu hii huamua muda ambao seva ya pili ya DNS inasubiri kabla ya kuomba sasisho la eneo kwenye seva ya msingi. Baada ya muda wa kusasisha kuisha, seva ya pili ya DNS huuliza seva ya msingi ili kupata nakala ya rekodi ya sasa ya SOA. Baada ya kupokea jibu, seva ya sekondari ya DNS inalinganisha nambari ya serial ya rekodi ya sasa ya SOA ya seva ya msingi (iliyoainishwa katika jibu) na nambari ya serial ya rekodi yake ya ndani ya SOA. Ikiwa maadili haya yanatofautiana, seva ya pili ya DNS huomba uhamishaji wa eneo kutoka kwa seva ya msingi ya DNS. Muda wa kusasisha chaguo-msingi ni dakika 15.

    MudaJaribu tena Muda

    Mudainaisha muda wakeBaada ya (Muda wake unaisha)

    Thamani katika sehemu hii huamua muda ambao seva ya pili inaendelea kutekeleza maswali ya mteja wa DNS bila kuwasiliana na seva msingi. Baada ya wakati huu, data inachukuliwa kuwa isiyoaminika. Kwa chaguomsingi, mpangilio huu umewekwa kuwa siku moja.

    Kiwango cha chinimudamaisha TTL (Kima cha chini kabisa (Chaguomsingi)TTL)

    Thamani za TTL hazitumiki kwa rekodi za rasilimali katika maeneo yenye mamlaka. Na kanda hizi hutumia maisha ya uandishi wa rasilimali kwenye seva zisizoidhinishwa kwa thamani za TTL. Seva ya DNS iliyohifadhi rekodi ya rasilimali kutoka kwa ombi la awali huweka upya rekodi hiyo, lakini TTL ya rekodi imekwisha muda wake.

    Muda maisha(TTL)kumbukumbu(TTL kwa Rekodi Hii)

    Thamani iliyobainishwa katika sehemu hii huamua maisha ya ingizo la sasa la SOA. Thamani hii inachukua nafasi ya thamani chaguo-msingi iliyobainishwa katika sehemu iliyotangulia.

    Rekodi za Nameserver

    Rekodi ya seva ya jina (NS) hubainisha seva inayoidhinishwa ya eneo. Unapounda eneo katika Windows Server 2008, kila seva inayodhibiti nakala msingi ya eneo lililounganishwa la Active Directory itapokea rekodi yake ya NS katika ukanda mpya kwa chaguo-msingi. Unapounda eneo la msingi la kawaida, rekodi ya NS ya seva ya ndani itaongezwa kwa chaguo-msingi.

    Kwa seva zinazodhibiti maeneo ya ziada, lazima uongeze mwenyewe rekodi za NS kwenye nakala kuu ya eneo.

    Rekodi za NS zinaundwa kwa kutumia utaratibu tofauti kuliko wakati wa kuunda aina nyingine za kumbukumbu za rasilimali. Ili kuongeza rekodi za NS, katika Kidhibiti cha DNS, bofya mara mbili rekodi yoyote iliyopo ya NS. Kichupo cha Seva za Majina cha kisanduku cha mazungumzo cha sifa za eneo hufungua. Kwenye kichupo cha Seva za Majina, bofya kitufe cha Ongeza ili kuongeza FQDN na anwani ya IP ya seva ambayo inadhibiti eneo la pili la eneo msingi la karibu. Baada ya kuongeza seva mpya, bofya Sawa - rekodi mpya ya NS itaonekana kwenye Kidhibiti cha DNS inayoonyesha seva hii.

    KUMBUKA: Washa utumaji kwa maeneo ya ziada

    Eneo la pili halitambui ingizo hili kama seva halali ya jina mradi tu lina nakala halali ya data ya eneo. Ili eneo la ziada lipokee data hii, uhamishaji wa eneo lazima uwezeshwe kwa seva hiyo kwenye kichupo cha Uhamisho wa Eneo cha kisanduku cha kidadisi cha sifa za eneo. Kichupo hiki kinaelezewa kwa undani zaidi katika mada inayofuata.

    Chini ni mfano wa ingizo iliyoundwa katika faili ya kawaida ya eneo:

    @NS dns1.lucernepublishing.com.

    Alama ya @ inawakilisha eneo lililofafanuliwa na ingizo la SOA kwenye faili ya eneo. Kisha rekodi kamili ramani ya kikoa wikipedia.org kwa seva ya DNS dns1.wikipedia.org.

    Kuunda Rekodi za Rasilimali

    Mbali na rekodi za SOA na NS, rekodi nyingine kadhaa za rasilimali zinaundwa moja kwa moja. Kwa mfano, wakati wa usakinishaji wa seva mpya ya DNS, seva inapoteuliwa kuwa kidhibiti cha kikoa, rekodi nyingi za Active Directory Domain Services (AD DS) SRV huundwa kiotomatiki katika eneo linalodhibitiwa ndani ya nchi. Kwa kuongeza, kupitia usasishaji unaobadilika, wateja wengi wa DNS husajili kiotomatiki rekodi za seva pangishi (A na AAAA) na pointer (PTR) katika ukanda kwa chaguo-msingi.

    Ingawa rekodi nyingi za rasilimali huundwa kiotomatiki, mazingira ya biashara kwa kawaida huhitaji baadhi ya rekodi za rasilimali kuundwa kwa mikono, kama vile MX (Mail Exchangers) kwa seva za barua, lakabu (CNAME) za seva za wavuti na programu, na rekodi za mwenyeji kwa seva na wateja , ambayo hawawezi kufanya masasisho yao wenyewe.

    Ili kuongeza rekodi ya rasilimali kwa ukanda, kwenye kiweko cha Kidhibiti cha DNS, bofya kulia ikoni ya eneo na uchague aina ya rekodi ya kuunda kutoka kwa menyu ya muktadha.

    Baada ya kuchagua ingizo kutoka kwa menyu ya muktadha, sanduku la mazungumzo linafungua ambapo unaweza kutaja jina la kuingia na kompyuta inayohusishwa nayo. Kumbuka kwamba rekodi za seva pangishi pekee huhusisha jina la kompyuta na anwani ya IP. Aina nyingi za rekodi huhusisha jina la huduma au lakabu na rekodi asili ya mwenyeji. Kwa hivyo, rekodi ya MX inategemea uwepo wa node ya SRV 12.nwtraders .msft katika eneo la rekodi.

    Aina za machapisho

    Zifuatazo ni rekodi za rasilimali za kawaida ambazo zinaundwa kwa mikono:

    nodi (AauALAA);

    jina la utani (CNAME);

    baruambadilishaji (MX);

    pointer (PTR);

    eneohuduma (SRV).

    Fundo (A au AAAA)

    Kwa mitandao mingi, wingi wa rekodi za rasilimali katika hifadhidata ya eneo ni rekodi za rasilimali za mwenyeji. Rekodi hizi hutumiwa katika eneo ili kuhusisha majina ya kompyuta (majina ya wapangishaji) na anwani za IP.

    Hata masasisho yanayobadilika yakiwa yamewashwa kwa maeneo, baadhi ya matukio ya ingizo la seva pangishi itakuhitaji uongeze maingizo kwenye eneo. Jedwali lifuatalo katika jedwali la Contoso, Inc. hutumia jina la kikoa contoso.com katika nafasi ya majina ya umma na kikoa cha Saraka Inayotumika. Katika hali hii, seva ya wavuti ya umma www.contoso.com iko nje ya kikoa cha Saraka Inayotumika na hufanya masasisho kwa seva ya DNS inayoidhinishwa na umma contoso.com. Lakini wateja wa ndani hutuma maombi yao ya DNS kwa seva za ndani za DNS. Kwa sababu www .contoso .com Rekodi haijasasishwa kiutendaji kwenye seva za ndani za DNS, inaongezwa mwenyewe ili wateja wa ndani waweze kutatua majina na kuunganishwa kwenye seva ya Wavuti ya umma.

    Rekodi za mwenyeji zinaweza kuongezwa mwenyewe ikiwa mtandao wako unatumia Seva ya UNIX. Kwa mfano, Fabrikam, Inc. ina kikoa kimoja cha Active Directory katika mtandao wake wa kibinafsi unaoitwa fabrikam,com. Mtandao huu pia unajumuisha seva ya UNIX, App1.fabrikam, com, ambayo huendesha programu muhimu kwa shughuli za kila siku za kampuni. Kwa kuwa seva za UNIX haziwezi kufanya masasisho yanayobadilika, itabidi uongeze mwenyewe rekodi ya seva pangishi ya App1 kwenye seva ya DNS inayodhibiti eneo la fabrikam.com. Vinginevyo, watumiaji hawataweza kuunganisha kwenye seva ya programu kwa kubainisha FQDN yake.

    Lakabu (CNAME)

    Maingizo haya wakati mwingine huitwa majina ya kisheria. Zinaruhusu majina mengi kutumika kurejelea nodi moja. Kwa mfano, majina ya seva zinazojulikana (ftp, www) kwa kawaida husajiliwa kwa kutumia rekodi za CNAME. Rekodi hizi hupanga majina ya wapangishaji yanayolingana na huduma zao na rekodi halisi ya AComputer inayodhibiti huduma.

    Unapotaka kubadilisha jina la nodi iliyoainishwa kwenye rekodi A ya eneo moja.

    Wakati jina la jumla la seva inayojulikana (km www) linahitaji kutatuliwa katika kundi la kompyuta binafsi (kila moja ikiwa na rekodi A) zinazotoa huduma sawa (km kundi la seva zisizohitajika za wavuti).

    Mbadilishaji wa posta (MX)

    Rekodi hizi hutumiwa na programu za barua pepe kupata seva ya barua katika eneo. Wanakuruhusu kulinganisha jina la kikoa lililoainishwa kwenye anwani ya barua pepe na rekodi ya Kompyuta inayodhibiti seva ya barua kwenye kikoa. Kwa hivyo, aina hii ya rekodi inaruhusu seva ya DNS kushughulikia barua pepe ambazo hazina seva ya barua iliyobainishwa.

    Mara nyingi rekodi za MX huundwa ili kutoa kushindwa kwa seva nyingine ya barua ikiwa seva inayopendekezwa haipatikani.

    Seva nyingi zimepewa maadili ya upendeleo. Kadiri thamani hii inavyopungua, ndivyo mpangilio wa upendeleo wa seva unavyoongezeka.

    KUMBUKA: Alama @

    Katika mfano huu, alama ya @ inawakilisha jina la kikoa la ndani lililo katika anwani ya barua pepe.

    KielekeziPTR

    Ingizo hili linatumika tu katika maeneo ya kuangalia kinyume ili kusaidia utafutaji wa kinyume unaotokea wakati wa kusuluhisha anwani za IP kwa majina ya wapangishaji au FQDN. Utafutaji wa kinyume unafanywa kwenye maeneo ya mizizi ya kikoa cha in -addr .arpa. Rekodi za PTR zinaweza kuongezwa kwa maeneo kwa mikono au kiotomatiki.

    Ufuatao ni mfano wa uwakilishi wa maandishi katika faili ya eneo la rekodi ya PTR iliyoundwa katika Kidhibiti cha DNS ambacho hupanga anwani ya IP 192.168.0.99 hadi seva ya jina la mpangishaji 1.google.ru:

    99 PTRseva 1.google.ru.

    KUMBUKA: Rekodi nambari 99PRT

    Katika ukanda wa kuangalia kinyume, oktet ya mwisho ya anwani ya IPv 4 ni sawa na jina la mwenyeji. Kwa hiyo, nambari 99 inawakilisha jina lililopewa node ndani ya eneo la 0.168.192.in -addr .arpa. Eneo hili linalingana na subnet ya 192.168.0.0.

    Mahali pa hudumaSRV

    Machapisho SRV hutumiwa kuonyesha eneo la huduma katika kikoa. Programu za mteja zinazotumia SRV zinaweza kurejesha rekodi za SRV za seva za programu kupitia DNS.

    Programu inayotumia SRV ni Saraka Inayotumika ya Windows Server 2008. Huduma ya nembo ya mtandao wa Netlogon hutumia rekodi za SRV kupata vidhibiti vya kikoa kwa kutafuta kikoa cha Itifaki ya Ufikiaji wa Saraka ya Uzito wa Saraka (LDAP). DNS ili kuboresha uvumilivu wa makosa au kutatua huduma za mtandao.

    KujumuishaDNS kwa utatuziAMESHINDA

    Kwenye kichupo cha WINS cha dirisha la sifa za eneo, unaweza kubainisha seva ya WINS ambayo huduma ya Seva ya DNS itawasiliana ili kutafuta majina ambayo hayapatikani na hoja za DNS. Unapobainisha seva ya WINS kwenye kichupo cha WINS cha sanduku la mazungumzo la Sifa za Eneo la Kutafuta Mbele, ingizo maalum la WINS linaongezwa kwenye eneo hilo ambalo linarejelea seva ya WINS. Unapobainisha seva ya WINS kwenye kichupo cha WINS cha sanduku la mazungumzo la mali ya eneo la kuangalia nyuma, ingizo maalum la WINS -R linaongezwa kwenye eneo ili kutambua seva hiyo ya WINS.

    Kwa mfano, ikiwa mteja wa DNS ataomba jina ClientZ .contoso .com na seva ya DNS inayopendelewa haiwezi kupata jibu katika vyanzo vya kawaida(kache, data eneo la ndani na kwa kupigia kura seva zingine), seva inaomba jina la CLIENTZ. kwenye seva ya WINS iliyoainishwa kwenye rekodi ya WINS. Ikiwa seva ya WINS itajibu swali, seva ya DNS hurejesha jibu lake kwa mteja.

    Kusafisha na kufuta rekodi zilizopitwa na wakati

    Mihuri ya saa hutumiwa katika DNS kufuatilia umri wa rekodi za rasilimali zilizosajiliwa kwa nguvu. Usafishaji wa rekodi za zamani ni mchakato wa kuondoa rekodi zilizopitwa na wakati kwa mihuri ya muda. Usafishaji unaweza kufanywa tu ikiwa mihuri ya muda itatumika. Mihuri ya wakati na kusugua hufanya kazi pamoja ili kuondoa rekodi za zamani ambazo zinaweza kuwa zimekusanywa katika eneo baada ya muda. Kwa chaguo-msingi, mihuri ya muda na kusugua huzimwa.

    Washa kusafisha

    Ili kuwezesha kusugua kwa eneo la mtu binafsi, lazima uwashe kipengele kwenye kiwango cha seva na kiwango cha eneo.

    Ili kuwezesha uondoaji wa kiwango cha seva, katika mti wa koni ya Kidhibiti cha DNS, bofya kulia ikoni ya seva na utumie amri ya Kuweka Kuzeeka / Kutafuta Kwa Maeneo Yote. Kisha, katika kisanduku cha mazungumzo cha Sifa za Kuzeeka / Kusafisha cha Seva inayofungua, chagua kisanduku tiki cha Rekodi za Rasilimali za Scavenge. Ingawa mpangilio huu huwezesha uwekaji muhuri wa saa wa kiwango cha seva na kusafisha maeneo yote mapya, hauwashi uwekaji muhuri wa nyakati na kusafisha maeneo yaliyopo ya Saraka Inayotumika.

    Ili kuwawezesha, bofya OK, na kisha katika sanduku la mazungumzo la Uthibitishaji wa Kuzeeka / Kutafuta Udhibiti unaofungua, chagua kisanduku cha kuteua ili kutumia mipangilio hii kwa kanda zilizopo za Active Directory-integrated.

    Ili kuwezesha mihuri ya muda na usafishaji wa kiwango cha eneo, fungua Sifa za Eneo, kisha kwenye kichupo cha Jumla, bofya kitufe cha Kuzeeka. Katika kisanduku cha mazungumzo cha Sifa za Kuzeeka/Kutafuta Mali zinazofungua, chagua kisanduku tiki cha Rekodi za Rasilimali za Scavenge.

    Mihuri ya muda Seva ya DNS husafisha kwa kutumia mihuri ya muda ambayo imewekwa kwenye rekodi za rasilimali katika eneo. Kanda zilizounganishwa za Saraka Inayotumika huweka thamani za muhuri wa muda kwa maingizo yaliyoingia kwa hiari kwa chaguo-msingi kabla ya kusugua kuwezeshwa. Hata hivyo, kanda za msingi za kawaida huweka mihuri ya muda kwa maingizo yaliyoingia kwa nguvu katika eneo baada ya kusugua kuwashwa. Rekodi za rasilimali zilizoundwa kwa mikono kwa aina zote za kanda zimepewa muhuri wa muda wa 0; hii ina maana kwamba umri wao hautajulikana.- huu ni wakati kati sasisho la hivi karibuni muhuri na inawezekana sasisho linalofuata. Kuzuia huzuia seva kuchakata masasisho yasiyo ya lazima na kupunguza kiasi cha trafiki. Kipindi chaguo-msingi cha kuzuia ni siku 7.

    Marekebishomudasasisho

    Muda wa kusasisha ni muda kati ya muda wa kwanza ambapo muhuri wa muda ulisasishwa na usafishaji wa rekodi ya muda ulianza. Baada ya kuzuia na kusasisha vipindi, maingizo yanaweza kuondolewa kwenye eneo. Kwa chaguo-msingi, muda ni siku 7. Kwa hivyo, ikiwa mihuri ya muda imewashwa, rekodi za rasilimali zilizoingia kwa nguvu zinaweza kufutwa baada ya siku 14.

    Kufanya usafishaji

    Kusafisha hufanywa katika eneo moja kwa moja au kwa mikono. Kwa utekelezaji otomatiki Usafishaji lazima uwezeshwe kwa kufuta kiotomatiki rekodi za rasilimali zilizopitwa na wakati kwenye kichupo cha Kina cha kisanduku cha mazungumzo cha sifa za seva ya DNS.

    Ikiwa chaguo hili halijawezeshwa, unaweza kufanya usafishaji wa eneo wewe mwenyewe kwa kubofya kulia aikoni ya seva katika mti wa kiweko wa Kidhibiti cha DNS na kutumia amri ya Rekodi za Rasilimali za Scavenge.

    Majina ya Ulimwenguni ya Eneo

    Windows Server 2008 inajumuisha kipengele kipya kinachoruhusu wateja wote wa DNS katika msitu wa Active Directory kutumia majina kutoka kwa lebo sawa, kama vile Mail, kuunganisha kwenye rasilimali za seva. Kipengele hiki ni muhimu ikiwa orodha ya utafutaji kiambishi tamati cha DNS kwa wateja wa DNS hairuhusu watumiaji kuunganisha kwa haraka (au kabisa) kwa nyenzo kwa kutumia jina la lebo moja.

    Seva ya DNS katika Windows Server 2008 hukuruhusu kuunda eneo la GlobalNames. Kwa chaguo-msingi, eneo la GlobalNames halipo, lakini kwa kupeleka eneo lenye jina hili, unaweza kutoa ufikiaji kwa rasilimali zilizochaguliwa kwa kutumia majina ya lebo moja bila kutumia WINS. Kwa kawaida, majina ya lebo moja hupewa seva muhimu na zinazotumiwa sana ambazo tayari zimepewa anwani tuli za IP. GlobalNames kwenye seva ya mbali, badilisha kipindi na jina la seva ya mbali.

    UumbajiKanda za GlobalNames

    Hatua inayofuata katika kupeleka eneo la GlobalNames ni kuunda eneo kwa ajili ya seva ya DNS ambayo inatumika kama kidhibiti cha kikoa cha Windows Server 2008. Eneo la GlobalNames si aina maalum ya eneo, bali ni eneo la kuangalia mbele la Active Directory-jumuishi linaloitwa GlobalNames. . Unapounda eneo, chagua kunakili data ya eneo kwa seva zote za DNS msituni. Chaguo hili linapatikana kwenye ukurasa wa upeo wa urudiaji wa eneo uliounganishwa wa Saraka Inayotumika (ili kuwezesha utatuzi wa jina la lebo moja, unda rekodi ya paka la rasilimali (CNAME) katika eneo la GlobalNames. Jina lililopewa kila rekodi ya CNAME linawakilisha jina la lebo moja ambalo watumiaji wanaweza kutumia kuunganisha kwenye rasilimali. Kumbuka kwamba kila rekodi ya CNAME inabainisha rekodi ya mwenyeji katika eneo lingine.

    Mfumo wa jina la kikoa ndio msingi wa 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?

    Kuwa na anwani ya rDNS iliyosanidiwa kwa usahihi ni muhimu kabisa kutuma ujumbe kutoka kwa seva yako ya barua pepe ya shirika. 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 kanuni ya kawaida Seva ya barua ya SMTP inayoripoti 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. Unaweza kusoma zaidi kuhusu kusajili mfumo wako wa uhuru (AS) na kizuizi cha anwani ya IP katika makala 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 yamekabidhiwa kwa kompyuta za mteja ambazo seva ya barua haiwezi kusakinishwa, na kwa hivyo 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 marekebisho madogo ya programu. 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
  • MS Seva ya Kubadilishana
    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: ukaguzi wa kinyume cha DNS unakataa idadi kubwa ya barua taka zinazotumwa kutoka kwa kompyuta zilizoambukizwa. watumiaji wa kawaida, kutengeneza botnets za barua 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 haiathiri majina ya kikoa kwa njia yoyote na anwani za posta katika barua zilizotumwa.

    • 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