Ручне конфігурування. Windows.

У MS Windows адреса DNS-сервера, ім'я домену та ім'я хоста встановлюються в налаштуваннях мережі (вибрати протокол TCP/IP, перейти до його властивостей та вибрати закладку DNS).

За кожну зону DNS відповідає щонайменше двох серверів. решта - вторинними, вторинними. Первинний сервер містить оригінальні файли бази даних DNS для своєї зони. Вторинні сервери отримують ці дані по мережі від первинного сервера і періодично запитують первинний сервер щодо оновлення даних (ознакою оновлення даних служить збільшення серійного номера в запису SOA - див. нижче). Якщо дані на первинному сервері оновлені, вторинний сервер запитує "передачу зони" ("zone transfer")- тобто. бази даних необхідної зони. Передача зони відбувається за допомогою протоколу TCP, порт 53 (на відміну від запитів, які надсилаються на UDP/53).

Зміни до бази даних DNS можуть бути внесені лише на первинному сервері. З точки зору обслуговування клієнтських запитів первинні та вторинні сервери ідентичні, всі вони видають авторитативнівідповіді. Рекомендується, щоб первинні та вторинні сервери знаходилися в різних мережах - для збільшення надійності обробки запитів на випадок, якщо мережа одного із серверів стає недоступною. Сервери DNS не повинні перебувати в домені, за який вони відповідають.

Примітка. Вторинний сервер необов'язково отримує дані безпосередньо з первинного сервера; джерелом даних може бути й інший вторинний сервер. У будь-якому випадку сервер-джерело даних для цього вторинного сервера називається "головним" ("master"). Далі у цьому розділі вважається, що вторинний сервер отримує дані зони безпосередньо з первинного сервера.

23.2. Вимога СНиП до обладнання комп'ютерних мереж
Вимога до СКС
Документи:
Проектовані та/або експлуатовані СКС мають бути виконані відповідно до положень наступних нормативних документів:

- ГОСТ Р 53245-2008 Інформаційні технології. Системи кабельні структуровані. Монтаж основних вузлів системи. Методи випробувань;

- ГОСТ Р 53246-2008 Інформаційні технології. Системи кабельні структуровані. Проектування основних вузлів системи;

– ISO/IEC 11801:2010 Information technology – Generic cabling for customer premises – Amendment 2 (Інформаційні технології. Структурована кабельна система для приміщень замовників. 2-ге видання);

– ISO/IEC 14763-1:1999 Information technology – Implementation and operation of customer premises cabling – Part 1: Administration (Інформаційні технології. Введення та функціонування кабельної системи у приміщенні користувача. Частина 1. Адміністрування);

– ISO/IEC 14763-2:2000 Information technology. Implementation and operation of customer premises cabling – Part 2: Planning and installation (Інформаційні технології. Введення та функціонування кабельної системи у приміщенні користувача. Частина 2. Планування та встановлення);

– ISO/IEC 14763-3:2006 Information technology. Implementation and operation of customer premises cabling – Part 3: Testing of optical fibre cabling (Інформаційні технології. Введення та функціонування кабельної системи у приміщенні користувача. Частина 3. Випробування волоконно-оптичної системи).

Вимога до структури СКС:
структура СКС повинна включати магістральну (вертикальну) та розподільну (горизонтальну) кабельні складові. При цьому магістральна телефонна кабельна складова СКС рекомендується виконувати багатопарним кабелем категорії не нижче 5е. Основні характеристики кабелю категорії 5е повинні бути не гіршими:
- Ширина смуги пропускання сигналу - 100 МГц;
– хвильовий опір на 100 МГц – 100 ± 15 Ом;
- Швидкість поширення сигналу (NVP) - 68%;
- Опір постійному струму - ≤ 10 Ом/100 м;
– ємність кручений пари - ≤ 56 нФ/км;
– тимчасовий перекіс затримки (delay skew) на 100 МГц – 45 нс/100 м;
- Затримка поширення сигналу (propagation delay) на 100 МГц - 536 нс/100 м.

Магістральну кабельну складову СКС для активного обладнання ЛОМ рекомендується виконувати багатомодовим або одномодовим оптичним кабелем, відповідно:

– не гірше ОМ3 із шириною смуги пропускання 2000 МГц×км для ефективної пропускної спроможності моди (ЕМВ) на 850 нм, зі структурою кабелю 50/125 мкм для світлових хвиль завдовжки 850 нм, 1300 нм;

- не гірше OS1 зі структурою кабелю 9(8)/125 мкм для світлових хвиль завдовжки 1310 нм, 1550 нм.
Для невеликих мереж (до 120 портів, див. п. 6.4.2) з розміщенням комутаторів ЛОМ на об'єкті та дотриманням довжин магістралей між їхніми портами не більше 90 м допускається використовувати як магістральний складник СКС для активного обладнання ЛВС мідний UTP кабель категорії, що забезпечує необхідну пропускну спроможність магістрального ділянки мережі.
Оптичні магістральні канали повинні переважно виконуватися з резервуванням за схемою, що враховує організаційну структуру ЛОМ та виключає єдину точку відмови магістральної мережі. Кількість оптичних волокон у магістральних кабелях має бути не менше ніж 4.

При проектуванні оптичної магістральної складової СКС повинна забезпечуватися сумісність із системою ЛОМ об'єкта в частині оптичних модулів активного обладнання, що використовуються в них оптичних роз'ємів, типу оптичного волокна

При прокладанні магістральних кабелів між будівлями одного об'єкта повинні максимально використовуватися відповідні каналоутворюючі каналізації для слаботочних систем, що існують на об'єкті. За відсутності останніх, прокладання магістральних кабелів має виконуватися в ґрунт. Організація повітряних ліній зв'язку заборонена.

У загальному випадку структура СКС повинна включати головний крос, що встановлюється переважно на перших поверхах об'єкта, та поверхові комутаційні центри (далі - ЕКЦ), що встановлюються на поверхах будівлі або на місцях концентрації великої кількості користувачів. Головний крос може бути поєднаний з ЕКЦ.

Головний крос СКС повинен встановлюватись у приміщенні апаратної (далі – ПА), ЕКЦ – в окремо виділених кімнатах на поверхах. У разі відсутності можливості виділення окремих приміщень для ЕКЦ, допустиме їх розміщення в коридорах, технологічних або офісних приміщеннях об'єкта. При цьому телекомунікаційна шафа має бути забезпечена замком. Обладнання головного кросу, ЕКЦ повинне встановлюватися у стандартних 19-дюймових шафах для підлогового або навісного виконання, висота яких повинна визначатися проектом.

На робочих місцях повинні встановлюватись дві інформаційні розетки RJ‑45 (якщо в технічному завданні не визначено інше) у короб в одному блоці з електричними розетками. Допустимо за погодженням з кінцевим користувачем в окремих місцях встановлювати інформаційні розетки приховано в стіну, накладні, в лючках або сервісних стійках як спільно з електричними розетками, так і окремо.

Кількість встановлюваних портів СКС на об'єктах повинна враховувати перспективи розвитку установ щодо збільшення кількості співробітників, при цьому загальна кількість портів повинна визначатися за погодженням з кінцевим користувачем.

Прокладка магістральних кабелів СКС повинна проводитись в окремих металевих лотках, там, де це можливо, з максимальним використанням простору за стельою, стояків будівлі. У межах ПА кабельна структура повинна виконуватися у просторі фальшпідлог або, за відсутності останніх, у металевих лотках над телекомунікаційними шафами. Лотки повинні бути заземлені на шину захисного заземлення відповідно до вимог ПУЕ та вимог робочої документації.

Прокладка кабелів горизонтальної складової СКС повинна виконуватись у настінних коробах. Частина горизонтальної кабельної складової, аналогічно магістральної, може бути прокладена в лотках, у тому числі існуючих на об'єкті, за наявності достатнього вільного місця в них. Допустимо в окремих місцях об'єктів прокладати кабелі горизонтальної складової СКС за погодженням з кінцевим користувачем приховано в стіну, підлогу з використанням каналоутворюючих пластикових труб. При суміщенні в одному коробі горизонтальної складової СКС та електричного кабелю короб повинен містити дві секції розділені перегородкою.

Розміщення інформаційних розеток має виконуватися відповідно до планів розміщення робочих місць, що надаються кінцевим користувачем. Розміщення інформаційних розеток, призначених для підключення на об'єкті системи бездротового доступу (Wi-Fi), інженерних систем, систем безпеки (диспетчеризація, відеоспостереження, система контролю та управління доступом (далі - СКУД) і т.д.), які використовують СКС як середовище передачі , має виконуватися відповідно до технічних умов, що видаються проектувальниками цих систем.

23.3. Вимога СНиП до обладнання приміщень для проектування комп'ютерних мереж
Вимоги до оснащення апаратних приміщень

Оснащення ПА повинно виконуватись відповідно до вимог будівельних норм СН512.

ПА має розміщуватися в капітальній будівлі на поверхах вище цокольного, вдалині від приміщень з мокрими та запорошеними технологічними процесами (туалети, кухні) та місць розміщення потужних електроустановок (ліфти, генераторні установки). При виборі приміщення нижче цокольного поверху повинні бути вжиті заходи для гідроізоляції ПА. У ПА не допускається наявність трубних транзитних (водопостачання, теплотраси) і кабельних проводок.

Розміри ПА повинні визначатися проектними вимогами щодо розміщення обладнання, технологічними проходами для проведення монтажних, ремонтних та профілактичних робіт, а також вимогами системи кондиціювання щодо необхідних умов розміщення обладнання з метою більш ефективної підтримки необхідних кліматичних норм.

ПА повинні оснащуватися системами кондиціювання для підтримки таких кліматичних параметрів:

З метою збереження обладнання у разі виникнення пожежі в ПА повинні бути встановлені автоматичні установки газового пожежогасіння

Підлога ПА має бути покрита антистатичним матеріалом - лінолеумом або іншим, що не накопичує статичної електрики, опором не менше 106 Ом. Допустиме розподілене і зосереджене навантаження на підлогу ПА повинні вибиратися відповідно до СНиП 2.01.07 з урахуванням ваги устаткування, що встановлюється в ПА.

При дотриманні температурно-вологісних режимів роботи обладнання допустимо за погодженням з кінцевим користувачем використовувати для відведення надлишкового тепла від обладнання ПА природну вентиляцію.

У ПА всім споживачів зазначеного приміщення повинен встановлюватися електрощит із загальним вимикачем вступного електроживлення. Розміри вступного щита, його установча DIN-рейка повинні дозволяти монтаж автоматичних вимикачів для підключення всіх споживачів, які визначаються проектом електропостачання обладнання ПА.

Прокладання силових кабелів у ПА має виконуватися у просторі фальшпідлоги або (за його відсутності) в окремих металевих лотках, що встановлюються над ТШ. Спуски силових кабелів, встановлення побутових розеток у ПА повинні виконуватись у настінних коробах.

При формуванні ІТС об'єктів з невеликою (до 60) кількістю користувачів, де не потрібне чи недоцільне забезпечення гарантованої безперервної роботи обладнання, можуть застосовуватися, за погодженням з кінцевими користувачем, спрощені вимоги щодо оснащення ПА. При цьому повинні дотримуватися вимог усіх необхідних стандартів, норм, правил та рекомендацій щодо електропостачання, протипожежної безпеки та забезпечення безпеки життєдіяльності.

У приміщеннях ЕКЦ, повинні встановлюватися ручні газові вогнегасники настінного кріплення з достатнім обсягом вогнегасної речовини, відповідного обсягу приміщення, що захищається відповідно до СП 9.13130.2009, а також дотримуватися інших норм протипожежної безпеки відповідно до Правил протипожежного регламент щодо вимог пожежної безпеки".

В ЕКЦ повинен встановлюватися електрощит із загальним вимикачем вступного електроживлення та автоматичними вимикачами для підключення активного обладнання ЛОМ.

При виборі місць розташування ЕКЦ перевагу слід надавати приміщенням поблизу місць розташування слаботочних стояків будівлі або поблизу місць концентрації великої кількості користувачів. Розміри приміщень для ЕКЦ повинні визначатись проектними вимогами на розміщення обладнання, технологічними проходами для проведення монтажних, ремонтних та профілактичних робіт. В ЕКЦ повинні забезпечуватись необхідні кліматичні параметри роботи обладнання.

Більшість користувачів Інтернету знають, що DNS-сервер забезпечує трансляцію імен сайтів на IP адреси.І зазвичай, на цьому знання про DNS-сервер закінчуються. Ця стаття розрахована більш поглиблений розгляд його функций.

Отже, уявімо, що Вам доведеться налагоджувати мережу, для якої провайдер виділив блок «чесних» адрес, або налаштовувати піднімати в локальній мережі свій DNS-сервер. Ось тут відразу і спливуть усілякі страшні слова, на зразок «зона», «трансфер», «форвардер», “in-addr.arpa” тощо. Давайте поступово з цим усім і розберемося.

Дуже абстрактно можна сказати, що кожен комп'ютер в Інтернеті має два основні ідентифікатори – це доменне ім'я (наприклад, www..0.0.1). А ось абстрактність полягає в тому, що, і IP-адрес у комп'ютера може бути кілька (більше того, у кожного інтерфейсу може бути своя адреса, ще й кілька адрес можуть належати одному інтерфейсі), і імен теж може бути кілька. Причому можуть зв'язуватися як із одним, і з кількома IP-адресами. А по-третє, комп'ютер може взагалі й не мати доменного імені.

Як було сказано раніше, основним завданням DNS-сервера є трансляція доменних імен в IP адреси і назад. На зорі зародження Інтернету, коли він був ARPANET'ом, це вирішувалося веденням довгих списків всіх комп'ютерних мереж. При цьому копія такого списку мала знаходитися на кожному комп'ютері. Природно, що зі зростанням мережі така технологія вже стала не зручною для користувачів, тому що ці файли були більших розмірів, до того ж, їх ще й потрібно було синхронізувати. До речі, деякі такі «відлуння минулого» цього методу ще можна зустріти і зараз. Ось так у файл HOSTS (і в UNIX, і Windows) можна внести адреси серверів, з якими ви регулярно працюєте.

Так ось, на зміну незручній "однофайловій" системі і прийшов DNS - ієрархічна структура імен, придумана доктором Полом Мокапетрісом.

Отже, є "корінь дерева" - "." (крапка). Зважаючи на те, що цей корінь єдиний для всіх доменів, то крапка наприкінці імені зазвичай не ставиться. Але вона використовується в описах DNS, і це потрібно запам'ятати. Нижче цього «кореня» є домени першого рівня. Їх небагато - com, net, edu, org, mil, int, biz, info, gov (та ін.) та домени держав, наприклад, ua. Ще нижче знаходяться домени другого рівня, а ще нижче – третього тощо.

Що таке «висхідна ієрархія»

При налаштуванні вказується адреса як мінімум одного сервера DNS, але як правило, їх два. Далі клієнт надсилає запит цьому серверу. Сервер, що отримав запит, або відповідає, якщо відповідь йому відомий, або пересилає запит на «вищий» сервер (якщо той відомий), або відразу на кореневий, тому що кожному DNS-серверу відомі адреси кореневих DNS-серверів.
Потім запит починає спускатися вниз - кореневий сервер пересилає запит серверу першого рівня, той серверу другого рівня і т.д.

Крім такого «вертикального зв'язку» є ще й «горизонтальні», за принципом “первинний – вторинний”. І якщо припустити, що сервер, який обслуговує домен і працює «без підстрахування», раптом стає недоступним, то комп'ютери, які розташовані в цьому домені, теж стануть недоступними! Ось тому при реєстрації домену другого рівня і пред'являється вимога вказувати мінімум два DNS-сервера, які обслуговуватимуть цей домен.

У міру подальшого зростання Інтернету всі домени верхнього рівня були поділені на піддомени або зони. Кожна зона є незалежним доменом, але при зверненні до бази даних імен запитує батьківський домен. Батьківська зона гарантує дочірній зоні право на існування і відповідає за її поведінку в мережі (так само, як і в реальному житті). Кожна зона повинна мати принаймні два сервери DNS, які підтримують базу даних DNS для цієї зони.

Основні умови для роботи серверів DNS однієї зони - наявність окремого з'єднання з мережею Інтернет та розміщення їх у різних мережах для забезпечення стійкості до відмови. Тому багато організацій покладаються на провайдерів Internet, які ведуть у тому інтересах вторинні і третинні сервери DNS.

Рекурсивні та нерекурсивні сервери

DNS-сервера можуть бути рекурсивні та нерекурсивні. Різниця в тому, що рекурсивні завжди повертають клієнту відповідь, оскільки самостійно відстежують відсилання до інших DNS-серверів і опитують їх, а нерекурсивні – повертають клієнту ці відсилання, і клієнт повинен самостійно опитувати зазначений сервер.

Рекурсивні сервери зазвичай використовують на низьких рівнях, наприклад, у локальних мережах, так як вони кешують всі проміжні відповіді, і так при наступних запитах, відповіді повертатимуться швидше. А нерекурсивні сервери часто стоять на верхніх щаблях ієрархії, оскільки вони отримують так багато запитів, що для кешування відповідей просто не вистачить ресурсів.

Forwarders – «пересилачі» запитів та прискорювачі дозволу імен

DNS-сервери мають досить корисну властивість – вміння використовувати так званих «пересилачів» (forwarders). «Чесний» DNS-сервер самостійно опитує інші сервери і знаходить відповідь. Але якщо ваша мережа підключена до Інтернету по повільній лінії (наприклад, dial-up), то цей процес може зайняти багато часу. Тому можна перенаправляти ці запити, наприклад на сервер провайдера, і після цього просто приймати його відповідь.

Застосування таких «пересилачів» може стати корисним для великих компаній, які мають кілька мереж. Так у кожній мережі можна встановити відносно слабкий DNS-сервер, і вказати як «пересилача» потужнішу машину з більш швидкою лінією. Ось і вийде, що всі відповіді кешуватимуться цим потужнішим сервером, що призведе до прискорення дозволу імен для цілої мережі.

До кожного домену ведеться своя база даних DNS, яка виглядає як набір простих текстових файлів. Вони розташовані на первинному (основному) DNS-сервері, і їх іноді копіюють до себе вторинні сервери. На конфігурації сервера вказується, який файл містить описи зон, і як є сервер первинним чи вторинним цієї зони.

Унікальна адреса

Унікальна адреса в Інтернеті формується додаванням до імені хоста доменного імені. Таким чином, комп'ютер, наприклад, “fred” у домені, наприклад, “smallorg.org” називатиметься fred.smallorg.org. До речі, домен може містити як хости, і зони. Наприклад, домен smallorg.org може містити хост fred.smallorg.org і водночас вести зону acctg.smallorg.org, яка є піддоменом та може містити ще один хост barney.acctg.smallorg.org. Хоча це й спрощує базу даних імен, проте робить пошук хостів у мережі Internet складнішим.

У системі DNS реалізуються три сценарії пошуку IP-адреси у базі даних.

• Комп'ютер, якому потрібно отримати з'єднання з іншим комп'ютером у тій же зоні, надсилає запит локальному DNS-серверу зони на пошук IP-адреси віддаленого комп'ютера. Локальний DNS-сервер, що має цю адресу в локальній базі даних імен, повертає запитувану IP-адресу комп'ютеру, який надсилав запит.

* Комп'ютер, якому необхідно отримати з'єднання з комп'ютером в іншій зоні, запитує локальний DNS-сервер своєї зони. Локальний DNS-сервер виявляє, що потрібний комп'ютер перебуває у іншій зоні, і формує запит кореневому DNS-серверу. Кореневий DNS-сервер спускається по дереву DNS-серверів і знаходить відповідний локальний DNS-сервер. Від нього він отримує IP-адресу запитуваного комп'ютера. Потім кореневий DNS-сервер передає цю адресу локальному серверу DNS, який надіслав запит. Локальний DNS-сервер повертає IP-адресу комп'ютеру, з якого було подано запит. Разом з IP-адресою передається особливе значення - час життя TTL (time to live). Це значення вказує локальному DNS-серверу, скільки часу він може зберігати IP-адресу віддаленого комп'ютера у кеші. Завдяки цьому збільшується швидкість обробки наступних запитів.

* Комп'ютер, якому необхідно повторно отримати з'єднання з комп'ютером в іншій зоні, запитує локальний DNS-сервер своєї зони. Локальний DNS-сервер перевіряє, чи немає цього імені в його кеші і чи не закінчилося значення TTL. Якщо адреса ще в кеші і значення TTL не закінчилося, то IP-адреса надсилається комп'ютеру, що запитує. Це вважається неавторизованою відповіддю, оскільки локальний DNS-сервер вважає, що з моменту останнього запиту IP-адреса віддаленого комп'ютера не змінилася.

У всіх трьох випадках комп'ютеру для пошуку будь-якого комп'ютера в мережі Internet потрібна лише IP-адреса локального сервера DNS. Подальшу роботу з пошуку IP-адреси, яка відповідає запрошеному імені, виконує локальний DNS-сервер. Як бачите, тепер все набагато простіше для локального комп'ютера.

У міру зростання дерева DNS до серверів системи доменних імен пред'являлися нові вимоги. Як згадувалося раніше, батьківські DNS-сервери повинні мати IP-адреси своїх дочірніх серверів DNS, щоб правильно обробляти DNS-запити на перетворення імен в IP-адреси. Щоб DNS-запити оброблялися правильно, пошук по дереву DNS повинен починатися з певної точки. У період дитинства мережі Internet більшість запитів на пошук імен припадало на локальні імена хостів. Основна частина DNS-трафіку проходила всередині локальної зони і лише в найгіршому випадку досягала батьківських серверів DNS. Однак зі зростанням популярності Internet і, зокрема, Web, все більше DNS-запитів формувалося до віддалених хостів поза локальною зоною. Коли DNS-сервер не знаходив ім'я хоста у своїй базі даних, він змушений був вимагати віддалений DNS-сервер. Найбільш підходящими кандидатами для віддалених DNS-серверів, природно, стали сервери DNS верхнього рівня, які мають повну інформацію про дерево доменів і здатні знайти потрібний DNS-сервер, відповідальний за зону, до якої належить хост, що запитується. Потім вони повертають IP-адресу потрібного хоста локальному DNS-серверу. Все це призводить до колосальних навантажень кореневих серверів системи DNS. На щастя, їх не так багато і всі вони поступово розподіляють навантаження між собою. Локальні сервери DNS працюють з серверами DNS доменів верхнього рівня за допомогою протоколу DNS, який розглядається далі в цій лекції.

Система DNS – вулиця з двостороннім рухом. DNS як шукає IP-адресу по заданому імені хоста, але здатна виконувати і зворотну операцію, тобто. за IP-адресою визначати ім'я хоста у мережі. Багато Web- і FTP-сервери в мережі Internet обмежують доступ на основі домену, до якого належить клієнт, що звернувся до них. Отримавши від клієнта запит на встановлення з'єднання, сервер передає IP-адресу клієнта DNS-серверу як зворотний запит DNS. Якщо клієнтська зона DNS налаштована правильно, на запит буде повернуто ім'я клієнтського хоста, на основі якого потім приймається рішення про те, допустити даного клієнта на сервер чи ні.

Найчастіше при самостійному підключенні роутера користувачі несподівано для себе виявляють в налаштуваннях маршрутизатора вкладку «DNS сервер» і прямують на простори всесвітньої мережі, шукаючи, як прописати dns на роутері.

Однак перш ніж "лізти в нетрі" і самостійно змінювати налаштування dns на роутері, потрібно розібратися, що це за "звір" такий - dns, і навіщо взагалі потрібний dns-сервер.

Більш докладно це питання ми розглядали у статті, тут же зупинимося лише на його основних «характеристиках».

Отже, DNS (або domain name system) – це один із протоколів, що забезпечують прикладний рівень комп'ютерних мереж.

Він був розроблений, щоб замінити надмірно довгі та незручні (IP) доменними іменами - лейблами для відповідних адрес.

Таким чином, основним завданням сервера DNS є «роздача» доменних імен і присвоєння цих лейблів, підключених на довіреному йому ділянці мережі.

Зрозуміло, на просторах інтернету працює багато основних DNS серверів - для різних регіонів і континентів. При цьому решта серверів запитують у них розшифровку доменів (переклад доменних імен в IP-адреси).

Що таке делегування?

Коли ви з виходом в інтернет, обов'язок розшифровки доменних імен для абонентів цієї мережі лягає на , який поєднує всі функціональні вузли вашої «локалки».

За промовчанням роутери запитують "ім'я" потрібного мережного IP у DNS сервера інтернет-провайдера. При цьому операція називається делегуванням і відбувається автоматично без «втручання» адміністратора цієї мережі.

Однак у налаштувань «за замовчуванням» є один істотний недолік - цей запит може делегуватися кілька разів кільком проксі-серверам. Таким чином, якщо з одним із серверів виникнуть проблеми, то замість улюбленого сайту у браузері висвітиться неприємне повідомлення. І доки адміністратори сервера не усунуть неполадку, на потрібний сайт ви зможете потрапити лише за IP-адресою - тобто. знаючи розшифровку його домену.

Крім того, навіть при повній функціональності кожної ланки цієї мережі, кожна операція делегування забирає зайвий час на передачу запиту та відповіді (від комп'ютера до одного з основних DNS-серверів і назад).

Відповідно, є сенс прописати dns на роутері вручну - тобто. настроїти делегування безпосередньо, минаючи всі сервери-посередники.

Які сервери dns прописати в роутері?

В принципі, існують кілька надійних адрес, які можна запам'ятати або записати, і «у разі чого» спокійно використати.

Однією з таких «адрес», які можна внести до налаштувань dns на роутері є 8.8.8.8

Ця адреса має вирішити питання стабільності доступу до DNS сервера, однак «вижати» максимум швидкості завантаження сторінок за його допомогою не вдасться.

Для цього варто з'ясувати, який сервер DNS знаходиться ближче до вашої ділянки всесвітньої мережі і прописати його на роутері.

При цьому дізнатися «оптимальний» сервер dns для роутера можна за допомогою спеціальної програми від Google під назвою Namebench.

Скачайте даний софт на свій мережевий комп'ютер, відкрийте файл, натисніть кнопку extract і в вікні - кнопку start benchmark.

Ця операція може тривати кілька хвилин.

За результатами даних тестів програма завантажить сторінку в браузері, де праворуч вгорі будуть перераховані сервери, що рекомендуються: первинний, вторинний і ще один додатковий - їх-то і потрібно внести в налаштування dns на роутері.

Залежно від моделі роутера, шлях до налаштувань DNS може змінюватись, проте дана операція завжди здійснюється і шукати потрібну вкладку слід або в «Загальних налаштуваннях» або в «Налаштуваннях інтернет-з'єднання».

"Як дізнатися ДНС сервер провайдера," - таке питання іноді може виникнути як у досвідчених користувачів, так і у людей, які вирішують свою проблему з доступом до мережі. Вона може виникнути при необхідності налаштування виходу в інтернет через внутрішню мережу, використовуючи конкретну адресу ДНС сервер, а не адресу, що автоматично визначається. Зазвичай це може знадобитися, якщо виникають якісь труднощі з динамічним пулом адрес. Таке з'єднання більш стабільне і дозволяє налаштувати доступ DSL без розривів на лінії.

Найпростішим варіантом, як дізнатися про DNS провайдера, є дзвінок до служби підтримки. Оператори зазвичай повідомляють дві адреси, які ви можете внести до настроюваних параметрів мережі. Якщо цього з якихось причин не можна зробити, скористайтеся нашими порадами, які є нижче.

Порада адміністратора! Якщо виникає проблема доступу до мережі. Можливо, некоректно працює служба визначення dns-адрес, в результаті ви матимете фізичний вихід у мережу, але без виходу в інтернет через браузер. Це можна виправити звичайним перезавантаженням комп'ютера, досвідчені користувачі можуть перезапустити службу та відновити роботу мережі за http-протоколом.

Принцип дії DNS

Принцип дії DNS (Domain Name Services) добре продемонстровано на ілюстрації. Користувач відправляє звичну текстову назву сайту і у відповідь отримує IP-адресу, за якою вже здійснюється доступ до певного ресурсу. DNS є глобальною мережею серверів-маршрутизаторів, що забезпечують послідовне підключення до системи серверів і доступ.

Порада адміністратора! Звичайним користувачам немає потреби в налаштуванні параметрів мережі та уточнення DNS провайдера та інших сайтів. Але для загального розвитку потрібно знати, що кожній текстовій назві зіставлено певну IP-адресу, наприклад, 78.1.231.78.

Підміна ДНР - класична хакерська атака

Досвідченим користувачам буде цікаво ознайомитися зі схемою серверів, які забезпечують доступ до мережі Інтернет. DNS-сервер, що маршрутизує трафік користувача, є і на стороні вашого провайдера.

Порада адміністратора! Зверніть увагу, що під час заміни DNS-сервера можливе підключення до «фейкового» сайту. За допомогою подібного інтерфейсу здійснюється крадіжка паролів та даних кредитних карток. Зазвичай це питання вирішується при встановленні антивірусного програмного забезпечення, що включає захист від подібного прослуховування трафіку.

ДНР провайдера

Як ми говорили, для налаштування мережного з'єднання потрібна ДНС адреса провайдера. Зазвичай їх кілька, особливо стосується великих телекомунікаційних систем, до яких підключається безліч користувачів. Зазвичай у службі підтримки можна дізнатися про первинний і вторинний ДНС, ці сервери дублюють один одного, коли йде досить велике навантаження при підключенні користувачів.

Визначення ДНЗ провайдера зі своєї мережі

Найпростіше це зробити, коли є мережа і вихід в інтернет, або те саме можна зробити від абонента, який також обслуговується у вашій провайдерській мережі. Для цього виконайте інструкції:

• запустіть командний рядок, натиснувши в меню "Пуск", потім "Виконати" і набравши в рядку CMD (рядковими);
• у вікні командного рядка наберіть ipconfig/all;
• у звіті ви отримаєте список DNS-адрес;
• отримані адреси можна фізично прописати в налаштуваннях мережі, у цьому випадку вихід у мережу стабільно працюватиме навіть при збоях автоматичного виявлення ДНС-серверів.

Цей спосіб допомагає зробити доступ до мережі більш стійким, фактично ви призначаєте постійний ДНС-сервер із резервною адресою. Обидва сервери здійснюватимуть маршрутизацію ваших запитів у мережі Інтернет.

Скрини

Приклади показані на скринях. У першому випадку вказано стандартні адреси серверів. У другому випадку резервні та додаткові. У цьому варіанті користувачі мають доступ до трьох резервних серверів.

Звіт після запуску команди ipconfig /all з одним ДНС-дзеркалом

Звіт після запуску команди ipconfig /all з двома дзенкалами

Альтернативні способи пошуку ДНС-адрес провайдера

Якщо у вас немає доступу до мережі, служба підтримки не дає прямі DNS-адреси і ви не можете їх отримати іншим способом, спробуйте пошукати через пошук в інтернеті. Це можна зробити, скориставшись пошуковою системою та ключовими словами «ДНС адреси (назва вашого провайдера)». В окремих випадках цю інформацію можна розміщувати на офіційному сайті телекомунікаційної компанії або у форумах користувачами.

DNS визначає два типи серверів: первинні та вторинні. Первинний сервер- Це сервер, що накопичує файл про зону, на яку він має повноваження. Він несе відповідальність за створення, експлуатацію та зміни зонового файлу. Зона файлу накопичується на локальному диску.

Вторинний сервер– це сервер, який передає повну інформацію про зону для інших серверів (первинних чи вторинних) та накопичує файл на своєму локальному диску. Вторинний сервер не створює та не змінює зоновий файл. Якщо зміна потрібна, вона має зробити це за допомогою первинного сервера, який посилає змінену версію на вторинний.

DNS в Інтернеті

DNS – це протокол, який можна використовувати у різних платформах. В Інтернеті простір доменних імен (дерево) поділяється на три різні секції: родовий домен, домен країни та інверсний домен.

Родовий домен

Родовий домен визначає реєстрацію хоста (generic domain) відповідно до його родової природи. Ці рівні пов'язані з типами організацій, як це, наприклад, наведено США в табл. 3.1.

Кожен вузол дерева – домен, який є частиною бази простору доменних імен.

У таблиці перший рівень у секції родового домену дозволяє сім можливих трисимвольних рівнів. Ці рівні співвіднесені з типами організацій оскільки перераховано в табл. 3.1.

Домени країни

Секція домени країнидотримується того ж формату, що й родові домени, але використовує двосимвольні скорочення країни (наприклад, ru для Росії) замість трисимвольної організаційної структури першого рівня. Абревіатури другого рівня можуть бути організаційними або більш детально визначати національну приналежність. Росія, наприклад, використовує абревіатури окремих міст (наприклад, spb.ru). Адреса gut.spb.ru може бути розшифрована як Державний університет телекомунікацій, Санкт-Петербург, Росія.

Інверсний домен

Інверсний доменвикористовує відображення адреси на ім'я. Це може знадобитися, наприклад, коли сервер отримав запит від клієнта виконання певного завдання. Оскільки сервер має файл, який містить список повноважних клієнтів, сервер перераховує лише IP-адреси клієнтів (витягуючи їх із отриманого пакета). Щоб визначити, чи є клієнт у дозволеному списку, сервер може запросити сервер DNS про відображення адреси в ім'я.

Цей тип запиту називається інверсним запитом або запитом вказівника. Щоб обробити запит покажчика, інверсний домен додає до простору доменних імен вузол першого рівня, званий arpa (з історичних причин). Другий рівень також називає одиночний вузол in-addr (для інверсної адреси). Залишок домену визначає IP-адресу.

Сервер, який обробляє інверсний домен, також ієрархічний. Це означає, що частина адреси, що містить мережевий номер (netid), повинна бути вищого рівня (в даному прикладі це 132), ніж частина адреси підмережі (subnetid), у цьому прикладі 45; а частина адреси підмережі має бути вищого рівня, ніж адреса хоста (hostid). Така конфігурація робить вигляд домену інверсним, якщо порівнювати з родовим доменом та доменом країни.

Розпізнавання імен

Відображення імені на адресу або адреси в ім'я називається "розпізнавання імені-адреси".

Розпізнавач (resolver)

Протоколи DNS розроблені як програма сервер-клієнт. Хост, який потребує відображення адреси в ім'я або ім'я на адресу, викликає DNS клієнта, який називається розпізнавачем. Розпізнавач отримує доступ до найближчого DNS-сервера з запитом на відображення. Якщо сервер має інформацію, він виконує запит розпізнавача; в іншому випадку він або відсилає розпізнавач до інших серверів, або сам запитує інші сервери для того, щоб забезпечити цю інформацію.

Після того, як розпізнавач отримає це відображення, він аналізує відгук для того, щоб подивитися, чи це реальне розпізнавання або помилка. Зрештою, результат доставляється процесу, який запросив його.

Відображення імен на адресу

Більшість часу розпізнавач видає імена серверу та запитує відповідні адреси. У цьому випадку сервер перевіряє родовий домен або домен країни, щоб знайти відображення.

Якщо ім'я домену від родової секції, розпізнавальник отримує доменне ім'я, таке як kafedra.gut.edu. Запит надсилається розпізнавачем до місцевого DNS-сервера для розпізнавання. Якщо місцевий сервер не розпізнає запит, він або посилає розпізнавач на інший сервер, або запитує інший сервер безпосередньо.

Якщо ім'я домену із секції доменів країн, розпізнавач отримує доменне ім'я, таке як kafedra.gut.spb.ru. Процедура та сама.

Відображення адрес в імена

Клієнт може надіслати IP-адресу на сервер, щоб відобразити доменне ім'я. Це називається PTR-запит. Для такого запиту DNS використовує інверсний домен. Однак IP-адреса запиту має бути реверсована, і повинні бути прикріплені дві мітки, in-addr або arpa, щоб створити доступний домен за допомогою інверсної доменної секції. Наприклад, якщо розпізнавач отримав IP-адресу 132.34.45.121, розпізнавальник спочатку інвертує адресу, а потім додає дві мітки перед посилкою. Ім'я домену, що посилається - 121.45.34.132.in-addr.arpa. Воно виходить за допомогою локальної DNS та розпізнається.

Рекурсивне розпізнавання

Клієнт (розпізнавач) може запросити рекурсивну відповідь із сервера імені. Якщо сервер може це зробити, він перевіряє свою базу даних та відповідає. Якщо сервер не уповноважений, він надсилає запит іншому серверу (зазвичай до вищестоящого) і чекає на відгук. Якщо сервер уповноважений, він відповідає; інакше він надсилає запит ще одному серверу. Коли запит остаточно розпізнаний, відповідь переміщається назад, доки остаточно не досягне запитуваного клієнта.

Ітераційне розпізнавання

Якщо клієнт не вимагає рекурсивної відповіді, відображення може бути зроблено ітераційно. Якщо сервер має дозволене ім'я, він надсилає відповідь. Якщо ні, він повертає клієнту IP-адресу сервера, яка, як він припускає, може відповісти на запит. Клієнт повторює запит на другий сервер. Якщо новий адресований сервер може розпізнати запит, він відповідає IP-адресою; інакше він повертає IP-адресу нового сервера клієнту. Тепер клієнт має повторити запит третьому серверу. Цей процес називається ітераційним, тому що клієнт повторює той самий запит до безлічі серверів.

Кешування

Щоразу як сервер отримує запит імені, якого немає у його домені, йому необхідно здійснити пошук у базі даних адрес первинного сервера. Зменшення часу пошуку збільшило б ефективність. DNS робить це за допомогою механізму, що називається кешуванням. Коли сервер запитує відображення від іншого сервера і отримує відгук, він накопичує цю інформацію у своїй надоперативній пам'яті (кеш-пам'ять), перш ніж надіслати її іншому клієнту. Якщо той чи інший клієнт запитує відображення, може перевірити свою кеш-пам'ять і розпізнати номер. Однак, щоб інформувати клієнта, що відгук прийшов від кеш-пам'яті, а не від повноважного джерела, сервер маркує відгук як неповноважний.

Кешування прискорює розпізнавання, але може створити проблеми. Якщо сервер кешує за довгий час, він може надіслати клієнтові застаріле відображення. Щоб протистояти цьому, використовуються два методи.

При першому їх повноважний сервер завжди додає шматок інформації для відображення так званого "часу життя" (TTL – time to live). Воно визначає час у секундах, протягом якого сервер, що приймає, може кешувати інформацію. Після цього часу відображення недійсне, і будь-який запит може бути знову надісланий до повноважного сервера.

Другий метод полягає в тому, що DNS-запит, який кожен сервер зберігає у пам'яті, містить TTL – обмежений час для кожного відображення. Кеш-пам'ять періодично сканується, і відображення з "часом життя" (TTL), що минув, видаляються.

DNS-повідомлення

DNS має два типи повідомлення: запит та відгук. Обидва типи мають один і той самий формат. Повідомлення запиту містить заголовок, запис запиту, запис у відповідь, запис повноважень і додаткові записи (рис. 4.1).

Мал. 4.1.Повідомлення запиту та запису

Заголовок

Обидва повідомлення, запит і відгук мають один і той же формат заголовка з кількома полями з встановленими нулями для повідомлень відгуку. Заголовок 12 байт та його формат показано в (табл. 4.2).

Поля заголовків – такі:

Ідентифікація. Це 16-бітове поле застосовується клієнтом для того, щоб порівняти відгук із запитом. Клієнт використовує різний номер ідентифікації щоразу, коли він надсилає запит. Сервер дублює цей номер у відповідному відгуку.

Прапори. Це 16-бітове поле, що містить субполя, показано (рис. 4.2).

Мал. 3.2.Поле прапорів

Короткий опис субполів кожного прапора наведено нижче.

1. QR (query/response) - запит/відповідь. Це однобітове субполе, яке визначає тип повідомлення. Якщо воно дорівнює 0, це повідомлення є запитом. Якщо воно дорівнює 1, то повідомлення – відповідь.

2. OpCode (код операції). Це 4-бітове субполе, яке визначає тип запиту або відповіді (0 – тип стандартний, 1 – тип інверсний та 2 – сервер запитує стан).

4. TC (truncated - усічене). Це однобітове поле. Коли воно встановлено (значення 1), це означає, що відповідь була більш ніж 512 байт і усічена до 512. Застосовується, коли DNS користується послугою UDP.

5. RD (recursiondesired – бажана рекурсія). Це однобітове субполе. Коли вона встановлена ​​(значення 1), це означає, що клієнту бажана рекурсивна відповідь. Він встановлюється в повідомленні запиту і повторюється в повідомленні у відповідь.

6. RA (recursion available - можлива рекурсія). Однобітове субполе. Коли вона встановлена ​​у відповіді, це означає, що можлива рекурсивна відповідь. Встановлюється тільки в повідомленні у відповідь.

7. Reserved (резервні). Це трибітове субполе із встановленими нулями.

8. rCode (r-код). Це 4-бітове поле, яке показує стан помилки у відповіді. Звичайно, лише повноважний сервер може зробити таку оцінку.

Таблиця 4.2. показує можливі значення поля.

Значення