Root сървъри
Кеширащи (кеш) сървъри
Този тип сървър се различава от обсъжданите по-рано по това, че този тип сървър не е авторитетен за нито една зона.
Сървърите от този тип се използват за организиране на централизирано кеширане на съвпадения между имена на домейни и IP адреси. Идеята за организиране на кеширащ сървър не е да се търси съвпадение между име на домейн и IP адрес в мрежата, а да се натрупват във вашия локален кеш и да се обслужват заявки за relover, използвайки данните от кеша.
Кеш сървърът не поддържа описания на зони и съответно не изпраща авторитетни отговори до преобразуватели:
MCBC> nslookup
> тип задаване = всеки
> www.w3.org
Сървър: udc.nwudc.lan
Адрес: 192.168.25.25
Неавторитетен отговор:
www.w3.org интернет адрес = 193.51.208.69
www.w3.org интернет адрес = 128.30.52.31
www.w3.org интернет адрес = 128.30.52.45
www.w3.org интернет адрес = 128.30.52.46
www.w3.org интернет адрес = 128.30.52.47
www.w3.org интернет адрес = 128.30.52.54
w3.org сървър за имена = ns3.w3.org
w3.org сървър за имена = ns1.w3.org
w3.org сървър за имена = ns2.w3.org
Горното е типичен отговор от кеширащ сървър на заявка nslookup за адреса "www.w3.org". Ако сървърът беше авторитетен, тогава редът „Неавторитетен отговор“ нямаше да бъде в отговора.
Тяхното място при получаване на отговор на заявка към системата за имена на домейни е ключово. С един от основните сървъри локалният сървър за имена на домейн се свързва, ако не намери съвпадение между името на домейна и IP адреса в своята зона на отговорност или в своя кеш.
DNS има две основни функции. Той позволява на клиентските компютри да отправят запитвания към DNS сървъра за IP адреса или името на хост в мрежата и също така позволява обмен на информация между бази данни на DNS сървъри. Този протокол използва стандартен формат заявка-отговор, при който клиентът изпраща пакет заявка, а сървърът отговаря или с пакет с информация, извлечена от базата данни, или със съобщение за грешка, което показва защо заявката е била отказана. В работата си този протокол използва порт 53 и добре познати протоколи - TCP или UDP. Освен това напоследък UDP се превърна в по-разпространен метод за транспортиране на пакети през Интернет. DNS пакетът се състои от пет полета: заглавие, въпрос, отговор, правомощия и поле за допълнителна информация. Фигура 5.7 показва общата структура на DNS пакет.
Ориз. 5.7 Описание на пакета DNS протокол
Заглавно поле
Полето на заглавката съдържа информация за пакета и неговото предназначение. Той дава общо описание на пакета (пакет с заявка или пакет с отговор) и посочва количеството данни, съдържащи се във всяко поле за данни на пакета. Описание на заглавката е дадено в Таблица 5.1.
Идентификационните битове са уникалният 16-битов идентификационен номер на пакета заявка. Пакетът с отговор, генериран от сървъра, също използва този идентификационен номер, така че клиентът да може да съпостави отговора на сървъра на неговата заявка. QR битът обозначава типа на пакета (пакет с заявка - 0, пакет с отговор - 1). Полето OPCODE дефинира вида на заявката - стандартна (0), обратна (1) или заявка за състояние на сървъра (2).
Таблица 5.1. Поле за заглавка на DNS пакет
| малко | Описание | малко | Описание |
| 0-15 | документ за самоличност | РА | |
| QR | 25-27 | З | |
| 17-20 | ОПКОД | 28-31 | RCODE |
| AA | 32-47 | QDCOUNT | |
| TC | 48-63 | АКАНТ | |
| RD | 64-79 | NSCOUNT | |
| 80-95 | ARCOUNT |
Следващите четири бита дефинират различни параметри на пакета. Битът AA се задава, когато отговорът е авторитетен (данните идват директно от DNS сървъра, отговорен за зоната). Неавторитетните отговори могат да идват от DNS сървъри, които имат кеширана информация за оригиналните записи от предишни заявки. Тази информация се счита за неоторизирана, тъй като е вероятно информацията да се е променила след последния достъп до сървъра. Битът TC се задава, когато искате да съкратите данните в пакет до форма, подходяща за предаване по мрежата. Това е напълно възможно при използване на UDP протокол, според който размерът на пакета не трябва да надвишава 512 байта. Битът RD се включва, когато клиентът желае да отправя рекурсивни заявки към DNS сървъра на текуща основа. Ако този бит е зададен, DNS сървърът ще запитва други DNS сървъри, докато не получи отговор. Ако този бит не е зададен, тогава DNS сървърът ще върне всяка информация, която има при поискване. Битът RA е настроен да уведомява клиента за възможността за рекурсивна заявка към този сървър. Z битовете в момента не се използват и са запазени за бъдещето.
RCODE битовете се използват само в пакети за отговор. Те показват състоянието на отговора - няма грешки (0), грешки в пакета заявка (1), вътрешни грешки са попречили на сървъра да обработи заявката (2), името, посочено в заявката, не съществува (3), този тип заявката не се поддържа от сървъра (4) и сървърът отказва да обработи заявката (5).
Другите четири параметъра на заглавката са 16-битови числа и се използват като броячи. Те се използват за проследяване на броя на оригиналните записи, върнати в пакета. QDCOUNT показва броя на заявките (в пакета могат да бъдат включени повече от една заявка). ANCOUNT е броят на оригиналните записи, включени в отговора. NSCOUNT е броят на оригиналните записи на авторитетен сървър за имена, а ARCOUNT е броят на записите в полето за допълнителна информация.
Поле за въпроси
Полето за въпроси съдържа заявките, на които клиентът иска да отговори от DNS сървъра. Един DNS пакет може да съдържа множество заявки. Броят на заявките в пакета се определя от параметъра QDCOUNT от полето на заглавката. Полето за въпроси се състои от три части: списък с имена на домейни за конвертиране; полета за типовете записи, които клиентът желае да получи в отговора, и параметъра на класа на заявката. Списъкът с имена на домейни за конвертиране е списък с имена, за които клиентът иска да получи IP адреси. За формиране на списък с имена се използва специален формат. Всяко име се предшества от еднобайтова стойност, която определя дължината на името. Краят на списъка е обозначен с име с нулева дължина. Текстовата част е последвана от двубайтов QTYPE запис. Той определя в каква форма клиентът желае да получава информация за наличните домейни. Тези стойности са абсолютно същите като оригиналните типове DNS записи. Например, за да намерите пощенски сървър за конкретен домейн, трябва да използвате типа MX запис. И накрая, последният параметър в полето за въпроси е QCLASS. Той дефинира класа на заявката, който в нашия случай винаги ще бъде IN за Интернет.
Полета за отговор, правомощия и допълнителна информация
Следващите три полета в DNS пакета са в същия формат. Всеки от тях може да връща данни във формата на оригиналния запис на DNS базата данни. Отговорите съдържат оригиналните DNS записи, налични на сървъра към момента на заявката на клиента. Ако битът на заглавката AA не е зададен, тогава секцията Authority Servers ще изброи DNS сървърите, до които клиентът има достъп за авторитетни отговори. И така, авторитетните отговори идват от DNS сървърите, които отговарят за зоните, съдържащи исканото име на хост. Всички други отговори се считат за неоторизирани, тъй като информацията, която съдържат, е взета от кеша на DNS сървъра и може да е остаряла. Полето за допълнителна информация съдържа всички оригинални записи, които се възприемат от DNS сървъра като подходящи за тази заявка.
Например, ако поискате информация за MX записи в домейн, тогава информация за MX записи ще бъде получена в полето за отговор и A записи за сървърите, посочени в полето за отговор в полето за допълнителна информация. По този начин, с една DNS заявка, можете да разберете както името, така и IP адреса на пощенския сървър за домейна.
Форматът за представяне на оригиналния запис в DNS пакета е показан в Таблица 5.2.
Таблица 5.2. Формати на отговор, правомощия и полета за допълнителна информация
В полето за отговор стойностите на RDATA съответстват на резултатите от обработката на заявката. MX записите не се представят в текстов формат. Стойността на приоритета се въвежда заедно с името на пощенския сървър.
DNS има две основни функции. Той позволява на клиентските компютри да отправят запитвания към DNS сървъра за IP адреса или името на хост в мрежата и също така позволява обмен на информация между бази данни на DNS сървъри. Този протокол използва стандартен формат заявка-отговор, при който клиентът изпраща пакет с заявка, а сървърът отговаря или с пакет с информация, извлечена от базата данни, или със съобщение за грешка, което посочва причината за отказа да обработи заявката. В работата си този протокол използва порт 53 и добре познати протоколи - TCP или UDP. Освен това напоследък UDP се превърна в по-разпространен метод за транспортиране на пакети през Интернет. DNS пакетът се състои от пет полета: заглавие, въпрос, отговор, правомощия и поле за допълнителна информация. На ориз. 4.5показва общата структура на DNS пакет.
Ориз. 4.5.
Заглавно поле
Полето на заглавката съдържа информация за пакета и неговото предназначение. Той дава общо описание на пакета (пакет с заявка или пакет с отговор) и посочва количеството данни, съдържащи се във всяко поле за данни на пакета. Заглавие Описаниепредадено раздел. 4.3.
| малко | Описание |
|---|---|
| 0-15 | документ за самоличност |
| 16 | QR |
| 17-20 | ОПКОД |
| 21 | AA |
| 22 | TC |
| 23 | RD |
| 24 | РА |
| 25-27 | З |
| 28-31 | RCODE |
| 32-47 | QDCOUNT |
| 48-63 | АКАНТ |
| 64-79 | NSCOUNT |
| 80-95 | ARCOUNT |
Идентификационните битове са уникалният 16-битов идентификационен номер на пакета заявка. Пакетът с отговор, генериран от сървъра, също използва този идентификационен номер, така че клиентът да може да съпостави отговора на сървъра на неговата заявка. QR битът обозначава типа на пакета (пакет с заявка - 0, пакет с отговор - 1). Поле ОПКОДопределя вида на заявката - стандартна (0), обратна (1) или заявка за статус на сървъра (2).
Следващите четири бита дефинират различни параметри на пакета. Битът AA се задава, когато отговорът е авторитетен (данните идват директно от DNS сървъра, отговорен за зоната). Неавторитетните отговори могат да идват от DNS сървъри, които имат кеширана информация за оригиналните записи от предишни заявки. Тази информация се счита за неоторизирана, тъй като е вероятно информацията да се е променила след последния достъп до сървъра. Битът TC се задава, когато искате да съкратите данните в пакет до форма, подходяща за предаване по мрежата. Това е напълно възможно при използване на UDP протокол, според който размерът на пакета не трябва да надвишава 512 байта. Битът RD се включва, когато клиентът желае да отправя рекурсивни заявки към DNS сървъра на текуща основа. Ако този бит е зададен, DNS сървърът ще запитва други DNS сървъри, докато не получи отговор. Ако този бит не е зададен, тогава DNS сървърът ще върне всяка информация, която има при поискване. Битът RA е настроен да уведоми клиента за възможността рекурсивна заявкакъм този сървър. Z битовете в момента не се използват и са запазени за бъдещето.
RCODE битовете се използват само в пакети за отговор. Те показват състоянието на отговора - няма грешки (0), грешки в пакета заявка (1), вътрешни грешки са попречили на сървъра да обработи заявката (2), името, посочено в заявката, не съществува (3), този тип заявката не се поддържа от сървъра (4) и сървърът отказва да обработи заявката (5).
Другите четири параметъра на заглавката са 16-битови числа и се използват като броячи. Те се използват за проследяване на броя на оригиналните записи, върнати в пакета. QDCOUNT показва броя на заявките (в пакета могат да бъдат включени повече от една заявка). ANCOUNT е броят на оригиналните записи, включени в отговора. NSCOUNT е броят на оригиналните записи на авторитетен сървър за имена, а ARCOUNT е броят на записите в полето за допълнителна информация.
Поле за въпроси
Полето за въпроси съдържа заявките, на които клиентът иска да отговори от DNS сървъра. Един DNS пакет може да съдържа множество заявки. Броят на заявките в пакета се определя от параметъра QDCOUNT от полето на заглавката. Полето за въпроси се състои от три части: списък с имена на домейни за конвертиране; полета за типовете записи, които клиентът желае да получи в отговора, и параметъра на класа на заявката. Списъкът с имена на домейни е списък с имена, за които клиентът иска да получи IP адреси. За формиране на списъка с имена се използва специален формат. Всяко име се предшества от еднобайтова стойност, която определя дължината на името. Краят на списъка е обозначен с име с нулева дължина. Текстовата част е последвана от двубайтов QTYPE запис. Той определя в каква форма клиентът желае да получава информация за наличните домейни. Тези стойности са абсолютно същите като оригиналните типове DNS записи. Например, за да намерите пощенски сървър за конкретен домейн, ще използвате типа MX запис. И накрая, последният параметър в полето за въпроси е QCLASS. Той дефинира класа на заявката, който в нашия случай винаги ще бъде IN за Интернет.
В този раздел се натъкнахме на концепциите за DNS заявка и DNS отговор. Заявката и отговорът са единствените два типа съобщения, използвани от DNS протокола. Форматите на тези съобщения са еднакви и са показани на фиг. 2.17. Следва описание на структурата на DNS съобщение.
□ Първите 12 байта съставляват заглавната секция, която се състои от няколко полета. Първото поле е 16-битово число, което идентифицира заявката. Идентификаторът на заявката се копира в съобщението за отговор, което позволява на клиента да съпостави отговорите със заявките. Полето флагове включва еднобитов флаг за заявка/отговор и определя дали съобщението е заявка (0) или отговор (1). Еднобитовият флаг за оторизация се задава за съобщението за отговор, ако сървърът за имена е авторитетен за исканото име.
Флагът за предпочитание за еднобитова рекурсия се задава, когато клиентът (хост или сървър на имена) трябва да инструктира сървъра на имена да приложи рекурсивна заявка при липса на IP адрес. Еднобитовият флаг за наличност на рекурсия се задава в съобщението за отговор, ако сървърът за имена поддържа механизъм за рекурсивна заявка. Заглавката съдържа също четири секции за „типове“ на данни.
□ Разделът с въпроси съдържа информация за заявката и включва поле за име, което съдържа името на искания хост и поле за тип, което указва съдържанието на отговора, като адрес на хост (тип A) или името на пощенския сървър (тип MX).
□ Разделът за отговор присъства в съобщенията за отговор и съдържа необходимите записи за ресурси. Всеки RR запис включва полета тип с една от стойностите A, NS, CNAME или MX, стойност и TTL. Тъй като име на хост може да бъде съпоставено с множество IP адреси (например поради дублирането на уеб сървъри, споменати в тази глава), секцията за отговор може също да съдържа множество записи.
□ Разделът за оторизация включва записи за други авторитетни сървъри.
□ Допълнителен раздел съдържа други „полезни“ записи. Например, полето за отговор за заявка за MX запис може да съдържа запис, съхраняващ каноничното име на пощенския сървър, а допълнителен раздел може да съдържа A запис с IP адреса на пощенския сървър.
Горната информация беше свързана основно с извличане на записи от DNS базата данни. Все още обаче остава отворен въпросът как се въвеждат нови данни в базата данни. Доскоро базата данни се актуализираше статично, например чрез ръчно въвеждане на данни в конфигурационния файл от системния администратор. Наскоро параметърът UPDATE беше добавен към DNS протокола, който ви позволява да добавяте и премахвате записи на база данни с помощта на DNS съобщения.
Премиум DNS- пакет от услуги, с които можете по-гъвкаво да управлявате домейн зоната, както и да преглеждате историята на промените в DNS записи.
Цялата информация за домейните, за които е свързан Премиум DNS, се дублира на нашите DNS сървъри и се съхранява в надеждни центрове за данни. Сървърите за "безопасност" са свързани в мрежа Anycast... Това гарантира безпроблемната им работа. Ако един от сървърите се повреди, останалите продължават да работят и осигуряват непрекъснато време на работана вашите сайтове и услуги в домейна.
Ако вашият домейн има хостинг DNS сървъри (ns1.hosting..hosting..
Пакет от услуги Премиум DNSдайте шанс:
създаване на шаблони за DNS зони;
експортиране на DNS зони;
импортиране на DNS зони;
отмяна на всяка нежелана промяна в DNS записи и възстановяване на настройките на зоната, на които сайтът функционира без грешка;
използвайте услугата за защита срещу кибератаки;
намалете времето за актуализиране на зоната след всяка операция 10 минути(при стандартни условия актуализацията отнема поне 1 час);
за повишаване на отказоустойчивостта на системата и осигуряване на непрекъсната работа на интернет ресурсите на сайта на клиента.
Кой се възползва от Premium DNS?
Пакетът от услуги ще е подходящ клиенти на дребнос голям брой домейни в един акаунт, както и партньори, които се занимават с препродажба на услуги.
Как да поръчам Premium DNS?
Готов! Поръчахте Premium DNS услуга.
Премиум управление на DNS услуги
Как да приложите създадения шаблон за зона?
Отидете в раздела „Шаблони за зона“ и кликнете върху необходимия шаблон Прилагане на шаблон:
Готов! Създаденият шаблон за зона се прилага.
Експорт и импорт на домейн зона
Отидете в раздела Управление на зоната. За да импортирате или експортирате домейн зона, щракнете Внос износи изберете необходимото действие:
Зоната се експортира във формата BIND... Възможно е също така да импортирате зона само от файл с този формат BIND.
Готов! Шаблонът се експортира/импортира.
Как да променя своя Premium DNS план?
Няма директна промяна от Premium DNS „за домейн“ към Premium DNS „за акаунт“.