вътрешни маршрутизатори (internal

Опорните маршутизатори могат същевременно да бъдат вътрешни, ако всичките им интерфейси са свързани към опорната мрежа.

В рамките на една област всички маршрутизатори имат една и съща топологична база данни. Нейното предназначение е да се изчислят най-късите пътища между дадения маршрутизатор и всички останали маршутизатори в областта.

Йерархичните области в OSPF мрежите увеличават скоростта на сходимост на протокола и намаляват натоварването на необходимите за работата му мрежови и изчислителни ресурси.

OSPF поддържа три вида различни връзки:

• 
  връзка от тип “точка-точка” между два маршрутизатора;
  
• 
  многоточкови мрежи с broadcast (например, повечето LAN);
  
• 
  многоточкови мрежи без broadcast (например, повечето WAN с комутация на пакети).
  

OSPF работи чрез обмяна на информация между прилежащи маршрутизатори, което не е същото като съседни маршрутизатори. Това се прави, тъй като не е ефективно всеки два маршрутизатора да обменят данни. За целта се избира един титулярен маршрутизатор (designated router), който става прилежащ към всички останали маршрутизатори и всеки от тях синхронизира топологичната си база данни с неговата. Ако настъпи промяна в състоянието на връзките на даден маршрутизатор, той изпраща съобщение на титулярния маршрутизатор, а от своя страна той съобщава промяната на всички останали маршрутизатори в мрежата. При отпадане на титулярния маршрутизатор има заместник, който е в състояние веднага да поеме неговите функции.

Полето Version number съдържа номера на версията на OSPF, която се използва.

Полето Type определя типа на съобщението. Има няколко типа съобщения:

• 
  “ехо” пакет (hello packet) – той се използва при откриване на съседни маршрутизатори, за проверяване на работоспособността на връзките и за избор на титулярен маршрутизатор;
  
• 
  описание на база данни (database description) – разменят се при първоначално установяване на връзка между два маршрутизатора и служат за обмен на информация за състоянието на връзките в областта от техните топологични бази данни;
  
• 
  пакет за запитване (link-state request) – чрез него даден маршрутизатор може да поиска информация от друг маршрутизатор за част от записите в неговата топологична база данни за състоянието на връзките;
  
• 
  пакет за обновяване (link-state update) – тези пакети се изпращат периодично от всеки маршрутизатор и съдържат данни за неговото състояние и за цените, използвани в топологичната база данни; разпространяват се по метода на наводняването към всички останали маршрутизатори в границите на дадена област;
  
• 
  пакет за потвърждение (link-state acknowledgement) – механизмът за надеждно доставяне на пакетите за обновяване изисква при получаването им да се изпращат потвърждения.
  

Полето Router ID съдържа уникален за автономната система идентификатор на маршрутизатора, изпратил пакета.

Полето Area ID съдържа номера на областта, към която е свързан интерфейса на маршрутизатора-подател на пакета.

Полето Check sum е контролна сума, която се изчислява върху цялото съдържание на OSPF пакета. Служи за проверка дали пакета е бил предаден правилно.

Полето Authentication type указва вида на използвания механизъм за идентифициране на подателя на пакета. Проблемът е, че в мрежата може да проникнат фалшиви пакети, които дублират информацията за състояние на връзките на някой маршрутизатор. За това трябва да се установява автентичността на пакетите.

Полето Authentication съдържа автентицираща информация.

За маршрутизиране между различни автономни системи се използват външни маршрутизиращи протоколи. Такъв протокол е BGP (border gateway protocol). В него се залага на политиката на маршрутизация – например, най-прекият път между две автономни системи не винаги е разумен. В политиката се включват икономически, административни и други фактори. Примери за политически ограничения:

• 
  да не се позволява транзитен трафик през дадена автономна система;
  
• 
  трафикът за Пентагона да не минава през Ирак;
  
• 
  трафикът, започващ или свършващ в IBM да не минава през Microsoft.
  

• 
  stub мрежи – те имат само една връзка в BGP графа и не могат да се използват за транзитен трафик;
  
• 
  multiconnected мрежи – те могат да се използват за транзитен трафик, но самите те отказват да го правят;
  
• 
  transit networks – например опорните мрежи, които пренасят транзитен трафик, обикновено срещу заплащане.
  

BGP протокола се базира на алгоритъма с вектор на разстоянието, но се различава доста от него. Вместо да се поддържа само цената към всяко местоназначение, всеки BGP маршрутизатор поддържа целия път към местоназначението. Освен това, вместо периодично да подава на съседите си цените до местоназначенията, всеки BGP маршрутизатор подава на съседите си целите пътища, които те използват. Това има смисъл, тъй като графът с възли автономните системи не е безмерно голям.

Като пример да разгледаме следната мрежа от BGP маршрутизатори:

По-конкретно да разгледаме маршрутизатора F. Той получава от съседите си следните пътища до D – път BCD от B, път GCD от G, път IFGCD от I и път EFGCD от E. F преглежда тези пътища за да определи кой е най-добрия. Той премахва пътищата от I и E, тъй като минават през него. Изборът е между B и G. Всеки BGP маршрутизатор съдържа модул, който изследва пътищата до дадено местоназначение и ги оценява. Път, който нарушава политическо ограничение автоматично получава оценка безкрайност. Маршрутизаторът избира пътят с най-ниска оценка. Оценяващата функция не е част от BGP протокола.

При BGP лесно се решава проблемът “броене до безкрайност”. Например, да предположим, че G пропадне или, че линията FG става недостъпна. Тогава F получава маршрути от останалите си три съседа. Тези маршрути са BCD, IFGCD и EFGCD. F бързо премахва последните два пътя, тъй като те са безсмислени – преминават през него и за това избира FBCD като нов маршрут. Другите алгоритми с вектор на разстоянието често правят погрешен избор, тъй като те не могат да съобщят кой от съседите има независим маршрут до местоназначението и кой няма.
17. Групова и безкласова маршрутизация в IP мрежи.
Протоколът IP поддържа групова маршрутизация, като използва IP адресите от клас D. Всеки адрес от клас D идентифицира една група хостове, използват се 28 бита за идентифициране на групите, което дава около 250000000 групи. Когато един процес изпрати пакет към адрес от клас D, се прави опит този пакет да се достави до всички членове на съответната група. Груповата маршрутизация се извършва от специални multicast маршрутизатори, които комуникират с хостовете посредством IGMP протокола.
Големият проблем на IP протокола е недостига на адреси. По принцип съществуват над 2 милиарда адреси, но организацията им по класове е неефективна и заради нея се губят милиони адреси. За повечето организации мрежа от клас A със 16 милиона адреси е твърде голяма, а мрежа от клас C с 256 адреси твърде малка. Затова се избират мрежи от клас B с 65536 адреси. Мрежите от клас B, обаче, са твърде недостатъчно – 16384, докато през 1996 в Internet вече са свързани над 100000 мрежи.
Друг проблем е големината на маршрутните таблици. От гледна точка на маршрутизаторите, IP адресите се състоят от номер на мрежата и номер на хоста. Маршрутизаторите не трябва да знаят всички хостове, но те трябва да имат информация за всички мрежи. Ако се използват, например, половин милион клас C мрежи, то всеки маршрутизатор трябва да има маршрутна таблица с половин милион реда, по един за всяка мрежа, който описва по коя линия се стига до съответната мрежа.

Съхраняването на таблици с половин милион реда да кажем е възможно, въпреки че повечето маршрутизатори съхраняват таблиците си в оперативната памет, но друг сериозен проблем е сложността на алгоритмите за маршрутизация. Освен това, маршрутизаторите периодично трябва да изпращат маршрутните си таблици – колкото са по-големи, толкова по-голяма е вероятността части от тях да се загубят при предаването.

При CIDR този алгоритъм не е приложим. Всеки ред от маршрутната таблица се разширява с 32-битова маска. По този начин маршрутната таблица е масив от тройки (IP адрес, маска, изходяща линия). За удобство IP адресът и маската се записват по следния начин: A.B.C.D/N, където N е броят на единиците в лявата част на маската. Например, 194.24.8.0/22 е мрежа, съставена от

При протоколите със съединение имаме три фази – установяване на съединение, трансфер на данни и закриване на съединението.

За преодоляване на тези проблеми при установяване на връзка се използва процедура за трикратно договаряне (three-way handshake). Да предположим, че крайните абонати A и B искат да установят връзка. Изпълняват се следните три стъпки:

1. 
   A изпраща заявка, че иска да установи съединение – указва размера на буферите, брой на буферите, скоростта на предаване и др. Тази заявка е специално служебно съобщение на транспортно ниво. За мрежовото ниво заявката е обикновен пакет. Съобщението може да стигне до B, но може и да не стигне. За целта A си включва таймер и ако той изтече преди да се получи отговор от B, A изпраща заявката наново. След три неуспешни опита A решава, че B е недостъпен и се отказва;
   
2. 
   B отговаря на A, като включва в отговора собствени параметри за връзката;
   
3. 
   A потвърждава съединението на B. Това потвърждение е необходимо, тъй като B трябва да знае, че A е получил отговора. След успешно получаване на потвърждаване A и B заделят заявените ресурси.
   

Прекратяването на връзката също се извършва с трикратно договаряне.

Всички тези изисквания са довели до избор на мрежа с комутация на пакети, базирана на обслужване с неустановена връзка, което се реализира от слой, наречен “интернет слой”. Той е основата на цялата мрежова архитектура. Негово основно предназначение е да позволи на хостовете от дадена мрежа да изпращат пакети, които се предават независимо един от друг до съответното местоназначение, намиращо се обикновено в друга мрежа. Те могат даже да пристигнат в различен ред от този, в който са били изпратени. В този случай задачата на по-високите слоеве е да ги пренареди в реда на изпращане, ако съответното приложение изисква това. Интернет слоя дефинира формат на пакета и съответен протокол, наречен интернет протокол IP (internet protocol). Една от неговите функции е да доставя IP пакетите до исканото местоназначение. Комутирането на пакетите е друга важна задача на този слой, както и предотвратяването на претоварвания в мрежата. Поради тази причина може да се каже, че интернет слоя е подобен във функционално отношение на мрежовия слой от OSI модела.

В модела TCP/IP над интернет слоя се намира транспортният слой. Той е конструиран, така че да позволи на двойка обекти от едноименни протоколни нива в хоста-източник и хоста-получател да провеждат коректен обмен на съобщения. Неговите функции са същите, като тези на транспортния слой в OSI еталонния модел. Два протокола от типа “край-край” са дефинирани в транспортния слой на TCP/IP модела. Първият протокол е TCP (transmission control protocol), който предоставя надеждно обслужване с установена връзка. Този протокол позволява потокът от байтове, изпратен от една машина да бъде предаден без грешка до произволна друга машина. В хоста-източник той фрагментира потока от байтове в отделни съобщения, които предава на интернет слоя. В хоста-получател транспортният слой реасемблира приетите съобщения в изходящ поток от байтове. TCP също така управлява потока от съобщения по такъв начин, че машината, която изпраща съобщения с по-висока скорост, да не препълни машината, която получава тези съобщения, но работи с по-ниска скорост. Вторият протокол на транспортния слой е UDP (user datagram protocol). Той осигурява ненадеждно обслужване с неустановена връзка. UDP се използва при приложения, които не изискват механизмите на TCP протокола за запазване от последователността на съобщенията и управление на потока от информация – например при предаване на звук.

При TCP/IP модела няма сесиен и представителен слой, тъй като няма необходимост от това.

Над транспортното ниво е приложният слой, който включва протоколи за различни приложения. Такива са TELNET (виртуалните терминали), FTP (обмен на файлове), SMTP (електронна поща), DNS (съответствие между име на хост и неговия IP адрес), NNTP (трансфер на USENET новини), HTTP (обмен на уеб-страници) и др.

Под интернет слоя в TCP/IP модела има голяма празнина. Споменава се за слой за достъп до мрежата, чрез който хостовете трябва да се свържат към мрежата посредством някакъв протокол, така че да могат да изпращат и приемат IP пакети. Този протокол не е дефиниран в TCP/IP модела и той варира в различните мрежи.

Недостатък на TCP/IP модела е, че той не прави хубав паралел между услуги, интерфейси и протоколи – нещо което е добре направено в OSI модела. TCP/IP моделът не е достатъчно общ, той не може да се използва за описание на друг протоколен стек. Освен това той не различава каналното и физическото ниво, които значително се отличават по своите функции.
20. Транспортни протоколи TCP и UDP – формати.
Най-важните протоколи, обслужващи транспортния слой, са TCP (transmission control protocol) и UDP (user datagram protocol). Предназначението на TCP е да осигурява надеждно предаване на данните между предавателя и приемника чрез установяване на връзка. Това означава, че на приложната програма, която използва TCP, е гарантирано доставянето на предадената информация до получателя. От друга страна, UDP не е ориентиран към установяване на връзка и е ненадежден протокол, който не гарантира, че предаденото съобщение ще достигне до местоназначението си.
TCP протоколът представлява множество правила за осъществяване на надежден информационен обмен между приложните слоеве на два хоста. TCP установява логическа връзка “край-край” между две приложни програми, които в общия случай се изпълняват на два различни хоста. Данните, обменяни между приложните програми по протокола TCP, се интерпретират и обслужват като поток от байтове. TCP не вмъква и не интерпретира никакви разделители между логическите записи.
Обменът на информация, който осъществява TCP се извършва посредством сегменти. При предаване TCP получава данни от по-горния слой, разделя ги на части, опакова ги в сегменти и ги изпраща на IP протокола. Той от своя страна опакова сегментите в дейтаграми и извършва маршрутизирането на всяка дейтаграма. При приемане IP протоколът разопакова пристигналите дейтаграми, след което предава получените сегменти на TCP протокола, който сглобява и подрежда данните от сегментите в съобщения към по-горните слоеве така, както те са били изпратени.

Всеки край на TCP връзката се идентифицира с IP адреса на съответния хост и с 16-битово число, наречено номер на порт, което определя съответната приложна програма, използваща тази връзка. Комбинацията от адреса на хоста и номера на порта се нарича socket. Всеки TCP сегмент съдържа номерата на портовете на източника и на получателя и това позволява на TCP протокола да определи за коя приложна програма е предназначен съответния сегмент. Комбинацията от socket-а на източника и socket-а на получателя е уникална и тя идентифицира TCP връзката. Съответствието между номер на порт и приложна програма се осъществява локално във всеки хост. Първите 1024 номера на портове са така наречените well-known портове, които са резервирани за най-често използваните стандартни приложни програми.

TCP осигурява на протоколите от по-горните слоеве възможност за двупосочно предаване на данните (пълен дуплекс), при което всеки сегмент може да се използва едновременно за пренос на данни и на информация за управление на обмена, съдържаща се в неговата заглавна част. Това означава, че всеки сегмент може, както да пренася данни от източника до получателя, така и да обслужва насрещния информационен поток чрез заглавната си част – например да извърши потвърждение за получаване на данните на вече приет сегмент. За да се осигури получаването на данните по реда на тяхното изпращане, всеки изпратен байт се номерира, а получаването на всяка последователност от байтове се потвърждава. Насрещните информационни потоци са относително независими в рамките на TCP връзката, което се отнася и до номерацията на байтовете. Данните се препредават, когато не е получено потвърждение за получаването им.

Протоколът TCP използва 32-битови поредни номера за идентифициране на всеки байт от данните, обменяни с приложното ниво. Във всеки TCP сегмент е записан поредния номер на първия байт от неговото поле за данни. Например, ако протоколът TCP предава данни с размер на сегмента 500 байта и в първия сегмент за началния байт данни е записал пореден

номер n, то във втория ще бъде записан пореден номер n+500, в третия пореден номер n+1000 и т.н.

Форматът на заглавната част на TCP сегмента е следния:

Заглавната част включва задължителни полета с фиксиран размер 20 байта, към които може да бъде добавено поле Options. След опциите (ако има такива) следва полето на обменяните

данни - Data, което също не е задължително. Максималната допустима дължина на полето Data е 65495 байта. Тя се получава от максималната допустима дължина на IP дейтаграмата 65535 байта, намалена с размера на задължителните полета на IP заглавната част (20 байта) и TCP заглавната част (20 байта).
Полетата Source port и Destination port са двубайтови и представляват номер на порта на източника и на получателя съответно, които заедно с IP адресите на източника и на получателя образуват номера на socket-и, идентифициращи връзката.

Полето Sequence number е поредния номер на първия байт (в рамките на последователността от байтове, предавани от източника), който е записан в полето Data на сегмента.

Полето Acknowledgement number е номерът на първия байт данни, който се очаква да се получи със следващия сегмент, изпратен от другия край на TCP връзката. Например, при успешно получаване на сегмент с размер на полето данни 500 байта и пореден номер на началния му байт n, към източника на този сегмент се изпраща TCP сегмент, в който потвърждението е с номер n+501.

Полето TCP header length е 4-битово и определя дължината на заглавната част на TCP сегмента в 32-битови думи. То е задължително, тъй като полето за опции е с променлива дължина. Фактически с това поле се определя началото на полето Data в рамките на TCP сегмента.

Заглавната част на TCP сегмента съдържа и 6 еднобитови флага. Те имат следното предназначение:

• 
  URG – валиден е указателят за спешни данни (Urgent pointer). Установяването на този флаг означава, че трябва да се преустанови обработката на получените данни, докато не се обработят байтовете, към които сочи указателят за спешни данни;
  
• 
  ACK – валиден е номерът на потвърждение, записан в полето Acknowledgement number на заглавната част;
  
• 
  PSH – при активирането на този флаг, програмните модули управляващи транспортния слой на източника и на приемника трябва да изпратят незабавно наличните данни колкото е възможно по-бързо към техния получател, т.е. източникът не изчаква да се съберат данните за образуване на пълен сегмент с избрания размер и съответно получателят не чака запълването на приемния буфер;
  
• 
  RST – сегмент, в който е установен този флаг, служи за прекратяване на TCP връзката. Използва се в случаите, когато връзката е нарушена (например, поради повреда в хоста) или когато се отхвърля невалиден сегмент или се отказва опит за установяване на връзка;
  
• 
  SYN – сегмент с установен флаг SYN се използва при установяване на TCP връзка и за изпращане на началния номер, от който ще бъдат номерирани байтовете на изходящия информационен поток;
  
• 
  FIN – сегмент, в който е установен този флаг, означава, че изпращачът прекратява предаването на данни. Поради двупосочния характер на информационния обмен това не означава, че TCP връзката е прекратена.
  

Полето Urgent pointer се използва да укаже позицията на първия байт на спешните данни спрямо началото на полето данни.

Полето Checksum се изчислява върху целия TCP сегмент. При неговото изчисляване участват и някои полета от заглавната част на IP дейтаграмата, в която е опакован сегмента.

Полето Options на заглавната част на TCP сегмента е предназначено да предостави допълнителни възможности за управление на обмена, които не се осигуряват от останалите полета на заглавието. Най-важната възможност е указване на максимална дължина на сегмента. Всеки хост указва своята максимална дължина на сегмента и за осъществяване на обмена се приема по-малката от двете. Ако максималната дължина на сегмента не се договори се приема по подразбиране, че нейната стойност е 556 байта, което е допустимо за всички интернет хостове.

1. 
   Хостът (клиентът), който отваря връзката, изпраща SYN сегмент. В същия сегмент клиентът указва номера на порта на сървъра, с който трябва да се установи връзка, и началният номер x на потока байтове, който клиентът ще предаде към сървъра.
   
2. 
   Сървърът отговаря със собствен SYN сегмент, включващ началния номер y на неговия поток от байтове. В сегмента се съдържа потвърждение за SYN сегмента с номер на потвърждението, равен на x+1, тъй като за самия SYN сегмент е необходим един пореден номер.
   
3. 
   Клиентът трябва да потвърди получаването на този SYN сегмент от сървъра, като изпрати сегмент с потвърждаващ номер y+1.
   

При затварянето на връзката се има пред вид процедура, при която прекратяването на връзката става по начин, предотвратяващ загубата на информация. Тъй като TCP връзката е пълен дуплекс, тя се затваря, когато всеки от двата хоста прекрати своя изходящ информационен поток. Такъв тип затваряне на връзката се нарича още симетрично. Вариантът, при който даден хост прекратява информационния обмен и в двете посоки, ще наричаме асиметрично прекратяване на връзката.

За симетричното затваряне на една връзка е необходим обмен на 4 сегмента – по два за всяка посока. Даден хост може да инициира затваряне на своята част на връзката, когато изпрати сегмент с установен флаг FIN, след като приключи с предаването на данни. Хостът, получил този сегмент, може да продължи да изпраща данни при положение, че не е затворил връзката. Всеки хост, който получи FIN сегмент, изпраща обратно потвърждение с номер, равен на получения пореден номер + 1, тъй като FIN сегментът изисква един пореден номер.

За асиметрично затваряне се изпраща сегмент с вдигнат флаг RST. То е необходимо когато по връзката се получи некоректен сегмент.

Форматът на заглавната част на UDP дейтаграмата е следния:

Полетата Source port и Destination port съдържат номерата на портовете, идентифициращи еднозначно изпращащия и получаващия процес.

Полето UDP length задава в брой байтове дължината на цялата UDP дейтаграма – заглавна част + данни. Минималната му стойност е 8, което съответства на UDP дейтаграма, състояща се само от заглавна част.

Полето UDP checksum е контролна сума, която се изчислява върху цялата UDP дейтаграма, заедно с някои полето от IP дейтаграмата, в която тя е опакована.

Съществуват два начина за съхраняване на NETBIOS имената.

Първият начин е всички имена да се съхраняват в таблица в клиента. При търсене на име се проверява в таблицата дали то го има, ако го няма се пуска broadcast в съответния сегмент на мрежата. Този broadcast е на канално ниво и той не минава през маршрутизаторите, но минава през мостовете. С него се запитва дали някой има търсеното име в таблицата си.

Вторият начин е поддържане на специален NETBIOS именен сървър, в който се регистрират имената и към който се пращат заявки дали дадено име е регистрирано. Този именен сървър се нарича WINS. Такъв сървър се прави за всеки сегмент.

127.0.0.1 localhost

, но може да се съдържат и други записи, например

100. 
     rhino
     

Маркерът #PRE означава, че съответния запис още със стартирането на системата ще се зареди в кеша, което означава че съответните имена ще са първите, които се проверяват при търсене.

Файлът PROTOCOL съдържа описание на протоколите, техните имена и идентификатори:

ip 0 IP

udp 17 UDP

rdp 27 RDP

Файлът SERVICES описва well-known портовете:

www 80

ftp 21

По отношение на NETBIOS търсенето имаме следните клиенти:

• 
  B-node – търсят само чрез broadcast;
  
• 
  P-node – търсят само в именния сървър WINS;
  
• 
  M-node – първо търсят с broadcast, при неуспех в WINS;
  
• 
  H-node – първо търсят в WINS, при неуспех с broadcast.
  

Стандартният тип клиент е H-node. При него, ако името го няма в кеша, то се търси в именния сървър WINS. Процедурата е следната: първо се пуска broadcast “има ли именен сървър”. Именният сървър трябва да се обади и да си каже IP адреса.

H-node записва този адрес в кеша си. След това праща заявка към сървъра дали има регистрирано търсеното име. Ако го има, сървърът връща неговия адрес, ако го няма се пуска broadcast “има ли някой, който да се обади за търсеното име”. Всеки компютър си пази таблица на NETBIOS имената. Ако след тези последователни допитвания името не се намери се проверява във файла LMHOSTS, ако и там го няма се счита, че името е невалидно.
NETBIOS е локална система за именуване и позволява динамично регистриране и изтриване на имена, за разлика от DNS.

Ново NETBIOS име се създава по следния начин:

1. 
   Откриваме именния сървър.
   
2. 
   Подаваме заявка към сървъра за регистриране на име. Сървърът запомня името и адреса на притежателя му.
   
3. 
   По някое време притежателят може да изтрие името от сървъра.
   

DNS (domain name system) разчита на раздробяването на имената на домейни. DNS се създава за нуждите на Internet, където имената са много и имат подструктура. В Internet обектите образуват йерархично дървовидно пространство. Създават се области от имена, като имената могат да са имена на други подобласти. Домейните представляват области от имена. Домейните са от първо, второ и трето ниво. Няма пречки да има домейни от четвърто ниво, но те почти не се използват.

Основният домейн е така нареченият root домейн. Той няма име и е един единствен. Под него се нареждат домейните от първо ниво, т.е. в root домейна стоят имената на всички домейни от първо ниво. Домейните от първо ниво исторически са получили фиксирани имена:

- com – комерсиални организации

- net – мрежови организации

- org – некомерсиални организации

- gov – правителствени организации

В началото всички те са в САЩ, но после в тях влизат още много имена на обекти извън САЩ, те нарастват твърде много и затова се въвежда друга голяма група от домейни на първо ниво, свързани с географското разположение по държави – uk, de, bg и др.

Цялостното име, което включва домейните и обекта се нарича URL (uniform resource locator). Пример за URL е

http://www.fmi.uni-sofia.bg

В това URL bg е името на домейна от първо ниво, uni-sofia е името на поддомейна на bg от второ ниво, fmi е името на домейна от трето ниво, www е web-сървъра от домейна fmi, http е името на протокола по който клиента се свързва към съответния обект.

Колкото са точките в едно URL, толковата са нивата на домейните без да се брои root.

DNS е йерархична именна система с три компонента – именно пространство (как се изграждат имената), resolver-и и именни сървъри (name servers).

Resolver-ите са абонатите в Internet, които знаят URL и искат да получат съответния IP адрес. Процесът на преобразуване се нарича resolving. Той се извършва от DNS протокола.

Именните сървъри са основните обекти на DNS протокола. Те съхраняват имената на домейните. Те са физически устройства, за разлика от домейните, които са логически компоненти на именната система. Класификацията на именните сървъри е следната:

• 
  първични именни сървъри;
  
• 
  вторични именни сървъри;
  
• 
  главни именни сървъри;
  
• 
  кеш именни сървъри.
  

Вторичните именни сървъри съхраняват копие на зонална информация, която се намир в първични сървъри. Със зонален трансфер първичните сървъри прехвърлят зонална информация във вторични сървъри. Първичните сървъри съдържат оригинала на зоналната информация, ако се прави промяна тя става в тях. Вторичните сървъри съдържат копие на тази информация – ако нещо се случи с първичния сървър да не се изгуби информация, също и за разпределение на натоварването. Един първичен сървър може да има няколко вторични сървъра.

Главните именни сървъри прехвърлят своите зонални файлове към вторични сървъри. Обикновено първичните сървъри са главни, но може вторичен сървър да е главен за друг вторичен сървър – това се прави с цел първичният сървър да не се грижи за обновяването на съдържанието на всички вторични сървъри.

Кеш именните сървъри нямат зонални файлове, разположени в локалното дисково пространство. Те са посредници – през тях минават заявки за resolving и ги препращат към първични и вторични сървъри. Кеш сървърът временно помни отговорите на преминалите през него заявки. Ако времето на отговора не е изтекло и в кеш сървъра дойде същото допитване, той връща запаметения отговор и не препраща заявката. Обикновено кеш сървъри се слагат пред защитни стени (firewall), които отделят вътрешна за предприятие мрежа от свободния Internet.

Когато към агента се подаде URL за resolve-ане той първо проверява дали отговора не стои в кеша. Ако това не е така, той изпраща заявка до DNS сървър. DNS сървърът може да формира три типа заявки – рекурсивна, итеративна или инверсна.

При рекурсивна заявка DNS сървърът има прилежащ към него друг именен сървър. Този именен сървър също може да има кеш, който евентуално да съдържа отговора. Именният сървър може да съдържа отговора в своите зонални файлове. Ако и двата случая не са налице, но за именния сървър има конфигуриран друг именен сървър, той ще изпрати заявката към него и т.н.

Рекурсивни заявки се формират в защитени области, където има защитна стена (firewall). Чрез тях се изнасят заявки за resolve-ане извън защитената област. В един момент някой именен сървър по описаната верига може да направи рекурсивната заявка в итеративна.

При итеративната заявка именният сървър е в свободното Internet пространство. Той започва да раздробява съответното URL и постъпково, съгласно структурата на URL започва resolve-ането. Първо се изпраща заявка към root-сървъра, като се иска адреса на сървъра, който отговаря за домейна от първо ниво, който участва в URL-то. След това се праща заявка към сървъра от първо ниво за адреса на сървъра, който отговаря за домейна от второ ниво, участващ в URL-то и т.н.

Например, нека имаме URL-то www.fmi.uni-sofia.bg

Първо запитваме root-сървъра за адреса на сървъра, отговарящ за домейна bg. След това запитваме сървъра, отговарящ за домейна bg за адреса на сървъра, отговарящ за домейна uni-sofia. След това запитваме сървъра, отговарящ за домейна uni-sofia за адреса на сървъра, отговарящ за домейна fmi. След това запитваме сървъра, отговарящ за домейна fmi за адреса на обекта www.

Именният сървър, който прави итеративна заявка знае поне адреса на root-сървъра.

След като една рекурсивна заявка е превърната в итеративна и итеративната заявка е изпълнена, полученият отговор се връща обратно по веригата на рекурсивната заявка през защитната стена (ако има такава) и се стига обратно до resolve-ра, който слага получения отговор в кеша си.

Инверсните заявки служат за обратен resolve – по IP адрес да се получи URL. В именните сървъри има специални записи, предназначени за инверсни заявки. Инверсните заявки са по-трудни от правите – докато при правата заявка, когато премине в итеративна се знае пътя в дървото, по който трябва да се спуснем, при инверсната трябва да се прави търсене по всички мрежи.

На клиентската машина агентът върви на произволен порт с номер по-голям от 1024.

Първите 12 байта са заглавието на DNS-съобщението.

Полето Parameters има следния формат:

Полето QR е 0 при запитване и 1 при отговор.

Полето Op code задава типа на заявката:

тип 0 – стандартна заявка

тип 1 – инверсна заявка

тип 2 – запитване за статус на сървъра

тип 5 – съобщение за обновяване

Полето AA е 1, когато заявката е отговор и сървърът, отговорил на заявката е упълномощен за съответното име на домейн.

Полето TC е 1, когато съобщението е прекалено дълго и трябва да се ореже.

Полето RD е 1, когато се изисква заявката да е рекурсивна.

Полето RA е 1, когато сървът е готов за рекурсия.

Полето zero не се използва.

Полето Rcode съдържа код на отговора:

код 0 – в операцията няма грешка

код 1 – грешка на формата

код 2 – грешка на сървъра

код 3 – грешка в името (името не може да бъде намерено)

код 4 – неприложима заявка (сървърът не поддържа такива заявки)

код 5 – отказана заявка (по съображения за сигурност)

Полето QDCount съдържа броя на записите в частта с въпроси (Question Section).

Полето ANCount съдържа броя на ресурсните записи, върнати в частта за отговори (Answer Section).

Полето NSCount съдържа броя на записите за именни сървъри в частта за упълномощени сървъри (Authority Section).

Полето ARCount съдържа броя на записите в частта за допълнения (Additional Information Section).

Един въпрос от частта Question Section съдържа полетата:

QNAME – поле за име с променлива дължина, съдържа в началото си собствената дължина

QTYPE – поле за тип на въпроса

QCLASS – поле за клас на въпроса

Останалите видове записи в другите три секции имат аналогични полета като въпросите, но освен това:

TTL – продължителност на живота на записа

RDLENGTH – 16-битов брояч за дължина на данните

RDATA – данни, зависещи от типа на записа
В класическия DNS ресурсните файлове се формират ръчно. Конфигурирането на един DNS сървър означава правенето на тези файлове или вземането им отнякъде. В класическия DNS файловете са 4: boot, cache, forward-lookup, reverse-lookup.

Файлът boot се нарича още NAMED.boot и е характерен за системите с UNIX. При системите с WINDOWS файлът го няма, а информацията е пръсната в системните регистри. Файлът съдържа:

• 
  директорията, където се намират останалите конфигурационни файлове;
  
• 
  името на cache-файла, който съдържа DNS сървърите на домейните от първо ниво;
  
• 
  името на файла, който съдържа ресурсните записи на всички домейни към сървъра;
  
• 
  имената на всички домейни от второ ниво, за които е отговорен сървъра;
  
• 
  адресите на вторичните сървъри, за които сървъра е главен.
  

Файлът cache съдържа адресите на всички сървъри, които са главни за домейните от първо ниво. Този файл ръчно се тегли от сайта на администрацията на DNS поне веднъж седмично. Това е необходимо, тъй като няма сървър за root домейна. С други думи, root домейна е логическа единица, която я няма физически. Ако физически имаше root сървър, към него щеше да има прекалено много обръщения и щеше да е труден за реализация. Затова информацията, която би трябвало да присъства в хипотетичен root сървър се записва във файл, който се разпространява по целия свят.

Файлът forward-lookup съдържа локална конфигурационна информация за домейните, за които сървърът отговаря.

Основен е SOA-записът, който определя кой е първичният сървър и как се обработват данните към него. Има следния формат:

@ IN SOA

source_host е пълното име на компютъра, който съхранява главното копие на информацията + серия от параметри, свързани с това как се работи с този компютър.

Вторият тип записи е NS-записът, който съдържа информация кои DNS сървъри са отговорни за този домейн. Имат следния формат:

IN NS

е име на домейн, а е име на сървър, който поддържа домейна.

Третият тип записи е MX-записът, чрез който се указва име на хост, готов да приема електронна поща в рамките на домейн.

Неговият формат е следния:

IN MX