DNS (Domain Name System) – важливий і досить складний у налаштуванні компонент, необхідний роботи веб-сайтів і серверів. Багато користувачів звертаються до DNS-серверів, які надає їхній хостинг-провайдер, проте власні DNS-сервери мають деякі переваги.
У цьому мануалі ви дізнаєтеся, як встановити Bind9 і налаштувати його як кешуючий або перенаправляючий DNS-сервер на сервері Ubuntu 14.04.
Вимоги
- Розуміння базових типів DNS-сервери. Ознайомитися з подробицями можна у .
- Дві машини, з яких хоч одна працює на Ubuntu 14.04. Перша машина буде налаштована як клієнт (IP-адреса 192.0.2.100), а друга – як DNS-сервер (192.0.2.1).
Ви навчитеся налаштовувати клієнтську машинудля надсилання запитів через сервер DNS.
Кешируючий DNS-сервер
Сервери цього типу також називають визначниками, оскільки вони обробляють рекурсивні запитиі, як правило, можуть виконати пошук даних DNSне на інших серверах.
Коли кешуючий DNS-сервер відстежує відповідь на запит клієнта, він повертає відповідь клієнту, а також зберігає її в кеші протягом періоду часу, дозволеного значенням TTL відповідних DNS-записів. Потім кеш можна використовувати як джерело відповіді на наступні запити, щоб прискорити загальний час обробки запиту.
Майже всі DNS-сервери у вашій мережній конфігурації будуть кешуючими. Кешируючий DNS-сервер гарний вибірдля багатьох ситуацій. Якщо ви не бажаєте покладатися на DNS-сервери вашого хостинг-провайдера або інші загальнодоступні DNS-сервери, налаштуйте власний кешуючий DNS-сервер. Чим менша відстань від DNS-сервера до клієнтським машинам, тим менше час обслуговування запитів DNS.
Перенаправляючий DNS-сервер
З погляду клієнта перенаправляючий DNS-сервер виглядатиме майже ідентично серверу, що кешує, але механізми і робоче навантаження у них абсолютно різні.
Перенаправляючий DNS-сервер має ті ж переваги, що і сервер, що кешує. Однак насправді він не виконує жодного рекурсивного запиту. Замість цього він перенаправляє всі запити на зовнішній сервер, а потім кешує результати для наступних запитів.
Це дозволяє серверу, що перенаправляє, обслуговувати запити зі свого кешу, не обробляючи при цьому рекурсивних запитів. Таким чином, цей сервер обробляє лише поодинокі запити (перенаправлені запити клієнта), а чи не всю процедуру рекурсії. Це може бути перевагою в середовищах з обмеженою зовнішньою пропускною здатністю, в яких необхідно часто змінювати сервери, що кешують, і в ситуаціях, коли потрібно перенаправити локальні запити на один сервер, а зовнішні - на інший.
1: Встановлення Bind на DNS-сервер
Пакет Bind можна знайти в офіційній репозиторії Ubuntu. Оновіть індекс пакетів та встановіть Bind за допомогою менеджера apt. Також потрібно встановити пару залежностей.
sudo apt-get update
sudo apt-get install bind9 bind9utils bind9-doc
Після цього можна розпочати налаштування сервера. Конфігурацію кешируючого сервера можна використовувати як шаблон для налаштування сервера перенаправлення, тому спочатку потрібно налаштувати кешуючий DNS-сервер.
2: Налаштування кешируючого DNS-сервера
Спочатку потрібно налаштувати Bind як кешуючий DNS-сервер. Така конфігурація змусить сервер рекурсивно шукати відповіді клієнтські запити інших DNS-серверах. Він послідовно опитуватиме всі відповідні DNS-сервера, поки не знайде відповідь.
Конфігураційні файли Bind зберігаються у каталозі /etc/bind.
Більшість файлів редагувати не потрібно. Головний конфігураційний файл називається named.conf (named і bind – дві назви однієї програми). Цей файл посилається на файли named.conf.options, named.conf.local та named.conf.default-zones.
Для налаштування сервера кешування DNS-сервера потрібно відредагувати тільки named.conf.options.
sudo nano named.conf.options
Цей файл виглядає так (коментарі опущені для простоти):
options (
directory "/var/cache/bind";
dnssec-validation auto;
listen-on-v6 ( any; );
};
Щоб настроїти сервер, що кеширує, потрібно створити список контролю доступу, або ACL.
Потрібно захистити DNS-сервер, що обробляє рекурсивні запити від зловмисників. Атаки DNS-посилення особливо небезпечні, оскільки можуть залучити сервер до розподілених атак на відмову в обслуговуванні.
Атаки DNS-посилення – це один із способів припинення роботи серверів та сайтів. Для цього зловмисники намагаються знайти загальнодоступні сервери DNS, які обробляють рекурсивні запити. Вони підробляють IP-адресу жертви та надсилають запит, який поверне DNS-серверу дуже об'ємну відповідь. При цьому DNS-сервер повертає на сервер жертви надто багато даних у відповідь на невеликий запит, збільшуючи доступну пропускну спроможністьзловмисник.
Для розміщення загальнодоступного рекурсивного DNS-сервера потрібне ретельне налаштування та адміністрування. Щоб запобігти зламу сервера, настройте список IP-адрес або діапазонів мережі, яким сервер зможе довіряти.
Перед блоком options додайте блок acl. Створіть мітку для групи ACL (у цьому мануалі група називається goodclients).
acl goodclients (
};
options (
. . .
У цьому блоці перерахуйте IP-адреси або мережі, які мають доступ до цього DNS-сервера. Оскільки сервер і клієнт працюють у підмережі /24, можна обмежити доступ до цієї підмережі. Також потрібно розблокувати localhost та localnets, які підключаються автоматично.
acl goodclients (
192.0.2.0/24;
localhost;
localnets;
};
options (
. . .
Тепер у вас є ACL безпечних клієнтів. Можна регулювати дозвіл запитів у блоці options. Додайте до нього такі рядки:
options (
directory "/var/cache/bind";
recursion yes;
. . .
Блок options явно включає в себе рекурсію, а потім налаштовує параметр allow-query для використання списку ACL. Для посилання на групу ACL також можна використовувати інший параметр, наприклад allow-recursion. При включеній рекурсії allow-recursion визначить список клієнтів, які можуть використовувати рекурсивні послуги.
Однак якщо параметр allow-recursion не встановлений, Bind повертається до списку allow-query-cache, потім до списку allow-query і, нарешті, до стандартних списків localnets і localhost. Оскільки ми налаштовуємо лише сервер, що кешує (він не має власних зон і не пересилає запити), список allow-query завжди буде застосовуватися тільки до рекурсії. Це самий загальний спосібвизначення ACL.
Збережіть та закрийте файл.
Це все налаштування, які потрібно додати до конфігураційного файлу кешируючого DNS-сервера.
Примітка: Якщо ви хочете використовувати тільки цей тип DNS, переходьте до перевірки конфігурацій, перезапустіть сервіс і налаштуйте клієнта.
3: Налаштування перенаправляючого DNS-сервера
Якщо вашій інфраструктурі більше підходить перенаправляючий DNS-сервер, ви можете трохи відкоригувати налаштування.
на Наразіфайл named.conf.options виглядає так:
acl goodclients (
192.0.2.0/24;
localhost;
localnets;
};
options (
directory "/var/cache/bind";
recursion yes;
allow-query ( goodclients; );
dnssec-validation auto;
auth-nxdomain no; # conform to RFC1035
listen-on-v6 ( any; );
};
Можна використовувати той самий список ACL, щоб обмежувати сервер DNS конкретним списком клієнтів. Однак необхідно трохи змінити конфігурацію, щоб сервер більше не намагався виконувати рекурсивні запити.
Не змінюйте значення recursion на no. Перенаправляючий сервер таки підтримує рекурсивні послуги. Щоб настроїти сервер, що перенаправляє, потрібно створити список кешуючих серверів, на які він буде перенаправляти запити.
Це робиться в блоці options(). Спочатку потрібно створити у ньому новий блок forwarders, де зберігатимуться IP-адреси рекурсивних серверів імен, куди потрібно перенаправляти запити. У даному випадкуце будуть DNS-сервери Google (8.8.8.8 та 8.8.4.4):
. . .
options (
directory "/var/cache/bind";
recursion yes;
allow-query ( goodclients; );
forwarders (
8.8.8.8;
8.8.4.4;
};
. . .
В результаті конфігурація виглядає так:
acl goodclients (
192.0.2.0/24;
localhost;
localnets;
};
options (
directory "/var/cache/bind";
recursion yes;
allow-query ( goodclients; );
forwarders (
8.8.8.8;
8.8.4.4;
};
forward only;
dnssec-validation auto;
auth-nxdomain no; # conform to RFC1035
listen-on-v6 ( any; );
};
Остання зміна стосується параметра dnssec. При поточної конфігураціїта в залежності від налаштування DNS-серверів, на які перенаправляються запити, у логах можуть з'явитися такі помилки:
Jun 25 15:03:29 cache named: error (спостереження DS servers) resolving "in-addr.arpa/DS/IN": 8.8.8.8#53
Jun 25 15:03:29 Опубліковано: error (no valid DS) "111.111.111.111.in-addr.arpa/PTR/IN": 8.8.4.4#53
Щоб уникнути їх, потрібно змінити значення параметра dnssec-validation на yes та явно дозволити dnssec.
. . .
forward only;
dnssec-enable yes;
dnssec-validation yes;
auth-nxdomain no; # conform to RFC1035
. . .
Збережіть та закрийте файл. Налаштування перенаправляючого сервера DNS завершено.
4: Перевірка налаштувань та перезапуск Bind
Тепер потрібно переконатися, що налаштування працюють належним чином.
Щоб перевірити синтаксис конфігураційних файлів, введіть:
sudo named-checkconf
Якщо у файлах немає помилок, командний рядок не відобразить жодного висновку.
Якщо ви отримали повідомлення про помилку, виправте її та повторіть перевірку.
Після цього можна перезапустити демон Bind, щоб оновити налаштування.
sudo service bind9 restart
Після цього потрібно перевірити логи сервера. Запустіть на сервер команду:
sudo tail -f /var/log/syslog
Тепер відкрийте новий термінал і починайте налаштування клієнтської машини.
5: Налаштування клієнта
Увійдіть на клієнтську машину. Переконайтеся, що клієнт був вказаний у групі ACL налаштованого сервера DNS. В іншому випадку DNS-сервер відмовиться обслуговувати запити клієнта.
Відредагуйте файл /etc/resolv.conf, щоб скерувати сервер на сервер імен.
Зміни, внесені тут, зберігатимуться лише до перезавантаження, що відмінно підходить для тестування. Якщо результати тестового налаштування вас задовольнять, ви зможете зробити ці налаштування постійними.
Відкрийте файл за допомогою sudo у текстовому редакторі:
sudo nano /etc/resolv.conf
У файлі потрібно перерахувати DNS-сервери, які використовуватимуться для дозволу запитів. Для цього використовуйте директиву nameserver. Закоментуйте всі поточні записи та додайте рядок nameserver, який вказує на ваш DNS-сервер:
nameserver 192.0.2.1
# nameserver 8.8.4.4
# nameserver 8.8.8.8
# nameserver 209.244.0.3
Збережіть та закрийте файл.
Тепер можна надіслати тестовий запит, щоб переконатися, що він дозволяється правильно.
Для цього можна використовувати ping:
ping -c 1 google.com
PING google.com (173.194.33.1) 56(84) bytes of data.
64 bytes from sea09s01-in-f1.1e100.net (173.194.33.1): icmp_seq=1 ttl=55 time=63.8 ms
--- google.com ping statistics ---
1 пакетів transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 63.807/63.807/63.807/0.000 ms
- Переклад
Уважний читач знайде на цій картинці IPv6
Люди часто спантеличені доменами. Чому мій сайт не працює? Чому ця хрень поламана, нічого не допомагає, я просто хочу, щоб це працювало!Зазвичай, той, хто запитує або не знає про DNS, або не розуміє фундаментальних ідей. Для багатьох DNS – страшна та незрозуміла штука. Ця стаття – спроба розвіяти такий страх. DNS – це простоякщо зрозуміти кілька базових концепцій.
Що таке DNS
DNSрозшифровується як Domain Name System. Це глобальне розподілене сховище ключів та значень. Сервера по всьому світу можуть надати вам значення по ключу, а якщо їм невідомий ключ, вони попросять допомоги у іншого сервера.
От і все. Щоправда. Ви або ваш браузер запитує значення для ключа www.example.com і отримує у відповідь 1.2.3.4.
Базові штуки
Великий плюс DNS у тому, що це публічна послуга, і можна потикати в сервер якщо хочеться розібратися. Давайте спробуєм. У мене є домен petekeen.net, який хоститься на машині web01.bugsplat.info. Команди, що використовуються нижче, можна запустити з командного рядка OS X ( ой, тобто macOS, - прим. пров.).
Давайте поглянемо на мапінг між ім'ям та адресою:
$dig web01.bugsplat.info
Команда dig це швейцарський армійський ніж для DNS-запитів. Крутий, багатофункціональний інструмент. Ось перша частина відповіді:
; <<>> DiG 9.7.6-P1<<>> web01.bugsplat.info;; Global options: +cmd;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51539 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
Тут є тільки одна цікава деталь: інформація про запит. Говориться, що ми запросили запис і отримали одну відповідь. Ось:
;;; QUESTION SECTION: ;web01.bugsplat.info. IN A
dig за замовчуванням запитує A-записи. А це address(Адреса), і це один з фундаментальних видів записів в DNS. A містить одну IPv4-адресу. Є еквівалент для IPv6-адрес - AAAA. Погляньмо на відповідь:
;;; ANSWER SECTION: web01.bugsplat.info. 300 IN A 192.241.250.244
Решта відповіді описує саму відповідь:
;;; Query time: 20 msec;; SERVER: 192.168.1.1#53(192.168.1.1);; WHEN: Fri Jul 19 20:01:16 2013;; MSG SIZE rcvd: 56
Зокрема, тут говориться, як довго сервер відгукувався, яка у сервера IP-адреса (192.168.1.1), на який порт стукався dig (53 , DNS-порт за замовчуванням), коли запит був завершений і скільки байтів було у відповіді.
Як бачите, при звичайному DNS-запиті відбувається купа всього. Щоразу, коли ви відкриваєте веб-сторінку, браузер робить десятки таких запитів, у тому числі для завантаження всіх зовнішніх ресурсів на кшталт картинок та скриптів. Кожен ресурс відповідає за мінімум один новий DNS-запит, і якби DNS не був розрахований на сильне кешування, трафіку генерувалося б дуже багато.
Але в цьому прикладі не видно, що DNS-сервер 192.168.1.1 зв'язався з купою інших серверів, щоб відповісти на просте запитання: «куди вказує web01.bugsplat.info?». Давайте запустимо трейс щоб дізнатися про весь можливий ланцюжок, який довелося б пройти dig "у, якби інформація не була закешована:
$dig +trace web01.bugsplat.info;<<>> DiG 9.7.6-P1<<>> +trace web01.bugsplat.info;; Global options: +cmd . 137375 IN NS l.root-servers.net. . 137375 IN NS m.root-servers.net. . 137375 IN NS a.root-servers.net. . 137375 IN NS b.root-servers.net. . 137375 IN NS c.root-servers.net. . 137375 IN NS d.root-servers.net. . 137375 IN NS e.root-servers.net. . 137375 IN NS f.root-servers.net. . 137375 IN NS g.root-servers.net. . 137375 IN NS h.root-servers.net. . 137375 IN NS i.root-servers.net. . 137375 IN NS j.root-servers.net. . 137375 IN NS k.root-servers.net. ;;; Received 512 bytes from 192.168.1.1#53(192.168.1.1) in 189 ms info. 172800 IN NS c0.info.afilias-nst.info. info. 172800 IN NS a2.info.afilias-nst.info. info. 172800 IN NS d0.info.afilias-nst.org. info. 172800 IN NS b2.info.afilias-nst.org. info. 172800 IN NS b0.info.afilias-nst.org. info. 172800 IN NS a0.info.afilias-nst.info. ;;; Received 443 bytes from 192.5.5.241#53(192.5.5.241) in 1224 ms bugsplat.info. 86400 IN NS ns-1356.awsdns-41.org. bugsplat.info. 86400 IN NS ns-212.awsdns-26.com. bugsplat.info. 86400 IN NS ns-1580.awsdns-05.co.uk. bugsplat.info. 86400 IN NS ns-911.awsdns-49.net. ;;; Received 180 bytes from 199.254.48.1#53(199.254.48.1) in 239 ms web01.bugsplat.info. 300 IN A 192.241.250.244 bugsplat.info. 172800 IN NS ns-1356.awsdns-41.org. bugsplat.info. 172800 IN NS ns-1580.awsdns-05.co.uk. bugsplat.info. 172800 IN NS ns-212.awsdns-26.com. bugsplat.info. 172800 IN NS ns-911.awsdns-49.net. ;;; Received 196 bytes from 205.251.195.143#53(205.251.195.143) in 15 ms
Інформація виводиться у ієрархічній послідовності. Пам'ятайте, як dig вставив крапку. після хоста, web01.bugsplat.info ? Так ось, крапка. це важлива деталь і вона означає корінь ієрархії.
Кореневі DNS-сервери обслуговуються різними компаніями та державами по всьому світу. Спочатку їх було мало, але інтернет зростав і зараз їх 13 штук. Але кожен із серверів має десятки чи сотні фізичних машин, які ховаються за одним IP.
Отже, в самому верху трейсу знаходяться кореневі сервери, кожен визначений за допомогою запису NS. NS-запис пов'язує доменне ім'я (в даному випадку, кореневий домен) із DNS-сервером. Коли ви реєструєте доменне ім'я у реєстратора типу Namecheap або Godaddy, вони створюють записи NS для вас.
У наступному блоці видно, як dig вибрав випадковий кореневий сервер і запросив у нього A-запис для web01.bugsplat.info. Видно лише IP-адресу кореневого сервера (192.5.5.241). То який саме кореневий сервер це був? Давайте дізнаємось!
$dig-x 192.5.5.241;<<>> DiG 9.8.3-P1<<>> -x 192.5.5.241;; Global options: +cmd;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2862 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;241.5.5.192.in-addr.arpa. IN PTR ;; ANSWER SECTION: 241.5.5.192.in-addr.arpa. 3261 IN PTR f.root-servers.net.
Прапор -x змушує dig провести зворотний пошук за IP-адресою. DNS відповідає записом PTR, який з'єднує IP і хост, в даному випадку - f.root-servers.net.
Повертаючись до нашого початкового запиту, кореневий сервер F повернув інший набір NS-серверів. Він відповідає за домен верхнього рівня info. dig запитує у одного з цих серверів запис A для web01.bugsplat.info , і отримує у відповідь ще один набір NS-серверів, а потім запитує у одного з цихсерверів запис A для web01.bugsplat.info. . І, нарешті, одержує відповідь!
Уф! Згенерувалося б багато трафіку, але майже всі ці записи були надовго закешовані кожним сервером у ланцюжку. Ваш комп'ютер також кешує ці дані, як і ваш браузер. Найчастіше DNS-запити ніколи не доходять до кореневих серверів, тому що їх IP-адреси майже ніколи не змінюються ( «Напевно, все-таки йдеться про великий TTL для записів у їхній базі. Якщо у DNS сервера IP адреса взагалі жодного разу не змінювався, то це не означає, що його база надовго закешована»- прим. від rrrav). Домени верхнього рівня com, net, org, і т.д. теж зазвичай сильно закешовані.
Інші типи
Є ще кілька типів, про які варто знати. Перший це MX. Він з'єднує доменне ім'я з одним або декількома поштовими серверами. Електронна пошта настільки важлива, що вона має свій тип DNS-запису. Ось значення MX для petekeen.net:
$dig petekeen.net mx;<<>> DiG 9.7.6-P1<<>> petekeen.net mx;; Global options: +cmd;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18765 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;petekeen.net. IN MX ;; ANSWER SECTION: petekeen.net. 86400 IN MX 60 web01.bugsplat.info. ;; Query time: 272 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Fri Jul 19 20:33:43 2013 ;; MSG SIZE rcvd: 93
Зауважте, що запис MX MX вказує на ім'я, а не на IP-адресу.
Ще один тип, який вам швидше за все знайомий, це CNAME. Розшифровуючи як Canonical Name(Канонічне ім'я). Він пов'язує одне ім'я з іншим. Давайте подивимося на відповідь:
$dig www.petekeen.net;<<>> DiG 9.7.6-P1<<>> www.petekeen.net;; Global options: +cmd;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16785 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.petekeen.net. IN A ;; ANSWER SECTION: www.petekeen.net. 86400 IN CNAME web01.bugsplat.info. web01.bugsplat.info. 300 IN A 192.241.250.244 ;; Query time: 63 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Fri Jul 19 20:36:58 2013 ;; MSG SIZE rcvd: 86
Відразу видно, що ми отримали дві відповіді. Перший говорить, що www.petekeen.net вказує на web01.bugsplat.info. Другий повертає запис A для сервера. Можна вважати, що CNAME – це псевдонім (або аліас) для іншого сервера.
Що не так з CNAME
Записи CNAME дуже корисні, але є важливий момент: якщо є CNAME з якимось ім'ям, то не можна створити інший запис з таким самим ім'ям. Ні MX, ні A, ні NS, нічого.
Причина в тому, що DNS робить заміну таким чином, що всі записи місця, куди вказує CNAME , також валідні для CNAME . У нашому прикладі, записи у www.petekeen.net та web01.bugsplat.info збігатимуться.
Тому не можна робити CNAME на кореневому домені на кшталт petekeen.net, тому що зазвичай там потрібні інші записи, наприклад, MX.
Запити до інших серверів
Уявімо, що конфігурація DNS зіпсована. Вам здається, що ви виправили проблему, але не хочете чекати, коли оновиться кеш щоб переконатися. За допомогою dig можна зробити запит до публічного DNS-сервера замість свого дефолтного, ось так:
$dig www.petekeen.net @8.8.8.8
Символ @ з IP-адресою або хостом змушує dig виробляти запит до вказаного сервера через порт за замовчуванням. Можна використовувати публічний DNS-сервер Гугла або майже публічний-сервер Level 3 за адресою 4.2.2.2 .
Типові ситуації
Давайте розглянемо типові ситуації, знайомі багатьом веб-розробникам.
Редирект домену на www
Часто потрібно зробити редирект домену iskettlemanstillopen.com на www.iskettlemanstillopen.com. Реєстратори типу Namecheap або DNSimple називають це URL Redirect. Ось приклад з адмінки Namecheap:
Символ @ означає кореневий домен iskettlemanstillopen.com. Давайте подивимося на запис A цього домену:
$dig iskettlemanstillopen.com;; QUESTION SECTION: ;iskettlemanstillopen.com. IN A;; ANSWER SECTION: iskettlemanstillopen.com. 500 IN A 192.64.119.118
Цей IP належить Namecheap"у, і там крутиться маленький веб-сервер, який просто робить перенаправлення на рівні HTTP на адресу http://www.iskettlemanstillopen.com:
$ curl -I iskettlemanstillopen.com curl -I iskettlemanstillopen.com HTTP/1.1 302 Moved Temporarily Server: nginx Date: Fri, 19 Jul 2013 23:53:21 GMT Content-Type: text/html Connection: keep-alive : 154 Місцезнаходження: http://www.iskettlemanstillopen.com/
CNAME для Heroku або Github
Погляньте на скріншот вище. На другому рядку там CNAME. У цьому випадку www.iskettlemanstillopen.com вказує на програму, запущену на Heroku.
$ heroku domains === warm-journey-3906 Domain Names warm-journey-3906.herokuapp.com www.iskettlemanstillopen.com
З Github схожа історія, але там потрібно створити спеціальний файл докорінно репозиторію, і назвати його CNAME . Див. документацію .dns Додати теги
Послуга «Перенаправлення домену» дозволяє налаштувати правила та перенаправляти відвідувача, який звернувся до доменного імені, на вказану вами інтернет-адресу. Послуга підтримує роботу з доменами. .
У цій статті ми розповімо про налаштування для роботи з послугою.
Налаштування домену
Послуга може працювати лише у випадку, якщо ваш домен делегований. Для делегування домену необхідні DNS-сервери, які могли б повідомити користувачам мережі Інтернет інформацію про ваш домен (зону). Таких серверів має бути два або більше.
У службу «Переадресація домену» вже включена підтримка DNS. Якщо послуга замовляється на той самий договір, що й домен, то при замовленні налаштування виконуються автоматично.
Також ви можете самостійно вказати DNS-сервери в залежності від рівня домену, для якого замовлена послуга перенаправлення:
ns3-fwl2.сайт
ns4-fwl2.сайт
ns8-fwl2.сайт
ns3-fwl3.сайт
ns4-fwl3.сайт
ns8-fwl3.сайт
ns3-fwl4.сайт
ns4-fwl4.сайт
ns8-fwl4.сайт
ns3-fwl5.сайт
ns4-fwl5.сайт
ns8-fwl5.сайт
Записи у файл зони
Якщо ви використовуєте DNS-сервера, включені до послуги «Переадресація домену», необхідні записи вносяться автоматично.
При використанні своїх DNS-серверів потрібно внести до файлу зони домену на первинному DNS-сервері (primary) запису A. В рамках однієї послуги перенаправлення для самого домену і будь-якого з його піддоменів необхідно вказувати ту саму IP-адресу.
Залежно від рівня домену, для якого замовлено послугу перенаправлення, записи A мають бути такими:
- для домену другого рівня, виду web-forward.ru:
www.forward.ru. A 109.70.27.4
- для домену третього рівня, виду test.web-forward.ru:
test.web-forward.ru. A 109.70.27.5
- для домену четвертого рівня, виду forum.eng.web-forward.ru:
forum.eng.web-forward.ru. A 109.70.27.6
- для домену п'ятого рівня, виду www.forum.eng.web-forward.ru:
www.forum.eng.web-forward.ru. A 109.70.27.7
Налаштування послуги «Перенаправлення домену»
Перенаправлення можна включити для домену, всіх його піддоменів, а також налаштувати до десяти індивідуальних правил перенаправлення для конкретних піддоменів.
Внести зміни до налаштувань послуги ви можете у Розділ для клієнтів → Послуги→ Перегляд та зміна даних.
Для кожного правила перенаправлення можна вказати такі параметри:
1. Ім'я піддомена, для якого налаштовується правило
Необхідно вказати піддомен, з якого буде здійснено перенаправлення. Можна вказувати:
- ім'я піддомену, для якого потрібно налаштувати перенаправлення. Допускається необмежену кількість рівнів вкладеності, але при цьому довжина запису, включаючи точки, не повинна перевищувати 63 символи;
- "*" (зірочку), якщо необхідно задати загальне правило перенаправлення. Таке правило діятиме будь-яких піддоменів, для яких не налаштовані індивідуальні правила.
2. Адреса перенаправлення
URL сторінки, на яку автоматично буде перенаправлено відвідувача.
3. Спосіб перенаправлення
Ви можете вибрати один із таких способів перенаправлення:
- Тимчасовий або постійний перенапрямок
Тимчасове перенаправлення (код HTTP відповіді "302 Moved Temporarily"). Код відповіді HTTP 302 повідомляє клієнтським програмам (у тому числі пошуковим системам), що сайт переміщений тимчасово. Встановлюється за замовчуванням.
Постійне перенаправлення (код HTTP відповіді "301 Moved Permanently"). Код відповіді HTTP 301 говорить клієнтським програмам (у тому числі пошуковим системам), що сайт переміщений назавжди.
В обох випадках відвідувач автоматично переходить на URL сторінки, на яку було здійснено перенаправлення. Вибір методу перенаправления (301, 302) практично має значення лише пошукових систем.
- Маскування адреси у кадрі
При такому способі перенаправлення веб-сторінка перебуватиме всередині кадру. При всіх переходах за посиланнями всередині кадру в адресному рядку браузера відвідувачі бачитимуть доменне ім'я, з якого було здійснено переадресацію. Як заголовок (title) сторінки буде відображатися текст, вказаний вами в налаштуваннях правила перенаправлення.
Якщо ви вибрали маскування адреси у кадрі, слід враховувати, що:
- при встановленні посилань всередині вашої веб-сторінки на інші ресурси, у тезі посилання необхідно вказати target=_top . В іншому випадку чужа веб-сторінка також буде відкрита всередині вашого кадру, і відвідувач бачитиме в віконці URL ваше доменне ім'я. Приклад правильного написання посилання на цей випадок: RU-CENTER
- дійсна адреса веб-сторінки, на яку здійснюється перенаправлення, хоча і не відображається в рядку URL, може бути легко розрахована будь-яким відвідувачем.
4. Опція «Зі збереженням шляху».
При спробі звернутися до сторінки, розміщеної на домені, для якого складається правило, перенаправлення відбудеться на адресу перенаправлення, до якого буде додано шлях до цієї сторінки ..web-forward.ru, то при зверненні до сторінки dns.web-forward.
