Рашид Ачілов
Створюємо зони DNS
Domain Name System – своєрідна "нервова система" мережі Інтернет. Саме завдяки їй ви, набираючи, потрапляєте на сайт журналу «Системний адміністратор», а не кудись ще. Як створити, налаштувати та запустити DNS-сервер для невеликого підприємства?
Структура DNS
В даний час Інтернет - це величезна мережа, в яку входять мільйони вузлів, які розташовані по всьому світу. Для того щоб запит, зроблений з одного комп'ютера, міг досягти мети, розташованої на іншому комп'ютері, потрібно насамперед цю мету поставити. Можна, звичайно, вказати IP-адресу безпосередньо. Якщо він вам відомий, звісно. Але тут існує можливість дуже просто помилитися - інформація про те, де знаходиться потрібна вам адреса вже могла змінитися, і в кращому випадку ви побачите повідомлення про те, що адреса не знайдена, а в гіршому - опинитеся на сайті, який абсолютно не має жодного стосунку до тому, що було потрібне. Надійніше та простіше буде звернутися до системи, яка зберігає відповідність між символічними іменами типу www.сайт та IP-адресами, що відповідають їм у Наразі(У нашому випадку 217.144.98.99). DNS і є такою системою. Оскільки від її успішного функціонування залежить робота всієї мережі Інтернет, ця система функціонує за принципом розподіленої бази даних – є «добре відомі» сервери, числом 13, їх ще називають «кореневими» (root servers), що містять інформацію про сервери, що містять інформацію про сервери і т. д. Як будинок, який збудував Джек.
Вся мережа Інтернет, яка описується зоною "." (Точка) ділиться на так звані TLD (Top Level Domains – домени верхнього рівня), що розподіляються або за функціональною, або за географічною ознакою. Існує також термін primary domain - "первинний домен", або "домен першого рівня", але цей термін використовується значно рідше. Розподіл за географічною ознакою здійснюється відповідно до ISO 3166, що встановлює для всіх країн світу дво- та трилітерні коди. Розподіл за функціональною ознакою здійснюється при необхідності створення нового TLD. Тут слід зазначити, що всіма питаннями щодо TLD займається ICANN (Internet Corporation for Assigned Names and Numbers), і саме цей орган вирішує чи створювати новий TLD.
Кореневі сервери самі по собі містять лише посилання на сервери, що містять інформацію про зони другого рівня, які у свою чергу містять інформацію про сервери, що містять інформацію про зони третього рівня і т. д. У більшості випадків ієрархія вичерпується на третій-четвертій зоні. Але не тому, що тут закладено якесь обмеження. Просто запам'ятовувати складні імена анітрохи не простіше IP-адрес.
Таким чином, процес пошуку інформації, припустимо, про веб-сервер www.granch.ru, буде виглядати наступним чином:
- Клієнт звертається до свого сервера DNS, адреса якого була задана системним адміністратором із запитом «Скажи мені адресу, відповідну імені www.granch.ru».
- Сервер DNS знає адреси серверів, з яких слід починати пошук у тому випадку, якщо в його кеші не зберігається запитана інформація, тому він звертається до одного з них.
- Кореневий сервер надсилає йому адресу сервера, що відповідає за зону.
- Сервер DNS звертається до сервера зони.
- Сервер зони.ru надсилає йому адресу сервера, який відповідає за зону granch усередині його зони.
- Сервер DNS звертається до сервера зони granch.
- І нарешті, сервер зони granch.ru повідомляє йому адресу, що відповідає імені www. У разі це буде 81.1.252.58.
Цей процес проілюстрований на рис. 1 де цифри позначають послідовність запитів.
Як вбудувати інформацію в структуру DNS?
Перш ніж вмикатися в будь-яку систему, потрібно мати певне уявлення про те, куди і яким чином вмикатися.
Куди вбудовуємо?
За різні TLD відповідають різні сервери, і якщо за географічні доменивідповідає, як правило, один сервер (точніше кажучи, одна організація), то за функціональні домени може відповідати, взагалі кажучи, необмежену кількість так званих реєстраторів, тобто компаній, які уклали спеціальні договори з ICANN про те, що саме вони будуть реєструвати імена в деяких функціональних доменів. Короткий описфункціонального домену та адреса його реєстратора наведені у .
Якщо реєстраторів кілька, то дається адреса основної (наприклад, VeriSign для домену.com). Домени.gov і.mil зарезервовані виключно за американським урядом і американськими військовими організаціями, причому резервування.gov оформлене відповідним RFC - RFC 2146 . Повний списоквсіх існуючих в даний момент географічних TLD із зазначенням реєстратора домену і необхідної контактної інформації можна подивитися в . Хоча якщо, скажімо, в зоне.com можна вибирати з величезного списку, то для зон.ru і.su РУЦЕНТР, без варіантів.
Тут слід зазначити кілька моментів. Фактично зона.su відноситься до неіснуючої держави Радянський Союз (Soviet Union), хоча продовжує обслуговуватися і відкрита для реєстрації. Реєстрація там досить дорога – 100 доларів за реєстрацію чи підтримку на рік.
Немає пріоритету, згідно з яким одна організація або людина має перевагу при реєстрації домену над іншим. Один американський бізнесмен, котрий займався виробництвом пластикових вікон, зареєстрував домен windows2000.com. Коли те саме спробувала зробити Microsoft, вона з подивом виявила, що це ім'я вже зайняте, і за нього компанії довелося викласти велику суму. Існує навіть поняття «кіберсквотерство» – процес реєстрації доменів з метою їхнього подальшого перепродажу. РУЦЕНТР теж вирішив прикласти до цього руку, і за новими правилами, які вводяться з 1 червня 2006 року, домени, що звільняються, виставляються на «аукціон доменних імен» і передаються тому, хто дасть більше. Імена утримуються на «аукціоні» протягом року, якщо за цей термін ніхто на нього не претендує, ім'я виводиться у вільну реєстрацію.
При створенні перерахованих вище TLD планувалося також створення TLD .xxx для сайтів з тематикою «для дорослих». ICANN відхилила цю пропозицію. Нещодавно його було винесено на повторне голосування, і ICANN знову його відхилила. Натомість з'явився TLD .tel, розрахований на використання одночасно у комп'ютерах та мобільних пристроях.
Існує RFC 1480, що описує правила реєстрації імен домену. Правила ці надзвичайно громіздкі і заплутані і передбачають створення імен із 6-7 рівнів типу Hamilton.High.LA-Unified.K12.CA.US
Як вбудовуємо?
Раніше все було набагато складніше. Для реєстрації зони.com мені довелося заповнювати безліч текстових форм - з даними на організацію, з даними на контактних осіб... Форми ці потім надсилалися на спеціальні адреси, звідки приходили відповіді – прийняті чи ні. Потім попередньо сформований файл зони тестувався, і знову ж таки поштою надходило повідомлення про те, успішно завершено тестування чи ні.
Нині все стало набагато простіше. І Network Solutions, і РУЦЕНТР обзавелися веб-інтерфейсами, за допомогою яких усе перераховане вище (за винятком, звичайно, складання файлу зони) можна зробити кількома кліками миші. Усі дані можна виправити, доповнити чи видалити будь-якої миті. Раніше з РУЦЕНТРом потрібно укладати договір на обслуговування, але починаючи з 1 червня 2006 року в дію вводяться нові правила, згідно з якими достатньо зареєструватися на їхньому сайті. Закордонні реєстратори, як правило, обходяться кредитними картками, але якщо домен з будь-якої причини не може бути зареєстрований, гроші будуть повернуті не раніше, ніж через три дні.
Реєстратору потрібно вказати IP-адресу та маску підмережі сервера, на якому буде запущено програму DNS-сервера, і який міститиме основну базу даних, яку створюється і редагується вами в міру необхідності. Цей сервер називатиметься первинним сервером (master server). Крім того, потрібно вказати як мінімум одну IPадресу сервера, що містить резервну копіюбази у разі відмови первинного сервера. Такі сервери називають вторинними серверами (slave servers). Щоб довго не думати про те, де розмістити вторинний DNS, РУЦЕНТР пропонує розмістити його на їхньому майданчику. Вартість послуг РУЦЕНТРу становить 15 доларів на рік за домен у зонах.ru, .net, .com, .org, 50 доларів за домен у зонах.biz, .info, 100 доларів за домен у зоні. підтримку вторинного DNSу будь-якій (у тому числі й зареєстрованій не в них) зоні.
Чому вимога до наявності вторинного DNS-сервера є обов'язковою? Оскільки стабільність роботи DNS вкрай важлива для стабільності роботи мережі Інтернет в цілому, особа або організація, що реєструє домен, зобов'язана задовольняти певні умови, що стосуються стабільності роботи DNS:
- Повинно бути передбачено не менше двох серверів, які обслуговують цей домен.
- Ці сервери повинні бути доступні щонайменше 22 години на добу.
Будь-яких вимог до розміщення серверів за новими правилами не висувається, хоча раніше була потрібна наявність їх у різних IP-мережах.
www.krokodil.ru
Отже, припустимо, ми хочемо створити сайт www.krokodil.ru (на момент написання статті це ім'я було вільним), присвячений розведенню крокодилів у домашніх умовах. Підключення за виділеною лінією є, мережа класу С, а саме 212.20.5.0 – 212.20.5.255 (цей діапазон в даний час вільний) провайдером виділено. Цей приклад дещо нехарактерний для сьогодення з його дефіцитом IP-адрес, але він узятий спеціально для того, щоб розглянути створення зворотної зони. Також буде розглянуто варіант із підключенням через мережу 212.20.5.0/31. Внутрішня мережа нашої крокодилячої контори складається з шести комп'ютерів і буде відокремлена від Інтернету firewall-proxy і т.д. під керуванням FreeBSD. Що нам знадобиться для здійснення задуманого?
Насамперед зазначу, що існують варіанти, які не передбачають будь-яких знань DNS – все розміщується на майданчику провайдера, все обслуговується провайдером, вам надається лише веб-інтерфейс. Ця послуга надзвичайно популярна за кордоном, але дуже затребувана в Росії. Її опис виходить за межі цієї статті, тому розглядати її я не буду.
По-перше, нам знадобиться програма DNS-сервера. На сьогоднішній день лише одна програма реалізує необхідний набір функцій. Це DNS-сервер BIND, що розповсюджується ISC (Internet System Consortium Inc., ) - Некомерційною організацією, яка займається розробкою серверів BIND, DHCP, INN і NTP. Якщо він відсутній у вашій системі, його потрібно завантажити та встановити. FreeBSD поставляється разом з BIND 9.3.2, тому в цій статті розглядатиметься саме ця версія. Слід зазначити, що для версій BIND 8.x опис конфігурації, що наводиться нижче, абсолютно неприйнятно, оскільки формат конфігураційних файлів BIND 8.x докорінно відрізняється від формату конфігураційних файлів BIND 9.x.
По-друге, знадобиться розподілити виділені нам IP-адреси та наділити адресами внутрішні комп'ютери. Тут все надзвичайно просто: нехай 212.20.5.1 – шлюз провайдера, 212.20.5.2 – адреса UNIX-сервера, 10.87.1.0/24 – внутрішня підмережа, в якій з 1-ї до 6-ї – робочі станції, 254 – адреса внутрішнього інтерфейсусервера. Решта адрес буде зарезервована для майбутнього розширення.
По-третє, потрібно заздалегідь підготовлений файл опису зони, який визначатиме невелику кількість зовнішніх адрес: krokodil.ru – кореневий сервер зони, www.krokodil.ru, ftp.krokodil.ru, mail.krokodil.ru та ns.krokodil.ru . Ім'я ns (nameserver) є практично традиційним найменуванням комп'ютерів, на яких працює служба DNS, хоча, звичайно, ніхто не завадить вам назвати його, наприклад, jaws.krokodil.ru. Буде визначено також імена для комп'ютерів внутрішньої мережі, доступні лише зсередини: tooth1.krokodil.ru – tooth6.krokodil.ru.
Записи DNS
Існує досить багато типів різноманітних записів, які можна поміщати в DNS. Обсяг цієї статті дозволяє розглянути лише найважливіші з них, щоб отримати повної інформаціїслід звернутися до відповідних RFC: RFC 1033 та RFC 1035 визначають формати основних записів, RFC 1122 – формат запису PTR, RFC 2782 – формат запису SRV. Ми розглянемо лише записи, які знадобляться для формування файлів зон, необхідні реєстрації домену:
- Запис SOA, що задає початок опису зони.
- Запис NS, що визначає сервер імен зони.
- Запис A, що задає відповідність між IP-адресою та іменем ( пряме перетворення).
- Запис MX, який описує параметри доставки пошти для цього комп'ютера.
- Запис CNAME задає альтернативні імена.
- Запис PTR, що задає відповідність між ім'ям та IPадресою (зворотне перетворення), використовується в описі «зворотної» зони.
Формат записів DNS загальний для всіх типів записів:
[ім'я] [клас]<тип> <данные>
- ім'я- Це ім'я об'єкта, з яким асоціюються дані;
- ttl- Час життя об'єкта;
- клас- Клас запису;
- тип- Тип запису;
- дані- Асоційовані з цим об'єктом дані.
Ім'я може набувати будь-якого значення, і в такому випадку воно вважається ім'ям об'єкта. Якщо ім'я закінчується на точку, воно вважається цілком певним, інакше наприкінці імені підставляється ім'я зони, що може бути задано двома способами:
- Завдання імені зони в директиві $ORIGIN, наприклад:
$ORIGIN krokodil.ru
- Завдання імені зони в директиві zone конфігураційного файлу BIND.
Спеціальний символ "@" означає поточне ім'я зони. Майте на увазі, що директива $ORIGIN скасовує директиву zone і діє до появи наступної директиви $ORIGIN або до кінця файлу. До появи першої директиви $ORIGIN вона вважається заданою значенню директиви zone конфігураційного файлу BIND.
Якщо ім'я задано, воно має починатися з першої позиції рядка.
TTL зазвичай опускається і задається глобально директивою $TTL. Директива $TTL для BIND 9.x є обов'язковою і, як правило, задається на початку файлу. У полі даних цієї директиви визначається час життя (в секундах) елемента, протягом якого він може знаходитися в кеші і вважатися достовірним. У цьому прикладі це дві доби (48 годин).
$TTL 172800
Клас запису може приймати одне з таких значень:
- IN- Запис ресурсів Інтернет.
- CH– запис ресурсів ChaosNet – абсолютно незнайомий російському користувачумережі, що застосовувалась на машинах фірми Symbolics.
- HS– запис ресурсів Hesiod – службового протоколу BIND.
Тип запису – одне із типів, перелічених вище.
Слід звернути увагу, що поля ім'я, ttl і клас можуть бути опущені. При цьому як їх значення приймається останнє певне значення (при цьому завдання @ буде коректним визначенням), а якщо значення не було визначено ніде, то для поля клас приймається значення за умовчанням «IN», для інших полів – призводить до повідомлення про помилку.
Окрім записів, у файлі зони можуть бути команди. Усього команд чотири – $TTL, $ORIGIN, $INCLUDE та $GENERATE. Опис команди $GENERATE наведено в документації на програму BIND, а також в і , команда $INCLUDE працює відповідно до свого написання - включає вказаний файл до поточного файлу.
Примітка: знак ";" (Точка з комою) є ознакою коментаря.
Запис SOA
Цей запис визначає початок зони. Будь-яка зона повинна починатися із запису SOA. Поява іншого запису SOA автоматично закінчує першу зону та починає другу. Формат запису SOA наведено нижче. Практично запис SOA називає зону і задає для неї деякі умовчання.
2005122001; Serial number
3600; Retry every hour
172800); Minimum 2 дні
Розберемо приклад. Знак @ у полі імені означає, що потрібно взяти ім'я зони, задане раніше директивою $ORIGIN. Клас запису – IN, тип запису – SOA. SOA – це єдиний запис, який має такий складний перелік параметрів.
Перший параметр – це адреса головного сервера імен зони. У цьому прикладі це krokodil.ru. Другий параметр – адреса електронної пошти особи, відповідальної за дану зону. Зверніть увагу, що адреса записана як username.domain, а не username@domain.
Другий параметр – це список значень, укладений у дужки. Теоретично можна його записати в один рядок, але майже я ніде цього не бачив, всюди використовується форма запису, наведена в прикладі. Список складається з п'яти елементів:
- Серійний номер зони. Цей параметр грає надзвичайно важливу рольу поширенні оновлення, виконаного на первинному серверіпо всіх його вторинних серверах. Необхідно якимось чином повідомити вторинний сервер про те, що дані на первинному сервері змінилися. Якщо первинний сервер був перезапущений, він відсилає всім вторинним серверам повідомлення про можливу зміну (DNS NOTIFY). Отримавши це повідомлення, вторинний сервер запитує серійний номер – якщо на первинному сервері серійний номер більше, ніж вторинному, вторинний сервер виконує команду оновлення зони. Крім того, вторинний сервер виконує періодичні перевірки серійного номера з тією самою метою. Тому слід запам'ятати одне просте правило: виправив зону – збільши серійний номер! Серед адміністраторів DNS поширена практика, відповідно до якої серійний номер формується так: YYYYMMDDv, де:
- YYYY, MM, DD– поточний рік (4 цифри), місяць та день відповідно
- v- Версія зони за день. Якщо вноситься кілька змін на день, число послідовно збільшується на одиницю.
Звичайно, вас ніхто не зобов'язуватиме слідувати подібній практиці. Наприклад, сервери DNS у Windows її не дотримуються, а просто нумерують її 1, 2, 3 і т.д. - Значення періоду оновлення, після якого підпорядкований сервер повинен зв'язатися з головним і перевірити, чи серійний номер зони не змінився. Якщо серійний номер змінився, підпорядкований сервер завантажить нові дані. У цьому прикладі 10800 секунд (3 години).
- Час, через який підлеглий сервер намагатиметься звернутися до головного, якщо спроба отримати новий серійний номер закінчилася невдало. У цьому прикладі 3600 секунд (одна година).
- Час, протягом якого підлеглі сервери обслуговуватимуть запити по цій зоні за тривалої відсутності головного сервера . Система має працювати, навіть якщо головний серверне працює тривалий період часу, тому у значенні даного параметра встановлено 1728000 секунд (20 діб).
- Час кешування негативних відповідей. У цьому прикладі 172800 секунд (2 доби).
Запис NS
Цей запис визначає імена серверів, що підтримують зону, тобто. провідних її основу. Тут мають бути перераховані імена первинного та всіх вторинних серверів. Зазвичай цей запис слідує безпосередньо за записом SOA. У полі дані заноситься одне значення – ім'я або IP-адреса сервера DNS-зони незалежно від того, чи вона головна чи підлегла. Усі вказані тут імена мають бути повністю визначеними, тобто закінчуватись точкою!
IN NS ns.krokodil.ru.
IN NS ns4.nic.ru
У наведеному прикладі описується спочатку головний сервер нашої зони ns.krokodil.ru, та був підлеглий сервер – вузол РУЦЕНТРа ns4.nic.ru.
Запис A
Запис типу A – це основний вміст файлів зони прямого перетворення або просто «прямої» зони, тобто видає ім'я комп'ютера за його адресою. Вона складається кожного комп'ютера. Для зручності читання ці записи зазвичай групуються в порядку зростання IP-адрес, а також групуються із записами MX, що відповідають даній IP-адресі, хоча це, звичайно, не є обов'язковим. У полі ім'я заноситься ім'я, яке призначається IP-адресою, у полі дані – IP адреса, якій призначається ім'я. За наявності адреси додаткових імен, ім'я, призначене адресою записом типу A, називають основним ім'ям.
tooth1 IN A 10.87.1.1
tooth2 IN A 10.87.1.2
tooth3 IN A 10.87.1.3
tooth4 IN A 10.87.1.4
tooth5 IN A 10.87.1.5
tooth6 IN A 10.87.1.6
У цьому прикладі описано призначення IP-адрес комп'ютерам внутрішньої мережі, яка має адресу 10.87.1.0/24. Для комп'ютерів внутрішньої мережі, як правило, немає необхідності формування будь-яких додаткових записів, за винятком хіба що CNAME.
Запис CNAME
Запис типу CNAME – це додаткова можливість DNS. Вона дозволяє призначити одній IP-адресі більше одного імені. У полі ім'я заноситься додаткове ім'я, яке призначається IP-адресою, у поле дані – основне ім'я, призначене раніше записом типу A, або інше додаткове ім'я, призначене записом CNAME. При цьому ім'я, яке стоїть у полі даних запису, називають канонічним (звідси назва запису – Canonical Name). Однією IP-адресою можна призначити необмежену кількість додаткових імен за допомогою записів CNAME, але в записах іншого типу має бути вказане ім'я, призначене записом A, а не записом CNAME. Нижче наведено приклад правильного та неправильного призначення додаткових імен.
Правильно:
ns IN A 10.87.1.1
name1 IN CNAME ns
IN MX 10 ns
Неправильно:
ns IN A 10.87.1.254
name1 IN CNAME ns
IN MX 10 name1
Записи CNAME можуть вказувати одна на іншу, але не більше семи рівнів, восьмий обов'язково повинен йти запис, який вказує на ім'я, призначене записом типу A. У літературі зустрічається рекомендація використовувати множинні записи типу A замість призначення адресою безлічі додаткових імен. З цього приводу можна сказати, що на даний момент згадується в RFC 2219 у плані «не існує абсолютних рекомендацій з цього приводу, кожен повинен вирішувати для себе, що для нього краще». Численні CNAME простіше для адміністрування, множинні A-записи легше обробляються, оскільки відбувається менше перенаправлень.
Запис MX
Запис типу MX – це другий елемент файлу зони. Цей запис розшифровується як « Mail eXchanger», і призначена для вказівки IP-адрес або імен комп'ютерів, які приймають пошту для вузла, описаного в полі name. У цьому полі може бути порожнім, а також вказано повністю або не повністю визначене ім'я. Якщо поле name порожнє або вказано не повністю визначене ім'я, то ім'я доповнюється з директиви $ORIGIN. Формування записів MX у складних випадках, коли налаштовується досить велика зона з розгалуженою схемою прийому пошти, дуже нетривіальне завдання, яка тісно переплітається з роботою програм, що використовують протокол SMTP для доставки пошти, тому ми розглянемо лише найпростіший випадок – вся пошта приймається сервером UNIX. У полі дані заносяться два значення – пріоритет та ім'я або IP-адреса комп'ютера, що приймає пошту, що направляється на даний комп'ютер. З однією IP-адресою може бути пов'язано, взагалі кажучи, необмежену кількість записів типу MX, і всі вони повинні мати різний пріоритет. Пошта направляється відповідно до пріоритету – поштовий агент сортує записи у порядку наростання пріоритетів і саме так робить спроби доставити пошту. Припустимо, ми домовилися з адміністратором вузла behemot.ru про те, що зможемо використовувати його сервер як транзитний вузол, який отримуватиме нашу пошту з метою подальшої доставки її адресатам, коли зв'язок відновиться. Тоді опис сервера krokodil.ru буде виглядати так:
krokodil.ru. IN A 212.20.5.2
IN MX 10 krokodil.ru
IN MX 50 behemot.ru
www IN CNAME krokodil.ru.
mail IN CNAME krokodil.ru.
ftp IN CNAME krokodil.ru.
Це комплексний приклад, він одразу показує використання записів MX, А та CNAME. Тут ми:
- Призначаємо адресою 212.20.5.2 ім'я krokodil.ru.
- Вказуємо, що пошту, яка надсилається за адресами типу [email protected], прийматимуть (у зазначеному порядку):
- сервер krokodil.ru;
- сервер behemot.ru
- Визначаємо додаткові імена www.krokodil.ru, mail.krokodil.ru та ftp.krokodil.ru. Зверніть увагу, що всі імена у правій частині повністю визначені, тобто закінчуються на точку. Якщо цього не зробити, то в кінці імені автоматично підставлятиме значення поточної директиви $ORIGIN. В даному випадку це призвело до появи імен типу www.krokodil.ru.krokodil.ru.
Запис PTR
Це особливий тип записів. У нашому прикладі ми «спеціально» взяли повну підсітку, щоб розглянути випадок «нормальної» роботи із записами PTR. Випадок із мережею 212.20.5.0/31 буде розглянутий трохи згодом.
Запис PTR призначений реалізації зворотного перетворення – імен в IP-адреси. Подібні перетворення дуже широко застосовуються в різних програмах, що надають доступ до деяких мережевих ресурсів: вони перевіряють відповідність прямого та зворотного перетворення і у разі розбіжності або відсутності запису PTR можуть відмовити у доступі. Зона, що містить записи PTR, називається зоною зворотного перетворення або просто «зворотною» зоною.
Записи PTR не мають жодного відношення до записів A, MX, CNAME та інших, що описують пряме перетворення. Зроблено це навмисно з метою використовувати для обох перетворень той самий набір програмних модулів. Тут, щоправда, на нас чекає складність наступного виду – цілком певне доменне ім'я виду www.krokodil.ru. «нарощує розмірність» зліва направо (тобто укрупнення вузлів йде у міру просування текстом імені зліва направо), а IP-адреса 212.20.5.2 – справа наліво. Для уніфікації програмних модулів прийняли таку умовність: всі IP-адреси – це імена, що входять до спеціального TLD in-addr.arpa. "Зонами" в цьому домені є підмережі, а ім'я зони записується у вигляді IP-адреси, що читається навпаки. Таким чином, "ім'я" нашої зворотної зони буде 5.20.212.in-addr.arpa для зворотної зони, що містить опис для зовнішньої мережі і 1.87.10.in-addr.arpa для зворотної зони, що містить опис внутрішньої мережі.
Точно так, як для використання доменного імені необхідно його зареєструвати, так і для використання зворотного перетворення необхідно зареєструвати зворотну «зону» у координатора зворотних зон. На відміну від зон прямого перетворення тут є лише один координатор, і реєстрація в нього безкоштовна. Реєстрацією зворотних зон займається RIPE NCC. Вся інформація про реєстрацію зворотної зони наведена в .
Для чого потрібно реєструвати зворотну зону? Сервер верхнього рівня зони in-addr.arpa повинен знати, що для виконання запиту зворотного перетворення йому слід звернутися до сервера, в даному випадку до нашого 212.20.5.2. Зрозуміло, будь-де реєструвати зворотну зону внутрішньої підмережі не потрібно.
Сам запис PTR виглядає дуже просто – у поле ім'я заноситься остання частина IP-адреси, у поле дані – цілком певне ім'я прямого перетворення. Звертаю увагу на останнє – ім'я, що заноситься в поле даних, має бути повністю визначеним, оскільки записи PTR самі задають зв'язок між IP-адресою та ім'ям, вони не можуть отримати нізвідки інформацію про те, до якої зони слід віднести не повністю кваліфіковане ім'я прямого перетворення .
$ORIGIN 1.87.10.in-addr.arpa
1 IN PTR tooth1.krokodil.ru.
2 IN PTR tooth2.krokodil.ru.
3 IN PTR tooth3.krokodil.ru.
4 IN PTR tooth4.krokodil.ru.
5 IN PTR tooth5.krokodil.ru.
6 IN PTR tooth6.krokodil.ru.
У цьому прикладі ми задали зворотне перетворення для комп'ютерів внутрішньої мережі. Для сервера ми запишемо один рядок (у реальному прикладідирективи $ORIGIN вказувати не треба, вони наведені тільки, щоб було зрозуміло, про яку зону йдеться):
$ORIGIN 5.20.212.in-addr.arpa
2 IN PTR krokodil.ru
Тут слід зазначити, що записи CNAME для завдання множинної зворотної відповідності не використовуються, тому при запиті «яке ім'я відповідає адресі 212.20.5.2» результатом завжди буде krokodil.ru незалежно від кількості встановлених для нього псевдонімів.
Чим відрізнятиметься випадок, коли провайдер виділяє блок 212.20.5.0/31 замість повноцінної підмережі? З погляду формування всіх записів, крім PTR, нічим. Процедура створення прямої зони та її реєстрації не залежить від кількості адрес, тим більше, що для більшості випадків багато адрес і не треба. Проте з погляду записів PTR різниця є. У бік спрощення. А може, й ні – залежно від провайдера. І полягає вона в тому, що записи:
gate.krokodil.ru. IN A 212.20.5.1
krokodil.ru. IN A 212.20.5.2
будуть перебувати на вашому сервері і керуватися вами, але записи:
1 IN PTR gate.krokodil.ru.
2 IN PTR krokodil.ru.
повинні бути сформовані провайдером, тому що можливість самому реєструвати зворотну зону і самому їй керувати надається лише за наявності мережі класу не менше ніж С. Це, з одного боку, полегшує роботу – не потрібно реєструватися в RIPE, але з іншого боку, ускладнює – для внесення змін в ім'я сервера потрібно щоразу зв'язуватися з провайдером.
Файлова структура
Самому BIND, звичайно, все одно, в якому порядку йдуть записи і як вони відформатовані. Це важливо лише тим, хто супроводжуватиме зону, особливо, якщо зміни до неї вноситимуться часто. Тут я опишу розподіл зон файлами так, як це використовується в тих зонах, які я супроводжую. Зрозуміло, це не єдиний можливий лад і, можливо, не найкращий. Але це працює.
Зони зовнішні та внутрішні
BIND 8.x мав один надзвичайно великий недолік - він не дозволяв диференціювати інформацію, що видається залежно від будь-яких факторів - доводилося або показувати зайве, або приховувати потрібне. Зовнішнім клієнтам немає потреби знати про наявність комп'ютерів внутрішньої мережі, але, оскільки розділити інформацію було можливості, будь-який комп'ютер міг встановити структуру внутрішньої мережі у вигляді запитів DNS. BIND 9.x вільний від цього недоліку – він дозволяє за допомогою списків керування доступом (Access Control List, АСL) розподілити запити щодо «уявлень» (views). Уявлення може мати довільні імена, зазвичай створюється внутрішнє уявлення «internal», якому задовольняють клієнти внутрішньої підмережі, і зовнішнє уявлення «extrenal», якому задовольняють й інші. Тут пам'ятайте, що це одна і та ж зона, просто показується вона по-різному - як правило, у файлах зовнішніх зон присутня тільки та інформація, яка необхідна зовнішнім клієнтам, - про зовнішній сервер, про шляхи доставки пошти і т.д. а у файлах внутрішніх зон відбивається вся мережева топологія. Крім того, якщо супроводжується зворотна зона, необхідно точно так само розділити по файлах інформацію про адреси зворотного перетворення.
Отже, повернемось до нашого прикладу.
Файлова структура буде такою. У нас є пряма зона krokodil.ru та зворотна зона 5.20.212.in-addr.arpa. Крім того, обов'язково повинна бути зворотна зона зона 0.0.127.in-addr.arpa для забезпечення коректного зворотного перетворення localhost 127.0.0.1. Зона ця потрібна для того, щоб BIND не намагався запитувати кореневі сервери про себе, що відбувається, коли 127.0.0.1 вказує на «localhost.» Запис прямого перетворення 127.0.0.1 localhost.krokodil.ru буде занесено до файлу прямого перетворення внутрішньої зони. Для того щоб не завантажувати мережу передачею непотрібних даних, для зовнішніх і внутрішніх зон використовуються різні записи SOA - записи в зовнішніх зонах змінюються дуже рідко, а у внутрішніх досить часто. Отже, ми маємо такі файли:
- localhost.rev- Файл зони зворотного перетворення 0.0.127.in-addr.arpa. Цей файл існує лише для внутрішнього уявлення.
- zone212.rev- файл зони зворотного перетворення 5.20.212.in-addr.arpa.
- zone10.rev- Файл внутрішньої зони зворотного перетворення 1.87.10.in-addr.arpa.
- direct-krokodil-ru.int- Файл внутрішньої зони прямого перетворення krokodil.ru.
- direct-krokodil-ru.ext- Файл зовнішньої зони прямого перетворення krokodil.ru.
- krokodil-ru-int.soa– файл із записами SOA та NS для внутрішніх зон.
- krokodil-ru-ext.soa– файл із записами SOA та NS для зовнішніх зон.
Незважаючи на великий список, файли досить короткі, тому наводяться тут повністю, крім коментарів.
Зробимо одне зауваження щодо імені localhost. RFC 1912 спеціально згадує налаштування файлів з роздільною здатністю імені 127.0.0.1 та localhost. У прикладі зона localhost відповідає RFC 1912, хоча у житті цілком можна зустріти дозвіл імені 127.0.0.1 localhost.domain.tld і відповідне йому зворотне дозвіл.
Файл localhost.rev. Використовує один запис SOA разом із внутрішньою зоною зворотного перетворення:
$INCLUDE /etc/namedb/krokodil-ru-int.soa
1 IN PTR localhost.
Файл zone212.rev:
1 IN PTR gate.krokodil.ru.
2 IN PTR krokodil.ru.
Файл zone10.rev:
$INCLUDE /etc/namedb/krokodil-ru-int.soa
1 IN PTR tooth1.krokodil.ru.
2 IN PTR tooth2.krokodil.ru.
3 IN PTR tooth3.krokodil.ru.
4 IN PTR tooth4.krokodil.ru.
5 IN PTR tooth5.krokodil.ru.
6 IN PTR tooth6.krokodil.ru.
Файл direct-krokodil-ru.int:
$INCLUDE /etc/namedb/krokodil-ru-int.soa
krokodil.ru. IN A 10.87.1.254
IN MX 10 krokodil.ru
www IN CNAME krokodil.ru.
mail IN CNAME krokodil.ru.
proxy IN CNAME krokodil.ru
ftp IN CNAME krokodil.ru.
ns IN CNAME krokodil.ru.
localhost. IN A 127.0.0.1
tooth1 IN A 10.87.1.1
tooth2 IN A 10.87.1.2
tooth3 IN A 10.87.1.3
tooth4 IN A 10.87.1.4
tooth5 IN A 10.87.1.5
tooth6 IN A 10.87.1.6
Файл direct-krokodil-ru.ext:
$INCLUDE /etc/namedb/krokodil-ru-ext.soa
krokodil.ru. IN A 212.20.5.2
IN MX 10 krokodil.ru
IN MX 50 behemot.ru
www IN CNAME krokodil.ru.
mail IN CNAME krokodil.ru.
ftp IN CNAME krokodil.ru.
gate IN A 212.20.5.1
Файл krokodil-ru-int.soa:
@ IN SOA krokodil.ru. hostmaster.krokodil.ru. (
2006051202; Serial number
10800; Refresh every 3 hours
3600; Retry every hour
1728000; Expire every 20 days
172800); Minimum 2 дні
IN NS krokodil.ru
Файл krokodil-ru-ext.soa:
$TTL 172800
@ IN SOA korkodil.ru. hostmaster.krokodil.ru. (
2005122001; Serial number
10800; Refresh every 3 hours
3600; Retry every hour
1728000; Expire every 20 days
172800); Minimum 2 дні
IN NS krokodil.ru
IN NS ns4.nic.ru
Висновок
Як створити, налаштувати та запустити DNS-сервер для невеликого підприємства? Насправді не так складно, як здається спочатку, – достатньо пройти цей шлях один раз, подальші дії будуть «на автоматі».
додаток
Домени верхнього рівня
Спочатку, згідно з RFC 920, у списку функціональних TLD були присутні тільки .com, .gov, .mil, .edu, .org , які представляли відповідно комерційні, урядові, військові організації, навчальні закладита некомерційні організації. Згодом цей список дещо розширився – у 1985 р. додався TLD .net, який представляє організації-постачальники мережевих послуг, а 1988 – TLD .int, що представляє міжнародні організації. У 2001-2002 до цього списку додалися практичні невідомі російському користувачу TLD .aero, .biz, .cat, .coop, .jobs, .mobi, .museum, .name, .pro і. Більше Детальна інформаціянаведено у . Географічні домени розподілені раз і назавжди. Хоча це не означає, що ви не можете зареєструвати свій домен. Багато географічних доменів, які випадково збіглися з «добре відомими» скороченнями, є надзвичайно привабливими. Наприклад, .md (Молдавія) дуже приваблива для медичних установта мешканців штату Меріленд, США; .tv (Тувалу) – для сайтів, пов'язаних із телебаченням; .tm (Туркменістан) збігається із написанням скорочення «Trade Mark», а.nu (Ніуе – є такий острів-колонія) – для сайтів у стилі «ню».
Система доменних імен – основа сучасного інтернету. Люди не бажають ускладнювати себе запам'ятовуванням набору цифр 63.245.217.105, а хочуть, щоб на ім'я mozilla.org комп'ютер з'єднав їх із зазначеним вузлом. Цим і займаються DNS-сервери: переводять запити людей у зрозумілий цифровий формат. Однак у деяких випадках може знадобитися зворотне (reverse) перетворення IP-адреси → DNS-ім'я. Про такі імена й йтиметься нижче.
Навіщо потрібно?
Наявність коректно налаштованого r DNS адресаа абсолютно необхідно, щоб надсилати повідомлення з вашого власного серверакорпоративної пошти. Практично всі поштові сервери відкинуто прийом повідомлення ще на стадії початку сесії, якщо IP-адреса вашого сервера відсутня запис у зворотній зоні DNS. Причина відмови віддаленим поштовим сервером буде, швидше за все, зазначена такою:
550-"IP-адреса не має PTR (адреса до електронної пошти) запису в DNS, або якщо PTR повідомлень не має жодного запису A (посилання на адресу) запису. Pls check and correct your DNS record."
або
550-There's не відповідають PTR для вашої IP-адреси (IP-адреси), які є 550 необхідних. Sorry, bye.
або просто
550 Ваш IP не має PTR Record
Число 550 у всіх трьох випадках є стандартним поштовим кодом SMTP сервера, повідомляє про критичну помилку, яка непереборно перешкоджає подальшій роботі в рамках даної поштової сесії. Треба сказати, що всі помилки серії 500 є критичними і продовження передачі пошти після їх появи неможливо. Текст пояснює причину відмови більш докладно і повідомляє, що адміністратор поштового сервера-отримувача налаштував його на перевірку наявності у поштового сервера-відправника запису в зворотній зоні DNS (rDNS) і у разі її відсутності сервер-отримувач зобов'язаний відмовляти відправнику в з'єднанні (SMTP- помилки серії 5XX).
Як налаштувати та використовувати?
Правами на налаштування зворотної зони DNS (reverse DNS) має лише власник відповідного блоку IP-адрес, якій ця зона відповідає. Як правило, цим власником виявляється провайдер, який володіє власною автономною системою. Детальніше про реєстрацію своєї автономної системи(AS) та блоку IP-адрес можна прочитати в цій статті. Якщо коротко, то оператору блоку IP-адрес для реєстрації зворотної зони DNS необхідно зареєструвати у своєму особистому кабінетіна сайті RIPE об'єкт типу «domain», вказати адресу DNS-серверів, які підтримуватимуть зону rDNS та налаштуватимуть підтримку зони виду 3.2.1.in-addr.arpa на них. За ресурси у зворотній зоні відповідає покажчик (pointer) – запис типу PTR. До неї і йдуть запити про дозвіл IP-адреси в ім'я хоста.
Якщо ви не є щасливим власником автономної системи, то налаштування rDNS для IP-адреси або адрес поштового сервера для вас починається і закінчується запитом до служби підтримки провайдера або хостера. В обох випадках ім'я IP-адреси поштового сервера, особливо корпоративного поштового сервера, слід давати осмислено.
Приклади хороших імен для сервера пошти:
mail.domain.ru
mta.domain.ru
mx.domain.ru
Приклади поганих імен:
host-192-168-0-1.domain.ru
customer192-168-0-1.domain.ru
vpn-dailup-xdsl-clients.domain.ru
та подібні. Такі імена з високою ймовірністю потраплять під фільтр як призначені клієнтським комп'ютерам, на яких не може бути встановлений поштовий сервер, відтак надсилається спам.
З успіхом використовувати запити до зворотних зон DNS можна і потрібно одразу після запуску поштового сервера. Для цього необхідно зробити лише невелике налаштуванняПЗ. У різних поштових серверах налаштування перевірки rDNS робиться по-різному:
reject_unknown_client
verify = reverse_host_lookup
У оснащенні Exgange Server перейти до розділу Servers далі вибрати сервер у розгорнутому списку, вибрати Protocols, далі протокол SMTP, у правому вікні виділити SMTP сервер і з кліку правою кнопкою миші вибрати зі списку Properties. Далі закладка Delivery → Perform reverse DNS lookup on incoming messages
Тепер усі повідомлення з IP-адрес не мають зворотного запису в DNS (записів типу PTR) будуть відкидатися, потік спаму значно скоротиться. Мабуть, це найпростіший, дієвий і найменш ресурсомісткий зі всіх методів фільтрації спаму: перевіркою reverse DNS відсікається переважна більшість спаму, що розсилається із заражених комп'ютерів звичайних користувачів, що складають спамерів ботнети.
При перепублікації статті встановлення активного індексованого гіперпосилання на джерело - сайт сайт обов'язковий!
Основи
Що таке запис зворотної зони DNS?
Звичайні запити DNS визначають невідому IP-адресу для відомого імені хоста. Це необхідно, коли, наприклад, браузеру потрібно встановити TCP-з'єднання з сервером по введеному в адресному полі URL.
Forum.hetzner.de --> 213.133.106.33
Зворотний DNS працює в іншому напрямку – запит визначає ім'я хоста, що належить IP-адресі.
213.133.106.33 --> dedi33.your-server.de
Як ви бачите, іменам хоста при прямому та зворотному запитах необов'язково збігатися!
Яким є призначення запису зворотної зони DNS?
- traceroute показує не тільки IP-адреси, але і імена вузлів. Це значно полегшує діагностику помилок.
- Велика кількість поштових серверів приймає листи тільки якщо IP-адреса відправника має зворотний DNS-запис.
- Зворотні DNS-записи можуть використовуватися в SPF-записах (Sender Policy Framework; технологія, що запобігає розсилці спаму та вірусів з підроблених email-адрес).
Як технічно працює зворотне перетворення на серверах DNS?
Практика
Як я можу призначити кілька імен на мою IP-адресу, якщо розміщені різні домени на моєму сервері?
Це неможливо. Тільки одне ім'я призначається на кожну IP-адресу.
Більш того, будь-які зворотні зони прописані для сервера. Для звернення до сайту браузеру достатньо провести лише пряме перетворення (Ім'я -> IP). Тут, звичайно, може бути кілька імен, наприклад, кілька записів типу A або кілька записів типу CNAME, які вказують на A-запис.
Для роботи поштових серверів необов'язково мати кілька імен хоста на одну IP-адресу. Зворотний запис DNS повинен відповідати імені хоста SMTP-сервера (зверніться до налаштувань відповідного SMTP-сервера).
Якщо кілька доменів керуються через IP-адресу (досить часто), можна використовувати нейтральне ім'я, не пов'язане з доменами користувачів. Спам-фільтри лише перевіряють чи відповідає зворотний DNS-запис імені у відповіді на команду HELO. Це ніяк не впливає на доменні іменаі поштові адреси в листах, що передаються.
- Зворотний запис DNS повинен відповідати імені поштового сервера або будуватися на підставі IP-адреси.
- Зворотний DNS-запис повинен також резолвуватися "вперед" - на ту ж IP-адресу.
- Зворотний DNS-запис не повинен бути схожим на автоматично-згенерований, наприклад "162-105-133-213-static.hetzner.de", так часто такі імена негативно оцінюються спам-фільтрами.
- Ім'я, що дається, має існувати. Будь ласка, не використовуйте неіснуючі доменні імена.
Приклад хорошого запису:
Srv01.grossefirma.de --> 213.133.105.162 213.133.105.162 --> srv01.grossefirma.de > telnet 213.133.105.162 25 220 srv01.gros
Я ставлю PTR на моєму DNS-сервері. Чому це не працює?
Ваш DNS-сервер відповідає лише за пряме перетворення.
Власник блоку IP-адрес (наприклад, Hetzner Online GmbH) є відповідальним за підтримку авторитативних DNS-серверів для зворотних записів.
Зворотні записи DNS можна створювати лише за допомогою відповідної функції панелі Robot ( ліве меню-> "Servers" -> клацання по серверу -> "IPs" -> клацання по текстовому полю поряд з IP-адресою).
Зворотній запис мого сервера відрізняється від HELO мого поштового сервера. Чи це проблема?
Приклад: зворотний запис DNS для IP-адреси сервера "www.grossefirma.de". У відповідь команду HELO поштовий сервер відповідає "mail.grossefirma.de".
Деякі спам-фільтри розцінюють листи від таких відправників як спам. Подібні невідповідності мають бути виправлені. Зворотний запис DNS та ім'я поштового сервера повинні бути однаковими. У прикладі вище можуть бути, наприклад, "srv01.grossefirma.de". Ім'я "www.grossefirma.de" може бути без жодних наслідків перенаправлено на srv01.grossefirma.de" за допомогою CNAME-запису.
Детальне тестування DNS-записів можна провести скориставшись
Продовжуючи тему сайтобудування, поговоримо про такий важливий аспект, як робота системи доменних імен - DNS. З налаштуванням та розташуванням DNS-зони пов'язані багато питань, що стосуються початкового розміщення, а також перенесення сайтів між різними серверамита хостингами. Розуміння принципів роботи системи доменних імен дозволяє легко управляти власними доменами і пов'язаними з ними сайтами та іншими службами.
Що таке доменне ім'я? Для багатьох це синонім адреси сайту, наприклад, www.сайт. Набираючи цю адресу ви впевнені, що потрапите саме на цей сайт, а не кудись ще. У той же час доменне ім'я може позначати не тільки сайт, а й сервер електронної пошти, обміну короткими повідомленнями або інший інтернет та мережевий сервіс. Доменні імена входять до доменних зон, які розташовані всередині один одного в ієрархічному порядку.
У загальному розумінні домен - це символьне ім'я, що дозволяє однозначно адресувати автономну область імен мережі Інтернет. І не тільки адресувати, а й дозволити будь-якому клієнту швидко знайти необхідний вузол, навіть не маючи жодного уявлення про його розміщення. Можна без перебільшення сказати, що система DNS – основа сучасної мережіінтернет у тому вигляді, в якій ми всі її знаємо та звикли.
Система DNS є глобальною та має сувору ієрархію. Розглянемо таку схему:
Верхнім рівнем ієрархії є кореневий домен, позначений точкою, який містить інформацію про домени першого рівня, наприклад, ru, сom, orgі т.п. Роботу кореневої зони забезпечують 13 кореневих серверів, розташованих у всьому світі і постійно реплікують свої дані між собою. Насправді кореневих серверів більше, але особливості протоколу дозволяють вказати лише 13 вузлів верхнього рівня, тому масштабованість і стійкість до відмови від системи забезпечується дзеркалами кожного кореневого сервера.
Домени першого рівня є звичними для нас доменними зонамиі можуть керуватися як національними, так і міжнародними організаціями та мати свої умови використання. Кожна доменна зона першого рівня дозволяє розміщувати необмежену кількість доменів другого рівня, котрі знайомі кожному користувачеві інтернету як адреси сайтів.
У свою чергу домени другого рівня теж є доменними зонами і дозволяють розміщувати в собі домени третього рівня, які, як у матрьошку, поміщати домени четвертого, п'ятого і т.д. рівнів. Для того щоб можна було однозначно визначати вузли, що знаходяться в різних зонах, введено поняття повністю визначене ім'я домену (FQDN, Fully Qualified Domain Name), яке включає всі імена батьківських доменів в ієрархії DNS. Наприклад, для нашого сайту FQDN буде: сайт.Саме так, із закінченням на точку, що означає кореневу зону.
Це дуже важливий момент. У повсякденному використанні завершальну точку прийнято відкидати, але в записах DNS відсутність останньої точкиозначає, що це доменне ім'я належить поточної доменної зоні, тобто. DNS-сервер додасть до такого імені власну доменну зону і всі зони, що стоять вище, аж до кореня.
Наприклад, на нашому сервері у зоні сайтми додаємо запис типу CNAME, який буде вказувати на сторонній сервер, скажімо, Яндекс-пошти Правильно запис має виглядати так:
MailIN CNAMEdomain.mail.yandex.net.
В даному випадку ім'я mail не FQDN і буде доповнено до mail.сайт.Якщо ж ми забудемо поставити крапку в кінці імені домену Яндекса, то це ім'я також не буде сприйматися як FQDN і має бути доповнено до повного імені домену. Нижче наведено неправильний запис:
Mail IN CNAME domain.mail.yandex.net
Непідготовленим поглядом різницю помітити складно, але замість веб-інтерфейсу пошти Яндекса така конструкція надішле нас на неіснуючу адресу: domain.mail.yandex.net.сайт.
Ще один момент. Всі записи доменної зони вносяться адміністраторами зон на власних DNS-серверах, яким чином ці записи стають відомі системі DNS? Адже ми не сповіщаємо вищестоящі DNS-сервера, що змінили будь-який запис.
Будь-яка DNS-зона містить записи тільки про вузли і дочірні зони, що входять до неї. Інформація про вузли нижчої зони зберігається на її власних серверах. Це називається делегуванням та дозволяє знизити навантаження на кореневі сервери та надати необхідну автономію власникам дочірніх доменних зон.
Отже, ви купили домен, скажімо, example.org, після чого ви маєте його делегувати, тобто. вказати сервера імен (DNS-сервера), які міститимуть записи даної файлової зони. Це можуть бути як ваші власні сервери, так і публічні сервіси, наприклад DNS Яндекса.
У цьому випадку у доменній зоні orgбуде додано запис:
Example IN NS dns1.yandex.net.
Яка вказуватиме, що всі записи цієї зони розташовані на сервері dns1.yandex.net. За правилами, кожна доменна зона повинна мати не менше двох NS-серверів, розташованих у різних підмережах. На практиці часто обходяться одним сервером, купуючи для нього дві IP-адреси з різних діапазонів.
Тепер розберемо, яким чином відбувається пошук необхідного нам DNS-запису та чому запис, зроблений на вашому сервері, дозволяє потрапити на ваш сайт відвідувачам з будь-якої точки земної кулі.
Допустимо, користувач хоче відвідати популярний ресурс Яндекс Маркет, він набирає в адресному рядку браузера відповідне ім'я сайту та натискає кнопку Enter. Для того, щоб відобразити користувачеві вміст сторінки браузер повинен надіслати запит веб-серверу, який обслуговує сайт, а для цього потрібно знати його IP-адресу. Тому браузер звертається до DNS-клієнта з метою дізнатися, яка адреса відповідає введеному доменному імені користувачеві.
У свою чергу, DNS-клієнт перевіряє записи у файлі hosts, потім у локальному кеші і, не виявивши там потрібних записів, передає запит вказаному в мережевих налаштуваннях DNS-серверу. Швидше за все це буде локальний DNS-проксі, що кешує, наприклад, dnsmasq або локальний DNS-сервер підприємства. Дані рішення зазвичай не є повноцінними серверами глобальної системи DNS і не входять до неї, обслуговуючи тільки локальну зону і кешуючи DNS-запити, тому такий запит, якщо даних не виявляється в кеші, передається вищому DNS-серверу, як правило, це сервер провайдера.
Отримавши запит, сервер провайдера перевірить власні записи, потім власний кеш, і, якщо результат буде знайдено, повідомить його клієнта, інакше сервер змушений буде вдатися до рекурсії- Пошук у глобальній системі DNS. Щоб краще зрозуміти механізм цього процесу, ми підготували таку схему:
Отже, клієнт відправляє DNS-запит серверу провайдера з метою дізнатися адресу домену market.yandex.ru, сервер провайдера не має подібної інформації, тому звертається до одного з кореневих серверів, передаючи йому запит. Кореневий сервер також не має потрібних записів, але відповідає, що знає сервер, який відповідає за зону ru - a.dns.ripn.net. Разом з цим ім'ям кореневий сервер може відразу повідомити його IP-адресу (і в більшості випадків повідомить), але може і не зробити цього, якщо не має такої інформації, в такому випадку, перед тим як звернутися до цього сервера, потрібно буде виконати ще один рекурсивний запит, Тільки для визначення його імені.
З'ясувавши адресу сервера, що відповідає за зону ru, сервер провайдера передасть запит йому, але цей сервер також не має потрібних записів, але повідомить, що за зону yandexвідповідає сервер ns1.yandex.ruі обов'язковоповідомить його адресу. Інакше рекурсію завершити не вдасться, оскільки за зону yandexвідповідає сервер, що у зоні yandex. Для цього у вищій зоні, крім NS-запису про сервери імен, що обслуговують зону серверах, створюється "пов'язаний" А-записяка дозволяє дізнатися адресу такого сервера.
Нарешті, надіславши запит серверу, який обслуговує зону yandex, сервер провайдера отримає адресу домену і повідомить його клієнту. Також він помістить отриманий результат у кеш на час, передбачений значенням TTL в SOA-записі цього домену. На практиці, оскільки рекурсивні запити дуже затратні, час кешування записів у провайдерів може ігнорувати значення TTL домену і досягати значень від двох-чотирьох годин до кількох днів і навіть тижня.
Тепер розглянемо ще один момент. Запити можуть бути рекурсивними чи нерекурсивними. Рекурсивний запит передбачає отримання готової відповіді, тобто. IP-адреси або повідомлення, що домен не існує, не делегований і т.п. Нерекурсивний запит передбачає відповідь лише про зону, за яку відповідає даний сервер або повернення помилки.
Оскільки рекурсивні запити є досить ресурсомісткими, більшість серверів мережі DNS обробляють рекурсивні запити нерекурсивно. Або можуть це робити вибірково, наприклад, DNS-сервера провайдера виконують рекурсивні запити лише своїх клієнтів, інші ж нерекурсивно.
У нашому випадку клієнт надіслав серверу провайдера рекурсивний запит, який, у свою чергу, послідовно надсилав нерекурсивні запити, поки не знайшов необхідний сервер, який дав необхідну відповідь. При цьому в кеш сервера провайдера поміщаються не тільки результати запиту користувача, але і результати проміжних запитів, що дозволяє виконувати такі запити нерекурсивно або з мінімальною кількістю запитів.
Наприклад, якщо користувач після відвідування Яндекс Маркета вирішить скористатися поштовим сервісом, сервер відразу направить запит до ns1.yandex.ru, тому що вже знає, який сервер містить записи для зони yandex.
Від теорії до практики
Коли ви купуєте у реєстратора домен, вам запропонують його делегувати, тобто. вказати DNS-сервера, на яких буде розташована доменна зона. Це можуть бути сервери реєстратора (зазвичай безкоштовно), сервери хостера, публічні DNS-сервіси або власні сервери імен, якщо він буде розташований у цій же доменній зоні, вам потрібно також вказати IP-адреси. Наприклад, так виглядає вікно делегування домену в одного відомого реєстратора:
Що саме туди вказувати? Це залежить від того, де і як ви розміщуватимете свій сайт. Якщо ви використовуєте віртуальний хостинг, всі необхідні записи створюються хостером автоматично, при додаванні в панелі управління хостингом вашого сайту, все що вам потрібно - це делегувати домен на NS-сервера хостера, тобто. вказати їх у цьому вікні. Цей спосіб добре підходить початківцям завдяки своїй простоті, але є і зворотний бік, можливість управління DNS-зоною з боку користувача відсутня або мінімальна. Крім того, на віртуальному хостингу IP-адреса сайту може бути змінена адміністраторами без повідомлення користувача, тому, якщо ви не хочете використовувати NS-сервер хостера, то це питання обов'язково слід обговорити з техпідтримкою.
Якщо ви переносите сайт до іншого хостера, вам потрібно перенести сайт і поміняти у реєстратора сервера імен старого хостера на сервера нового. Але врахуйте, що інформація в кеші DNS-серверів оновлюється не миттєво, а, як мінімум, після значення TTL-домену, тому протягом деякого часу ваш сайт може бути доступний ще за старою адресою. Якщо вам треба терміново з ним працювати, то можете, не чекаючи оновлення DNS-Кеша вашого провайдера, додати до файлу hostsзапис наступного змісту:
1.2.3.4 example.com
Де 1.2.3.4 і example.comвідповідно нова IP-адреса та ім'я вашого домену.
Якщо у вас свій VPS або ви хочете повністю контролювати доменну зону, слід скористатися серверами реєстратора або публічними сервісами. Створення власного сервера імен, на наш погляд, не виправдовує себе затія, якщо ви не робите власний хостинг.
У цьому випадку вам потрібно створити, як мінімум, два А-записи, які будуть вказувати на веб-сервер обслуговуючий сайт у цьому домені:
@ IN A 1.2.3.4
www IN A 1.2.3.4
Символ "собачки" в DNS-записах позначає сам домен, крім того, обов'язково слід створити запис для піддомену www, щоб користувачі, які набрали адресу сайту з www, також могли отримати до нього доступ.
Ми не розглядатимемо додавання записів для електронної пошти, про це можна прочитати в нашій статті:
При перенесенні сайту вам потрібно буде змінити лише IP-адреси в A-записах і дочекатися оновлення DNS інформації. Зазвичай, це найнеприємніший момент - начебто все зроблено, але нічого змінити ви не можете, залишається тільки чекати. Але якщо виконати деякі рекомендації, то даний процесможна провести максимально безболісно та непомітно для відвідувачів.
Перш за все змініть значення TTL у записі SOA. За замовчуванням воно одно кілька годин і саме стільки вам доведеться чекати оновлення вашого запису в кеші DNS-серверів. Щоб дізнатися поточне значення TTL, можна виконати команду, вказавши потрібне доменне ім'я:
Nslookup -typr=soa сайт
У нашому випадку це 4 години: 
Тому заздалегідь, не менше 4 годин (старе значення TTL) до планованого перенесення, змініть значення TTL на нижчу, наприклад, 900 (15 хвилин). Потім переведіть свій сайт в режим "тільки читання" та перенесіть його на новий сервер. Вимикати або переводити на техобслуговування сайт не слід, він може і повинен бути доступним. Але ви повинні виключити зміну та додавання інформації користувачами, тобто. заборонити реєстрацію, коментування, розміщення замовлень тощо. Також не забудьте розмістити на видному місці повідомлення про технічні роботита приблизний термін їхнього завершення.
Для того, щоб працювати з новим сервером, не змінюючи DNS-записи, додайте потрібний рядок файл hosts. Розмістивши сайт на новому майданчику та переконавшись у його нормальній роботізміните DNS-записи, тепер уже через 15 хвилин перші користувачі почнуть відвідувати ваш сайт на новому сервері. Працездатність старого сервера потрібно підтримувати ще деякий час, в ідеалі до тижня, тому що не всі провайдери використовують значення TTL із SOA-запису для оновлення кешу, для зменшення навантаження на обладнання можуть бути використані власні налаштування.
Після успішного перенесення значення TTL слід збільшити до колишніх значень, ніж створювати зайвого навантаження на сервера імен.
Ми розглянули найпростішу схему, але на практиці, окрім сайту, зазвичай є ще офісна мережа, багато ресурсів якої мають бути також доступні ззовні. Розглянемо таку схему:
У нас є публічні сервери для сайту та електронної пошти та офісна мережа, для якої ми виділили піддомен office. Якщо з поштою та веб-сервером особливих питань немає, то з офісною зоною є варіанти. Зазвичай локальна зона обслуговується власним DNS і не пов'язана з материнської зоною. Для глобальної системи DNS зона office.example.comне існує, але існує однойменний хост. Це виправдано, якщо мережа підприємства знаходиться за NAT та її вузли мають лише сірі адреси, а доступ ззовні здійснюється лише до шлюзу, на який прокинуто відповідні порти від внутрішніх вузлів.
В цьому випадку DNSзаписи зони example.comможуть виглядати так:
@ IN A 1.2.3.4
www IN A 1.2.3.4
mail IN A 1.2.3.5
office IN A 5.6.7.8
Але виникає деяка складність, всередині мережі клієнти звертаються до мережевим сервісампо внутрішнім іменам: corp.office.example.comабо rdp.office.example.com, які вказують на внутрішні "сірі" адреси. локальної мережідозволити IP-адресу для таких імен неможливо, оскільки містить їх зони для глобальної системи DNS не існує. Вийти зі становища дозволяє механізм, званий Split-DNS, що дозволяє віддавати різні результати залежно від становища клієнта.
У локальній мережі DNS-запити клієнтів обслуговує локальний сервер, які мають відповідні записи, за її межами запити будуть направлені серверу, який обслуговує зону example.com. При цьому все корпоративні ресурси, які у локальній мережі представлені різними серверами, ззовні доступні за адресою: office.example.com. Тому саме час згадати запис псевдоніма або CNAME. Цей запис дозволяє пов'язувати з реальним ім'ям хоста додаткові мнемонічні імена або псевдоніми. При цьому врахуйте, що використовувати інші записи псевдонімів неприпустимо. У нашому випадку слід додати записи:
Corp.office IN CNAME office.example.com.
rdp.office IN CNAME office.example.com.
Тепер клієнт, незалежно від свого розташування, може використовувати для доступу до ресурсів одне й те саме ім'я, але результат отримувати буде різний. У локальній мережі він отримає реальну адресу сервера та підключиться безпосередньо, а за її межами буде спрямований на шлюз мережі.
Також записи типу CNAME можна використовувати для перенаправлення за межі доменної зони, що обслуговується. Головна умова - CNAME записмає вказувати на реальне ім'я у форматі FQDN.
Ще одне застосування псевдонімів – це скорочення адреси. Допустимо, як поштовий сервер для всього домену example.comми хочемо використовувати сервер, який розташований у московському офісі та має адресу mail.office.msk.example.com, погодьтеся, виглядає не надто привабливо. Набагато зручнішою була б адреса виду mail.example.com, немає нічого простішого, додамо наступний запис:
Mail IN CNAME mail.office.msk.example.com.
Але пам'ятайте, що в інших ресурсних записах слід використовувати лише реальні імена, тому такий запис буде неправильним:
Example.com. IN MX 10 mail
Правильно буде так:
Example.com. IN MX 10 mail.office.msk
Насамкінець поговоримо про делегування доменних зон. У прикладі вище ми розглянули ситуацію, коли всередині домену різним підрозділам виділено свої піддомени, оскільки кожен підрозділ має свою інфраструктуру, тобто сенс делегувати їм управління власними доменними зонами. Для цього у зоні example.comслід розмістити NS і пов'язаний з нею запис A для кожної зони. Наприклад:
Msk IN NS ns1.msk.example.com.
msk IN NS ns2.msk.example.com.
ns1.msk IN A 1.2.3.4
ns2.msk IN A 5.6.7.8
Тепер при зверненні на адресу, скажімо mail.office.msk.example.comсервера імен зони example.comбудуть видавати ім'я та адресу сервера, що обслуговує зону msk.example.com. Це дозволяє адміністраторам зони самостійно вносити необхідні зміни, не торкаючись при цьому функціонування вищої зони та не звертаючись до її адміністраторів з будь-якого питання, що потребує зміни записів.
Теги:
Для правильної роботипоштового сервера важливо мати правильно налаштовану зону. Налаштування DNSзони відноситься до підготовчих операцій перед розгортанням поштового сервера та від неї безпосередньо залежить працездатність системи електронної пошти.
Неправильні установки можуть призвести до того, що пошту буде неможливо доставити вашому поштовому серверу або сервера одержувачів будуть відхиляти вашу пошту. Справді, якщо записи вашої зони не містять відомостей про поштовий сервер, куди має надсилатися пошта? На село дідусеві? Можна, звичайно, попросити налаштувати зону DNS вашого провайдера, але краще зробити це самим.
Що нам знадобиться? Виділена IP-адреса (припустимо 11.22.33.44), яку ви повинні отримати у свого провайдера. Доменне ім'я (наприклад, example.com), його можна зареєструвати у будь-якого реєстратора або їхнього партнера. При реєстрації у партнера уточнюйте, чи надає доступ до управління DNS зоною, інакше доведеться витратити додатковий час, нерви і гроші на перенесення домену до реєстратора.
Якщо у вас є домен і, швидше за все, на ньому функціонує сайт, уточніть, чи можливо керування DNSзоною з панелі хостинг провайдера, інакше краще перенести домен до реєстратора, для цього зверніться на підтримку провайдера.
Тож домен у нас є. Які записи містить його зона DNS? По-перше, це SOA запис - опис зони. Ми не будемо докладно розбирати всі записи, це виходить за межі нашої статті, але мати загальне уявленняпро них потрібно. Також повинні бути два NS записи, що вказують на сервер імен ( DNS сервера) що обслуговують даний домен, це будуть сервери реєстратора або хостинг провайдера.
Першим записом, який необхідно додати, буде A запис або запис імені. Вона повинна вказувати на IP-адресу вашого сервера, якщо ви вирішите обслуговувати всі запити до домену у себе або на адресу IP хостинг провайдера, якщо вирішите розмістити свій сайт на хостингу. При розміщенні сайту у хостера домен зазвичай делегується на його DNS сервері (прописуються відповідні NS записи) і A запис буде зроблено автоматично при паркуванні домену.
Найчастіше зустрічається цей варіант, але при необхідності ви завжди зможете створити запис A самі. Цей запис має вигляд:
example.com. IN A 22.11.33.44
У нашому прикладі 22.11.33.44 адреса нашого хостинг-провайдера, у якого розташований сайт. Зверніть увагу на точку в кінці імені, це вказує, що ім'я абсолютне, за відсутності точки ім'я вважається відносним і до нього додається доменне ім'я з SOA. Перевірити запис можна командою nslookup.
Для роботи поштового сервера потрібно створити запис MX, який повинен вказувати на наш поштовий сервер. Для цього створимо запис:
example.com. IN MX 10 mail.example.com.
Також можна написати просто:
example.com. IN MX 10 mail
Таке ім'я (без точки на кінці) example.com буде додано автоматично. Цифра 10 визначає пріоритет сервера, що вона менше, тим вищий пріоритет. До речі, DNS зона вже може містити запис MX MX:
example.com. IN MX 0 example.com
Зазвичай цей запис автоматично створюється хостинг-провайдером при розміщенні сайту, його потрібно видалити.
Тепер створимо запис A для mail.example.com
mail.example.com. IN A 11.22.33.44
Тепер вся пошта для домену example.com надсилатиметься хосту mail, що має адресу 11.22.33.44, тобто. Вашому поштовому серверу, в той же час, сайт example.com продовжить працювати на сервері провайдера за адресою 22.11.33.44.
Може виникнути питання, а чому не можна відразу вказати в MX запис IP адресу поштового сервера? В принципі, деякі так і роблять, але це не відповідає специфікаціям DNS.
Також можна зробити аліаси для поштового сервера типу pop.example.ruі smtp.example.ru. Для чого це треба? Це дозволить клієнту не залежати від особливостей вашої інфраструктури, один раз прописавши налаштування. Допустимо, що ваша компанія розрослася і виділила для обслуговування зовнішніх клієнтів окремий поштовий сервер mail1, все, що вам знадобиться, це змінити два DNS записи, клієнти і не помітять того, що працюють з новим сервером. Для створення аліасів використовуються записи типу CNAME:
Pop IN CNAME mail.example.com.
smtp IN CNAME mail.example.com.
На цьому налаштування прямої DNS зони можна вважати закінченою, залишається найцікавіше – зворотна зона. Зворотна зона управляється провайдером, який видав вам IP адресу і самостійно керувати нею ви не можете (якщо тільки ви не власник блоку IP адрес). Але додати щонайменше один запис у зворотну зону необхідно. Як ми писали в минулій статті, багато поштових серверів перевіряють PTR записи (записи зворотної зони) для відправляючого сервера і за їх відсутності або розбіжності з доменом відправника такий лист буде відхилено. Тому попросіть провайдера додати вам запис виду:
44.33.22.11.in-addr.arpa. IN PTR mail.example.com.
Трохи дивний вигляд, чи не так? Розберемо структуру PTR записи докладніше. Для перетворення імен використовується спеціальний домен верхнього рівня in-addr.arpa. Це зроблено для того, щоб використовувати для прямого та зворотного перетворення імен ті самі програмні механізми. Справа в тому, що менімонічні імена пишуться зліва направо, а IP адреси праворуч наліво. Так mail.example.com. означає, що хост mail знаходиться в домені example, який знаходиться в домені верхнього рівня com. що належить мережі 11. Для збереження єдиного порядку PTR записи містять IP адресу "задом наперед" доповнений доменом верхнього рівня in-addr.arpa.
Перевірити MX та PTR записи також можна командою nslookupвикористовуючи додатковий параметр -type=MXабо -type=PTR
Ну і звичайно не варто забувати, що будь-які зміни в DNS зонахвідбуваються не миттєво, а протягом кількох годин або навіть доби, необхідні поширення змін у світовій системі DNS. Це означає, що незважаючи на те, що поштовий сервер у вас почне працювати через 2 години після внесення змін, ваш партнер пошта може не відправлятися до вас протягом більш тривалого часу.
