Доменски именски систем: Разлика помеѓу преработките
| [непроверена преработка] | [проверена преработка] |
Избришана содржина Додадена содржина
Нема опис на уредувањето |
|||
Ред 17:
*Зголемен сообраќај во мрежата и оптоварување на процесорот на SRI мрежно – информациониот систем.
*Во оваа структура се појавуваат колизии на имињата, бидејќи не постои механизам за да ја спречи појавата на повеќе компјутери со исто име.
*Невозможноста да се одржи конзистентноста на HOSTS.TXT датотеката.<ref>Presentation by Joe Abley (April 2004). "Introduction to the DNS system". </ref>
Проблемот со лошата скалабилност на оваа структура ARPANET се обидува да го реши со создавање на хиерархиски простор на имиња.
Во 1984 година Пол Мокапетрис (Paul Mockapetris) од Институтот за информатички науки USC дизајнирал архитектура за новиот систем. Тој ги издал RFC 882 и RFC 883 со кои бил опишан системот за именување на домени (DNS), во ноември 1987 година биле заменети со RFC 1034 и RFC 1035. Подоцнежните RFC опишуваат различни аспекти на системот за именување на домени како: потенцијалните безбедносни проблеми на DNS, проблемите околу имплементацијата, административни пропусти, механизми за динамичко ажурирање и за обезбедување на податоци по зони.<ref>Paul Albitz, Cricket Liu (May 2006). "DNS and BIND, 5th Edition". O'Reilly. </ref>
Даглас Тери (Douglas Terry), Марк Пејнтер (Mark Painter), Дејвид Ригл (David Riggle) и Сонгиан Зоу (Songnian Zhou) во 1984 година ја пишуваат првата Unix имплементација за именување на домени, наречена (The Berkeley Internet Name Domain – BIND). BIND е широко застапен, најчесто на Unix системи и претставува доминантен DNS софтвер користен на Интернет. Поради неговиот отворен код и се пософистицираните напади, се откриени многу пропусти кај BIND. Тоа резултира со развој на алтернативни сервери на имиња и надградба на постоечките, така BIND во својата 9-та верзија бил комплетно репрограмиран од почеток.
Ред 40:
Доколку полето со името на коренот се појавува во името на доменот на јазолот, името ќе се прикаже како да завршува со точка, тоа всушност е точката која го одделува полето за текст со нулта должина на коренот. Кога единствено се појавува името на коренот се запишува со една точка.
Некои софтвери точката која е на крајот на името ја интерпретираат како индикатор дека се работи за апсолутно име на доменот. Апсолутното име се пишува релативно на коренот и недвосмислено ја означува локацијата на јазолот во хиерархијата. Апсолутното име на доменот уште се нарекува целосно квалификувано име на доменот (FQDN). Наспроти ова имињата кои не завршуваат со точка понекогаш се интерпретираат како релативни за одредени имиња на домени не само за коренот – како што се имињата на директориумите без коса линија (/) што се интерпретираат како релативни за тековниот директориум.<ref>Security and Stability Advisory Committee (1 November 2003). "DNS Infrastructure Recommendation". </ref>
==== Домени ====
Ред 84:
Во повеќето зони за да се обезбеди непреченост на операциите се користат два или повеќе авторитативни сервери. Авторитативниот сервер каде се чува главната копија на податоците за таа зона се нарекува примарен (master) сервер со имиња. Тој ги вчитува податоците за зоната од локална датотека за зоната која е креирана од администраторот на базата на податоци на DNS.
Секој примарен сервер во зоната може да има еден или повеќе од него зависни сервери – секундарни (slave) сервери. Секундарните сервери исто така се авторитативни за таа зона, но тие се ажурираат од примарниот сервер со користење на процес на репликација. Најчесто во секоја зона постои само еден примарен сервер од кој се ажурираат останатите сервери.<ref>Security Technical Implementation Guide (17 October 2007). "DOMAIN NAME SYSTEM". Developed by DISA for the DoD. </ref>
==== Сервери за кеширање ====
Ред 99:
=== Разрешувачи ===
Друга клучна компонента на DNS е разрешувачот за клиенти, негова задача е да ги формулира и испраќа DNS барањата до серверите на имиња.<ref>Origin (June 1999). "Domain Name System".Origin BV. </ref> Повеќето разрешувачи се едноставни, можат да се најдат на обичен компјутер или на серверски компјутерски систем кој користи DNS.
Разрешувачите најчесто се конфигурирани со листа од два или три сервери за кеширање и со тоа се осигурува непреченост во функционирањето во случај да не е достапен примарниот сервер.
Ред 105:
Исто така треба да постојат ограничувања на време, бидејќи можно е разрешувачот да не добил одговор на првото барање, додека на наредното барање со иста содржина да го добие барањето.
Од серверска страна првото барање го остава да чека додека да најде достапен сервер, за второто барање успева да пронајде друг сервер кој ќе го услужи, во тој случај првото барање останува неодговорено поради долгото време на чекање на серверот).<ref>Libor Dostalek, Alena Kabelova (March 2006). "DNS in Action". Packt Publishing. </ref>
Од страната на корисникот изгледа како првото барање да не успеало на првиот обид, но на повторен обид се добил одговор.
Ред 119:
Најчесто Интернет провајдерот до кој се поврзува корисникот го одредува DNS серверот, во случаи каде компаниите користат свој DNS сервер тогаш разрешувачот се обраќа до него.
Резултатите од серверот пристигаат до разрешувачот (доколку е добиен одговор), разрешувачот потоа го кешира барањето и го предава резултатот до програмата која го издаде барањето.<ref>http://www.swansonmedia.com/domain/domain-name-system.html </ref>
== Наводи ==
{{наводи}}
[[Категорија:Систем за именување на домени]]
| |||