Лабораторна робота №13, Створення та налаштування DNS-серверу під Linux
Код роботи: 3763
Вид роботи: Лабораторна робота
Предмет: Комп’ютерні системи та мережі
Тема: №13, Створення та налаштування DNS-серверу під Linux
Кількість сторінок: 31
Дата виконання: 2015
Мова написання: українська
Ціна: безкоштовно
Мета: Оволодіти базовими навичками по створенню DNS серверу.
Короткі теоретичні відомості
DNS сервер BIND (теорія)
Основна мета DNS - це відображення доменних імен в IP адреси і навпаки - IP в DNS. У статті я розгляну роботу DNS сервера BIND (Berkeley Internet Name Domain, раніше: Berkeley Internet Name Daemon), як самого поширеного. BIND входить до складу будь-якого дистрибутива UNIX. Основу BIND становить демон named, який для своєї роботи використовує порт UDP / 53 і для деяких запитів TCP / 53.
Основні поняття Domain Name System
Історично, до появи доменної системи імен роль інструменту дозволу символьних імен в IP виконував файл / etc / hosts, який і в даний час грає далеко не останню роль в цій справі. Але з ростом кількості хостів в глобальній мережі, відстежувати і обслуговувати базу імен на всіх хостах стало нереально важко. В результаті придумали DNS, що представляє собою ієрархічну, розподілену систему доменних зон. Давайте розглянемо структуру Системи доменних Імен на ілюстрації:
Доменна структура DNS являє собою деревоподібну ієрархію, що складається з вузлів, зон, доменів, піддоменів і ін. Елементів, про які піде мова. «Вершиною» доменної структури є коренева зона. Налаштування кореневої зони розташовані на безлічі серверів / дзеркал, розміщених по всьому світу і містять інформацію про всі сервери кореневої зони, а так само відповідають за домени першого рівня (ru, net, org і ін). Інформація про сервери кореневої зони розташована на даному сайті кореневих серверів http://www.root-servers.org/. Налаштування кореневої зони завжди доступні тут ftp://ftp.internic.net/domain/named.root. Сервери кореневої зони обробляють і відповідають на запити, видаючи інформацію тільки по доменах першого рівня (тобто відповідають на будь-які запити, як на нерекурсивні)! Отже, вже багато разів повторилося слово зона. Пора цей термін пояснити.
Зона - це будь-яка частина дерева системи доменних імен, що розміщується як єдине ціле на деякому DNS-сервері. Зону, для більшого розуміння, можна назвати «зоною відповідальності». Метою виділення частини дерева в окрему зону є передача відповідальності (Делегування) за цю гілку іншій особі або організації. На ілюстрації, приклади зон виділені синім градієнтом (зона name., Зона k-max.name. З усім підлеглими ресурсами, www.openoffice.org з усім підлеглими піддоменами і ресурсами). На ілюстрації виділені не всі зони, а лише деякі для загального розуміння і уявлення. У кожній зоні є, принаймні, один авторитетний сервер DNS, який зберігає ВРЮ інформацію про зону, за яку він відповідає.
Домен - це іменована гілка або поддерево в дереві імен DNS, тобто це певний вузол, що включає в себе всі підлеглі вузли. Наступна цитата з книги Linux Network Administrators Guide добре прояснює картину щодо різниці між зоною і доменом:
Таким чином, простір імен роздроблене на зони (zones), кожна з яких керується своїм доменом. Зверніть увагу на відмінність між зоною (zone) і доменом (domain): домен groucho.edu зачіпає всі машини в університеті Groucho Marx, в той час як зона groucho.edu включає тільки хости, які працюють в безпосередньо комп'ютерному центрі, наприклад у відділі математики. Хост в відділі фізики належать іншій зоні, а саме physics.groucho.edu.
Кожен вузол в ієрархії DNS відділений від свого батька точкою. Якщо провести аналогію з файлової системою Linux, система доменних імен має схожу структуру, за тим винятком, що роздільник в файлової системі - слеш, а в DNS - точка. А так же DNS адресу читається справа наліво (від кореневого домена до імені хоста) на відміну від шляху в файлової системі Linux. Доменне ім'я починається з точки (кореневого домена) і проходить через домени першого, другого і якщо потрібно третього і т.д. рівнів і завершується ім'ям хоста. Т.ч. доменне ім'я повністю відображає структуру ієрархії DNS. Часто (я б сказав - завжди в повсякденному житті), остання точка (позначення кореневого домена) в доменному імені опускається (тобто в браузері ми вводити не k-max.name., А k-max.name). Отже, розібравши структуру доменного імені, ми непомітно підійшли до поняття FQDN.
FQDN (англ. Fully Qualifed Domain Name, повністю певне ім'я домену) - це ім'я домену, що однозначно визначає доменне ім'я і включає в себе імена всіх батьківських доменів ієрархії DNS, в тому числі і кореневого. Своєрідний аналог абсолютного шляху в файлової системі. Давайте розберемо вищесказане на прикладі імені домена mail.k-max.name:
mail.k-max.name.
| | | | |
| | | | +-корневий домен
| | | +---домен першого рівня
| | +------точка, розділяюча домени/частини FQDN
| +---------домен другого рівня
+---------------піддомен/домен третього рівня, можливо - ім'я хоста
Різниця між FQDN і звичайним доменним (неFQDN) ім'ям з'являється при іменуванні доменів другого, третього (і т. Д.) Рівня. Для отримання FQDN потрібно обов'язково вказати в доменному імені домени вищого рівня (наприклад, mail є доменним ім'ям, проте FQDN ім'я виглядає як mail.k-max.name.). Максимальний розмір FQDN - 255 байт, з обмеженням в 63 байта на кожне ім'я домену.
Піддомени, коротко кажучи, це - підлеглі домени. За великим рахунком, всі домени в інтернеті є підлеглими за винятком кореневого. Наприклад домен k-max є поддоменом домену name, а name, в свою чергу - поддоменом кореневого домена.
Отже, на схемі вище ми розглянули кореневої домен, які проходитимуть у ієрархії йдуть домени першого / верхнього рівня, вони ж TLD, вони ж Top-Level Domain. До даних доменів відносяться національні домени (ru., Ua. І ін) і загальні домени (com., Net., Та ін). Існують так само спеціалізовані домени, які не опубліковані в системі DNS, але використовуються програмами (домен.onion використовується анонімної мережею Tor для перехоплення і подальшої маршрутизації звернень до прихованих сервісів цієї мережі). Ще є т.зв. зарезервовані доменні імена, визначені в RFC 2606 (Reserved Top Level DNS Names - Зарезервовані імена доменів верхнього рівня) визначає назви доменів, які слід використовувати в якості прикладів (наприклад, в документації), а також для тестування. До таких імен належать наприклад example.com, example.org і example.net, а також test, invalid і ін. Нижче по ієрархії, як видно, йдуть домени третього рівня і т.д. Закінчується доменна ієрархія - іменами хостів, які задаються відповідними ресурсними записами або хостовими записами.
Ресурсні записи
Ресурсний запис - це те, власне заради чого в кінцевому рахунку і існує DNS. Ресурсний запис - це одиниця зберігання та передачі інформації в DNS. Кожен такий запис несе в собі інформацію відповідності якогось імені та службової інформації в DNS, наприклад відповідність імені домена - IP адреси.
Запис ресурсу складається з наступних полів:
• имя (NAME) — доменне ім'я, до якого прив'язана або яким «належить» даний ресурсний запис, або IP адреса. При відсутності даного поля, запис ресурсу успадковується від попереднього запису.
• Time To Live (TTL) — дослівно «час життя» запису, час зберігання запису в кеші DNS (після зазначеного часу запис видаляється), дане поле може не вказуватися в індивідуальних записах ресурсів, але тоді воно повинно бути вказане на початку файла зони і буде спадкуватися всіма записами.
• клас (CLASS) — визначає тип мережі, (в 99,99% випадках використовується IN (що означає - Internet). Дане поле було створено з припущення, що DNS може працювати і в інших типах мереж, крім TCP / IP)
• тип (TYPE) — тип запису, синтаксис і призначення запису
• дані (DATA) — різна інформація, формат і синтаксис котрої визначається типом.
При цьому, можна використовувати наступні символ:
• ; - Вводить коментар
• # - Також вводить коментар (тільки в версії BIND 4.9)
• @ — Ім'я поточного домену
• ( ) — Дозволяє даним займати декілька рядків
• * — Метасимвол (тільки в полі імя)
З усім набором ресурсних записів можна ознайомитися в wikipedia. Найбільш часто застосовуються ресурсні записи наступні (далі, ми обов'язково розглянемо їх на практиці):
Типи.
• A — (Address record / запис адреси) відображають ім'я хоста (доменне ім'я) на адресу IPv4. Для кожного мережевого інтерфейсу машини повинен бути зроблений один A-запис. Наприклад, такий запис відображає доменне ім'я k-max.name. в IPv4 адресу хоста 81.177.139.65 (поле NAME - k-max.name., поле TTL - 86400, поле CLASS - IN, поле DATA - 81.177.139.65):
k-max.name. 86400 IN A 81.177.139.65
• AAAA (IPv6 address record) аналогічно запису A, але для IPv6.
• CNAME (canonical name record/канонічний запис імені (псевдонім)) - відображає аліас(маску) на реальне ім'я (для перенаправлення на інше ім'я), наприклад, такий запис задає аліас ftp для хоста www.k-max.name.:
ftp 86400 IN CNAME www.k-max.name.
• MX (mail exchange) — вказує хости для доставки пошти, адресованої домену. При цьому поле NAME вказує домен призначення, поля TTL, CLASS - стандартне значення, поле TYPE приймає значення MX, а поле DATA вказує пріоритет і через пробіл - доменне ім'я хоста, відповідального за прийом пошти. Наприклад, такий запис показує, що для домену k-max.name направляти пошту спочатку на mx.k-max.name, потім на mx2.k-max.name, якщо з mx.k-max.name виникли якісь проблеми. При цьому, для обох MX хостів повинні бути відповідні A-записи:
• k-max.name. 17790 IN MX 10 mx.k-max.name.
k-max.name. 17790 IN MX 20 mx2.k-max.name.
• NS (name server/сервер імен) вказує на DNS-сервер, що обслуговує даний домен. Вірніше буде сказати - вказують сервера, на які делегований даний домен. Якщо записи NS відносяться до серверів імен для поточної зони, доменна система імен їх практично не використовує. Вони просто пояснюють, як організована зона і які машини грають ключову роль в забезпеченні сервісу імен. Наприклад, зону name. обслуговують такі NS:
• name. 5772 IN NS l6.nstld.com.
• name. 5772 IN NS m6.nstld.com.
• name. 5772 IN NS c6.nstld.com.
• name. 5772 IN NS j6.nstld.com.
......
зону k-max.name обслуговують:
k-max.name. 1577 IN NS ns2.jino.ru.
k-max.name. 1577 IN NS ns1.jino.ru.
• PTR (pointer) — відображає IP-адреси в доменне ім'я (про даний тип запису поговоримо нижче в розділі зворотного перетворення імен).
• SOA (Start of Authority/початковий запис зони) — описує основні / початкові настройки зони, можна сказати, визначає зону відповідальності даного сервера. Для кожної зони повинна існувати тільки одни запис SOA і він повинен бути першим. Поле Name містить ім'я домену / зони, поля TTL, CLASS - стандартне значення, поле TYPE приймає значення SOA, а поле DATA складається з декількох значень, розділених пробілами: ім'я головного DNS (Primary Name Server), адреса адміністратора зони, далі в дужках - серійний номер файлу зони (Serial number). При кожному внесенні змін у файл зони дане значення необхідно збільшувати, це вказує вторинним серверів, що зона змінена, і що їм необхідно оновити у себе зону. Далі - значення таймерів (Refresh - вказує, як часто вторинні сервери повинні опитувати первинний, щоб дізнатися, чи не збільшився чи серійний номер зони, Retry - час очікування після невдалої спроби опитування, Expire - максимальний час, протягом якого вторинний сервер може використовувати інформацію про отриманої зоні, Minimum TTL - мінімальний час, протягом якого дані залишаються в кеші вторинного сервера). Нижче в прикладі наведено 2 однакові записи SOA (хоча друга і записана в декілька рядків), але вони однакові за значенням і формат запису другого більш зрозумілий в силу його структурованості::
• k-max.name. 86400 IN SOA ns1.jino.ru. hostmaster.jino.ru. 2011032003 28800 7200 604800 86400
• k-max.name. 86400 IN SOA ns1.jino.ru. hostmaster.jino.ru. (
• 2011032003; serial (серійний номер)
• 28800; refresh (обновлення)
• 7200; retry (повторна спроба)
• 604800; expire (строк придатності)
86400); minimum TTL (мінімум)
• SRV (server selection) — вказують на сервера, що забезпечують роботу тих чи інших служб в даному домені (наприклад Jabber і Active Directory).
Давайте розглянемо, що є Делегування. Делегування (коректніше сказати делегування відповідальності) - це операція передачі відповідальності за частину дерева доменних імен (зону) іншій особі або організації. За рахунок делегування, в DNS забезпечується распределенность адміністрування і зберігання зон. Технічно, делегування полягає у виділенні будь-якої частини дерева в окрему зону, і розміщенні цієї зони на DNS-сервері, що належить іншій особі або організації. При цьому, в батьківську зону включаються «склеюють» ресурсні записи (NS і А), що містять покажчики на авторитативні DNS-сервера дочірньої зони, а вся інша інформація, що відноситься до дочірньої зоні, зберігається вже на DNS-серверах дочірньої зони. Наприклад, на ілюстрації кореневої домен делегує повноваження серверів відповідає за TLD, TLD же в свою чергу, делегують повноваження управління зонами - серверам другого рівня, іноді на цьому ланцюжок закінчується, але буває, що делегування простягається до 4 і навіть 5 рівнів.
Для більшого розуміння, наведу приклад. Делегування управління поддоменом k-max.name іншій особі (в моєму випадку - хостера) призводить до створення нової зони, яка адмініструється незалежно від решти простору імен (незалежно від вищестоящого name.). Зона k-max.name після делегування повноважень тепер не залежить від name. і може містити всі (вірніше сказати - будь-які імена, які я захочу) доменні імена, які закінчуються на *.k-max.name. З іншого боку, зона name. містить тільки доменні імена, що закінчуються на *.name., але не входять в делеговані цієї зони, такі, наприклад, як k-max.name або a-lab.name або будь-яка інша. k-max.name може бути поділений на піддомени з іменами на кшталт mail.k-max.name, ftp.k-max.name і деякі з цих піддоменів можуть бути виділені в самостійні зони, і відповідальність за дані зони може так само бути делегована. Якщо ftp.k-max.name буде самостійною зоною, то зона k-max.name нічого очікувати утримувати доменні записи, які закінчуються на *.ftp.k-max.name.
Т.ч. після делегування відповідальності, інформація зберігається делегує зоною вже не включає інформацію з делегованого піддомену і його ресурсним записам хостів, а зберігає інформацію про серверах імен, які є для делегованого поддомена авторитативні. Це і є «склеюють» записи, про що я вище вже говорив. У такому випадку, якщо у DNS-сервера батьківського домену запитуються дані про адресу, що належить делегированному поддомену, у відповідь надається список DNS-серверів, які володіють відповідною інформацією.
Сервери DNS
Вище, при розгляді типів ресурсних записів я згадував про первинному і вторинному сервері. Крім даних типів, існує ще один тип - кешуючий.
Головний сервер DNS (він же первинний, він же master, він же primary) - це авторитетний сервер (іноді називають - авторитативні, як правильніше називати - не знаю), який зберігає головну копію файлу даних зони, супроводжувану адміністратором системи.
Вторинний сервер - теж є авторитетним, але він копіює головний файл зони з первинного сервера. Відмінність головного від вторинного лише в тому, що головний завантажує свою інформацію з конфігураційних файлів зони, а вторинний - завантажує (отримує) настройки зон - з головного сервера. Вторинний DNS може отримувати свої дані і від іншої вторинної сервера. Будь-який запит щодо хоста в межах зони, за яку відповідає авторитетний сервер, буде в кінці кінців переданий одному з цих серверів (головному або вторинному). Вторинних серверів може бути скільки завгодно багато. Залежно від налаштувань, головний сервер може надсилати вторинному сигнал про зміну зони, при цьому вторинний, отримавши сигнал проводить копіювання. Дана дія називається трансфер зони (zone transfer). Існує два механізми копіювання зони: повне копіювання (AXFR) і инкрементальное (incremental) копіювання зони (IXFR).
Кешуючий сервери не авторитетну, дані сервери зберігають в пам'яті (кеші), відповіді на попередні запити, якщо даний сервер отримав запит, то він спочатку переглядає інформацію в кеші, і якщо в кеші не виявилося необхідного відповіді, то відправляє запит вищестоящому сервера DNS.
Можливо так само налаштувати DNS в режимі stels (т.зв. невидимий), інформацію про даний сервері неможливо отримати використовуючи прямі запити. Це може бути корисно для організації primary сервера в захищеному середовищі і тим самим захистити зону від атак на зону.
Клієнти DNS (resolver)
Як же програми на кінцевих машинах знають куди і в якому вигляді посилати запити DNS? Вони цього не знають. Для розпізнавання імен та IP адрес клієнтськими додатками використовується бібліотека Resolver. Це не якесь спеціальне додаток, це функціональність системи (ядра). Т.ч. додатки посилають системні виклики gethostbyname (2) і gethostbyaddr (2), а ядро вже на підставі налаштувань у файлі /etc/nsswitch.conf визначає яким шляхом йому далі діяти. Даний файл визначає які сервіси (будь то файл / etc / hosts або DNS) і в якому порядку використовувати. У ранніх версіях бібліотеки Linux - libc, використовувався файл /etc/host.conf. Ось фрагмент файлу, який нас цікавить:
root@DNS:~# cat /etc/nsswitch.conf
......
hosts: files dns
networks: files
Два рядки даного фрагмента вказують ядру виробляти перетворення імен хостів в IP (рядок hosts: files dns) спочатку з файлу hosts, потім силами DNS, а так само перетворення імен мереж в IP (рядок networks: files) за допомогою файлу / etc / network. можливі також параметри nis або nisplu, що визначають використовувати Network Information System (NIS) щоб знайти адресу. Порядок, в якому перераховані сервіси, визначає послідовність їх опитування.
Якщо згідно /etc/nsswitch.conf запит відправляється DNS, то буде використано стандартні з файлу /etc/resolv.conf, який визначає які сервери DNS використовувати. Ось типовий приклад файлу /etc/resolv.conf:root@DNS:~# cat /etc/resolv.conf
nameserver 192.168.1.1
nameserver 192.168.1.2
domain examle.com
Директива nameserver визначає адресу сервера доменних імен, який буде виконувати рекурсивні запити resolver. В даному файлі вказано використовувати північ імен спочатку 192.168.1.1 потім, якщо перший не зміг обробити запит, 192.168.1.2. Рекомендується не використовувати більше 3х параметрів nameserver. Якщо опція nameserver не задана, то Резолвер спробує з'єднатися з сервером на локальному хості. Параметр domain визначає заданий за замовчуванням ім'я домену, яке буде підставлена, коли DNS не вдасться знайти ім'я хоста. Існує так само опція search, яка задає додаткові домени, в яких необхідно провести пошук і дозвіл імені хоста. Опції search і domain не можна використовувати спільно.
Крім кеша на ДНС сервері, існують кеші інтернет-браузерів, кеші Резолвер. Досить прозору картину надає Wikipedia:
Запити DNS
У DNS є такі типи запитів: ітеративний (він же прямий), зворотний і рекурсивний.
Ітеративний (він же прямий, він же нерекурсивний) запит посилає доменне ім'я DNS сервера і просить повернути або IP адреса цього домену, або ім'я DNS сервера, авторитативні для цього домену. При цьому, сервер DNS опитує інші сервери для отримання відповіді. Так працюють кореневі і TLD сервери.
Рекурсивний запит посилає DNS сервера доменне ім'я і просить повернути IP адреса запитаного домену. При цьому сервер може звертатися до інших DNS серверів.
Зворотний запит посилає IP і просить повернути доменне ім'я.
Будь-DNS-server повинен відповідати на ітеративні запити. Можливо налаштувати DNS відповідати і на рекурсивні запити. Якщо DNS не налаштований відповідати на рекурсивні запити, він обробляє їх як ітеративні.
Зазвичай, провайдер видає в локальній мережі варто DNS-сервер, що обробляє рекурсивні запити, а так же, швидше за все, він налаштований на кешування запитів, що заощаджує трафік і знижує навантаження на мережу. Схему взаємодії клієнта і DNS серверів можна представити наступною картинкою:
Давайте розберемося, що тут намальовано по кроках:
1. Клієнт (Браузер, поштовий клієнт, або будь-яке інше додаток) відправляє запит Резолвер, Резолвер на підставі зазначених конфігов визначає адресу налаштованого сервера імен.
2. Резолвер надсилає запит вказаному серверу імен.
3. Сервер імен приймає даний рекурсивний запит і, тому не має інформації ні про домен, ні, можливо, навіть про зону name., відправляє рекурсивний (або нерекурсивний в залежності від налаштувань) запит серверу, що відповідає за кореневу зону.
4. Сервер корневої зони і не виконує жодних рекурсивні запити, в результаті обробляє цей запит як інтерактивний і повертає ім'я та адресу сервера, авторитетного за зону name.
5. Сервер послідовно продовжує запитувати авторитативні сервера для наступних зон, в порядку убування рівня зон в імені
6. поки не отримує задовільну відповідь, даних кроків може бути більше, в залежності від довжини доменного імені
7. і «вкладеності» доменних імен.
8. У підсумку, сервер отримує необхідну відповідь від сервера імен, що зберігає необхідну ресурсну запис про хості.
9. Сервер провайдера локальної мережі повертає Резолвер клієнта запитані дані.
Зазвичай, кількість кроків скорочено до мінімуму, тому що на шляху проходження запитів зустрічається кешуючий сервер, який зберігає необхідну інформацію в кеші. У даній схемі може виникнути питання: яким чином локальний DNS сервер, який отримав рекурсивний запит від Резолвер, вибирає DNS-сервер зі списку авторитативні? Існує безліч кореневих DNS-серверів в мережі Інтернет, якого з кореневих серверів наш DNS-сервер відправить запит?
Для вирішення даного питання DNS-сервери BIND використовують метрику, звану часом відгуку (roundtrip time, або RTT), для вибору серед авторитативні DNS-серверів однієї зони. RTT визначає затримку, з якою приходить відповідь на запити від віддаленого сервера. Кожен раз, при передачі запиту віддаленим сервером DNS-сервер BIND запускає внутрішній таймер. Таймер зупиняється при отриманні відповіді, і метрика фіксується локальним сервером. Якщо доводиться вибирати один з декількох авторитативні серверів, вибір падає на сервер з найменшим показником RTT.
До того як BIND вперше послав запит якого-небудь сервера і отримав від нього відповідь, віддаленого сервера присвоюється випадкове значення RTT, яке менше, ніж всі інші, отримані на підставі вимірів. Таким чином, DNS BIND гарантовано опитає все авторитативні сервери для певної зони випадковим чином, перш ніж почне вибирати кращий на підставі метрики.
Відповіді DNS сервера
Відповіді DNS бувають наступного типу:
• Авторитативна відповідь (authoritative response) приходить від серверів, що є відповідальними за зону.
• Неавторитативна відповідь (non authoritative response) приходить від серверів, котрі не відповідають за зону (від кешуючого).
Відповідь DNS зазвичай містить таку інформацію:
• Запис заголовка — службову інформацію про запит.
• Запис запиту — повторяє відправлений запит.
• Запис відповіді — власне, сама відповідь.
• Записи авторитетних серверів — інформацію про авторитетні сервери, що зберігають інформацію по поточному запиту.
• Додаткова інформація — додаткові записи, наприклад адреси DNS-серверів.
Вищенаписане наочно підтверджується утилітою dig:
root@DNS:~# dig ya.ru
; <<>> DiG 9.7.3 <<>> ya.ru (раздел заголовка)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<
Зворотне перетворення імен
DNS використовується в першу чергу для перетворення доменних імен в IP-адреси, але він також може виконувати зворотний процес, званий Зворотне перетворення імен або зворотним відображенням. Оскільки записи в прямій базі DNS структуровані ієрархічно по доменних іменах, DNS не може ефективно виконувати пошук по IP адресою в такій базі. Для зворотного перетворення в DNS використовується спеціальний домен in-addr.arpa. Ресурсні записи в даному домені в поле Name містять IP-адреси, в поле Type - PTR, а в поле Data - FQDN-имя відповідне даному IP.
На схемі представлена структура домена arpa. Думаю, що тут все досить наочно. Домен arpa. має 2 поддомена in-addr і ip6, що відповідають за IPv4 і IPv6 адреси відповідно. Домен in-addr.arpa. має від *.0.in-addr.arpa. до *.255.in-addr.arpa. піддоменів, кожен з яких так само має по 256 піддоменів.
З метою зменшення обсягу небажаної кореспонденції (спаму) багато поштові сервери можуть перевіряти наявність PTR запису для хоста, з якого відбувається відправка. В цьому випадку PTR запис для IP адреси повинна відповідати імені відправляє поштового сервера, яким він представляється в процесі SMTP сесії.
Наочно наведену схему можна представити командами:
[root@DNS~]# dig www.ru
...
;; QUESTION SECTION:
;www.ru IN A
;; ANSWER SECTION:
www.ru 52119 IN A 194.87.0.50
...
[root@DNS~]# dig -x 194.87.0.50
...
;; QUESTION SECTION:
;50.0.87.194.in-addr.arpa. IN PTR
;; ANSWER SECTION:
50.0.87.194.in-addr.arpa. 30385 IN PTR www.ru
....
При цьому, команду dig -x 194.87.0.50 правильніше буде представити як dig 50.0.87.194.in-addr.arpa., Тобто записи в піддоменів *.in-addr.arpa. представлені в так званої зворотної нотації (або reverse формі), тобто хосту з IP 194.87.0.50 буде відповідати PTR-запис, що має FQDN 50.0.87.194.in-addr.arpa., яка в свою чергу вказує на домен www.ru Хочеться відзначити, що найчастіше за зворотну зону і її редагування відповідає постачальник інтернету.
Як і обіцяв, описую ресурсну запис PTR в домені IN-ADDR.ARPA, відповідна наведеної вище записи А для машини www.ru. матиме такий вигляд:
50.0.87.194 IN PTR www.ru
Ім'я 50.0.87.194 не закінчується точкою і тому є відносним. Питання: відносним щодо чого? Ні в якому разі не щодо "www.ru". Для того щоб цей запис був FQDN, домен за замовчуванням повинен називатися «IN-ADDR.ARPA.». Цього можна домогтися або помістивши записи PTR в окремий файл, в якому доменне ім'я зони за замовчуванням - IN-ADDR.ARPA. (Заданий в файлі початкового завантаження демона named), або змінивши цей домен за допомогою директиви $ ORIGIN. Якщо домен за замовчуванням визначено як 0.87.194.IN-ADDR.ARPA., То запис можна уявити так: 80 IN PTR www.ru
Реєстрація доменних імен
У двох словах хотів би торкнутися питання реєстрації доменних імен.
Реєстрація доменів - це процедура, за допомогою якого клієнт повідомляє реєстратору, яким DNS-серверів слід делегувати піддомен, і також постачає реєстратора контактної і платіжною інформацією. Реєстратор передає інформацію до відповідного реєстру. Найчастіше, це процес внесення в реєстр зони першого рівня (тобто в TLD зони ru, com або ін.), Записи про новий доменному подімені.
Реєстратор доменних імен - це організація, що має повноваження створювати (реєструвати) нові доменні імена і продовжувати термін дії вже існуючих доменних імен в домені, для якого встановлено обов'язкової реєстрації.
Рівні доменів, для яких необхідна обов'язкова реєстрація особи, відповідальної за домен, такі:
Кореневої домен
Всі домени першого рівня (TLD)
Деякі домени другого рівня (наприклад, com.ru або co.uk)
Реєстратором для кореневого домена є організація ICANN. Щоб стати реєстратором доменів в зонах другого рівня (.com.net.org.biz.info.name.mobi.asia.aero.tel.travel.jobs...), необхідно отримати акредитацію ICANN.
Правила реєстрації в міжнародних (gTLD - com., Org, і ін.) Доменах встановлюються ICANN. Правила реєстрації в національних (ccTLD - ru, us і ін.) Доменах встановлюються їх реєстраторами та / або органами влади відповідних країн, наприклад єдині правила для всіх реєстраторів в доменах.ru, і.рф задаються Координаційним центром національного домену мережі Інтернет. Для багатьох доменів (в тому числі і для ru) реєстратор не єдиний. При наявності декількох реєстраторів все вони повинні використовувати єдину (централізовану або розподілену) базу даних для виключення конфліктів і забезпечення унікальності доменного імені.
Послуга реєстрації домену в більшості випадків платна, ціну та умови реєстрації визначає реєстратор. Для реєстрації домену, необхідно вибрати вільне ім'я і відправити заявку на реєстрацію у одного з реєстраторів (наприклад nic.ru), оплатити надання послуги. Після підтвердження реєстрації, необхідно в інтерфейсі реєстратора визначити (делегувати) dns сервера, швидше за все це будуть DNS вашого хостера.
На завершення статті хочу відзначити так само про таке маркетинговому аспекті, що іноді домени другого рівня називають іменами доменів ПЕРШОГО рівня, тим самим «опускаючи» значення кореневого домена і приймаючи за кореневої домен - домени TLD.
Так само хочу відзначити, що доменну адресу і IP-адреса не тотожні - один IP-адреса може мати безліч імен, що дозволяє підтримувати на одному комп'ютері безліч веб-сайтів (це називається віртуальний хостинг). Зворотне теж справедливо - одному імені можна порівнювати безліч IP-адрес: це дозволяє створювати балансування навантаження.
Резюме
Отже, ми постарався якомога зрозуміліше описати роботи доменної системи імен. Сподіваюся, це вийшло. Ми розглянули ієрархічну структуру бази даних DNS, а так само розглянули процеси взаємодії клієнтів і серверів DNS, а так же різновиди серверів DNS. У наступній статті я розгляну практичні питання установки і настройки DNS сервера BIND на Linux. Буду радий Вашим коментарям.
Що ще почитати:
man (5) resolver: http://www.opennet.ru/man.shtml?topic=resolver&category=5&russian=0
man (3) gethostbyname: http://www.opennet.ru/cgi-bin/opennet/man.cgi?topic=gethostbyname&category=3
Linux Network Administrators Guide v2 Russian: завантажити.
RFC882, 1035, 1183
Переклад виконано з статті mcsim85( Хабр) Про всяк випадок посилання на оригінал http://www.k-max.name/linux/dns-server-bind/.
Кешуючий сервер імен
Кешуючий сервер імен не авторитетний для будь-яких доменів, окрім 0.0.127.in- addr.arpa (localhost). Він шукає імена як всередині, так і за межами ваших зон, як на первинних, так і на підлеглих серверах. У відмінності від них, кешуючий сервер ініціює пошук імен в межах вашої зони, опитуючи один з первинних або підлеглих серверів.
Файли необхідні для установки простого кешуючого серверу імен:
named.conf
db.127.0.0
db.cache
Скрипт named
Конфігурація файлу “/etc/named.conf” для простого кешуючого серверу імен.
Використовуйте цю конфігурацію для всіх серверів у вашій мережі, які не виступають як основний або підлеглий серверу імен. Установка простого кешуючого сервера на локальній клієнтській машині зменшить завантаження первинного серверу. Багато користувачів, що використовують dialup з'єднання, можуть використовувати цю конфігурацію. Створіть файл named.conf (touch /etc/named.conf) і додайте в нього наступні рядки:
options {
directory "/var/named";
forwarders { 208.164.186.1; 208.164.186.2; };
forward only;
};
//
// а caching only nameserver config
zone "." in {
type hint;
file "db.cache";
};
zone "0.0.127.in-addr.arpa" in {
type master;
file "db.127.0.0";
};
В рядку “forwarder” 208.164.186.1 і 208.164.186.2 це IP адреси ваших основного (Master) і підлеглого (Slave) BIND/DNS серверів. Це можуть бути також адреси DNS серверів вашого провайдера або взагалі будь-якого іншого серверу імен.
Для поліпшення безпеки вашого BIND/DNS серверу ви можете заборонити вашому серверу контактувати із сторонніми серверами, якщо свої сервери не працюють або не відповідають. З опцією “forward only”, встановленою у файлі “named.conf”, сервер імен не контактуватиме з іншими серверами для пошуку інформації, якщо серверу на які перенаправляються запити не відповідають.
Конфігурація файлу “/var/named/db.127.0.0” для простого кешуючого серверу імен.
Використовуйте цю конфігурацію для всіх серверів у вашій мережі, які не виступають як основний або підлеглий сервер імен. Файл “db.127.0.0” розповсюджується на мережу loopback. Створіть його в “/var/named/”.
Створіть файл db.127.0.0 (touch /var/named/db.127.0.0) і внесіть в нього наступні рядки:
$TTL 345600
@ IN SOA localhost. root.localhost. (
00; Serial
86400; Refresh
7200; Retry
2592000; Expire
345600 ); Minimum
IN NS localhost.
1 IN
PTR localhost.
Конфігурація файлу “/var/named/db.cache” для простого кешуючого серверу імен.
Перед запуском вашого DNS серверу необхідно узяти файл “db.cache” і помістити його в каталог “/var/named/”. “db.cache” визначає сервер кореневої зони.
Використовуйте наступні команди на іншому UNIX комп'ютері для запиту нового файлу db.cache для вашого DNS серверу або візьміть його з вашого Red Hat Linux CD-ROM:
Для запиту нового файлу db.cache для вашого DNS серверу використовуйте наступну команду:
[root@deep]# dig @.aroot-servers.net. ns > db.cache
Не забудьте скопіювати файл db.cache в каталог “/var/named/” на вашому сервері після отримання його з Інтернет.
ЗАУВАЖЕННЯ. Внутрішні адреси, подібні 192.168.1/24, не включаються у файли конфігурації DNS з міркувань безпеки. Дуже важливо, щоб між внутрішніми хостами і зовнішніми не існував DNS.
Основний сервер імен.
Первинний майстер сервер імен читає файл з даними про зону і відповідає за цю зону.
Файли необхідні для настройки первинного майстер серверу імен:
named.conf
db.127.0.0
db.208.164.186
db.openna
db.cache
Скрипт named
Конфігурація файлу “/etc/named.conf” для первинного майстра серверу
Використовуйте цю конфігурацію для серверів, які виступають як майстер сервера імен. Після компіляції DNS, вам необхідно встановити первинне доменне ім'я серверу. Ми використовуємо “openna.com”, як приклад домена, припускаючи, що використовуємо IP мережу з адресою 208.164.186.0. Для цього, додайте наступні рядки у файл “/etc/named.conf”.
Створіть файл named.conf (touch /etc/named.conf) і додайте наступне:
options {
directory "/var/named";
fetch-glue no;
recursion no;
allow-query { 208.164.186/24; 127.0.0/8; };
allow-transfer { 208.164.186.2; };
transfer-format many-answers;
};
// Ці файли не прив'язані до якої-небудь зони
zone "." in {
type hint;
file "db.cache";
};
zone "0.0.127.in-addr.arpa" in {
type master;
file "db.127.0.0";
};
// Це файл вашої первинної зони
zone "openna.com" in {
type master;
file "db.openna ";
};
zone "186.164.208.in-addr.arpa" in {
type master;
file "db.208.164.186";
};
Опція “fetch-glue no” може використовуватися в зв'язці з опцією “recursion no” для запобігання зростання і руйнування кеша серверу. Також, відключення рекурсії переведе ваш сервер імен в пасивний режим, говорячий йому ніколи не посилати запити від імені іншого серверу імен або ресолвера. Не рекурсивні серверу імен дуже складно обдурити за допомогою атаки spoof, оскільки вони не відправляють ніяких запитів і отже не кешують ніяких даних.
В рядку “allow-query”, 208.164.186/24 і 127.0.0/8 визначаються IP адреси, яким дозволено здійснювати звичайні запити до серверу.
В рядку “allow-transfer”, 208.164.186.2 це IP адреса, якій дозволяється приймати пересилки зон з серверу. Ви повинні забезпечити, щоб тільки ваші вторинні сервери могли одержувати зони з серверу. Ця інформація часто використовується спамерами і IP spoofers.
ЗАУВАЖЕННЯ. Опції “recursion no”, “allow-query” і “allow-transfer” у файлі “named.conf” використовуються для забезпечення більшої безпеки серверу імен.
Конфігурація файлу “/var/named/db.127.0.0” для основного і допоміжного серверів імен.
Цей файл може бути використаний як на основному, так і на допоміжному серверах. Файл “db.127.0.0” описує мережу loopback. Створіть файл db.127.0.0 (touch /var/named/db.127.0.0) і додайте в нього наступну інформацію:
; Revision History: April 22, 1999 - admin@mail.openna.com
; Start Authority (SOA) records.
$TTL 345600
@ IN SOA deep.openna.com. admin.mail.openna.com. (
00; Serial
86400; Refresh
7200; Retry
2592000; Expire
345600 ); Minimum
; Name Server (NS) records.
NS deep.openna.com.
NS mail.openna.com.
; only One PTR record.
1 PTR localhost.
Конфігурація файлу “/var/named/db.208.164.186” для основного серверу імен.
Використовуйте цю конфігурацію для серверу, який виступає у вашій мережі, як основний сервер імен. Файл “db.208.164.186” прив'язує імена вузлів до адрес. Створіть наступний файл db.208.164.186 (touch /var/named/db.208.164.186) в каталозі “/var/named/”:
; Revision History: April 22, 1999 - admin@mail.openna.com
; Start Authority (SOA) records.
$TTL 345600
@ IN SOA deep.openna.com. admin.mail.openna.com. (
00; Serial
86400; Refresh
7200; Retry
2592000; Expire
345600 ); Minimum
; Name Server (NS) records.
NS deep.openna.com.
NS mail.openna.com.
; Addresses Point to Canonical Names (PTR) for Reverse lookups
1 PTR deep.openna.com.
2 PTR mail.openna.com.
3 PTR www.openna.com.
Конфігурація файлу “/var/named/db.openna” для основного серверу імен
Використовуйте цей файл для серверу виступаючого в ролі основного серверу імен. Файл “db.openna” прив'язує адреси до імен вузлів. Створіть файл db.openna в каталозі “/var/named/” (touch /var/named/db.openna):
; Revision History: April 22, 1999 - admin@mail.openna.com
; Start Authority (SOA) records.
$TTL 345600
@ IN SOA deep.openna.com. admin.mail.openna.com. (
00; Serial
86400; Refresh
7200; Retry
2592000; Expire
345600 ); Minimum
; Name Server (NS) records.
NS deep.openna.com.
NS mail.openna.com.
; Mail Exchange (MX) records.
MX 0 mail.openna.com.
; Address (А) records.
localhost А 127.0.0.1
deep А 208.164.186.1
mail А 208.164.186.2
www А 208.164.186.3
; Aliases in Canonical Name (CNAME) records.
;www CNAME deep.openna.com.
Конфігурація файлу “/var/named/db.cache” для основного і підлеглого серверів імен
Перед запуском вашого DNS серверу ви повинні зробити копію файлу “db.cache” і помістити його в каталог “/var/named/”. Він говорить серверу, які сервери відповідають за кореневу зону.
Використовуйте наступну команду на іншому UNIX комп'ютері для отримання нового файлу db.cache або візьміть його з вашого Red Hat Linux CD-ROM:
[root@deep /]# dig @.aroot-servers.net. ns > db.cache
Не забудьте скопіювати файл “db.cache” в каталог “/var/named/” після отримання його з Інтерент.
Вторинний сервер імен.
Основне призначення вторинного серверу імен – розділення навантаження з основним сервером, і обробка запитів, якщо основний сервер не працює. Вторинний сервер завантажує дані через мережу з іншого серверу імен (звичайно основного, але може і з іншого вторинного). Цей процес називається пересилкою зони.
Файли необхідні для установки вторинного серверу імен:
named.conf
db.127.0.0
db.cache
скрипт named
Конфігурація файлу “/etc/named.conf” для вторинного серверу імен
Використовуйте цю конфігурацію для серверу виконуючого роль вторинного серверу імен. Ви повинні модифікувати файл “named.conf” на вторинному сервері імен. Змініть кожне входження master на slave, зробивши виключення для “0.0.127.in-addr.arpa”, і додайте рядок з IP адресою первинного серверу, як це показано нижче.
Створіть файл named.conf (touch /etc/named.conf) і додайте в нього:
options {
directory "/var/named";
fetch-glue no;
recursion no;
allow-query { 208.164.186/24; 127.0.0/8; };
allow-transfer { 208.164.186.1; };
transfer-format many-answers;
};
// These files are not specific to any zone
zone "." in {
type hint;
file "db.cache";
};
zone "0.0.127.in-addr.arpa" in {
type master;
file "db.127.0.0";
};
// These are our slave zone files
zone "openna.com" in {
type slave;
file "db.openna";
masters { 208.164.186.1; };
};
zone "186.164.208.in-addr.arpa" in {
type slave;
file "db.208.164.186";
masters { 208.164.186.1; };
};
Цей файл говорить серверу, що він є вторинним для зони “openna.com” і повинен брати інформацію про цю зону з вузла “208.164.186.1”. Вторинному серверу імен немає необхідності одержувати всі файли (db) через мережу, оскільки db файли “db.127.0.0” і “db.cache” однакові як для основного так і для вторинних серверів, тому ви можете створити їх локальні копії на вторинному сервері.
Копіюйте файл “db.127.0.0” з основного серверу на підлеглий.
Копіюйте файл “db.cache” з основного серверу на підлеглий.
Конфігурація скрипта “/etc/rc.d/init.d/named” для всіх типів серверів імен
Конфігуруйте ваш скрипт “/etc/rc.d/init.d/named” для запуску і зупинки демона BIND/DNS. Цей скрипт може бути використаний для всіх типів серверів (кешуючого, основного або підлеглого).
Створіть наступний скрипт named (touch /etc/rc.d/init.d/named):
#!/bin/sh
#
# named Цей скрипт командного інтерпретатора відповідає за запуск і
# зупинку (BIND DNS серверу).
#
# chkconfig: - 55 45
# description: named (BIND) is а Domain Name Server (DNS)
# that is used to resolve host names to IP addresses.
# probe: true
# Source function library.
. /etc/rc.d/init.d/functions
# Source networking configuration.
. /etc/sysconfig/network
# Check that networking is.
[ ${NETWORKING} = "no" ] && exit 0
[ -f /usr/sbin/named ] || exit 0
[ -f /etc/named.conf ] || exit 0
RETVAL=0
# See how we were called.
case "$1" in
start)
# Start daemons.
echo -n "Starting named: "
daemon named
RETVAL=$?
[ $RETVAL -еq 0 ] && touch /var/lock/subsys/named
echo
;;
stop)
# Stop daemons.
echo -n "Shutting down named: "
illproc named
RETVAL=$?
[ $RETVAL -еq 0 ] && rm -f /var/lock/subsys/named
echo
;;
status)
/usr/sbin/ndc status
exit $?
;;
restart)
$0 stop
$0 start
;;
reload)
/usr/sbin/ndc reload
exit $?
;;
probe)
# named знає як правильно перезавантажуватися; ми не хочемо використовувати
# linuxconf для перезавантажень
/usr/sbin/ndc reload >/dev/null 2>&1 || echo start
exit 0
;;
*)
echo "Usage: named {start|stop|status|restart}"
exit 1
esac
exit $RETVAL
Зараз, треба зробити цей скрипт виконуваним і змінити доступ, прийнятий за замовчанням:
[root@deep]# chmod 700 /etc/rc.d/init.d/named
Створіть символічні rc.d посилання для BIND/DNS:
[root@deep]# chkconfig --add named
Скрипт BIND/DNS автоматично не стартуватиме, коли ви перезавантажуєте сервер. Щоб змінити це, виконайте наступну команду:
[root@deep]# chkconfig --level 345 named on
Запустіть уручну ваш DNS сервер:
[root@deep]# /etc/rc.d/init.d/named start
Starting named: [ OK ]
Завдання до виконання роботи
1. Завантажте ПК з Лінукс.
2. Отримайте пароль адміністратора.
3. Створіть простий кешуючий сервер.
4. Перевірте його функціонування.
5. Створіть первинний сервер імен.
6. Перевірте його функціонування.
7. Оформити звіт.