Zonă dns suplimentară. Crearea și configurarea zonelor DNS
Bună ziua, dragi cititori și abonați obișnuiți, site blog IT. Ultima dată ne-am uitat la ce este un server DNS, principiile sale de funcționare, înregistrările de bază și multe altele. Dacă ați omis nota, vă sfătuiesc să o citiți. În publicația de astăzi vreau să iau în considerare problema zonelor inverse și aplicarea lor.
Căutare inversă DNS- o zonă specială de domeniu concepută pentru a determina numele unei gazde prin adresa sa IPv4 utilizând o înregistrare PTR. Adresa nodului AAA.BBB.CCC.DDD este tradusă în notație inversă și devine DDD.CCC.BBB.AAA.in-addr.arpa. Datorită model ierarhic gestionarea numelor, devine posibilă delegarea managementului zonei proprietarului unei game de adrese IP. Pentru a face acest lucru, înregistrările autoritare ale serverului DNS indică faptul că un server separat este responsabil pentru zona CCC.BBB.AAA.in-addr.arpa (adică rețeaua AAA.BBB.CCC.000/24).
O înregistrare PTR (din engleză pointer - pointer) asociază IP-ul unei gazde cu numele său canonic. O solicitare în domeniul in-addr.arpa către IP-ul gazdei în formă inversă va returna numele acestei gazde. De exemplu, (la momentul scrierii), pentru adresa IP 192.0.34.164: o solicitare pentru înregistrarea PTR 164.34.0.192.in-addr.arpa va returna numele său canonic referrals.icann.org.in-addr.arpa
in-addr.arpa este o zonă specială de domeniu concepută pentru a determina un nume de gazdă după adresa sa IPv4 utilizând o înregistrare PTR. Adresa gazdă AAA.BBB.CCC.DDD este tradusă în notație inversă și devine DDD.CCC.BBB.AAA.in-addr.arpa. Datorită modelului ierarhic de gestionare a numelor, este posibilă delegarea managementului zonei proprietarului unei game de adrese IP. Pentru a face acest lucru, înregistrările cu autoritate ale serverului DNS indică faptul că un server separat este responsabil pentru zona CCC.BBB.AAA.in-addr.arpa (adică rețeaua AAA.BBB.CCC/24).
Utilizare
Pentru a reduce volumul de mail nedorite (spam), multe servere de primire e-mail poate verifica prezența unei înregistrări PTR pentru gazda de la care are loc trimiterea. În acest caz, înregistrarea PTR pentru adresa IP trebuie să se potrivească cu numele expeditorului server de mail, la care apare în timpul sesiunii SMTP.
Continuând subiectul construirii site-ului web, să vorbim despre asta aspect important Cum funcționează sistemul de nume de domeniu (DNS)? Multe probleme legate de plasarea inițială, precum și transferul de site-uri între diferite servere și găzduiri, sunt asociate cu configurarea și locația zonei DNS. Înțelegerea modului în care funcționează sistemul de nume de domenii facilitează gestionarea propriilor domenii și site-uri asociate și alte servicii.
Ce este un nume de domeniu? Pentru mulți, aceasta este sinonimă cu o adresă de site web, de exemplu, www.site. Introducând această adresă, sunteți ferm încrezător că veți ajunge pe acest site și nu în altă parte. În același timp, un nume de domeniu poate desemna nu numai un site web, ci și un server de e-mail, de schimb mesaje scurte sau alt serviciu de internet și de rețea. Numele de domenii sunt incluse în zonele de domeniu, care sunt situate unul în celălalt într-o ordine ierarhică.
Într-un sens general, un domeniu este un nume simbolic care vă permite să vă adresați în mod unic unui spațiu de nume autonom pe Internet. Și nu numai adresa, ci și permite oricărui client să găsească rapid nodul necesar, fără să aibă măcar cea mai mică idee despre locația lui. Nu este o exagerare să spunem că sistemul DNS stă la baza internetului modern în forma în care cu toții îl cunoaștem și suntem obișnuiți cu el.
Sistemul DNS este global și are o ierarhie strictă. Luați în considerare următoarea diagramă:
Nivelul superior al ierarhiei este domeniul rădăcină, notat cu un punct, care conține informații despre domeniile de prim nivel, de ex. ru, com, org etc. Funcționarea zonei rădăcină este asigurată de 13 servere rădăcină situate în întreaga lume și replicând constant datele între ele. De fapt, există mai multe servere rădăcină, dar caracteristicile de protocol vă permit să specificați doar 13 noduri nivel superior, prin urmare, scalabilitatea și toleranța la erori a sistemului este asigurată de oglinzile fiecărui server rădăcină.
Domeniile de prim nivel sunt zone de domeniu familiare nouă și pot fi gestionate atât de organizații naționale, cât și internaționale și au propriile lor condiții de utilizare. Fiecare zonă de domeniu de prim nivel vă permite să plasați cantitate nelimitată domenii de nivel al doilea, care sunt familiare fiecărui utilizator de Internet ca adrese de site-uri web.
La rândul lor, domeniile de nivel al doilea sunt, de asemenea, zone de domeniu și vă permit să plasați domenii de nivel al treilea, în care, ca într-o păpușă nesting, puteți plasa domenii al patrulea, al cincilea etc. niveluri. Pentru a putea determina fără ambiguitate nodurile situate în zone diferite, a fost introdus conceptul nume de domeniu complet calificat (FQDN, complet calificat Nume de domeniu ), care include toate numele de domenii părinte din ierarhia DNS. De exemplu, pentru site-ul nostru, FQDN-ul va fi: site-ul web. Exact așa, se termină cu un punct care indică zona rădăcină.
Acest lucru este foarte punct important. ÎN utilizarea de zi cu zi Se obișnuiește să se renunțe la punctul final, dar în înregistrările DNS absența punctului final înseamnă că acest nume de domeniu aparține zonei de domeniu curente, adică. Serverul DNS va adăuga la acest nume propria zonă de domeniu și toate zonele de nivel superior până la rădăcină.
De exemplu, pe serverul nostru din zonă site-ul web adăugăm o înregistrare de tip CNAME care va indica un server terță parte, de exemplu, e-mail Yandex. Intrarea corectă ar trebui să arate astfel:
MailIN CNAMEdomain.mail.yandex.net.
În acest caz, numele de e-mail nu este un FQDN și va fi extins la mail.site., dacă uităm să punem un punct la sfârșitul numelui de domeniu Yandex, atunci și acest nume nu va fi perceput ca un FQDN și trebuie completat cu numele complet al domeniului. Următoarea este o intrare incorectă:
E-mail ÎN domeniul CNAME.mail.yandex.net
Este dificil de observat diferența cu ochiul neantrenat, dar în loc de interfața web de e-mail Yandex, acest design ne va trimite la o adresă inexistentă: domeniu.mail.yandex.net.site.
Încă un lucru. Toate înregistrările pentru o zonă de domeniu sunt introduse de către administratorii de zonă pe propriile lor servere DNS, cum devin aceste înregistrări cunoscute sistemului DNS? La urma urmei, nu notificăm serverele DNS de nivel superior că am schimbat vreo înregistrare.
Orice zonă DNS conține înregistrări numai despre nodurile sale membre și zonele copil. Informațiile despre nodurile dintr-o zonă în aval sunt stocate pe propriile servere. Aceasta se numește delegare și vă permite să reduceți încărcarea pe serverele rădăcină și să oferiți autonomia necesară proprietarilor zonelor de domenii copil.
Deci ai cumpărat un domeniu, să zicem exemplu.org, după care trebuie să-l delegeți, i.e. specificați serverele de nume (servere DNS) care vor conține înregistrări pentru această zonă de fișiere. Acestea pot fi fie propriile servere, fie servicii publice, de exemplu, Yandex DNS.
În acest caz, în zona de domeniu org se va adăuga o intrare:
Exemplu IN NS dns1.yandex.net.
Ceea ce va indica faptul că toate înregistrările acestei zone sunt localizate pe server dns1.yandex.net. Conform regulilor, fiecare zonă de domeniu trebuie să aibă cel puțin două servere NS situate în subrețele diferite. În practică, adesea se descurcă cu un singur server, cumpărând pentru acesta două adrese IP din intervale diferite.
Acum să vedem cum are loc căutarea înregistrării DNS de care avem nevoie și de ce înregistrarea făcută pe serverul dvs. permite vizitatorilor de oriunde din lume să ajungă pe site-ul dvs.
Să presupunem că un utilizator dorește să viziteze resursa populară Yandex Market, el introduce numele site-ului corespunzător în bara de adrese a browserului și apasă butonul Enter. Pentru a afișa utilizatorului conținutul unei pagini, browserul trebuie să trimită o solicitare către serverul web care deservește site-ul, iar pentru aceasta trebuie să cunoașteți adresa IP a acestuia. Prin urmare, browserul contactează clientul DNS pentru a afla care adresă se potrivește cu numele de domeniu introdus de utilizator.
La rândul său, clientul DNS verifică intrările din fișierul hosts, apoi din cache-ul local și, negăsindu-l acolo înregistrările necesare, transmite cererea către serverul DNS specificat în setările de rețea. Acesta va fi cel mai probabil un proxy DNS local de cache, cum ar fi dnsmasq sau un server DNS local de întreprindere. Aceste soluții nu sunt de obicei servere cu drepturi depline sistem global DNS și nu sunt incluse în acesta, deservind doar zona locală și memorând în cache cererile DNS, astfel încât o astfel de solicitare, dacă datele nu sunt în cache, este transferată la un server DNS de nivel superior, de obicei serverul furnizorului.
După ce a primit cererea, serverul furnizorului va verifica propriile înregistrări, atunci propriul cache, iar dacă rezultatul este găsit, îl va raporta clientului, în caz contrar serverul va fi obligat să recurgă la recursiunea- căutare în sistemul DNS global. Pentru a înțelege mai bine mecanismul acestui proces, am pregătit următoarea diagramă:
Deci, clientul trimite o solicitare DNS către serverul furnizorului pentru a afla adresa de domeniu market.yandex.ru, serverul furnizorului nu deține astfel de informații, așa că contactează unul dintre serverele rădăcină, transmițându-i cererea. De asemenea, serverul rădăcină nu are înregistrările necesare, dar răspunde că cunoaște serverul responsabil pentru zonă ru - a.dns.ripn.net. Alături de acest nume, serverul rădăcină își poate raporta imediat adresa IP (și în majoritatea cazurilor o va face), dar s-ar putea să nu facă acest lucru dacă nu deține astfel de informații, caz în care, înainte de a contacta acest server, va trebui să faceți mai multe o interogare recursivă, doar pentru a-i determina numele.
După ce a aflat adresa serverului responsabil pentru zona ru, serverul furnizorului îi va trimite cererea, dar nici acest server nu are înregistrările necesare, dar va raporta care este zona. yandex serverul răspunde ns1.yandex.ruŞi Neapărat va da adresa lui. În caz contrar, recursiunea nu va putea fi finalizată, deoarece zona yandex serverul situat in zona raspunde yandex. Pentru a face acest lucru, în zona superioară, pe lângă înregistrarea NS despre serverele de nume care deservesc zona, a Înregistrare A „legată”., care vă permite să aflați adresa unui astfel de server.
În cele din urmă, prin trimiterea unei cereri către serverul care deservește zona yandex, serverul furnizorului va primi adresa domeniului necesar și o va raporta clientului. De asemenea, va plasa rezultatul rezultat în cache pentru timpul specificat de valoarea TTL în înregistrarea SOA a acestui domeniu. În practică, deoarece interogările recursive sunt foarte costisitoare, timpul de memorare în cache pentru furnizori poate ignora valorile TTL de domeniu și poate ajunge la valori de la două până la patru ore până la câteva zile sau chiar o săptămână.
Acum să ne uităm la încă un punct. Interogările pot fi recursive sau nerecursive. O cerere recursivă prevede obținerea unui răspuns gata făcut, de ex. Adrese IP sau mesaje că domeniul nu există, nu este delegat etc. O solicitare nerecursivă oferă un răspuns numai despre zona pentru care serverul dat este responsabil sau returnează o eroare.
Deoarece interogările recursive consumă destul de mult resurse, majoritatea serverelor DNS procesează interogările recursive în mod nerecursiv. Sau pot face acest lucru selectiv, de exemplu, serverele DNS ale furnizorului efectuează interogări recursive numai pentru clienții lor, iar restul în mod nerecursiv.
În cazul nostru, clientul a trimis o cerere recursivă către serverul furnizorului, care, la rândul său, a trimis secvențial cereri nerecursive până a găsit serverul necesar, care a dat răspunsul necesar. Totodată, nu numai rezultatele solicitării utilizatorului, ci și rezultatele solicitărilor intermediare sunt plasate în memoria cache a serverului furnizorului, ceea ce permite ca următoarele astfel de solicitări să fie executate nerecursiv sau cu un număr minim de solicitări .
De exemplu, dacă un utilizator, după ce a vizitat Yandex Market, decide să utilizeze serviciul postal, atunci serverul va trimite imediat cererea către ns1.yandex.ru, deoarece știe deja ce server conține înregistrări pentru zonă yandex.
De la teorie la practică
Când achiziționați un domeniu de la un registrator, vi se va cere să îl delegeți, de ex. specificați serverele DNS pe care va fi localizată zona de domeniu. Acestea pot fi servere de înregistrare (de obicei gratuite), servere hoster, servicii DNS publice sau propriile servere de nume dacă se află în aceeași zonă de domeniu, atunci va trebui să specificați și adrese IP; De exemplu, așa arată fereastra de delegare a domeniului pentru un registrator binecunoscut:
Ce anume ar trebui sa pun acolo? Depinde unde și cum îți vei găzdui site-ul. Dacă utilizați găzduire partajată, atunci totul înregistrările necesare sunt create automat de găzduitor, atunci când vă adăugați site-ul la panoul de control al găzduirii, tot ce aveți nevoie este să delegați domeniul serverului NS al găzduitorului, adică. indicați-le în această fereastră. Această metodă este potrivită pentru începători datorită simplității sale, dar există și reversul, capacitatea utilizatorului de a gestiona zona DNS este absentă sau minimă. În plus, pe gazduire virtuala Adresa IP a site-ului poate fi schimbată de către administratori fără a anunța utilizatorul, așa că dacă nu doriți să utilizați serverul NS al hosterului, atunci această problemă ar trebui să fie discutată cu suportul tehnic.
Dacă transferați un site către un alt hoster, atunci va trebui să transferați site-ul și să schimbați serverele de nume ale vechiului hoster pe serverele celui nou de la registrator. Rețineți însă că informațiile din cache-ul serverelor DNS nu sunt actualizate instantaneu, ci cel puțin după ce valoarea domeniului TTL a expirat, așa că de ceva timp site-ul dvs. poate fi încă accesibil la vechea adresă. Dacă trebuie să lucrați cu el urgent, puteți, fără să așteptați actualizarea cache-ului DNS al furnizorului dvs., să îl adăugați în fișier gazde intrare cu următorul conținut:
1.2.3.4 exemplu.com
Unde 1.2.3.4 Şi exemplu.comîn consecință, noua adresă IP și numele dvs. de domeniu.
Dacă aveți propriul VPS sau doriți să controlați complet zona de domeniu, atunci ar trebui să utilizați serverele registratorului sau serviciile publice. Crearea propriului server de nume, în opinia noastră, nu este o idee utilă decât dacă vă faceți propria găzduire.
În acest caz, trebuie să creați cel puțin două înregistrări A care vor indica serverul web care deservește site-ul din acest domeniu:
@ ÎN A 1.2.3.4
www ÎN A 1.2.3.4
Caracterul câine din înregistrările DNS denotă domeniul în sine și ar trebui să creați și o înregistrare pentru subdomeniul www, astfel încât utilizatorii care introduc adresa site-ului cu www să o poată accesa și ei.
Nu vom lua în considerare adăugarea de intrări pentru e-mail, puteți citi despre acest lucru în articolul nostru:
Când mutați un site, va trebui doar să schimbați adresele IP din înregistrările A și să așteptați ca informațiile DNS să fie actualizate. De obicei, acesta este cel mai neplăcut moment - totul pare a fi făcut, dar nu poți schimba nimic, poți doar să aștepți. Dar dacă urmați câteva recomandări, acest proces poate fi efectuat cât mai nedureros și neobservat de vizitatori.
În primul rând, modificați valoarea TTL din înregistrarea SOA. În mod implicit, este egal cu câteva ore și acesta este cât timp va trebui să așteptați ca intrarea dvs. în cache-ul serverului DNS să fie actualizată. Pentru a afla valoarea TTL curentă, puteți rula comanda specificând numele de domeniu dorit:
Nslookup -typr=soa site
În cazul nostru este de 4 ore: 
Prin urmare, cu cel puțin 4 ore (vechea valoare TTL) înainte de transferul planificat, modificați valoarea TTL la o valoare mai mică, de exemplu, 900 (15 minute). Apoi setați site-ul în modul numai citire și mutați-l pe noul server. Site-ul nu trebuie oprit sau transferat pentru întreținere, poate și trebuie să rămână accesibil. Dar trebuie să împiedicați utilizatorii să modifice și să adauge informații, de ex. interzice înregistrarea, comentarea, plasarea comenzilor etc. De asemenea, asigurați-vă că postați o notificare într-un loc vizibil despre munca tehnicași data aproximativă de finalizare.
Pentru a lucra cu noul server fără a modifica înregistrările DNS, adăugați linia dorită V fișierul hosts. După ce ați plasat site-ul pe noul site și v-ați asigurat că funcționează corect, schimbați înregistrările DNS, acum în 15 minute primii utilizatori vor începe să vă viziteze site-ul pe noul server. Funcționalitatea vechiului server trebuie menținută pentru o perioadă de timp, ideal până la o săptămână, deoarece nu toți furnizorii folosesc valoarea TTL din înregistrarea SOA pentru a actualiza propriile setări pentru a reduce încărcarea echipamentului; .
După un transfer cu succes, valoarea TTL ar trebui mărită la valorile sale anterioare pentru a nu se crea încărcătură suplimentară pentru a denumi serverele.
Am luat în considerare cel mai mult schema simpla, dar în practică, pe lângă site, există de obicei și retea de birouri, multe dintre ale căror resurse trebuie să fie disponibile și extern. Luați în considerare următoarea diagramă:
Avem servere publice pentru site-ul web și rețeaua de e-mail și birouri, pentru care am alocat un subdomeniu birou. Dacă nu există probleme speciale cu serverul de e-mail și web, atunci există opțiuni cu zona de birou. De obicei, o zonă locală este deservită de propriul DNS și nu are nicio conexiune cu zona mamă. Pentru zona sistemului DNS global office.example.com nu există, dar gazda cu același nume există. Acest lucru este justificat dacă rețeaua întreprinderii se află în spatele NAT și nodurile sale au doar adrese gri, iar accesul din exterior se realizează numai către gateway-ul către care sunt redirecționate porturile corespunzătoare din nodurile interne.
În acest caz, înregistrările DNS ale zonei exemplu.com poate arata asa:
@ ÎN A 1.2.3.4
www ÎN A 1.2.3.4
mail IN A 1.2.3.5
birou ÎN A 5.6.7.8
Dar apare o oarecare complexitate: în cadrul rețelei, clienții accesează serviciile de rețea folosind nume interne: corp.office.example.com sau rdp.office.example.com, care indică adrese interne „gri”. Cu toate acestea, nu este posibilă rezolvarea adresei IP pentru astfel de nume în afara rețelei locale, deoarece nu există nicio zonă care să le conțină pentru sistemul DNS global. Un mecanism numit Split-DNS permite tu sa iesi din aceasta situatie care iti permite sa dai rezultate diferite in functie de pozitia clientului.
În rețeaua locală, solicitările DNS ale clienților sunt deservite de server local, care are înregistrări corespunzătoare, cererile din afara acestuia vor fi trimise către serverul care deservește zona exemplu.com. În același timp, totul resurse corporative, care sunt reprezentate de diverse servere din rețeaua locală, sunt accesibile din exterior la o singură adresă: office.example.com. Prin urmare, este timpul să vă amintiți porecla sau înregistrarea CNAME. Această intrare permite ca nume mnemonice sau aliasuri suplimentare să fie asociate cu numele de gazdă real. Vă rugăm să rețineți că utilizarea aliasurilor în alte intrări este inacceptabilă. În cazul nostru, ar trebui să adăugăm următoarele intrări:
Corp.office ÎN CNAME office.example.com.
rdp.office ÎN CNAME office.example.com.
Acum un client, indiferent de locația sa, poate folosi același nume pentru a accesa resurse, dar rezultatele vor fi diferite. În rețeaua locală va primi adresa reală a serverului și se va conecta direct, iar în afara acesteia va fi direcționat către gateway-ul de rețea.
De asemenea, înregistrările de tip CNAME pot fi folosite pentru a redirecționa în afara zonei de domeniu acceptate. Condiția principală este ca înregistrarea CNAME să indice un nume real în format FQDN.
O altă utilizare a alias-urilor este scurtarea unei adrese. Să spunem, ca server de e-mail pentru întregul domeniu exemplu.com dorim să folosim un server care se află în biroul din Moscova și are adresa mail.office.msk.example.com, trebuie să recunoști, nu pare foarte atractiv. Ar fi mult mai convenabil să ai o adresă ca mail.example.com, nu este nimic mai simplu, adăugați următoarea intrare:
E-mail ÎN CNAME mail.office.msk.example.com.
Dar amintiți-vă că în rest înregistrările resurselor Ar trebui folosite doar nume reale, deci ar fi incorect:
Exemplu.com. ÎN poștă MX 10
Calea corectă ar fi:
Exemplu.com. ÎN MX 10 mail.office.msk
În sfârșit, să vorbim despre delegarea zonelor de domeniu. În exemplul de mai sus, ne-am uitat la o situație în care în cadrul unui domeniu diferitelor divizii li se alocă propriile subdomenii, deoarece fiecare divizie are propria infrastructură, este logic să le delegem gestionarea propriilor zone de domeniu. În acest scop în zonă exemplu.com o înregistrare NS și A asociată trebuie plasate pentru fiecare zonă. De exemplu:
Msk IN NS ns1.msk.example.com.
msk IN NS ns2.msk.example.com.
ns1.msk ÎN A 1.2.3.4
ns2.msk ÎN A 5.6.7.8
Acum, când accesați o adresă, să spunem mail.office.msk.example.com servere de nume de zonă exemplu.com va afișa numele și adresa serverului care deservește zona msk.example.com. Acest lucru permite administratorilor zonei să facă ei înșiși modificările necesare fără a afecta funcționarea zonei părinte sau să îi contacteze administratorii pentru orice problemă care necesită modificarea înregistrărilor.
Etichete:
În acest material, ne vom uita la configurația programului numit atunci când organizăm un server de domeniu, ale cărui gazde sunt distribuite pe două rețele IP fizice de clasă C (în notație CIDR x.x.x.x/24). Atenția principală va fi acordată zonelor „reverse”, deoarece Zona „directă” în acest caz nu diferă semnificativ de zona luată în considerare atunci când descriem un domeniu corporativ mic.
Situația luată în considerare în acest caz este tipică pentru organizațiile care au mai mult de o rețea de clasă C în care este necesară implementarea unui domeniu corporativ. Pentru a fi mai precis, atunci despre care vorbim nu numai despre rețelele de clasa C.
Să presupunem că grupurile de adrese care sunt alocate unei organizații și diviziilor acesteia nu sunt un singur spațiu de adrese, ci o porțiune din mai multe blocuri de adrese. Mai mult, aceste blocuri sunt tăiate în așa fel încât adresele să fie de la zone diferite, dacă luăm în considerare spațiul de adrese din punct de vedere al notației CIDR x.x.x.x/24. De exemplu:
192.168.0.0/24 și 192.168.10.0/24
Din punctul de vedere al descrierii corespondenței dintre un nume de domeniu și o adresă IP în zona „directă”, nu există probleme aici:
$ORIGIN ro.
test IN SOA ns.test.ru. hostmaster.test.ru (
233 3600 300 9999999 3600)
;
IN NS ns.test.ru.
IN NS ns.privider.ru.
ÎN A 192.168.10.1
ÎN MX 10 mail.test.ru.
ÎN MX 20 mail.provider.ru.
;
ns IN A 192.168.10.1
mail IN A 192.168.0.1
www IN A 192.168.10.2
ftp ÎN A 192.168.0.2
Exemplul arată că înregistrările de adrese pot fi perfect „amestecate” în descrierea zonei. Astfel, o zonă directă poate fi definită pe orice set de seturi de adrese, care pot fi împrăștiate în mod arbitrar în spațiul de adrese.
Desigur, există adrese care nu ar trebui să fie interferate. De exemplu, adresele rutabile și neroutable nu trebuie amestecate. De fapt, în exemplu îl folosim exact pe acesta din urmă (pentru mai multe informații despre adresele non-routable, vezi RFC 1918).
Dacă solicitați o adresă IP de pe Internet folosind un nume de domeniu și, ca răspuns, primiți o adresă de la un pool nerutabil, nu este clar ce să faceți cu ea. Chiar dacă tu însuți te afli într-o rețea nerutabilă, cel mai probabil adresa primită din exterior din aceeași rețea nu este adresa pe care o cauți.
De fapt, același server de nume de domeniu poate suporta atât potriviri rutabile, cât și non-rutabile, dar pentru ușurința prezentării, acest caz este cel mai bine lăsat pentru o analiză separată într-un alt material.
Și așa, în zona „directă” putem „interveni” adrese, dar cum putem menține potrivirile inverse? Într-adevăr, în cazul zonelor „reverse”, avem de-a face și cu nume de domenii, deși sunt formate prin inversarea adreselor IP. Separatorul din ierarhia de denumire a domeniului este caracterul ".", prin urmare, limitele de octeți din adresă vor corespunde limitelor de imbricare a domeniului.
Soluția este simplă - creați două zone inverse 0.168.192.in-addr.arpa și 10.168.192.in-addr.arpa. Va arata cam asa:
3600 USD TTL
10 IN SOA ns.test.ru. hostmaster.test.ru. (
75 3600 300 9999999 3600)
IN NS ns.test.ru.
IN NS ns.privider.ru.
1 IN PTR ns.test.ru.
2 IN PTR www.test.ru.
Iar pentru 0.168.192.in-addr.arpa. respectiv:
3600 USD TTL
$ORIGIN 168.192.in-addr.arpa.
0 ÎN SOA ns.test.ru. hostmaster.test.ru. (
75 3600 300 9999999 3600)
IN NS ns.test.ru.
IN NS ns.privider.ru.
1 IN PTR ns.test.ru.
2 IN PTR www.test.ru.
Două zone „inversate” trebuie declarate pe serverul principal. În BIND 4.x ar arăta cam așa în fișierul named.boot:
directorul /etc/namedb
primar test.ru test.ru
localhost primar localhost
primar 127.in-addr.arpa localhost.rev
primar 10.168.192.in-addr.arpa 10.168.192.in-addr.arpa
primar 0.168.192.in-addr.arpa 0.168.192.in-addr.arpa
xfrnets 192.168.20.1&255.255.255.255
cache. numit.rădăcină
opțiuni no-recursive no-fetch-glue fake-iquery
De fapt, din punctul de vedere al contextului acestui material, este important ca printre directivele de control să existe două directive primare pentru zonele inverse corespunzătoare.
Aici merită doar clarificat faptul că în acest caz adresa 192.168.20.1 este adresa serverului slave, căruia îi este permis să copieze zona. Scopul directivelor de control rămase este discutat în detaliu în „Un domeniu corporativ mic în domeniul ru Descrierea zonelor „reverse”.
În ceea ce privește fișierul named.conf pentru versiunile BIND 8.x și 9.x, conținutul acestuia va arăta cam așa:
opțiuni (
directorul „/etc/namedb”;
permite-interogare(orice;);
recursiunea nu;
fals-iccare da;
aduce lipici nr;
use-id-pool da;
};
//Sugestii pentru serverul rădăcină
zona "." ( tastați indiciu; fișierul „named.root”; );
// Buclă înainte
zona „localhost” (
tip master;
fișierul „localhost”;
};
// Reverse Loopback
zona „0.0.127.in-addr.arpa” (
tip master;
fișierul „localhosr.rev”;
};
// Domeniul corporativ
zona "test.ru" (
tip master;
fișierul „test.ru”;
};
zona „0.168.192.in-addr.arpa” (
tip master;
fișierul „0.168.192.in-addr.arpa”;
permite-transfer ( 192.168.20.1; );
};
// Inversați domeniul corporativ
zona „10.168.192.in-addr.arpa” (
tip master;
fișierul „10.168.192.in-addr.arpa”;
permite-transfer ( 192.168.20.1; );
};
Această descriere conține, de asemenea, două directive pentru zonele inverse la care sunt mapate numele. Descrierea este ceva mai lungă decât pentru BIND 4.x datorită formatului diferit al fișierului de configurare, dar esența sa este aceeași.
Trebuie remarcat aici că apar mai multe zone inverse, de exemplu, pentru rețele precum x.x.x.x/23. Ideea este că grupul de adrese, de exemplu, 192.168.0.0.23, combină două blocuri adiacente 192.168.0.0/24 și 192.168.1.0/24. Prin urmare, vor exista două zone inverse corespunzătoare: 0.168.192.in-addr.arpa și 1.168.192.in-addr.arpa. Combinați-le într-un mod standard este posibil doar la nivelul 168.192.in-addr.arpa, dar nu mai jos.
Din cele de mai sus rezultă că proprietarul zonei 168.192.in-addr.arpa trebuie să delege clientului său responsabilitatea gestionării celor două zone inversate dacă nu dorește să le gestioneze el însuși.
Observații similare sunt valabile pentru grupurile de adrese x.x.x.x/16 și pentru grupurile de adrese x.x.x.x.8, de exemplu. rețele de clase B și respectiv A. Spațiul de nume de domeniu al zonelor „reverse” a fost construit ținând cont de vechea clasificare a adreselor, într-o perioadă în care notația CIDR nu era încă utilizată pe scară largă.
RFC 1519 detaliază maparea spațiului de adrese CIDR la „supernetul” rețelelor de clasă C, adică pool-uri de adrese care sunt alcătuite din subrețele de rețele de clasă B și A Furnizorul în acest caz trebuie să delege clienților zonele inverse corespunzătoare, iar aceștia le oferă suport într-o manieră similară cu cazul 192.168.0.0/23, discutat. mai sus.
- Albitz P., Lee K.. DNS și BIND. - Per. din engleză - Sankt Petersburg: Symbol-Plus, 2002. - 696 p.
- P. Mockapetris. RFC-1034. NUMELE DE DOMENIILE - CONCEPTE ȘI FACILITĂȚI. ISI, 1987. (
Vedere directă necesare pentru a rezolva numele de domenii în adrese IP, căutare inversă– pentru a rezolva adresele IP în nume de domenii.
Fiecare segment de rețea trebuie să aibă o zonă de căutare inversă. Mai exact, dacă aveți subrețele 192.168.10.0, 192.168.11.0 și 192.168.12.0, ar trebui să aveți trei zone de căutare inversă.
Numele standard al zonei de căutare inversă este format din identificatorul de rețea încorporat ordine inversă, iar sufixul in-addr.arpa. Zonele de căutare inversă din exemplul anterior s-ar numi 10.168.192. in-addr.arpa, 11.168.192.in-addr.arpa și 12.168.192.in-addr.arpa. Înregistrările zonelor de căutare inversă și directă trebuie sincronizate. Dacă sincronizarea eșuează în domeniu, autentificarea poate eșua.
Pentru a crea o zonă de căutare inversă, urmați acești pași:
1. Deschide consola Manager DNSși conectați-vă la serverul dorit.
2. Clic clic dreapta element server și selectați comanda Creați o zonă nouă (Zonă nouă). Se va deschide Expert pentru zonă nouă. Clic Următorul.
3. Dacă vă configurați serverul principal Integrat cu Active Directory, setați butonul radio Zona primarăși asigurați-vă că caseta de selectare este bifată . Dacă nu doriți să integrați DNS în Active Directory, selectați butonul radio Zona primarăși debifați caseta Stocați Zona în Active Directory. Clic Următorul.
4. Dacă configurați o zonă de căutare inversă pentru un server secundar, selectați butonul radio Zona secundarași faceți clic Următorul.
5. Dacă integrați o zonă cu Active Directory, alegeți una dintre următoarele strategii de replicare:
Pentru toate serverele DNS din această pădure (Adică toate serverele DNS din această pădure) Aceasta este o strategie extinsă de replicare. Amintiți-vă că o pădure Active Directory include toți arborii de domenii care partajează date de director cu domeniul curent.
Pentru toate serverele DNS din acest domeniu (Adică toate serverele DNS din acest domeniu) Selectați această strategie pentru a replica informațiile DNS în domeniul curent și în domeniile sale secundare.
Pentru toți controlorii de domeniu din acest domeniu (Adică toate controlerele de domeniu din acest domeniu) Selectați această strategie dacă doriți să replicați informațiile DNS către toate controlerele de domeniu din domeniul curent și domeniile secundare ale acestuia. Deși această strategie permite o replicare mai largă informații DNSîntr-un domeniu, nu fiecare controler de domeniu este un server DNS (nu trebuie să configurați fiecare controler de domeniu ca server DNS).
6. Setați comutatorul Zona de căutare inversă. Clic Următorul.
7. Specificați pentru ce adrese doriți să creați o zonă de căutare inversă (IPv4 sau IPv6)și faceți clic Următorul. Efectuați una dintre următoarele:
Dacă configurați IPv4, introduceți ID-ul rețelei pentru zona de căutare inversă. Valorile pe care le introduceți determină numele implicit pentru zona de căutare inversă. Clic Următorul.
Dacă configurați IPv6, introduceți prefixul de rețea pentru zona de căutare inversă. Numele zonelor sunt generate automat pe baza valorilor pe care le introduceți. În funcție de prefixul introdus, puteți crea până la opt zone. Clic Următorul.
8. Dacă configurați un server primar sau secundar care nu este integrat în Active Directory, specificați numele fișierului de zonă. Numele de fișier implicit pentru baza de date a zonei DNS ar trebui să fie deja introdus. Lăsați-l neschimbat sau introduceți un nume nou. Clic Următorul.
9. Specificați dacă doriți să permiteți actualizări dinamice. Ai trei variante:
Permiteți numai actualizări dinamice securizate Dacă zona dvs. este integrată în Active Directory, puteți utiliza ACL-uri pentru a limita clienții care pot efectua actualizări dinamice. Dacă selectați acest comutator, numai clienții cu conturi de computer autentificate și ACL-uri aprobate pot actualiza în mod dinamic înregistrările de resurse.
Permite actualizări dinamice atât nesecurizate, cât și securizate Selectați acest comutator pentru a permite oricărui client să își actualizeze înregistrările de resurse în DNS atunci când apar modificări.
Nu permiteți actualizări dinamice Acest comutator dezactivează actualizările DNS dinamice. Ar trebui utilizat numai dacă zona nu este integrată cu Active Directory.
După instalarea zonelor de căutare inversă, trebuie să vă asigurați că delegarea este procesată corect pentru zonă. Contact departamentul de informare sau ISP-ul dumneavoastră pentru a verifica înregistrările de zonă în domeniul părinte.
Rashid Achilov
Crearea zonelor DNS
Sistemul de nume de domeniu este un fel de „sistem nervos” al Internetului. Datorită ei, atunci când tastați , ajungeți pe site-ul revistei „Administrator de sistem”, și nu în altă parte. Cum să creați, să configurați și să rulați un server DNS pentru o afacere mică?
Structura DNS
În prezent, Internetul este o rețea uriașă care include milioane de noduri situate în întreaga lume. Pentru ca o solicitare făcută de pe un computer să atingă un obiectiv situat pe un alt computer, acest obiectiv trebuie mai întâi specificat. Puteți, desigur, să specificați direct adresa IP. Dacă îl cunoști, desigur. Dar aici este posibil să faceți o greșeală foarte ușor - informații despre locul în care adresa de care aveți nevoie s-ar fi schimbat deja și cel mai bun scenariu veți vedea un mesaj care spune că adresa nu a fost găsită, iar în cel mai rău caz, vă veți găsi pe un site care nu are absolut nimic de-a face cu ceea ce aveți nevoie. Va fi mai fiabil și mai ușor să apelați la un sistem care stochează o corespondență între nume simbolice precum www.site și adresele IP corespunzătoare acestora în în acest moment(în cazul nostru 217.144.98.99). DNS este un astfel de sistem. Deoarece funcționarea întregului Internet depinde de funcționarea cu succes a acestuia, acest sistem funcționează pe principiul unei baze de date distribuite - există 13 servere „cunoscute”, ele sunt numite și servere „rădăcină”, care conțin informații despre servere, care conțin informații. despre servere etc. La fel ca casa pe care a construit-o Jack.
Întreaga rețea de internet, care este descrisă de zona „.” (punctul) este împărțit în așa-numitele TLD-uri (Top Level Domains), distribuite fie funcțional, fie geografic. Există și termenul de domeniu primar - „domeniu primar” sau „domeniu de prim nivel”, dar acest termen este folosit mult mai rar. Distribuția geografică se realizează în conformitate cu ISO 3166, care stabilește coduri din două și trei litere pentru toate țările din lume. Alocarea pe baze funcționale este efectuată după cum este necesar pentru a crea un nou TLD. Trebuie remarcat aici că toate problemele privind TLD-urile sunt tratate de ICANN (Internet Corporation for Assigned Names and Numbers) și este acest organism cel care decide dacă va crea un nou TLD.
Serverele rădăcină în sine conțin doar link-uri către servere care conțin informații despre zonele de nivel al doilea, care la rândul lor conțin informații despre servere care conțin informații despre zonele de nivelul trei etc. În cele mai multe cazuri, ierarhia se termină în zona a treia sau a patra. Dar nu pentru că există un fel de limitare aici. Pur și simplu amintirea numelor complexe nu este mai ușoară decât adresele IP.
Astfel, procesul de căutare a informațiilor, să zicem, despre serverul web www.granch.ru, va arăta astfel:
- Clientul contactează serverul său DNS, a cărui adresă a fost stabilită de administratorul de sistem cu solicitarea „Spune-mi adresa corespunzătoare numelui www.granch.ru”.
- Serverul DNS cunoaște adresele serverelor de pe care ar trebui să înceapă căutarea dacă informațiile solicitate nu sunt stocate în cache-ul său, așa că apelează la unul dintre ele.
- Serverul rădăcină îi trimite adresa serverului responsabil pentru zone.ru
- Serverul DNS accesează serverul zone.ru
- Serverul zone.ru îi trimite adresa serverului care este responsabil pentru zona grainch din zona sa.
- Serverul DNS accesează serverul zonei granch.ru.
- Și în final, serverul zonei granch.ru îi spune adresa corespunzătoare numelui www. În acest caz, va fi 81.1.252.58.
Acest proces este ilustrat în Fig. 1, unde numerele indică succesiunea cererilor.
Cum să vă integrați informațiile în structura DNS?
Înainte de a vă alătura oricărui sistem, trebuie să aveți o idee despre unde și cum să vă alăturați.
Unde îl încorporăm?
Diferite servere sunt responsabile pentru diferite TLD-uri și, dacă, de regulă, un server (mai precis, o organizație) este responsabil pentru domeniile geografice, atunci, în general, un număr nelimitat de așa-numiții registratori, adică companii care au încheiate în acorduri speciale, pot fi responsabile pentru domeniile funcționale cu ICANN, că ei vor fi cei care înregistrează nume în anumite domenii funcționale. Scurtă descriere domeniul funcțional și adresa registratorului acestuia sunt date în .
Dacă există mai mulți registratori, atunci este dată adresa celui principal (de exemplu, VeriSign pentru domain.com). Domeniile .gov și .mil sunt rezervate exclusiv guvernului american și organizațiilor militare americane, iar rezervarea .gov este oficializată prin RFC - RFC 2146 corespunzător. Lista completă toate existente în momentul prezent TLD-uri geografice care indică registratorul domeniului și necesarul informații de contact poate fi vizualizat în . Deși, dacă, să zicem, în zone.com puteți alege dintr-o listă uriașă, atunci pentru zones.ru și.su RUTSENTR, nu există opțiuni.
Există mai multe puncte de remarcat aici. De fapt, zone.su aparține statului inexistent al Uniunii Sovietice, deși, totuși, continuă să fie deservit și este deschis pentru înregistrare. Înregistrarea acolo este destul de costisitoare - 100 USD pentru înregistrare sau asistență pe an.
Nu există o prioritate prin care o organizație sau persoană să aibă prioritate față de alta atunci când înregistrează un domeniu. Un om de afaceri american implicat în producție ferestre din plastic, a înregistrat domeniul windows2000.com. Când Microsoft a încercat să facă același lucru, a fost surprins să constate că numele fusese deja luat, iar compania a trebuit să plătească o sumă mare. Există chiar și conceptul de „cybersquatting” - procesul de înregistrare a domeniilor în scopul revânzării lor ulterioare. De asemenea, RUTSENTR a decis să participe în acest sens, iar conform noilor reguli, care sunt introduse la 1 iunie 2006, domeniile eliberate sunt scoase la o „licitație de nume de domeniu” și transferate celui mai mare ofertant. Numele sunt ținute la „licitație” timp de un an dacă nimeni nu o revendică în această perioadă, numele este eliberat pentru înregistrarea gratuită.
Când au fost create TLD-urile enumerate mai sus, TLD-ul .xxx a fost planificat și pentru site-uri cu tematică pentru adulți. ICANN a respins această propunere. Acesta a fost recent supus unui al doilea vot și ICANN l-a respins din nou. A apărut însă TLD-ul .tel, conceput pentru a fi utilizat simultan pe computere și dispozitive mobile.
Există RFC 1480, care descrie regulile de înregistrare a numelor în domeniul .us. Aceste reguli sunt extrem de greoaie și confuze și necesită crearea de nume de la 6-7 niveluri precum Hamilton.High.LA-Unified.K12.CA.US
Cum îl încorporăm?
Anterior, totul era mult mai complicat. Pentru a înregistra zone.com, a trebuit să completez multe formulare text - cu date pentru organizație, cu date pentru persoane de contact... Aceste formulare au fost apoi trimise la adrese speciale, de unde au venit răspunsurile - acceptate sau nu. Apoi, fișierul de zonă pre-generat a fost testat și din nou a fost trimis un mesaj prin poștă, indiferent dacă testarea a avut succes sau nu.
Acum totul a devenit mult mai simplu. Atât Network Solutions, cât și RUTSENTR au dobândit interfețe web, cu ajutorul cărora toate cele de mai sus (cu excepția, desigur, crearea unui fișier de zonă) pot fi realizate cu câteva clicuri de mouse. Toate datele pot fi corectate, completate sau șterse în orice moment. Anterior a fost necesară încheierea unui contract de servicii cu RUCENTER, dar începând cu 1 iunie 2006 sunt introduse noi reguli, conform cărora este suficient să se înregistreze pe site-ul lor. Registratori străini, de regulă, costă carduri de credit, dar dacă domeniul nu poate fi înregistrat din orice motiv, banii vor fi returnați nu mai devreme de trei zile mai târziu.
Registratorul va trebui să furnizeze adresa IP și masca de subrețea a serverului care va rula programul server DNS și care va conține baza de date principală pe care o creați și editați după cum este necesar. Acest server va fi numit server primar (server principal). În plus, va trebui să specificați cel puțin o adresă IP a serverului care conține o copie de rezervă a bazei de date în cazul defecțiunii serverului primar. Astfel de servere sunt numite servere secundare (servere slave). Pentru a nu se gândi mult timp unde să plaseze DNS-ul secundar, RUCENTER se oferă să îl plaseze pe site-ul lor. Costul serviciilor RUCENTER este de 15 USD pe an pe domeniu în zonele .ru, .net, .com, .org, 50 USD pe domeniu în zonele .biz, .info, 100 USD pe domeniu în zona .su și 5 USD pe an pentru suport pentru DNS secundar în orice zonă (inclusiv cei neînregistrați la ei).
De ce este obligatorie cerința unui server DNS secundar? Pentru că stabilitate DNS funcționează este extrem de important pentru stabilitatea Internetului în ansamblu, persoana sau organizația care înregistrează domeniul trebuie să îndeplinească anumite condiții privind stabilitatea DNS-ului:
- Trebuie să existe cel puțin două servere care deservesc acest domeniu.
- Aceste servere trebuie să fie disponibile cel puțin 22 de ore pe zi.
Conform noilor reguli, nu există cerințe pentru amplasarea serverelor, deși anterior se cerea ca acestea să fie amplasate pe rețele IP diferite.
www.krokodil.ru
Deci, să presupunem că vrem să creăm un site web www.krokodil.ru (la momentul scrierii acestui articol era gratuit), dedicat creșterii crocodililor acasă. Există o conexiune de linie dedicată, o rețea de clasă C și anume 212.20.5.0 – 212.20.5.255 (acest interval este în prezent gratuit) alocată de furnizor. Acest exemplu este oarecum necaracteristic momentului actual, cu lipsa de adrese IP, dar a fost luat special pentru a lua în considerare crearea unei zone inverse. Se va lua în considerare și opțiunea de conectare prin rețeaua 212.20.5.0/31. Rețeaua internă a biroului nostru de creștere a crocodililor este formată din șase computere și va fi separată de firewall-ul Internet-proxy, etc., rulând FreeBSD. De ce vom avea nevoie pentru a ne implementa planurile?
În primul rând, observ că există opțiuni care nu necesită cunoștințe despre DNS - totul este găzduit pe site-ul furnizorului, totul este deservit de furnizor, vi se oferă doar o interfață web. Acest serviciu este extrem de popular în străinătate, dar este foarte puțin solicitat în Rusia. Descrierea sa depășește scopul acestui articol, așa că nu o voi lua în considerare.
În primul rând, vom avea nevoie de un program server DNS. Până în prezent, un singur program implementează setul necesar de funcții. Acesta este un server DNS BIND distribuit de ISC (Internet System Consortium Inc.), o organizație non-profit care dezvoltă servere BIND, DHCP, INN și NTP. Dacă nu este în sistemul dvs., trebuie să îl descărcați și să îl instalați. FreeBSD este livrat cu BIND 9.3.2, așa că acest articol se va concentra pe versiunea respectivă. Trebuie remarcat faptul că pentru versiunile BIND 8.x descrierea configurației de mai jos este complet inacceptabilă, deoarece formatul configurației BIND fișiere 8.x este fundamental diferit de formatul fișierului de configurare BIND 9.x.
În al doilea rând, va trebui să distribuim adresele IP alocate nouă și să atribuim adrese computerelor interne. Totul aici este extrem de simplu: să fie 212.20.5.1 gateway-ul furnizorului, 212.20.5.2 să fie adresa serverului UNIX, 10.87.1.0/24 să fie subrețeaua internă, în care se află stațiile de lucru 1 până la 6, 254 să fie adresa serverul de interfață internă. Adresele rămase vor fi rezervate pentru extinderea viitoare.
În al treilea rând, veți avea nevoie de un fișier de descriere a zonei pregătit în prealabil, care va defini cantitate mica adrese externe: krokodil.ru – server rădăcină al zonei, www.krokodil.ru, ftp.krokodil.ru, mail.krokodil.ru și ns.krokodil.ru. Numele ns (server de nume) este aproape numele tradițional al computerelor pe care rulează serviciu DNS, deși, desigur, nimeni nu te va opri să-l numești, de exemplu jaws.krokodil.ru. De asemenea, vor fi definite nume pentru calculatoarele din rețeaua internă, accesibile doar din interior: tooth1.krokodil.ru – tooth6.krokodil.ru.
înregistrări DNS
Există un număr destul de mare de tipuri diferite de înregistrări care pot fi plasate în DNS. Scopul acestui articol ne permite să le luăm în considerare doar pe cele mai importante dintre ele, pentru a le obține informatii complete RFC-urile relevante ar trebui să fie menționate: RFC 1033 și RFC 1035 definesc formatele de înregistrare master, RFC 1122 formatul de înregistrare PTR, RFC 2782 formatul de înregistrare SRV. Vom lua în considerare doar acele înregistrări care sunt necesare pentru a genera fișierele de zonă necesare pentru înregistrarea domeniului:
- O înregistrare SOA care specifică începutul descrierii zonei.
- O înregistrare NS care definește serverele de nume ale zonei.
- O înregistrare A care mapează o adresă IP la un nume (traducere directă).
- O înregistrare MX care descrie setările de livrare a e-mailului pentru acest computer.
- O înregistrare CNAME care specifică nume alternative.
- Înregistrarea PTR, care specifică corespondența dintre nume și adresa IP (traducere inversă), este utilizată în descrierea zonei „inversare”.
Formatul de înregistrare DNS este comun tuturor tipurilor de înregistrare:
[nume] [clasa]<тип> <данные>
- Nume– acesta este numele obiectului cu care sunt asociate datele;
- ttl– durata de viață a obiectului;
- Clasă– clasa record;
- tip– tipul de înregistrare;
- date– date asociate acestui obiect.
Numele poate lua orice valoare, caz în care este considerat numele obiectului. Dacă numele se termină cu un punct, atunci este considerat pe deplin calificat, în caz contrar, numele zonei este înlocuit la sfârșitul numelui, care poate fi specificat în două moduri:
- Specificând numele zonei în directiva $ORIGIN, de exemplu:
$ORIGIN krokodil.ru
- Prin specificarea numelui zonei în directiva de zonă a fișierului de configurare BIND.
Caracterul special „@” indică numele zonei curente. Rețineți că directiva $ORIGIN înlocuiește directiva zone și durează până când apare următoarea directivă $ORIGIN sau până la sfârșitul fișierului. Până când apare prima directivă $ORIGIN, aceasta este luată în considerare valoare dată directivele de zonă din fișierul de configurare BIND.
Dacă este dat un nume, acesta trebuie să înceapă la prima poziție a liniei.
TTL este de obicei omis și setat global cu directiva $TTL. Directiva $TTL este obligatorie pentru BIND 9.x și este de obicei setată chiar la începutul fișierului. Câmpul de date al acestei directive specifică durata de viață (în secunde) a unui element în timpul căreia acesta poate rămâne în cache și poate fi considerat de încredere. ÎN în acest exemplu aceasta este de două zile (48 de ore).
172800 TTL USD
Clasa de intrare poate fi una dintre următoarele valori:
- ÎN– înregistrarea resurselor Internet.
- CH– o înregistrare a resurselor ChaosNet – o rețea complet necunoscută utilizatorului rus, folosită pe mașinile Symbolics.
- H.S.– Înregistrarea resurselor Hesiod – Protocolul serviciului BIND.
Tipul de înregistrare este unul dintre tipurile enumerate mai sus.
Vă rugăm să rețineți că câmpurile nume, ttl și clasă pot fi omise. În acest caz, ultima valoare definită este luată drept valorile lor (în acest caz, specificarea @ va fi o definiție corectă), iar dacă valoarea nu a fost definită nicăieri, atunci pentru câmpul de clasă valoarea implicită „IN” este acceptat, pentru alte câmpuri duce la un mesaj de eroare.
Pe lângă intrări, un fișier de zonă poate conține comenzi. Există patru comenzi în total: $TTL, $ORIGIN, $INCLUDE și $GENERATE. O descriere a comenzii $GENERATE este dată în documentația pentru programul BIND, precum și în și, comanda $INCLUDE funcționează conform ortografiei sale - include fișierul specificat în fișierul curent.
Notă: semnează „;” (punct virgulă) este un semn de comentariu.
Record SOA
Această intrare definește începutul zonei. Orice zonă trebuie să înceapă cu o intrare SOA. Apariția unei alte intrări SOA încheie automat prima zonă și începe a doua. Formatul de înregistrare SOA este prezentat mai jos. De fapt, o înregistrare SOA denumește o zonă și stabilește unele valori implicite pentru aceasta.
2005122001; Număr de serie
3600; Reîncercați la fiecare oră
172800); Minim 2 zile
Să ne uităm la un exemplu. Semnul @ din câmpul nume înseamnă că este necesar să luați numele zonei specificat anterior de directiva $ORIGIN. Clasa de înregistrare este IN, tipul de înregistrare este SOA. SOA este singura înregistrare care are asta lista complexa parametrii.
Primul parametru este adresa serverului de nume master al zonei. În acest exemplu, acesta este krokodil.ru. Al doilea parametru este adresa de e-mail a persoanei responsabile pentru această zonă. Vă rugăm să rețineți că adresa este scrisă ca „nume utilizator.domeniu” și nu „nume utilizator@domeniu”.
Al doilea parametru este o listă de valori cuprinse între paranteze. Teoretic, este posibil să o scrieți pe o singură linie, dar în practică nu am văzut asta nicăieri forma de notație dată în exemplu este folosită peste tot. Lista constă din cinci elemente:
- Numărul de serie al zonei. Această setare joacă un rol extrem de important în propagarea actualizării efectuate pe serverul primar către toate serverele sale secundare. Trebuie să existe o modalitate de a informa serverul secundar că datele de pe serverul principal s-au schimbat. Dacă serverul principal a fost repornit, acesta trimite un DNS NOTIFY către toate serverele secundare. La primirea acestei notificări, serverul secundar solicită număr de serie– dacă numărul de serie de pe serverul primar este mai mare decât pe serverul secundar, serverul secundar execută comanda de actualizare a zonei. În plus, serverul secundar efectuează verificări periodice ale numărului de serie în același scop. Prin urmare, ar trebui să vă amintiți o regulă simplă: dacă corectați zona, creșteți numărul de serie! O practică obișnuită în rândul administratorilor DNS este de a forma numărul de serie după cum urmează: AAAAMMDDv, unde:
- AAAA,LL,ZZ– anul curent (4 cifre), luna și respectiv ziua
- v– versiunea de zonă pentru ziua respectivă. Dacă se fac mai multe modificări pe zi, acest număr este incrementat cu unul succesiv.
Desigur, nimeni nu te va obliga să urmezi o asemenea practică. De exemplu, server DNSîn Windows nu se țin de el, ci doar îl numesc 1, 2, 3 etc. - Valoarea perioadei de actualizare după care serverul slave trebuie să contacteze masterul și să verifice dacă numărul de serie al zonei s-a schimbat. Dacă numărul de serie s-a schimbat, serverul slave va descărca date noi. În acest exemplu, 10800 de secunde (3 ore).
- Timpul după care serverul slave va încerca să contacteze masterul dacă încercarea de a obține un nou număr de serie eșuează. În acest exemplu, 3600 de secunde (o oră).
- Timpul în care serverele slave vor servi cererile pentru o anumită zonă în cazul unei absențe îndelungate a serverului master. Sistemul ar trebui să funcționeze chiar dacă serverul principal este oprit perioadă lungă timp, prin urmare valoarea acestui parametru este setată la 1.728.000 de secunde (20 de zile).
- Timp de stocare în cache a răspunsului negativ. În acest exemplu, 172800 de secunde (2 zile).
intrare NS
Această intrare specifică numele serverelor care acceptă zona, adică conducându-i baza. Numele serverelor primare și ale tuturor serverelor secundare ar trebui să fie listate aici. De obicei, această intrare urmează imediat intrarea SOA. În câmpul de date este introdusă o singură valoare - numele sau adresa IP a serverului zonei DNS, indiferent dacă este master sau slave. Toate numele specificate aici trebuie să fie complet calificate, adică să se încheie cu un punct!
ÎN NS ns.krokodil.ru.
ÎN NS ns4.nic.ru.
În exemplul dat, descriem mai întâi serverul principal al zonei noastre ns.krokodil.ru, iar apoi serverul slave - nodul RU CENTER ns4.nic.ru.
Înregistrarea A
O înregistrare de tip A este conținutul principal al fișierelor într-o zonă de conversie directă sau pur și simplu într-o zonă „directă”, adică oferind numele unui computer după adresa sa. Este compilat pentru fiecare computer. Pentru ușurință de lizibilitate, aceste înregistrări sunt de obicei grupate în ordine crescătoare a adreselor IP și sunt, de asemenea, grupate cu înregistrările MX corespunzătoare la această adresă IP, deși acest lucru desigur nu este obligatoriu. În câmpul de nume se introduce numele atribuit adresei IP, în câmpul de date - adresa IP căreia i se atribuie numele. Când o adresă are nume suplimentare, numele atribuit adresei de o înregistrare A se numește nume principal.
dinte1 IN A 10.87.1.1
dinte2 IN A 10.87.1.2
dinte3 IN A 10.87.1.3
dinte4 IN A 10.87.1.4
dinte5 IN A 10.87.1.5
dinte6 IN A 10.87.1.6
Acest exemplu descrie atribuirea adreselor IP computerelor din rețeaua internă, care are adresa 10.87.1.0/24. Pentru computerele din rețea internă, de regulă, nu este nevoie să se formeze niciuna intrări suplimentare, cu posibila excepție CNAME.
Înregistrare CNAME
O înregistrare CNAME este o caracteristică suplimentară a DNS. Vă permite să atribuiți mai mult de un nume unei adrese IP. În câmpul de nume se introduce numele suplimentar atribuit adresei IP, în câmpul de date - numele principal atribuit anterior de înregistrarea de tip A, sau un alt nume suplimentar atribuit de înregistrarea CNAME. În acest caz, numele din câmpul de date al înregistrării se numește canonic (de unde și numele înregistrării - Nume canonic). O singură adresă IP i se poate atribui un număr nelimitat de nume suplimentare prin înregistrările CNAME, dar alte tipuri de înregistrări trebuie să utilizeze numele atribuit de înregistrarea A mai degrabă decât înregistrarea CNAME. Mai jos este un exemplu de atribuire corectă și incorectă a numelor suplimentare.
Corect:
ns ÎN A 10.87.1.1
nume1 ÎN CNAME ns
IN MX 10 ns
Greşit:
ns IN A 10.87.1.254
nume1 ÎN CNAME ns
ÎN MX 10 nume1
Înregistrările CNAME pot indica unele către altele, dar nu mai mult de șapte niveluri, al optulea trebuie să fie o înregistrare care indică numele atribuit de înregistrarea de tip A În literatură, există o recomandare de a utiliza mai multe înregistrări de tip A în loc de alocarea multiple nume suplimentare la adresa. În acest sens, putem spune că acest punct este menționat în RFC 2219 în termenii „nu există recomandări absolute în această chestiune, fiecare trebuie să decidă singur ce este mai bine pentru el”. Mai multe CNAME sunt mai ușor de administrat, mai multe înregistrări A sunt mai ușor de gestionat, deoarece apar mai puține redirecționări.
Înregistrare MX
Înregistrarea MX este al doilea element principal al fișierului de zonă. Această intrare înseamnă „ Mail eXchanger", și are scopul de a indica adresele IP sau numele computerelor care primesc e-mail pentru nodul descris în câmpul nume. Acest câmp poate fi gol, un nume complet sau parțial calificat. Dacă câmpul nume este gol sau este specificat un nume incomplet calificat, atunci numele este completat din directiva $ORIGIN. Generarea de înregistrări MX în cazuri complexe, când este configurată o zonă destul de mare cu o schemă extinsă de recepție a e-mailului, este o sarcină foarte nebanală, care este strâns legată de munca programelor care utilizează protocolul SMTP pentru livrarea e-mailului, așa că vom luați în considerare doar cel mai simplu caz - toate e-mailurile sunt primite de un server UNIX. În câmpul de date sunt introduse două valori - prioritatea și numele sau adresa IP a computerului care primește e-mailul trimis către acest computer. O singură adresă IP poate avea, în general, un număr nelimitat de înregistrări MX asociate cu ea și toate ar trebui să aibă priorități diferite. Poșta este trimisă în funcție de prioritate - agent postal sortează înregistrările în ordinea priorității crescânde și încearcă să livreze corespondența în acest mod. Să presupunem că am convenit cu administratorul nodului behemot.ru că putem folosi serverul său ca nod de tranzit care va primi corespondența noastră în scopul livrării ulterioare către destinatarii săi atunci când conexiunea este restabilită. Apoi descrierea serverului krokodil.ru va arăta astfel:
krokodil.ru. ÎN A 212.20.5.2
ÎN MX 10 krokodil.ru.
ÎN MX 50 behemot.ru.
www ÎN CNAME krokodil.ru.
e-mail ÎN CNAME krokodil.ru.
ftp ÎN CNAME krokodil.ru.
Acest exemplu complex, arată imediat utilizarea înregistrărilor MX, A și CNAME. Aici suntem:
- Atribuim numele krokodil.ru adresei 212.20.5.2.
- Indicăm că e-mailul trimis la adrese precum [email protected], va accepta (în această ordine):
- server krokodil.ru;
- server behemot.ru.
- Definim nume suplimentare www.krokodil.ru, mail.krokodil.ru și ftp.krokodil.ru. Vă rugăm să rețineți că toate numele din partea dreaptă sunt complet calificate, adică se termină cu un punct. Dacă acest lucru nu se face, atunci valoarea directivei curente $ORIGIN va fi înlocuită automat la sfârșitul numelui. În acest caz, acest lucru ar duce la apariția unor nume precum www.krokodil.ru.krokodil.ru.
Înregistrare PTR
Acesta este un tip foarte special de înregistrare. În exemplul nostru, am luat „în special” întreaga subrețea pentru a lua în considerare cazul de lucru „normal” cu înregistrările PTR. Cazul rețelei 212.20.5.0/31 va fi discutat puțin mai târziu.
Înregistrarea PTR este concepută pentru a efectua traducerea inversă a numelor în adrese IP. Astfel de transformări sunt utilizate pe scară largă în diverse programe, oferind acces la unele resursele rețelei: Ei verifică dacă traducerile înainte și inversă se potrivesc și, dacă există o nepotrivire sau o înregistrare PTR lipsă, pot refuza accesul. Zona care conține înregistrări PTR este numită zonă de translație inversă sau, pur și simplu, zonă „inversată”.
Înregistrările PTR nu au nicio legătură cu A, MX, CNAME și alte înregistrări care descriu conversia directă. Acest lucru a fost făcut în mod intenționat pentru a utiliza același set pentru ambele transformări module software. Aici, însă, ne așteaptă complexitatea următorul tip– nume de domeniu complet calificat sub forma www.krokodil.ru. „mărește dimensiunea” de la stânga la dreapta (adică nodurile sunt mărite pe măsură ce vă deplasați prin textul numelui de la stânga la dreapta), iar adresa IP 212.20.5.2 este de la dreapta la stânga. Pentru unificarea modulelor programului, a fost adoptată următoarea convenție: toate adresele IP sunt nume incluse în TLD-ul special in-addr.arpa. „Zonele” din acest domeniu sunt subrețele, iar numele zonei este scris ca adresa IP citită invers. Astfel, „numele” zonei noastre inverse va fi 5.20.212.in-addr.arpa pentru zona inversă care conține descrierea pentru rețeaua externă și 1.87.10.in-addr.arpa pentru zona inversă care conține descrierea rețeaua internă.
Așa cum pentru a folosi un nume de domeniu trebuie să-l înregistrați, pentru a utiliza o traducere inversă trebuie să înregistrați o „zonă” inversă cu un coordonator de zonă inversă. Spre deosebire de zonele de conversie directă, există un singur coordonator, iar înregistrarea la el este gratuită. Înregistrarea zonelor inverse se ocupă de RIPE NCC. Toate informațiile despre înregistrarea zonei inverse sunt furnizate în.
De ce trebuie să înregistrați o zonă inversă? Serverul de nivel superior din zona in-addr.arpa trebuie să știe că, pentru a efectua o cerere de traducere inversă, trebuie să contacteze un astfel de server, în acest caz 212.20.5.2. Desigur, nu este nevoie să înregistrați nicăieri zona inversă a subrețelei interne.
Înregistrarea PTR în sine pare foarte simplă - ultima parte a adresei IP este introdusă în câmpul de nume, iar numele de traducere directă complet calificată este introdus în câmpul de date. Vă atrag atenția asupra ultimului lucru - numele introdus în câmpul de date trebuie să fie complet calificat, deoarece înregistrările PTR în sine definesc relația dintre adresa IP și nume, nu pot primi informații de nicăieri despre ce zonă traducerea directă incomplet calificată numele ar trebui să fie atribuit lui .
$ORIGIN 1.87.10.in-addr.arpa
1 IN PTR tooth1.krokodil.ru.
2 IN PTR tooth2.krokodil.ru.
3 IN PTR tooth3.krokodil.ru.
4 IN PTR tooth4.krokodil.ru.
5 IN PTR tooth5.krokodil.ru.
6 IN PTR tooth6.krokodil.ru.
În exemplul de mai sus, am specificat maparea inversă pentru computerele din rețeaua internă. Pentru server vom scrie o linie (în exemplu real Directivele $ORIGIN nu trebuie specificate, ele sunt date doar pentru a clarifica despre ce zonă vorbim):
$ORIGIN 5.20.212.in-addr.arpa
2 ÎN PTR krokodil.ru
Trebuie remarcat aici că înregistrările CNAME nu sunt folosite pentru a specifica mai multe potriviri inverse, așa că atunci când întrebați „ce nume se potrivește cu adresa 212.20.5.2”, rezultatul va fi întotdeauna krokodil.ru, indiferent de numărul de alias-uri setate pentru acesta.
Cum va fi diferit cazul când furnizorul alocă blocul 212.20.5.0/31 în loc de o subrețea completă? Din punctul de vedere al generării tuturor înregistrărilor cu excepția PTR, nimic. Procedura de creare a unei zone directe și înregistrarea acesteia nu depinde de numărul de adrese, mai ales că în majoritatea cazurilor nu este nevoie de multe adrese. Cu toate acestea, în ceea ce privește înregistrările PTR, există o diferență. Spre simplificare. Sau poate nu, în funcție de furnizor. Și constă în faptul că înregistrările:
poarta.krokodil.ru. ÎN A 212.20.5.1
krokodil.ru. ÎN A 212.20.5.2
va fi pe serverul dvs. și va fi gestionat de dvs., dar intrările:
1 IN PTR poarta.krokodil.ru.
2 ÎN PTR krokodil.ru.
trebuie să fie format de furnizor, deoarece capacitatea de a înregistra singur o zonă inversă și de a o gestiona singur este oferită numai dacă aveți o rețea de cel puțin clasa C. Acest lucru, pe de o parte, ușurează munca - nu aveți trebuie să vă înregistrați la RIPE, dar, pe de altă parte, complică schimbarea denumirii serverului trebuie contactată de fiecare dată cu furnizorul.
Structura fișierului
BIND în sine, desigur, nu-i pasă în ce ordine sunt înregistrările sau cum sunt formatate. Acest lucru este important doar pentru cei care vor întreține zona, mai ales dacă se vor face modificări frecvent la aceasta. Aici voi descrie distribuția zonelor pe fișiere așa cum este folosită în zonele pe care le întrețin. Desigur, aceasta nu este singura comandă posibilă și poate nu cea mai bună. Dar funcționează.
Zone exterioare și interioare
BIND 8.x avea un dezavantaj extrem de mare - nu permitea diferențierea informațiilor de ieșire în funcție de niciun factor - era necesar fie să se arate ceea ce nu era necesar, fie să se ascundă ceea ce era necesar. Nu este absolut necesar ca clienții externi să știe despre prezența calculatoarelor în rețeaua internă, dar din moment ce nu exista o modalitate de a separa informațiile, orice computer putea stabili structura rețelei interne prin interogări DNS. BIND 9.x nu are acest dezavantaj - vă permite să distribuiți cererile în „vizualizări” utilizând liste de control al accesului (ACL). Vizualizările pot avea nume arbitrare, creând de obicei o vedere internă care este satisfăcută de clienții din subrețeaua internă și o vedere externă care este satisfăcută de toți ceilalți. Amintiți-vă aici că aceasta este aceeași zonă, doar este afișată diferit - de regulă, fișierele zonelor externe conțin doar informațiile de care au nevoie clienții externi - despre serverul extern, despre căile de livrare a e-mailurilor etc. și fișierele zonei interne. reflectă întreaga topologie a rețelei. Mai mult, dacă este însoțit zona inversa, atunci este necesar să împărțiți informațiile despre adresele de conversie inversă în fișiere în același mod.
Deci, să revenim la exemplul nostru.
Structura fișierului va fi după cum urmează. Avem o zonă directă krokodil.ru și o zonă inversă 5.20.212.in-addr.arpa. În plus, zona inversă 0.0.127.in-addr.arpa trebuie să fie prezentă pentru a asigura traducerea inversă corectă a localhost 127.0.0.1. Această zonă este necesară pentru a împiedica BIND să încerce să interogheze serverele rădăcină despre sine, ceea ce se întâmplă atunci când 127.0.0.1 indică „localhost”. Înregistrarea de conversie directă 127.0.0.1 localhost.krokodil.ru va fi scrisă în fișierul intern de conversie directă a zonei. Pentru a nu încărca rețeaua cu transmiterea de date inutile, se folosesc zone externe și interne intrări diferite SOA – înregistrările în zonele externe se schimbă foarte rar, iar în zonele interne se schimbă destul de des. Prin urmare, avem următoarele fișiere:
- localhost.rev– fișierul zonei de conversie inversă 0.0.127.in-addr.arpa. Acest fișier există doar pentru reprezentare internă.
- zona212.rev– fișierul zonei de conversie inversă 5.20.212.in-addr.arpa.
- zona10.rev– fișierul zonei de inversare internă 1.87.10.in-addr.arpa.
- direct-krokodil-ru.int– fișier intern de zonă de conversie directă krokodil.ru.
- direct-krokodil-ru.ext– fișier extern de zonă de conversie directă krokodil.ru.
- krokodil-ru-int.soa– un fișier cu înregistrări SOA și NS pentru zonele interne.
- krokodil-ru-ext.soa– un fișier cu înregistrări SOA și NS pentru zonele externe.
În ciuda listei extinse, fișierele sunt destul de scurte, așa că sunt prezentate aici integral, cu excepția comentariilor.
Să facem o notă cu privire la numele localhost. RFC 1912 menționează în mod special setarea fișierelor de rezolvat la 127.0.0.1 și localhost. În exemplul nostru, zona localhost respectă RFC 1912, deși în viața reală este foarte posibil să întâlnim rezoluția numelui 127.0.0.1 localhost.domain.tld și rezoluția inversă corespunzătoare.
Fișierul Localhost.rev. Utilizează o singură înregistrare SOA împreună cu o zonă internă de inversare:
$INCLUDE /etc/namedb/krokodil-ru-int.soa
1 ÎN PTR localhost.
Fișier zone212.rev:
1 IN PTR poarta.krokodil.ru.
2 ÎN PTR krokodil.ru.
Fișier zone10.rev:
$INCLUDE /etc/namedb/krokodil-ru-int.soa
1 IN PTR tooth1.krokodil.ru.
2 IN PTR tooth2.krokodil.ru.
3 IN PTR tooth3.krokodil.ru.
4 IN PTR tooth4.krokodil.ru.
5 IN PTR tooth5.krokodil.ru.
6 IN PTR tooth6.krokodil.ru.
Fișier direct-krokodil-ru.int:
$INCLUDE /etc/namedb/krokodil-ru-int.soa
krokodil.ru. ÎN A 10.87.1.254
ÎN MX 10 krokodil.ru.
www ÎN CNAME krokodil.ru.
e-mail ÎN CNAME krokodil.ru.
proxy ÎN CNAME krokodil.ru.
ftp ÎN CNAME krokodil.ru.
ns ÎN CNAME krokodil.ru.
localhost. ÎN A 127.0.0.1
dinte1 IN A 10.87.1.1
dinte2 IN A 10.87.1.2
dinte3 IN A 10.87.1.3
dinte4 IN A 10.87.1.4
dinte5 IN A 10.87.1.5
dinte6 IN A 10.87.1.6
Fișier direct-krokodil-ru.ext:
$INCLUDE /etc/namedb/krokodil-ru-ext.soa
krokodil.ru. ÎN A 212.20.5.2
ÎN MX 10 krokodil.ru.
ÎN MX 50 behemot.ru.
www ÎN CNAME krokodil.ru.
e-mail ÎN CNAME krokodil.ru.
ftp ÎN CNAME krokodil.ru.
poarta IN A 212.20.5.1
Fișier krokodil-ru-int.soa:
@ ÎN SOA krokodil.ru. hostmaster.krokodil.ru. (
2006051202; Număr de serie
10800; Reîmprospătați la fiecare 3 ore
3600; Reîncercați la fiecare oră
1728000; Expiră la fiecare 20 de zile
172800); Minim 2 zile
ÎN NS krokodil.ru.
Fișier krokodil-ru-ext.soa:
172800 TTL USD
@ IN SOA korkodil.ru. hostmaster.krokodil.ru. (
2005122001; Număr de serie
10800; Reîmprospătați la fiecare 3 ore
3600; Reîncercați la fiecare oră
1728000; Expiră la fiecare 20 de zile
172800); Minim 2 zile
ÎN NS krokodil.ru.
ÎN NS ns4.nic.ru.
Concluzie
Cum să creați, să configurați și să rulați un server DNS pentru o afacere mică? De fapt, nu este atât de dificil pe cât pare inițial - este suficient să parcurgeți această cale o dată, alte acțiuni vor avea loc „automat”.
Aplicație
Domenii de nivel superior
Inițial, conform RFC 920, lista TLD-urilor funcționale includea doar .com, .gov, .mil, .edu, .org, care reprezentau organizații comerciale, guvernamentale, militare, educaționale și non-profit. Ulterior, această listă s-a extins oarecum - în 1985, a fost adăugat TLD .net, reprezentând organizațiile furnizorilor servicii de rețea, iar în 1988 - TLD .int, reprezentând organizații internaționale. În 2001-2002, practic necunoscute utilizatorului rus TLD-urile .aero, .biz, .cat, .coop, .jobs, .mobi, .museum, .name, .pro și .travel au fost adăugate la această listă. Mai mult informatii detaliate este dat în . Domeniile geografice sunt distribuite o dată pentru totdeauna. Deși acest lucru nu înseamnă că nu vă puteți înregistra domeniul cu acesta. Multe domenii geografice care coincid întâmplător cu abrevieri „cunoscute” sunt extrem de atractive. De exemplu, .md (Moldova) este foarte atractiv pentru institutii medicaleși locuitorii din Maryland, SUA; .tv (Tuvalu) – pentru site-uri web legate de televiziune; .tm (Turkmenistan) coincide cu ortografia abrevierei „Marcă comercială” și .nu (Niue - există o astfel de colonie insulară) - pentru site-urile în stilul „nud”.
