|tot fajl schityvaetsya pervym pri zapuske named. On soobshchaet serveru ego tip, za kakie zony on otvechaet i gde vzyat' svoi nachal'nye dannye. Po umolchaniyu etot fajl nahoditsya v /etc/named.boot. Odnako eto mozhet byt' izmeneno ustanovkoj peremennoj BOOTFILE pri kompilyacii named ili ukazaniem mesta ego raspolozheniya v komandnoj stroke pri zapuske named.

Domen po umolchaniyu dlya servera imen mozhet byt' opredelen ispol'zuya stroku tipa:

domain       Berkeley.Edu

Bolee starye servera imen ispol'zuyut etu informaciyu kogda oni poluchayut zapros na imya bez ". ", kotoroe ne izvestno. Bolee novye ponimayut, chto biblioteka opredelitelya dobavit ego sobstvennoe ponimanie "domena po umolchaniyu (default domain) " k lyubomu neopredelennomu imeni. Na samom dele server imen mozhet byt' skompilirovan s podderzhkoj direktivy domain v fajle zagruzki, po umolchaniyu propuskaya ee, i my ochen' rekomenduem ne ispol'zovat' ee. Esli vy vse zhe ispol'zuete eto, klienty nahodyashchiesya vne vashego lokal'nogo domena budut posylat' k vam zaprosy ob neopredelennyh imenah i budet proishodit' stolknoveniya opredeleniya vashego domena s ih. Naibolee podhodyashchee mesto dlya ispol'zovaniya etoj funkcii - eto klient, v ego fajle /etc/resolv.conf (ili ravnoznachnom). Ispol'zovanie direktivy domain v vashem zagruzochnom fajle sbivaet vseh s tolku.

Direktiva directory opredelyaet katalog, v kotorom dolzhen rabotat' server imen i razreshaet ispol'zovanie dlya ostal'nyh imen fajlov v zagruzochnom fajle otnositel'nyh putej. Mozhet byt' ispol'zovana tol'ko odna direktiva directory i ona dolzhna byt' dana do vseh ostal'nyh direktiv, opredelyayushchih imena fajlov.

       directory        /var/named

Esli u vas bol'she chem para fajlov, s kotorymi dolzhen rabotat' named, vy mozhete pomestit' eti fajly v katalog tipa /var/named i primenit' sootvetstvuyushchuyu komandu directory. Glavnaya cel' etoj komandy - udostoverit'sya, chto named nahoditsya v sootvetstvuyushchem kataloge, kogda pytaetsya vklyuchit' fajly s otnositel'nym putem v $INCLUDE, a takzhe pozvolit' named rabotat' v tom meste, gde on mozhet otbrosit' korku (dump core) esli emu vdrug stanet ploho.

Stroka v zagruzochnom fajle, naznachayushchaya server pervichnym glavnym serverom dlya zony vyglyadit sleduyushchim obrazom:

primary        Berkeley.Edu   ucbhosts

Pervoe pole govorit nam, chto server yavlyaetsya pervichnym dlya zony, opisannoj vo vtorom pole. Tret'e pole yavlyaetsya imenem fajla, iz kotorogo nuzhno chitat' dannye.

Vysheskazannoe podrazumevaet, chto zona, kotoruyu vy opredelyaete est' zona klassa IN. Esli vy hotite opredelit' drugoj klass, vy mozhete dobavit' /class k pervomu polyu, gde class - eto celoe chislo ili standartnoe simvol'noe predstavlenie klassa. Naprimer, stroka dlya pervichnogo servera zony klassa hesiod vyglyadit tak:

primary/HS         Berkeley.Edu    hesiod.data

Neobhodimo zametit', chto podderzhka klassov zon, otlichayushchihsya ot klassa IN vklyuchaetsya vo vremya kompilyacii i mozhet byt' otklyuchena vashim postavshchikom pri postroenii vashej operacionnoj sistemy.

Stroka dlya vtorichno servera analogichna pervichnomu za isklyucheniem togo, chto ona perechislyaet adresa drugih serverov (obychno pervichnyh), ot kotoryh budut polucheny dannye o zone.

secondary     Berkeley.Edu   128.32.0.10  128.32.0.4  ucbhosts.bak

Pervoe pole govorit o tom, chto eto vtorichnyj server dlya zony opisannoj vo vtorom pole. Dva setevyh adresa opredelyayut servera imen, na kotoryh imeyutsya dannye dlya etoj zony. Nuzhno otmetit', chto kak minimum odin iz nih budet pervichnym, i, poka vy ispol'zuete kakoj-libo drugoj protokol vmesto IP/DNS dlya mehanizma peredachi zony, ostal'nye budut drugimi vtorichnymi serverami. Vytyagivanie dannyh s drugih vtorichnyh serverov na vash vtorichnyj server obychno ne ochen' horosho, tak kak proishodit zaderzhka v rasprostranenii izmenenij v zone. Mozhno celenapravlenno ispol'zovat' mnogo adresov v opisanii secondary, kogda pervichnyj server imeet mnogo setevyh interfejsov i, sootvetstvenno, mnogo adresov. Vtorichnyj server poluchaet svoi dannye cherez set' ot odnogo iz perechislennyh serverov. Adresa serverov probuyutsya v poryadke perechisleniya. Posle spiska pervichnyh serverov propisano imya fajla, dannye o zone budut zapisany v etot fajl. Kogda server zapuskaetsya v pervyj raz, dannye zagruzhayutsya, esli eto vozmozhno, iz etogo fajla, a pervichnyj server oprashivaetsya po povodu togo, ne ustareli li eti dannye. Nuzhno otmetit', chto perechislenie vashego servera kak vtorichnogo ne neobhodimo -- roditel'skaya zona dolzhna delegirovat' polnomochiya vashemu serveru, kak pervichnomu, kak i dlya ostal'nyh vtorichnyh, ili vy budete perekachivat' vsyu zonu; ni odin drugoj server ne budet imet' prichiny oprashivat' vash po povodu zony poka v roditel'skoj zone on ne budet perechislen kak server dlya zony.

Kak i v sluchae pervichnogo dlya klassa, otlichnogo ot IN, vy dolzhny opredelyat' vtorichnyj server dobavleniem /class k klyuchevomu slovu secondary, naprimer secondary/HS.

Stroka dlya poddel'nogo servera analogichna vtorichnomu. (|ta vozmozhnost' poyavilas' kak eksperimental'naya v versii 4.9.3.)

    stub   Berkeley.Edu       128.32.0.10  128.32.0.4  ucbhosts.bak 

Pervoe pole govorit o tom, chto server yavlyaetsya poddel'nym serverom dlya zony opisannoj vo vtorom pole.

Poddel'nye zony nuzhny dlya togo, chtoby byt' uverennymi v tom, chto pervichnyj server dlya zony vsegda imeet korrektnye zapisi tipa NS dlya vseh porozhdennyh zon. Esli pervichnyj server ne yavlyaetsya vtorichnym dlya porozhdennoj zony, to on dolzhen byt' skonfigurirovan s poddel'nymi zonami dlya vseh svoih "detej". Poddel'nye zony obespechivayut mehanizm dozvolyayushchij zapisi tipa NS dlya zon, opisannyh tol'ko v odnom meste.

  

    primary        CSIRO.AU       csiro.dat
    stub           dms.CSIRO.AU   130.155.16.1  dms.stub 
    stub           dap.CSIRO.AU   130.155.98.1  dap.stub

Vse servera, vklyuchaya "tol'ko keshiruyushchie " servera, dlya inicializacii kesha servera imen dolzhny imet' v zagruzochnom fajle stroku tipa:

  

    cache       .             root.cache

V vashih fajlah kesha ne pishite nichego krome informacii o kornevom servere.

Vse opisannye kesh-fajly budut prochitany vo vremya zagruzki named i vse destvitel'nye znacheniya budut vosstanovleny v keshe. Informaciya o kornevom servere imen v kesh-fajlah budet ispol'zovat'sya do teh por, poka na zapros o korne ne budet poluchen otvet ot odnogo iz serverov imen, opisanyh v kesh-fajle, posle chego etot otvet budet ispol'zovat'sya vmesto kesh-fajla poka vremya dejstviya otveta ne istechet.

Vmeste s pervichnym i vtorichnym, vy mozhete ukazat' vtorichnyj server dlya klassa otlichnogo ot IN dobavleniem k klyuchevomu slovu cache slova /class, naprimer class/HS.

Lyuboj server iozhet ispol'zovat' peresyl'shchikov. Peresylka - eto eshche odna vozmozhnost' servera pri obrabotke rekursivnyh zaprosov ot imeni drugih sistem. Komanda forwarders ukazyvaet peresyl'shchika po ego adresu v internet:

  

    forwarders       128.32.0.10   128.32.0.4

Imeyutsya dve bol'shie prichiny, chtoby tak delat'.

Pervaya, nekotorye sistemy mogut ne imet' polnyj dostup k seti i mogut byt' zakryty ot posylki kakih-libo IP paketov v ostal'nuyu chast' Internet, i takim obrazom dolzhny polozhit'sya na peresyl'shchika imeyushchego polnyj dostup ko vsej seti. Vtorya prichina - eto to, chto peresyl'shchik vidit vse zaprosy prohodyashchie cherez ego server v sovokupnosti i takim obrazom vystraivaet ochen' bogatyj kesh dannyh po sravneniyu s keshem servera imen tipichnoj rabochej stancii. V rezul'tate, peresyl'shchik stanovitsya metakeshem, kotorym mogut vospol'zovat'sya vse hosty, umen'shaya v rezul'tate obshchee chislo zaprosov iz dannogo mesta v ostal'nuyu chast' seti.

Rabota "peresyl'shchikov " sostoit v tom, chtoby sootnesti nekotorye fiksirovannye adresa so spiskom serverov imen, kotorye nuzhno probovat' pri kazhdom zaprose. Obychno etot spisok sostoit tol'ko iz serverov s bolee vysokoj vlast'yu, obnaruzhennyh cherez NS zapisi dlya sootvetstvuyushchego domena. Esli peresyl'shchiki ne otvechayut, to poka direktiva slave ne byla dana, budut oprosheny neposredstvenno sootvetstvuyushchie servera dlya oblastej.

Podchinennyj rezhim ispol'zuetsya, esli ispol'zovanie peresyl'shchikov - edinstvennyj vozmozhnyj sposob razreshit' zaprosy iz-za otsutstviya polnogo dostupa k seti ili esli vy zhelaete ogradit' server imen ot ispol'zovaniya kakih-libo drugih peresyl'shchikov, krome perechislennyh. Podchinennyj rezhim aktiviziruetsya ukazaniem v zagruzochnom fajle prostoj komandy

  

     options forward-only 

Esli ispol'zuetsya eta opciya, to vy dolzhny opredelit' peresyl'shchikov. V podchinennom rezhime, server budet peresylat' kazhdyj zapros k kazhdomu iz peresyl'shchikov, do teh por, poka ne budet najden otvet, ili ischerpan spisok peresyl'shchikov. Server ne budet probovat' vhodit' v kontakt s lyubym udalennym serverom imen, krome perechislennyh spiske peresyl'shchikov.

Tak, v to vremya kak forwardres ispol'zuet adresa iz "spiska serverov" dlya kazhdogo zaprosa, options forward-only zastavlyaet "spisok serverov" soderzhat' tol'ko te adresa, kotorye perechisleny v ob®yavlenii forwarders. Nebrezhnoe ispol'zovanie direktivy options forward-only mozhet vyzyvat' dejstvitel'no uzhasnye cikly peresylki, tak kak vy mogli by zakonchit' zaprosy peresylki k nekotoromu naboru hostov, kotorye takzhe yavlyayutsya podchinennymi, a odin ili neskol'ko iz nih mogli by peresylat' zaprosy obratno k vam.

Ispol'zovanie direktivy options forward-only dolzhno byt' ochen' ostorozhnym. Obratite vnimanie, chto to zhe samoe povedenie mozhet byt' dostignuto ispol'zovaniem direktivy slave.

Razdelenie dannyh BIND na avtoritativnye (zony) i neavtoritativnye (kesha) vsegda bylo neskol'ko slabo, i, kak izvestno vozmozhno zagryaznenie vysheupomyanutyh cherez poslednie. Odin iz sposobov predotvratit' eto, takzhe kak i sohranit' pamyat' na serverah podderzhivayushchih mnozhestvo avtoritativnyh dannyh (naprimer kornevyh serverah) sostoit v tom, chtoby delat' takie servera " nerekursivnymi". |to mozhet byt' dostignuto ispol'zovaniem v zagruzochnom fajle direktivy

  

     options      no-recursion

Server, na kotorom vklyuchena eta opciya ne budet pytat'sya vybirat' dannye, chtoby pomoch' otvetit' na zaprosy - esli vy sprashivaete ego o dannyh kotorye on ne imeet, to on budet posylat' vam sylki na bolee avtoritativnye servera ili, esli on sam avtoritativen za zaprashivaemuyu zonu, to on prishlet vam otricatel'nyj otvet.

Nerekursivnyj server mozhet byt' proimenovan v NS RR, no ne mozhet byt' ukazan v fajle resolv.conf.

Esli fajlovaya sistema, soderzhashchaya vash fajl syslog imeet dostatochno mnogo mesta, to vy mozhete rassmotret' ispol'zovanie v vashem zagruzochnom fajle direktivy

  

           options        query-log

|to zastavit vash server imen protokolirovat' vse poluchaemye zaprosy, a ispol'zovanie kombinacii skriptov na Perl ili AWK pri posleduyushchej obrabotke fajla protokola, mozhet stat' poleznym sredstvom upravleniya.

BIND po umolchaniyu ne podderzhivaet obratnye zaprosy, i eto, kak izvestno, mozhet vyzyvat' problemy dlya nekotoryh operacionnyh sistem mikro|VM i dlya bolee staryh versij instrumenta nslookup. Vy mozhete reshit', chto namnogo luchshe, esli vmesto otveta "operation not implemented", named dolzhen obnaruzhivat' naibolee obshchie obratnye zaprosy i otvechat' na nih poddel'noj informaciej; konechno zhe luchshe proizvesti obnovlenie vashih klientov, chtoby prekratit' zavisimost' ot obratnyh zaprosov, no esli eto ne vozmozhno, vy dolzhny ispol'zovat' etu direktivu v vashem zagruzochnom fajle

  
    
         options    fake-iquery

OBRATITE VNIMANIE: otvety fakticheski poddel'ny, oni soderzhat kvadratnye skobki ISO8859 ([ i ]), tak chto vashi klienty ne budut sposobny sdelat' chto-nibud' poleznoe s etimi otvetami. Nablyudalos', chto ni odin klient nikogda ne delal chto-nibud' poleznoe dazhe s real'nymi otvetami na obratnye zaprosy.

Nekotorye operacii servera imen mogut ispol'zovat' dostatochno bol'shoe kolichestvo resursov, i dlya togo, chtoby sootvetstvenno nastroit' vashu sistemu inogda neobhodimo izmenit' vnutrennie kvoty BIND. |to dostigaetsya posredstvom sleduyushchih direktiv v zagruzochnom fajle:

  
    
        limit   <name>   <value>

Ogranicheniya i ih znacheniya po umolchaniyu vyglyadyat tak:

  

        limit  transfers-in  10

Pri etom chislo oznachaet kolichestvo odnovremennyh processov named-xfer kotorye BIND mozhet zapustit'. Esli vash vtorichnyj server imeet sotni ili tysyachi podderzhivaemyh zon, to bolee vysokie chisla mogut privesti k bolee bystroj shodimosti k pervichnym serveram,no ustanovka slishkom vysokogo znacheniya mozhet privesti k ochen' vysokoj zagruzke servera i pozhiraniyu resursov, takih kak shirina propuskaniya seti ili svopingovogo prostranstva. OBRATITE VNIMANIE: eto ogranichenie mozhet byt' vyrazheno pdirektivoj max-fetch NN.

  

       limit   transfers-per-ns  2

|to chislo oznachaet kolichestvo processov named-xfer, kotorye mozhet iniciirovat' BIND k lyubomu zadannomu serveru imen. V bol'shinstve sluchaev vy ne dolzhny izmenyat' eto chislo. Esli vash vtorichnyj server tashchit sotni ili tysyachi zon s odnogo pervichnogo servera, uvelichenie transfers-per-ns mozhet' uskorit' shodimost'. |to chislo nuzhno derzhat' kak mozhno men'shim, vo izbezhanie bol'shoj zagruzki i pozhiraniya resursov na pervichnom servere.

Bol'shinstvo sistem imeyut kvoty, ogranichivayushchie razmer tak nazyvaemogo "segmenta dannyh", gde BIND derzhit vse avtoritativnye dannye i kesh. BIND budet postupat' suboptimal'no (vozmozhno dazhe pri zavershenii raboty) esli on rabotaet pri etoj kvote. Esli vasha sistema podderzhivaet sistemnyj vyzov, izmenyayushchij etu kvotu dlya opredelennogo processa, vy mozhete poprosit' BIND ispol'zovat' etot sistemnyj vyzov posredstvom direktivy limit datasize NN. Znachenie zadannoe zdes' mozhet byt' zadano dobavleniem k dlya 1024X, m dlya (1024^2)X, i g dlya (1024^3)X. V 1995g., vse kornevye servera ispol'zovali limit datasize 64m.

|to mozhet byt' sluchaj, kotoryj vasha organizaciya ne zhelaet vydavat' polnye spiski vashih hostov komu ugodno v Inernet, kto mozhet dostich' vashih serverov imen. Hotya poka eto vse eshche vozmozhno dlya lyudej "iterirovat'" cherez vash diapazon adresov, ishcha zapisi PTR i formiruya spisok vashih hostov "medlennym " " sposobom, poetomu vse eshche vyglyadit rezonnym ogranichit' vash eksport zon cherez protokol peredachi zon. CHtoby ogranichit' spisok sosedej mogushchih brat' zony s vashego servera, ispol'zujte direktivu xfrnets.

|ta direktiva imeet takoj zhe sintaksis, chto i forwarders, za isklyucheniem togo, sto vy mozhete perechislit' setevye adresa v dobavlenie k adresam hostov. Naprimer, esli vy hotite razreshit' dostup k peredache zon s vashego servera tol'ko hostam seti klassa A s nomerom 16, vy mozhete ispol'zovat' direktivu

|to ne dostatochno detal'no, i budushchaya versiya BIND budet razreshat' opredelyat' takoj kontrol' dostupa na pohostovoj osnove, vmesto tekushchego na posetevoj osnove. Obratite vnimanie, chto, v to vremya kak v etoj direktive adresa bez yavnyh masok prinimayutsya za seti, vy mozhete opredelit' masku, kotoraya budet nastol'ko detal'na, kak vy zahotite, vozmozhno, vklyuchaya vse bity adresa tak, chto tol'ko odin edinstvennyj host poluchit razreshenie na peredachu. Naprimer, rassmotrim

chto razreshit tol'ko hostu 16.1.0.2 peredavat' zony ot vas. Zamet'te, chto ne dolzhno byt' ni odnogo probela vokrug znaka "& ", predstavlyayushchego soboj setevuyu masku.

Direktiva xfrnets dlya sovmestimosti s promezhutochnymi vypuskami BIND 4.9. takzhe mozhet byt' zadana kak tcplist.

Esli imeetsya mnozhestvo adresa, dostupnyh dlya servera imen, s kotorymi zahochet kontaktirovat' BIND, BIND snachala budet probovat' te, kotorye on schitaet "samymi blizkimi". "Blizost'" opredelyaetsya v terminah pohozhesti po adresu; to-est' esli odin iz adresov nahoditsya v toj zhe samoj podseti chto i nekotoryj interfejs hosta, to pervym budet oprobovan etot adres. Esli eto ne poluchitsya, to zatembudet poprobovan adres, nahodyashchijsya v toj zhe seti. Esli i eto provalitsya, i esli v fajle named.boot ne byla zadana direktiva sortlist, to adresa budut oprobovany v bolee ili menee proizvol'nom poryadke. Direktiva sortlist imeet sintaksis, podobnyj forwarders, xfrnets, i bogusns - vy zadaete emu spisok setej v vide xxx.xxx.xxx.xxx, i on ispol'zuet ih pri "predpochtenii" odnih serverov imen pered drugimi. Esli nikakaya yavnaya maska ne obespechivaetsya kazhdym elementom sortlist , to budet sdelan vyvod osnovannyj na bitah adresa starshego razryada.

Esli vy nahodites' v seti klassa C, imeyushchej set' klassa B vami i ostal'nym Internet, vy mogli by poprobovat' uvelichit' udachu servera imen v poluchenii otvetov, perechisliv set' klassa B v direktive sortlist. |to dolzhno imet' effekt pri oprobovanii "blizhajshih" serverov pered bolee "udalennymi". Obratite vnimanie, chto eto povedenie yavlyaetsya novym, i poyavilos' nachinaya s, BIND 4.9.

Drugoj i bolee staryj effekt direktivy sortlist dolzhen zastavit', BIND sortirovat' zapisi tipa A v lyubom generiruemom otvete, chtoby pomestit' te, kotorye imeyutsya v sortlist pered ostal'nymi. |to ne nastol'ko polezno, kak vy mogli by podumat', tak kak mnogie klienty budut peresortirovyvat' zapisi tipa A v proizvol'nom poryadke ili ispol'zuya "magazinnyj poryadok" (LIFO); takzhe uchtite to, chto server budet sposoben dogadat'sya o topologii seti klienta, i takim obrazom ne budet sposoben tochno uporyadochit' "blizost'" ko vsem vozmozhnym klientam. Vypolnenie uporyadocheniya v razreshitele yasno vyshe.

V real'noj praktike, eta direktiva ispol'zuetsya ochen' redko, tak kak eto zhestko privyazyvaet bystro menyayushchuyusya informaciyu; set', kotoraya "blizka" segodnya, mozhet byt' "otdalena" uzhe v sleduyushchem mesyace. Tak kak BIND sozdaet kesh vremen otveta udalennyh serverov imen, to on budet bystro shodit'sya na "priemlemom" povedenii, kotoroe ne oznachaet "optimal'noe", no pochti to zhe samoe. Budushchie napravleniya razvitiya BIND, vklyuchayut vybor adresov, osnovyvayas' na metrikah lokal'nyh interfejsov (hostah, imeyushchih bol'she chem odin interfejs) i, vozmozhno, na informacii iz tablicy marshrutizacii. My ne sobiraemsya reshat' obobshchennuyu problemu "multihomed" hostov, no my dolzhny byt' sposobny sdelat' chto-to poluchshe chem to,chto my imeem sejchas. Analogichno, my nadeemsya uvidet' biblioteku razreshitelya na bolee vysokom urovne, sortiruyushchuyu otvety na osnove informacii o topologii, sushchestvuyushchej tol'ko na klientskom hoste.

Inogda sluchaetsya, chto nekotoryj udalennyj server imen stanovitsya "plohim". Vy mozhete ukazat' vashemu serveru imen otkazat'sya slushat' ili zadavat' voprosy k konkretnym serveram imen, perechisliv ih v direktive bogusns v vashem fajle named.boot. |ta direktiva imeet tot zhe sintaksis chto i forwarders, xfrnets, i sortlist -vam nuzhno tol'ko zadat' emu spisok adresov Internet v vide xxx.xxx.xxx.xxx. Obratite vnimanie, chto zony, delegiruemye na takie servera ne budut dostupny dlya klientov vashih serverov; takim obrazom vy dolzhny ispol'zovat' etu direktivu umerenno ili voobshche ne ispol'zovat'.

Esli vash server yavlyaetsya vtorichnym dlya mnozhestva zon, vy mozhete najti udobnym raschlenit' vash fajl named.boot na staticheskuyu chast', kotoraya vryadli kogda-libo izmenitsya (v nee mogli by vojti direktivy tipa directory, sortlist, xfrnets i cache), i dinamicheskie chasti, kotorye izmenyayutsya dostatochno chasto (vse vashi direktivy primary mogli vojti v odin fajl, a vse direktivy secondary - v drugoj fajl - i lyuboj iz nih, ili oba eti fajla mogli byt' vytashcheny avtomaticheski ot nekotorogo soseda tak, chtoby oni mogli izmenit' vash spisok vtorichnyh zon bez vashego aktivnogo vmeshatel'stva). Vy mozhete vypolnyat' eto posredstvom direktivy include, kotoraya beret v kachestve parametra tol'ko odno imya fajla. Ne nuzhny nikakie kavychki vokrug imeni fajla. Imya fajla budet oceneno posle togo, kak server imen izmenit rabochij katalog na tot, chto opredelen direktivoj directory, poetomu vy mozhete ispol'zovat' otnositel'nye imena, esli vasha sistema ih podderzhivaet.

Fajl konfiguracii nazyvaetsya /etc/resolv.conf. |tot fajl oboznachaet servera imen v seti, k kotorym nuzhno poslat' zaprosy. Razreshitel' budet probovat' ustanovit' kontakt s serverom imen na localhost, esli on ne smozhet najti fajl konfiguracii. V lyubom sluchae vy dolzhny ustanovit' fajl konfiguracii na kazhdom hoste, tak kak eto - edinstvennyj rekomenduemyj sposob opredelit' domen po umolchaniyu na sistemnom urovne, i vy mozhete zapisat' v nego adres lokal'nogo hosta, esli na nem rabotaet server imen. Budet vpolne rezonno sozdat' etot fajl v sluchae esli u vas rabotaet lokal'nyj server, tak kak ego soderzhimoe budet keshirovat'sya kazhdym klientom razreshitelya, kogda klient delaet pervyj vyzov programmy razreshitelya.

Fajl resolv.conf soderzhit direktivy, po odnoj v kazhdoj strochke, v sleduyushchej forme:

; kommentarij
# drugoj kommentarij
domain local-domain 
search search-list 
nameserver server-address 
sortlist sort-list 
options option-list

Hotya by odna iz direktiv domain ili search dolzhna byt' dana, hotya by odin raz. Esli dana direktiva search, to pervyj element v zadannom spiske poiska (search-list) perevesit lyuboj ranee opredelennyj local-domain. Direktiva nameserver mozhet byt' dana do treh raz; vse dopolnitel'nye direktivy nameserver budut ignorirovany. Esli stroka budet nachinat'sya s ";" ili "#", to eta stroka budet schitat'sya kommentariem; nuzhno otmetit', chto kommentarii ne byli pozvoleny v rannih versiyah razreshitelya (teh chto byli vklyucheny v BIND versij mladshe 4.9) - tak chto esli versiya razreshitelya vashego prodavca podderzhivaet kommentarii, to on v samom dele ochen' rastoropen.

Local-domain budet dobavlen k lyubomu zaprosu, ne soderzhashchemu ".". local-domain mozhet byt' obojden na urovne processov ustanovkoj peremennoj okruzheniya LOCALDOMAIN. Nuzhno otmetit', chto obrabotka local-domain mozhet byt' otklyuchena ustanovkoj opcii v razreshitele.

Search-list - eto spisok domenov, kotorye probuyutsya, po poryadku, dlya imen, ne soderzhashchih ".". Obrabotka search-list mozhet byt' otklyuchena ustanovkoj opcii v razreshitele. Takzhe otmet'te, chto peremennaya okruzheniya "LOCALDOMAIN" mozhet podavit' search-list na urovne processov.

Adresa serverov (server-address) sobirayutsya vmeste i zatem ispol'zuyutsya kak naznachenie po umolchaniyu zaprosov, generiruemyh cherez razreshitel'. Drugimi slovami, takim obrazom vy mozhete skazat' razreshitelyu, kakie servera imen on dolzhen ispol'zovat'. Dlya opredelennyh klientskih prilozhenij sushchestvuet vozmozhnost' obojti etot spisok, i ona obychno osushchestvlyaetsya vnutri servera imen (kotoryj v to zhe samoe vremya i est' klient razreshitelya) i v testovyh programmah tipa nslookup. Nuzhno otmetit', chto esli vy hotite perechislit' lokal'nyj host v fajle konfiguracii razreshitelya, vy luchshe vsego dolzhny ispol'zovat' ego pervichnyj adres v Internet, chem psevdoimya lokal'nogo hosta tipa 127.0.0.1 ili 0.0.0.0. |to neobhodimo iz-za oshibki v setevom kode nekotoryh versij BSD pri obrabotke soedinennyh soketov SOCK_DGRAM. Esli vy dolzhny ispol'zovat' psevdoadres, to luchshe vsego vmesto 127.0.0.1 ispol'zovat' 0.0.0.0 (ili prosto "0"), vprochem, vy preduprezhdeny, chto v zavisimosti ot tipa vashego setevogo koda BSD, oba iz nih sposobny na oshibku, kakzhdyj po-svoemu. Esli realizaciya IP na vashem hoste ne sozdaet korotkozamknutyj marshrut mezhdu interfejsom po umolchaniyu i petlevym (loopback) interfejsom, to vy mozhete dobavit' staticheskij marshrut (naprimer v /etc/rc.local) eto delaetsya tak:

route add myhost.domain.name localhost 1

Sort-list - eto spisok par IP adresov i setevyh masok. Adresa vozvrashchaemye proceduroj gethostbyname sortiruyutsya v poryadke opredelennom etim spiskom. Lyubye adresa, kotorye ne sootvetstvuyut param adresov i setevyh masok budut vozvrashcheny posle vsego. Setevaya maska opcional'na, i esli ona ne opredelena, budet ispol'zovana natural'naya setevaya maska.

Option-list - eto spisok opcij, kazhdaya iz kotoryh podavlyaet kakuyu-libo iz vnutrennih peremennyh razreshitelya. V nastoyashchee vremya podderzhivayutsya sleduyushchie opcii:

 
debug

vystavlyaet bit RES_DEBUG v _res.options.

 
ndots:n

vystavlyaet bolee nizkij porog (izmeryaemyj v "kolichestve tochek") v imenah zadannyh res query(), tak chto imena s kak minimum etim kolichestvom tochek budut oprobovany kak absolyutnye imena, prezhde chem budet proizvedena obrabotka local-domain ili search-list. Po umolchaniyu eta vnutrennyaya peremennaya ravna "1".

6.3.1. root.cache

Server imen dolzhen znat' servera, kotorye yavlyayutsya avtoritarnymi serverami imen dlya kornevogo domena seti. CHtoby eto sdelat', my dolzhny zapolnit' kesh servera imen adresami etih avtoritarnyh serverov imen. Raspolozhenie etogo fajla opredeleno v fajle nachal'noj zagruzki. |tot fajl ispol'zuet Standartnyj Format Zapisi Resursa (inache nazyvaemogo Masterfile Format) opisyvaemogo dalee v etom dokumente.

Imeetsya dva standartnyh fajla dlya opisaniya dannyh dlya domena. |to hosts i host.rev. |ti fajly ispol'zuyut Standartnyj Format Zapisi Resursa, opisyvaemyj dalee v etom dokumente. Nuzhno otmetit', chto imena fajlov vybrany proizvol'no; mnogie setevye administratopy predpochitayut nazyvat' svoi fajly zon po imenam soderzhashchihsya v nih domenov, osobenno v usrednennom sluchae, kogda dannyj server yavlyaetsya pervichnym i/ili vtorichnym dlya mnozhestva razlichnyh zon.

|tot fajl soderzhit vse dannye o mashinah v etoj zone. Mestonahozhdenie etogo fajla opredeleno v fajle nachal'noj zagruzki.

|tot fajl opredelyaet domen IN-ADDR.ARPA. |to special'nyj domen dlya togo, chto by mozhno bylo preobrazovyvat' adresa v imena. Tak kak adresa hostov v Internet ne vhodyat v granicy domena, etot special'nyj domen byl sformirovan dlya togo, chtoby mozhno bylo proizvodit' obratnoe preobrazovanie. Domen IN-ADDR.ARPA imeet chetyre metki, uprezhdayushchie ego. |ti metki sootvetstvuyut chetyrem oktetam adresov Internet. Vse chetyre okteta dolzhny byt' opisany, dazhe esli oktet soderzhit tol'ko nuli. Adres Internet 128.32.0.4 nahoditsya v domene 4.0.32.128.IN-ADDR.ARPA. |ta perestanovka adresa ochen' neudobna dlya chteniya, no pozvolyaet estestvennoe gruppirovanie hostov v seti.

|tot fajl opredelyaet zapis' PTR dlya lokal'nogo petlevogo interfejsa (loopback interface), bolee izvestnogo kak local-host, chej setevoj adres 127.0.0.1. Mestonahozhdenie etogo fajla opredelyaetsya v fajle nachal'noj zagruzki. Dlya pravil'noj raboty kazhdogo servera imen zhiznenno vazhno, chtoby adres 127.0.0.1 imel zapis' PTR ukazyvayushchuyu obratno na imya "localhost.". Imya etoj zapisi PTR vsegda "1.0.0.127.IN-ADDR.ARPA". |to prosto neobhodimo, esli vy hotite, chtoby pol'zovateli mogli ispol'zovat' opoznavanie imeni hosta po imeni "localhost" (v hosts.equiv ili ~/.rhosts). Kak svyazannaya s etoj zapis'yu PTR, v kazhdom domene, soderzhashchem hosty dolzhna sushchestvovat' zapis' "localhost.my.dom.ain" A (s adresom 127.0.0.1). "localhost." poteryaet poslednyuyu tochku, kotoraya trebutsya dlya 1.0.0.127.in-addr.arpa; togda opcii razreshitelya DEFNAMES i/ili DNSRCH zastavyat ocenit' "localhost" kak imya hosta v lokal'nom domene.

Strochka vklyuchenij nachinaetsya s $INCLUDE, nachinaya s pervoj kolonki, i prodolzhaetsya imenem fajla, i, neobyazatel'no, novym vremennym $ORIGIN ispol'zuemym poka etot fajl schityvaetsya. |ta osobennost', v chastnosti, polezna dlya razdeleniya razlichnyh tipov dannyh na neskol'ko fajlov. Naprimer:

    
$INCLUDE /usr/local/adm/named/data/mail-exchanges

|ta strochka mozhet byt' interpretirovana kak zapros na schityvanie fajla /usr/local/adm/named/data/mail-exchanges. Kommanda $INCLUDE ne zastavlyaet schityvat' dannye v razlichnye zony ili derev'ya. Ona predostavlyaet prostuyu vozmozhnost' organizovat' dannye dannogo pervichnogo domena v otdel'nyh fajlah. Odna lish' osobennost' "vremennogo $ORIGIN" opisannaya vyshe ne dostatochna dlya togo chtoby razdelit' vashi dannye na nekotorye drugie zony - granicy zon mogut byt' vvedeny tol'ko v fajle nachal'noj zagruzki.

Fajl $INCLUDE v svoej pervoj zapisi resursa dolzhen imet' imya. |to oznachaet, chto pervyj simvol pervoj ne zakommentirovannoj stroki ne dolzhen byt' probelom. Tekushchee imya po umolchaniyu v roditel'skom fajle ne privodit k fajlu $INCLUDE.

Istochnik (origin) - sposob izmeneniya istochnika v fajle dannyh. Stroka nachinaetsya s pervoj kolonki i prodolzhaetsya domennym istochnikom. Kazhetsya, chto eto mozhet byt' polezno dlya soderzhaniya bolee chem odnoj zony v fajle dannyh, no eto rabotaet sovsem ne tak. Server imen po sushchestvu dela trebuet, chtoby dannaya zona polnost'yu otobrazhalas' v nekotorom opredelennom fajle. Takim obrazom, vy dolzhny byt' ochen' ostorozhny i ispol'zovat' $ORIGIN tol'ko odin raz v nachale fajla ili vnutri fajla dlya perehoda k "bolee nizkomu" domenu v zone - no nikogda k sovershenno inoj zone.

{name}  {ttl}  addr-class   SOA     Origin               Person in charge
@              IN           SOA     ucbvax.Berkeley.Edu.
kjd.ucbvax.Berkeley.Edu. (
                                    1995122103   ; Serial
                                    10800        ; Refresh
                                    1800         ; Retry
                                    3600000      ; Expire
                                    259200 )     ; Minimum

Nachalo Polnomochij. Zapis' SOA, oboznachaet nachalo zony. Imya - eto imya zony i chasto zadaetsya kak "@", tak kak eto vsegda tekushchij $ORIGIN i zapis' resursa SOA obychno pervaya zapis' v fajle pervichnoj zony. Origin - eto imya hosta na kotorom nahoditsya etot fajl dannyh (govorya inache, pervichnyj glavnyj (primary master)server dlya etoj zony). Otvetstvennoe lico (Person in charge) - eto adres elektronnoj pochty cheloveka otvetstvennogo za server imen, s "@" zamenennoj na ".". Serijnyj nomer (serial number) - eto nomer versii etogo fajla dannyh, kotoryj dolzhen byt' polozhitel'nym celym chislom. |tot nomer dolzhen uvelichivat'sya kazhdyj raz, kogda v dannye vnosyatsya izmeneniya. Starye servera razreshali ispol'zovat' fantomnuyu "." v etom i drugih chislah v fajle dannyh; n.m schitalos' kak "n000m", a ne kak bolee intuitivnoe "n*1000+m" (tak chto 1.234 perevodilos' v 1000234 a ne v 1234). |ta osobennost' sil'no osuzhdalas' iz-za ee neponyatnosti, nepredskazuemosti, i voobshche ona byla absolyutno nenuzhnoj. Nuzhno otmetit', chto ispol'zuya zapis' "YYYYMMDDNN" vy mozhete delat' do 100 izmenenij v den' vplot' do 4294 goda. A voobshche vy mozhete ispol'zovat' takoj tip zapisi, kotoryj dlya vas bolee udoben. Esli vy horosho programmiruete na perl vy dazhe mozhete ispol'zovat' nomera versij RCS dlya generacii serijnogo nomera. Pole Refresh pokazyvaet kak chasto (v sekundah)vtorichnye servera imen dolzhny proveryat' pervichnyj server imen, chtoby uznat', ne nuzhno li obnovit' zonu? Pole Retry pokazyvaet kak dolgo (v sekundah) vtorichnyj server dolzhen zhdat' pered tem kak povtorit' provalennuyu peredachu zony. Pole Expire ukazyvaet verhnee ogranichenie, v sekundah, v techenie kotorogo vtorichnyj server mozhet ispol'zovat' dannye do togo kak oni poteryayut silu iz-za otsutstviya obnovleniya. Pole Minimum - eto kolichestvo sekund, ispol'zuemoe po umolchaniyu dlya vremeni zhizni (ttl) v zapisyah resursov. Ono takzhe yavlyaetsya vynuzhdennym minimumom dlya Vremeni ZHizni, esli ono opredeleno v kakoj-libo zapisi resursa (RR) v zone. Dlya kazhdoj zony dolzhna byt' tol'ko odna zapis' SOA.

Zapis' Server Imen, NS, opisyvaet server imen otvetstvennyj za dannyj domen, sozdavaya tochku delegirovaniya i podzonu. Pervoe pole imeni opisyvaet zonu obsluzhivaemuyu serverom imen vo vtorom imeni. Dlya kazhdoj zony neobhodimo po krajnej mere dva servera imen.

 
{name}   {ttl}   addr-class   A    address
  
ucbarpa          IN           A    128.32.0.4
                 IN           A    10.0.0.78

Zapis' Adres, A, opisyvaet adres ukazannoj mashiny. Pole imeni opisyvaet imya mashiny, a pole adresa - setevoj adres.Dlya kazhdogo adresa mashiny dolzhna byt' odna zapis' A.

 
{name}   {ttl}    addr-class  HINFO   Hardware    OS

                  IN          HINFO   VAX-11/780  UNIX

Zapis' Informaciya o Hoste, HINFO, prednaznachena dlya specificheskih dannyh o hoste. Ona prednaznachena dlya opisaniya This lists the apparatury i operacionnoj sistemy, rabotayushchej na opisannom hoste. Esli vy hotite vklyuchit' probel v imya mashiny, to by dolzhny zaklyuchit' imya v kavychki (ispol'zuya simvoly ""). Na kazhdyj host mozhet sushchestvovat' odna zapis' HINFO, hotya iz-za soobrazhenij bezopasnosti bol'shinstvo domenov voobshche ne soderzhat ni odnoj zapisi HINFO. Ni odna programma ot nee ne zavisit.

 
{name}   {ttl}    addr-class  WKS   address     protocol   list-of-services

                  IN          WKS   128.32.0.10 UDP        who route timed domain
                  IN          WKS  128.32.0.10 TCP       ( echo telnet discard
sunrpc sftp uucp-path systat daytime netstat qotd nntp link chargen ftp auth
time whois mtp pop rje finger smtp supdup hostnames domain nameserver )

Zapis' Izvestnye Servisy, WKS, opisyvaet izvestnye servisy, podderzhivaemye opredelennym protokolom po ukazannomu adresu. Spisok servisov i nomerov portov beretsya iz spiska servisov opisannyh v /etc/services. Na kazhdyj protokol na kazhdyj adres dolzhna byt' tol'ko odna zapis' WKS. Vot chto govorit RFC1123 o zapisyah WKS:

2.2 Ispol'zovanie Servisa Domennyh Imen

...

Prilozhenie NE DOLZHNO nadeyat'sya na vozmozhnost' obnaruzhit' zapis' WKS soderzhashchuyu tochnoe perechislenie vseh servisov po konkretnomu adresu hosta, tak kak zapis' resursa WKS ne slishkom chasto ispol'zuetsya v Internet. CHtoby udostoverit'sya, chto servis prisutstvuet, prosto popytajtes' ego ispol'zovat'.

...

5.2.12 Ispol'zovanie WKS pri obrabotke MX: RFC-974, str. 5

RFC-974 [SMTP:3] rekomenduetsya oprashivat' domennuyu sistemu po povodu zapisi WKS ("Izvestnye Servisy"), chtoby udostoverit'sya, chto kazhdaya predpolagaemaya pochtovaya cel' podderzhivaet SMTP. Opyt pokazyvaet, chto WKS ne imeet shirokoj podderzhki, poetomu shag poiska WKS pri obrabotke MX NE NUZHNO ispol'zovat'.

...

6.1.3.6 Status of RR Types

...

Tipy zapisej resursov TXT i WKS ne imeyut shirokogo ispol'zovaniya v Internet; v rezul'tate, prilozheniya ne mogut polozhit'sya na sushchestvovanie zapisej resursov tipa TXT ili WKS v bol'shinstve domenov.

 
alias     {ttl}     addr-class   CNAME   Canonical-name
 
ucbmonet            IN           CNAME   monet

Zapis' resursa Kanonicheskoe Imya (Canonical Name), CNAME, ukazyvaet psevdoimya ili psevdonim dlya oficial'nogo, ili kanonicheskogo, imeni hosta. Tol'ko odna eta zapis' dolzhna associirovat'sya s psevdonimom. Vse ostal'nye zapisi dolzhny associirovat'sya s kanonicheskim imenem, a ne psevdoimenem. Lyubaya zapis' resursa, vklyuchayushchaya domennoe imya kak svoe znachenie (naprimer, NS ili MX) dolzhna soderzhat' kanonicheskoe imya, a ne psevdoimya. Analogichno, pri poiske zapisej resursov tipa A budut sledovat' CNAME, a pri drugih zapisyah, tipa MX ili NS i bol'shinstve drugih - net. Kanonicheskie imena (CNAME) mogut ukazyvat' na drugie CNAME, no eto vyglyadit ochen' nebrezhno.

Psevdonimy polezny, kogda horosho izvestnyj host menyaet svoe imya. V etom sluchae, horosho by imet' zapis' CNAME, chtoby lyudi, vse eshche ispol'zuyushchie staroe imya mogli popast' v nuzhnoe mesto.

 
name      {ttl}     addr-class   PTR     real-name

7.0                 IN           PTR     monet.Berkeley. Edu.

Zapis' Ukazatel' na Domennoe Imya (Domain Name Pointer), PTR, pozvolyaet special'nym imenam ukazyvat' v kakoe-libo inoe mestonahozhdenie v domene. Predydushchij primer zapisi PTR ispol'zuetsya pri ustanovke obratnogo ukazatelya dlya special'nogo domena IN-ADDR.ARPA. |ta stroka vzyata iz primera fajla hosts.rev. Zapisi PTR neobhodimy dlya funkcii gethostbyaddr. Nuzhno otmetit' poslednyuyu "." kotoraya zashchishchaet ot dobavleniya BIND tekushchego $ORIGIN k etomu domennomu imeni.

 
name      {ttl}     addr-class   MX      preference value    mail exchange 

Munnari.OZ.AU.      IN           MX      0                  Seismo.CSS.GOV.
*.IL.               IN           MX      0                  RELAY.CS.NET.

Zapisi Mail eXchange, MX, ispol'zuyutsya dlya oboznacheniya spiska hostov, kotorye skonfigurirovany dlya priema pochty poslannoj na eto domennoe imya. Kazhdoe imya, poluchayushchee pochtu dolzhno imet' MX, potomu chto esli kto-to ne najden vo vremya dostavki pochty, MX budet "vveden" so stoimost'yu 0 i sam budet yavlyat'sya adresatom informacii dlya hosta. Esli vy hotite, chtoby host sam poluchal svoyu pochtu, vy dolzhny sozdat' zapis' MX dlya imeni vashego hosta, ukazyvayushchuyu na imya hosta. Luchshe, chtoby eto bylo yavno ukazano, chem pozvolit' vvesti eto udalennym pochtovym otpravitelyam. V pervom primere vyshe, Seismo.CSS.GOV. - eto pochtovyj shlyuz, znayushchij kak dostavit' pochtu v Munnari.OZ.AU.. |ti dve mashiny mogut imet' svoi sobstvennye podklyucheniya ili ispol'zovat' razlichnye sposoby peredachi dannyh. "preference value" - eto ukazanie otpravitelyu povtoryat' peredachu, esli imeetsya bolee odnogo puti dlya dostavki pochty na opredelennuyu mashinu. Zamet'te, chto bolee nizkie chisla pokazyvayut bolee vysokij prioritet, a otpraviteli dolzhny ispol'zovat' v proizvol'nom poryadke hosty MX s odinakovym prioritetom dlya ravnomernogo raspredeleniya nagruzki esli stoimost' odinakova. Dlya bolee podrobnoj informacii smotri RFC974.

Imena zadannye s ispol'zovaniem simvola "*" (vmesto lyubyh simvolov) mogut byt' ispol'zovany dlya pochtovoj marshrutizacii s zapisyami MX. Veroyatno, v seti imeyutsya servera, kotorye prosto schitayut, chto lyubaya pochta dlya domena dolzhna byt' marshrutizirovana cherez translyator (relay). Vtoroj primer vyshe: vsya pochta dlya hostov v domene IL marshrutiziruetsya cherez RELAY.CS.NET. |to zadano s pomoshch'yu sozdaniya zapisi resursa s ispol'zovaniem "wildcard", kotoryj ukazyvaet, chto *.IL imeyut MX na RELAY.CS.NET. Zapisi MX s "wildcard" na praktike ne ochen'-to i polezny, ved' dazhe esli pochtovoe soobshchenie postupaet na shlyuz dlya zadannogo domena, ono vse eshche dolzhno byt' marshrutizirovano vnutri etogo domena, i v nastoyashchee vremya nevozmozhno imet' yavno raznyj nabor zapisej MX vnutri i snaruzhi domena. Esli vam ne ponadobyatsya kakie-libo Pochtovye Kommutatoryvnutri vashego domena, nu chto zhe, togda vpered, smelo ispol'zujte "wildcard". Esli vy hotite ispol'zovat' zapisi MX s ispol'zovaniem "wildcard" kak dlya zapisej "verhnego urovnya" tak i dlya specificheskih "vnutrennih" zapisej, to zamet'te, chto kazhdaya specificheskaya zapis' dolzhna budet "zakanchivat'sya" polnym perechisleniem dannyh, soderzhashchihsya v zapisi dlya "verhnego urovnya". |to neobhodimo iz-za togo, chto specificheskie zapisi MX voz'mut verh nad zapisyami "verhnego urovnya" s ispol'zovaniem "wildcard", i budut vypolnyat' funkcii "verhnego urovnya", esli dannyj vnutrennij domen mozhet prinimat' pochtu snaruzhi cherez shlyuz. Zapisi MX s "wildcard" - ochen' tonkoe delo, poetomu vy dolzhny byt' ochen' ostorozhny s nimi.

 
name   {ttl}   addr-class   TXT   string
Munnari.OZ.AU. IN           TXT   "foo"

Zapis' TXT soderzhit tekstovye dannye lyubogo vida. Sintaksis teksta zavisit ot domena, gde on byl najden; mnogie sistemy ispol'zuyut zapisi TXT dlya kodirovaniya lokal'nyh dannyh v stilizovannom formate. MIT Hesiod - odna iz takih sistem.

 
owner   {ttl}  addr-class   RP    mbox-domain-name   TXT-domain-name

franklin       IN           RP    ben.franklin.berkeley.edu. sysadmins.berkeley.edu.

Zapis' "Otvetstvennaya Persona", RP, opredelyaet imya ili gruppu imen otvetstvennyh za host. Obychno zhelatel'no, chtoby bylo vozmozhno opredelit' sushchestvo, otvetstvennoe za opredelennyj host. Kogda etot host nahoditsya v vyklyuchennom sostoyanii ili rabotaet nepravil'no, vy mozhete zahotet' poznakomit'sya slyud'mi, kto mozhet byt' otvetstvennen za vosstanovlenie hosta.

Pervoe pole, mbox-domain-name - eto domennoe imya, opredelyayushchee pochtovyj yashchik otvetstvennogo cheloveka. Ego format v fajle zon ispol'zuet soglashenie DNS po kodirovaniyu pochtovyh yashchikov, identichnoe tomu, chto ispol'zovalos' v zapisi SOA v pole pochtovogo yashchika dlya Otvetstvennoj Persony (Person-in-charge). V vysheprivedennom primere, mbox-domain-name pokazyvaet zashifrovannoe "<ben@franklin.berkeley.edu>". Mozhet byt' opredelen kornevoj domen (prosto "."), chto budet ukazyvat' na to, chto pochtovogo yashchika net.

Vtoroe pole, TXT-domain-name - eto imya domena dlya kotorogo sushchestvuet zapis' TXT. Mozhet byt' osushchestvlen posleduyushchij zapros dlya polucheniya sootvetstvuyushchej zapisi resursa TXT dlya TXT-domain-name. |to obespechivaet uroven' kosvennoj adresacii, tak chto na cheloveka mozhno delat' ssylki iz razlichnyh mest v DNS. Dlya TXT-domain-name mozhet byt' opredelen kornevoj domen (prosto ".") chto budet pokazyvat', chto ne sushchestvuet sootvetstvuyushchih Zapisej Resursa tipa TXT. V vysheprivedennom primere "sysadmins.berkeley.edu." - eto imya zapisi TXT, kotoraya mozhet soderzhat' nekotoryj tekst s imenamii telefonnymi nomerami.

Format zapisi RP ne chuvstvitelen k klassu. Na odno imya v baze dannyh mozhet byt' mnozhestvo zapisej RP, no oni dolzhny imet odinakovoe TTL.

Zapis' RP vse eshche eksperimental'na; ne vse servera imen podderzhivayut ili raspoznayut ee.

 
name     {ttl}    addr-class  AFSDB   subtype   server-host-name
toaster.com.      IN          AFSDB   1         jack.toaster.com.
toaster.com.      IN          AFSDB   1         jill.toaster.com.
toaster.com.      IN          AFSDB   2         tracker.toaster.com.

Zapis' AFSDB ispol'zuetsya dlya oboznacheniya hostov, obespechivayushchih nekotoryj tip raspredelennogo servisa, reklamiruemogo v etom domennom imeni. Znachenie subtype (analogichno znacheniyu "preference" v zapisi MX) pokazyvaet, kakoj tip raspredelennogo servisa obespechivaet dannoe imya. Subtype 1 pokazyvaet, chto nazvannyj host yavlyaetsya serverom baz dannyh AFS (R) dlya elementa AFS v dannom domennom imeni. Subtype 2 pokazyvaet, chto nazvannyj host obespechivaet servis imen vnutri elementa dlya elementa DCE (R) nazvannogo dannym domennym imenem. V vysheprivedennom primere, jack.toaster.com i jill.toaster.com ob®yavlyayutsya kak servera baz dannyh dlya elementa AFS toaster.com, tak chto klienty AFS kotorym nuzhen servis ot toaster.com napravlyayutsya na eti dva hosta za dal'nejshej informaciej. Tret'ya zapis' ob®yavlyaet chto tracker.toaster.com soderzhit server direktorij dlya kornya yachejki DCE toaster.com, tak chto klienty DCE, zhelayushchie obratit'sya k servisu DCE dolzhny prokonsul'tirovat'sya s hostom tracker.toaster.com po povodu dal'nejshej informacii. Podtip zapisi DCE obychno soprovozhdaetsya zapis'yu TXT opisyvayushchej vse ostal'nye detali, ispol'zuemye pri dostupe k elementu DCE. RFC1183 soderzhit bolee podrobnuyu informaciyu ob etom tipe zapisi.

Zapis' AFSDB vse eshche eksperimental'na; ne vse servera imen podderzhivayut ili raspoznayut ee.

 
name    {ttl}   addr-class   PX   prefer    822-dom    X.400-dom

*.ADMD-garr.X42D.it.   IN    PX   50        it.        ADMD-garr.C-it.
*.infn.it.             IN    PX   50        infn.it.   O.PRMD-infn.ADMD-garr.C-it.
*.it.                  IN    PX   50        it.        O-gate.PRMD-garr.ADMD-garr.C-it.

Zapisi PX (Ukazatel' na preobrazovanie informacii X.400/RFC822) ispol'zuyutsya dlya ukazaniya pravil preobrazovaniya adresov mezhdu adresami X.400 O/R i pochtovymi adresami tipa RFC822 (domennogo tipa). Dlya bolee detal'nogo opisaniya processa preobrazovaniya smotri RFC1327.

Imeetsya 3 razlichnyh tipa pravil preobrazovaniya:

1) preobrazovanie iz X.400 v RFC822 (opredelyaetsya kak "table 1 rules" v RFC1327)

2) preobrazovanie iz RFC822 v X.400 (opredelyaetsya kak "table 2 rules" v RFC1327)

3) kodirovanie RFC822 v X.400 (opredelyaetsya kak "gate table" v RFC1327)

Vse tri tipa pravil preobrazovanich opredeleny ispol'zovaniem Zapisi Resursa tipa PX v DNS, nesmotrya na to, chto znachenie name razlichny: dlya sluchaya 1, znachenie name - eto domen X.400 v sintaksise DNS, togda kak dlya sluchaev 2 i 3 znachenie name yavlyaetsya domenom RFC822. CHtoby uznat', kak opisat' domen X.400 v sintaksise DNS i ispol'zovat' v nem klyuchevoe slovo X42D, smotri RFC-1664. Imeetsya opredelennyj instrumentarij dlya preobrazovaniya tablic iz formata RFC1327 v format fajlov v sintaksise DNS. Preference analogichno parametru Preference v Zapisi Resursa MX: v nastoyashchee vremya dlya nego sovetuetsya ispol'zovat' fiksirovannoe znachenie 50. 822-dom zadaet pravilo preobrazovaniya dlya chasti RFC822, a X.400-dom zadaet pravilo preobrazovaniya dlya chasti X.400 (v sintaksise DNS). V nastoyashchee vremya sovetuetsya vsegda ispol'zovat' znacheniya name s simvolom lyubogo znaka (wildcarded),tak kak specifikacii tablic RFC1327 pozvolyayut tol'ko "wildcard" specifikacii. |to nuzhno dlya togo, chtoby sohranit' sovmestimost' s sushchestvuyushchimi servisami, ispol'zuyushchimi staticheskie tablicy RFC1327 vmesto informacii DNS PX.

Specifikacii pravil preobrazovaniya iz X.400 v sintaksis RFC822 trebuyut sozdaniya sootvetstvuyushchego domennogo dereva X.400 v DNS, vklyuchaya takzhe specificheskie zapisi SOA i NS dlya samogo domena. Specifikacii pravil preobrazovaniya iz RFC822 v X.400 mogut byt' vstroeny pryamo v normal'noe pryamoe derevo name. I opyat' skazhem: dlya bolee detal'nogo opisaniya organizacii podobnyh struktur smotrite RFC1664.

Instrumental'nye programmy i biblioteki, osnovannye na standartnyh programmah i bibliotekah razreshitelya, mogut poluchit' iz DNS pravila preobrazovaniya v sintaksise RFC1327 ili DNS.

I snova, smotrite RFC1664, o tom kak ispol'zovat' Zapis' Resursa PX, i bud'te ostorozhny v koordinirovanii informacii o preobrazovanii, kotoruyu vy mozhete opredelit' v DNS s podpbnoj informaciej opredelennoj v statichnyh tablicah RFC1327.

Zapis' PX vse eshche eksperimental'na; ne vse servera podderzhivayut ili raspoznayut ee.

Ispol'zovanie razlichnyh polej Vremeni ZHizni (Time To Live) v RRset bylo osuzhdeno i teper' ustanavlivaetsya serverom vo vremya zagruzki pervichnoj zony. Smotri razdel "Bezopasnost'", gde obsuzhdayutsya raznye TTL.

Naznachenie Vremeni ZHizni dlya zapisej i dlya zony posredstvom polya Minimum v zapisi SOA ochen' vazhno. Vysokie znacheniya privedut k nizkomu setevomu traffiku BIND i bolee bystromu vremeni otveta. Bolee nizkie znacheniya privedut k generacii bol'shogo kolichestva zaprosov no obespechat bystroe rasprostranenie izmenenij.

TTL vliyaet tol'ko na izmeneniya i udaleniya iz zony. Dobavleniya rasprostranyayutsya v sootvetstvii so znachenie Refresh v SOA.

Opyt pokazyvaet, chto znachenie TTL po umolchaniyu dlya zon menyaetsya ot 0.5 dnya do 7 dnej. Vy mozhete poprobovat' uvelichit' TTL po umolchaniyu, kotoroe pokazyvaetsya v proshlyh versiyah etogo rukovodstva ot odnogo dnya (86400 sekund) do treh dnej (259200 sekund).

|to ochen' sil'no umen'shit kolichestvo zaprosov k vashim serveram imen.

Esli vam nuzhno bystroe rasprostranenie izmenenij i udalenij, mudrym resheniem mozhet stat' umen'shenie znacheniya polya Minimum za neskol'ko dnej do izmenenij, zatem sdelat' nuzhnye izmeneniya i vosstanovit' TTL v ego prezhnem znachenii.

Esli vashi zony dostatochno stabil'ny (vy v osnovnom dobavlyaete novye zapisi bez izmenenij i udalenij staryh) to vy dazhe mozhete poprobovat' ustanovit' znachenie TTL bol'she chem tri dnya.

Zamet'te, chto v lyubom sluchae, ne imeet smysla imet' zapisi s TTL nizhe chem znachenie zaderzhki SOA Refresh, tak kak Zaderzhka - eto vremya trebuemoe dlya vtorichnyh serverov dlya polucheniya kopii zanovo modificirovannoj zony.

Bezopasnye zony realizuyut bezopasnost' na osnove "zona za zonoj". |to razrabotano dlya ispol'zovaniya spiskov dostupa setej ili hostov, kotorye mogut poluchat' opredelennuyu informaciyu iz zony.

Dlya togo, chtoby ispol'zovat' bezopasnost' zony, named dolzhen byt' skompillirovan s vystavlennym SECURE_ZONES i vy dolzhny imet' po krajnej mere odnu Zapis' Resursa secure_zone TXT. Poka dlya dannoj zony ne sushchestvuet zapis' secure_zone, ne mozhet byt' predprinyato nikakih ogranichenij k dannym v etoj zone. Format Zapisi Resursa secure_zone TXT sleduyushchij:

 
secure_zone     addr-class     TXT     string

Zdes' addr-class mozhet byt' ili HS ili IN. Sintaksis dlya strochki TXT ili "network address:netmask" ili "host IP address:H".

"network address:netmask" pozvolyaet delat' zaprosy iz vsej seti. Esli setevaya maska opushchena, dlya ukazannogo setevogo adresa named budet ispol'zovat' setevuyu masku po umolchaniyu.

"host IP address:H" pozvolyaet delat' zaprosy s hosta. "H" posle ":" trebuetsya dlya otdeleniya adresa hosta ot adresa seti. V odnom fajle zony mozhet sushchestvovat' mnozhestvo Zapisej Resursov secure_zone TXT.

Naprimer, vy mozhete ustanovit' tak, chto zona budet otvechat' tol'ko na zaprosy Hesiod iz seti klassa B 130.215.0.0 i s hosta 128.23.10.56, esli vy dobavite sleduyushchie dve zapisi resursa tipa TXT:

secure_zone     HS     TXT     "130.215.0.0:255.255.0.0" 
secure_zone     HS     TXT     "128.23.10.56:H" 

|ta osobennost' mozhet byt' ispol'zovana dlya ogranicheniya dostupa k karte parolej Hesiod ili dlya razdel'nogo razresheniya vnutrennih i vneshnih adresov internet na faervol'noj (firewall) mashine bez neobhodimosti zapuska otdel'nogo named dlya vnutrennego i vneshnego razresheniya adresov.

Zamet'te, chto vam nuzhno budet vklyuchit' vash kol'cevoj (loopback) interfejs (127.0.0.1) v vashu zapis' secure_zone, ili vashi lokal'nye klienty ne smogut razreshit' imena.

Hesiod, razrabotannyj MIT Project Athena - eto informacionnyj servis, postroennyj na BIND. Ego cel' analogichna Sun'ovskomu NIS: dlya dostavki informacii o pol'zovatelyah, gruppah, dostupnyh po seti fajlovyh sistemah, printerah, i pochtovyh servisah po vsem installyaciyam. Krome togo, chto eta shtuka ispol'zuet BIND vmesto otdel'nogo servernogo koda, eshche odnim vazhnym razlichiem mezhdu Hesiod i NIS yavlyaetsya to, chto Hesiod ne sobiraetsya imet' delo s parolyami i identifikaciej, a tol'ko s dannymi, ne trebuyushchimi povyshennoj bezopasnosti. Servera Hesiod mogut byt' organizovany dobavleniem zapisej resursov v servera BIND; ili kak otdel'nye servera s otdel'nym administrirovaniem.

CHtoby pobol'she uznat' i razdobyt' Hesiod zajdite po anonymous FTP na host ATHENA-DIST.MIT.EDU i vytashchite kompressirovannyj tar fajl /pub/ATHENA/hesiod.tar.Z. Vam ne ponadobyatsya novye biblioteki named i razreshitelya tak kak ih funkcional'nye vozmozhnosti uzhe byli integrirovany v BIND nachinaya s versii 4.9. CHtoby uznat' kak Hesiod funkcioniruet v vide chasti vychislitel'noj sredy Athena vytashchite dokument /pub/ATHENA/usenix/athena-changes.PS s togo zhe FTP servera. Tam eshche est' tar fajl s primerami fajlov resursov Hesiod.

v to vremya kak ispol'zovanie klassa Hesiod vse eshche otkrytyj vopros, te zhe samye servisy vozmozhno mogut byt' obespecheny ispol'zovaniem zapisej klassa IN, tipa TXT i tipa CNAME. V lyubom sluchae, kod i dokumentaciya dlya Hesiod pomogut uznat' kak ustanovit' i ispol'zovat' etot servis.

Zamet'te, chto v to vremya kak BIND vklyuchaet podderzhku dlya zaprosov klassa HS, logika peredachi zon dlya zon, otlichnyh ot klassa INvse eshche nahoditsya na stadii eksperimenta.

|ta sekciya soderzhit primernye fajly dlya servera imen. Zdes' imeyutsya primery dlya fajlov nachal'noj zagruzki dlya razlichnyh tipov serverov i primery dlya domennyh fajlov baz dannyh.

; 
; Boot file for Primary Name Server
; 
            ;type         domain                  source file or host
;
             directory    /usr/local/adm/named
             primary      Berkeley.Edu            ucbhosts
             primary      32.128.in-addr.arpa     ucbhosts.rev
             primary      0.0.127.in-addr.arpa    named.local
             cache;       .                       root.cache

6.9.2.1. /etc/resolv.conf

domain Berkeley.Edu
nameserver 128.32.0.4
nameserver 128.32.0.10
sortlist   130.155.160.0/255.255.240.0 130.155.0.0