Principiile sistemului de rezoluție a numelui
Zona rădăcină care conține informații despre toate subdomeniile: net. com. org. ru. su. și așa mai departe. Mai precis, informații despre serverele care servesc aceste domenii.
Domeniul copt. conținând informații despre toate subdomeniile, precum și numele serverelor înregistrate direct în acest domeniu, de exemplu www. coapte. net.
Figura 1 Procesul de traducere a numelor în DNS
Această arhitectură DNS vă permite să distribuiți sarcina și responsabilitatea pentru funcționarea sistemului între administratorii domeniilor individuale. Datoriile lor includ asigurarea unei performanțe normale atunci când răspunde la întrebările din zonă, menținerea unicității numelor în zonă și notificarea administratorului zonei părinte a schimbărilor în serverele care deservesc zona.
Această arhitectură DNS distribuită ierarhic a asigurat o viață lungă și o evoluție evolutivă a sistemului pentru mai mult de un sfert de secol.
Dar există o caracteristică în sistemul DNS care o deosebește de multe alte sisteme de Internet care sunt descentralizate. Acesta este același punct, rădăcina arborelui DNS. unde încep toate cererile proaspete. Vom vorbi mai mult despre asta.
Nivel rădăcină DNS
Serverele rădăcină (CS) ale DNS sunt o componentă critică a sistemului, deoarece oferă acces la zona rădăcină DNS. Zona rădăcină conține informații despre toate domeniile de nivel superior: domenii naționale (de exemplu, .ru), domenii generale (de exemplu .com) și domenii sponsorizate (de exemplu, .museum). Această informație indică clientului care servere DNS să trimită o solicitare ulterioară de a continua rezolvarea FQDN. Cu alte cuvinte, orice solicitare "proaspătă" (adică nu este stocată în memoria cache client) începe cu accesul la serverul rădăcină.
Sistemul de server rădăcină de astăzi și coordonarea funcționării acestuia
Să luăm în considerare în detaliu participanții SCS. Pentru a face acest lucru, trebuie să ne îndreptăm spre procesul de modificare a conținutului zonei rădăcină, prezentat în Figura 2.
Figura 2 Procesul de a efectua modificări în zona rădăcinilor
Cererea de modificare vine de la administratorul de domeniu de nivel superior (ccTLD, gTLD, etc.) și este menținută de IANA. Un exemplu tipic al unei astfel de solicitări este schimbarea compoziției serverelor care deservesc domeniul.
Apoi, modificările sunt transmise organizației responsabile pentru editarea și publicarea efectivă a zonei în DNS. Acest rol este în prezent realizat de VeriSign. Apropo, aceeași companie este operatorul a două servere rădăcină - a.root-servers.net și j.root-servers.net.
Zona este publicată inițial pe serverul master master și apoi distribuită tuturor replicilor folosind protocolul TSIG, care protejează datele de modificări în timpul transmisiei.
Operatorii COP
Operatorii COP sunt diverse organizații care au obținut dreptul de a gestiona servere într-un trecut relativ îndepărtat, când astfel de probleme au fost rezolvate mai puțin formal. Printre operatori se numără universitățile, organizațiile Departamentului Apărării al SUA, asociațiile non-profit. Operatorii sunt independenți din punct de vedere financiar și juridic de ICANN, sub care operează IANA. Atunci când iau decizii operaționale, operatorii se ghidează după oportunitatea tehnică și standardele existente (de exemplu, RFC2870), sprijinind în principal status quo-ul. Cea mai mare soluție de acest tip, adoptată independent de operatorul de servere f. root - servere. net de ISC, a existat o decizie de a aplica tehnologia Anycast. Deși această decizie a fost examinată temeinic de experți, aceasta nu a fost reglementată de ICANN sau de niciunul dintre camerele sale. Ulterior, un număr de alți operatori s-au alăturat ISC.
Se crede, în general, că această independență și eterogenitate a operatorilor CC este baza stabilității tehnice și politice a sistemului în ansamblu, excluzând uzurparea conducerii oricăreia dintre părți.
Operatorii CC formează un grup informal al cărui scop este coordonarea activităților comune și schimbul de informații și experiențe operaționale. Grupul desfășoară întâlniri periodice de 3 ori pe an, programate la ședința IETF. Un rezultat al acestor întâlniri este generarea unei chei private pentru protocolul TSIG.
Membrii grupului sunt, de asemenea, membri ai Consiliului consultativ al Comitetului consultativ al sistemului de raportare a radacinilor (RSSAC) al ICANN, al cărui obiectiv este de a elabora recomandări privind gestionarea KSK și efectuarea de diverse modificări ale sistemului.
Până de curând nu existau relații oficiale între operatori și ICANN / IANA. Această situație sa schimbat odată cu semnarea primului acord între ICANN și operatorul de servere f.root-serve r s.net de către ISC. Prezentul acord nu prevede calcule financiare și determină numai responsabilitățile reciproce ale părților în ceea ce privește gestionarea COP. Se știe că un număr de operatori discută, de asemenea, acorduri similare cu ICANN.
Mai jos este o listă și o scurtă descriere a operatorilor SCS actuali.
SCS alternativ
Deși posibilitatea unei încălcări intenționate a COP sau modificarea conținutului zonei de rădăcină în oricare dintre situațiile sau ICANN / IANA puțin probabil, strict vorbind, nu există în prezent nici un proces formal sau legile internaționale care ar putea împiedica acest lucru. Putem spune că funcționarea normală a SCS depinde în parte de "bunăvoința" participanților.
Trebuie remarcat faptul că astfel de dependențe "informale", bazate pe încredere, sunt tipice pentru funcționarea sistemului DNS (și în multe privințe a Internetului) în general. În cele din urmă, alegerea COP-urilor de utilizat rămâne pentru client. Aceste informații sunt conținute în sugestiile fișierului de configurare și pot fi modificate.
Această caracteristică, combinată cu nemulțumirea față de sistemul de management SCS existent, condus de ICANN, cu participarea guvernului unei țări - SUA, a condus la crearea așa-numitei SCS alternative. Exemple de astfel de sisteme sunt Public-Root, Open Server Root Network (ORSN) și UnifiedRoot. Deși aceste sisteme copiază starea curentă a zonei rădăcină, arhitectura însăși prevede că, în anumite condiții, SCS-urile alternative pot oferi un spațiu de nume alternativ. Administratorul clientului DNS (de obicei, un server DNS care deservește utilizatorii întreprinderi sau clienții rețelei de cablu) poate selecta un SCS alternativ prin modificarea corespunzătoare a fișierului de sugestii.
SCS alternativ a fost evaluat critic de către IETF ca deschizând potențialul pentru o divizare a internetului unificat (a se vedea RFC2826).
Dezvoltarea tehnică a nivelului rădăcinilor DNS
Sistemul de nivel rădăcină DNS este foarte conservator. Acest lucru este de înțeles - orice schimbare la acest nivel afectează funcționarea întregului sistem global de nume de domeniu. Cu toate acestea, în ultimii ani s-au introdus câteva modificări importante în RAS și zona rădăcinilor.
Este posibil să fi observat că numărul COP și denumirea exactă COP este „fericit“ numărul 13. Aceasta nu este o provocare pentru superstiție, numărul 13 se datorează unei limitări privind dimensiunea mesajului de 512 octeți, setați standardul DNS [RFC1035 4.2.1]. Deși punct de vedere istoric această restricție a fost din cauza unei restricții privind pachetele UDP evita fragmentarea, aceasta continuă să existe în protocolul DNS, în ciuda apariției unor noi protocoale de rețea, cum ar fi IPv6. DNS avansate etalon (EDNS0, RFC2671 2.3, 4.5) furniza un acord preliminar cu privire la suma de comunicare între client și server, însă amploarea acestei protocolului în sistemul DNS actual nu este suficient pentru a elimina limitarea de 512 octeți în viitorul apropiat.
Toate numele de COP 13 (o rădăcină. - Servere net -. M rădăcină - .. Servere net) se potrivesc în octetul rezervat 512, iar în cazul în care paisprezece nume pentru o parte considerabilă solicită un răspuns nu se poate integra complet alocate 512 octeți. Rezultatul poate fi o scădere semnificativă a performanței sistemului, deoarece unii clienți vor trebui să repete cererea, dar acum folosesc un protocol TCP mult mai lent.
Tehnologia Anycast este cea mai potrivită pentru aplicațiile care utilizează protocolul UDP. fără a stabili o conexiune pe termen lung. În caz contrar, cu orice modificări ale topologiei Internet (care apar în mod continuu), calea cea mai scurtă poate duce un client la o altă rețea anycast. iar conexiunea va fi ruptă.
La prima vedere sarcină simplă, includerea acestor informații în zona de rădăcină au fost asociate cu o problemă majoră - depășește dimensiunea de răspuns, și, în special, răspunsul la (amorsare) cererea primară, aceleași 512 octeți!
În sfârșit, a treia problemă posibilă poate fi sisteme intermediare, cum ar fi firewall (sisteme firewall), care nu pot trece -packet DNS a cărui dimensiune este mai mare de 512 octeți sau înregistrări cuprinde IPV 6 protocol.
Studiul acestor aspecte a arătat că nu există motive speciale de îngrijorare: majoritatea clienților moderni susțin extensia EDNS 0, care permite transmiterea de pachete DNS mai mari. Chiar dacă nu, răspunsul la cererea primară, care nu depășește 512 octeți, conține suficiente informații pentru a începe căutarea. Testarea nu a dezvăluit nici o problemă cu noile intrări din fișierul de sugestii.
Problema principală, după cum sa dovedit, ar putea fi sisteme intermediare, deși testele au arătat că multe dintre ele nu impun restricții privind dimensiunea pachetului DNS transmis. Singura modalitate de a rezolva această problemă a reprezentat o muncă educațională extinsă.
IDN înseamnă nume de domenii internaționalizate. sau nume de domenii internaționale și înseamnă posibilitatea de a utiliza alfabete naționale atunci când specificați un nume de domeniu sau de server. Tehnologia este foarte atractivă, atât din punct de vedere tehnic cât și politic, deoarece pentru utilizatorii cu alfabete non-latine permite aproape complet excluderea necesității de a folosi alfabetul latin atunci când lucrează pe Internet.
Cu toate acestea, standardul de bază DNS permite doar o codificare de caractere pe 7 biți, așa-numita tabelă ASCII. și chiar și atunci cu anumite restricții pentru numele de gazdă. În același timp, Unicode este formularul standard pentru codificarea simbolurilor limbilor scrise naționale.
Pentru a traduce caracterele Unicode într-un set de caractere DNS valide, se folosește așa numitul Punycode. Numele în Pyunikode arată cam ciudat, de exemplu, cuvântul "test" va fi reprezentat ca xn - 80akhbyknj4f, dar se conformează pe deplin standardului DNS.
În prezent, se discută așa-numitul proces Fast Track, care va permite operatorilor din domeniile naționale existente la nivel înalt să înregistreze aceste domenii în limbile naționale.
Cu ajutorul IDN, există o serie de probleme. De exemplu, IDN deschide mai multe oportunități de a falsifica numele dacă numele serverului arată foarte asemănător cu alt nume, dar utilizează de fapt și alte simboluri, așa-numitele homografe. Într-adevăr, cum să distingi www. paypal. com de la www. p și ypal. com în care a doua literă "a" este tastată în chirilică. În comparație cu denumirile obișnuite, unde 1 este similar cu l. și de la 0 la O. IDN conține mult mai multe omograme. Rezolvarea acestei probleme necesită un control strict al registratorilor domeniului, limitând numărul de limbi acceptate în domeniu și interzicând amestecarea diferitelor limbi în numele domeniului.
Principalul dezavantaj al DNS este sistemul slab de protecție a datelor. Aceasta înseamnă că, în procesul de transfer al datelor de la server către client, datele pot fi modificate. De asemenea, este posibil să se creeze servere false DNS care să furnizeze date modificate. DNSSEC. care este o extensie a standardului DNS. poate rezolva această problemă prin autentificarea datelor cu o semnătură digitală a administratorului de domeniu de la care au fost primite datele. La rândul său, semnătura administratorului de domeniu este certificată de administratorul zonei părinte. Acest lanț de identitate continuă până în zona de rădăcină, iar clientul DNS poate verifica dacă numele și întregul lanț de delegări sunt valide și nu au fost modificate.
În prezent, suportul DNSSEC este destul de împrăștiat în arborele DNS. care, în majoritatea cazurilor, nu permite construirea așa-numitelor lanțuri de încredere. Nu există suport DNSSEC în zona rădăcină. Toate acestea, în esență, anulează avantajele DNSSEC.
Directorul tehnic al RIPE NCC Andrey Robachevsky
Opiniile prezentate în articol nu reflectă neapărat poziția oficială a CNC RIPE
Articole similare
Trimiteți-le prietenilor: