Все, що потрібно знати про DNS

Якщо ви читаєте цю статтю, то швидше за все ви використовували систему доменних імен (DNS), навіть не підозрюючи про це. DNS — фундаментальна частина інтернету, яка дозволяє нам отримувати доступ до веб-сайтів та онлайн-послуг, використовуючи замість цифрових адрес зручні для людини імена. Але як саме вона працює? У цій статті я розповім про основи DNS і як вона допомагає нам орієнтуватися в Інтернеті.

Що таке DNS

DNS — це телефонна книга для Інтернету. Він зіставляє доменні імена, такі як www.example.com, з IP-адресами, наприклад 192.0.2.1, які є фактичним розташуванням серверів, на яких розміщені веб-сайти. Таким чином, нам не потрібно запам'ятовувати довгі рядки цифр, щоб відвідати наші улюблені сайти. Ми можемо просто ввести назву та дозволити DNS зробити все інше.

Як працює DNS

Але звідки DNS знає, де знайти IP-адресу для даного імені? Відповідь у тому, що не знає всього сам. Він покладається на мережу серверів, які називаються DNS-резолверами, що працюють разом, щоб знайти відповідь.

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

DNS-резолвер – це сервер, який зберігає записи DNS та відповідає на DNS-запити.

Давайте розберемо це з прикладу. Припустимо, ви хочете відвідати сайт www.example.com. Ось список кроків або місць, які беруть участь у отриманні відповіді на www.example.come :

• Перевіряються локальні кеші
• Перевіряються рекурсивні DNS-сервери
• Перевіряються кореневі DNS-сервери
• Перевіряються DNS-сервери доменів верхнього рівня
• Перевіряються авторитетні DNS-сервери

Крок 1: Локальні кеші

Першим місцем, яке перевірить комп'ютер, буде його локальний кеш. Це список доменних імен і відповідних IP-адрес, до яких ваш комп'ютер нещодавно звертався. Якщо шукане доменне ім'я знаходиться в кеші, комп'ютер буде використовувати IP-адресу з кешу і пропустить інші кроки.

Ось список локальних кешів, які можуть мати зіставлення домену та IP-адреси:

• Кеш браузера: Можливо, ви вже відвідували цей сайт, і ваш браузер міг кешувати IP-адресу.
• Кеш DNS: На основі TTL (Time To Live) запису DNS ваш комп'ютер міг кешувати IP-адресу.
• Файл Hosts: Можливо, ви вручну додали зіставлення домену та IP-адреси у файл hosts.

Крок 2: Рекурсивні сервери DNS

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

Крок 3: Кореневий DNS-сервер

Кореневий DNS-сервер — це DNS-сервер верхнього рівня в ієрархії DNS. Вони відповідають за передачу відповідальності за відповіді на запити для доменів верхнього рівня, таких як .com, .org та .net.

У них немає IP-адрес для самих веб-сайтів. Натомість у них є IP-адреси DNS-серверів доменів верхнього рівня. Наприклад, кореневий DNS-сервер для .com – це a.gtld-servers.net. Сервери імен для TLD можна переглянути, виконавши команду:

dig +short NS com  
dig +short NS org  
dig +short NS ai  
dig +short NS fyi  
dig +short NS io

Крок 4: DNS-сервер домену верхнього рівня

DNS-сервери домену верхнього рівня відповідають за делегування відповідальності за відповіді на запити для доменів другого рівня, таких як example.com, example.org та example.a i. У них немає IP-адрес самих веб-сайтів. Натомість вони мають IP-адреси авторитетних DNS-серверів (тобто місць, де зберігаються фактичні записи DNS).

Ви можете побачити сервери імен для домену другого рівня, виконавши команду:

dig +short NS cs.fyi  
dig +short NS github.com  
dig +short NS medium.com

Крок 5: Авторитарний DNS-сервер

Це місце, де зберігаються фактичні записи DNS. На цьому етапі авторитетний DNS-сервер запитує A запис доменного імені. Запис A — це запис DNS, який зіставляє доменне ім'я з IP-адресою. Авторитетний DNS-сервер надішле IP-адресу рекурсивному DNS-серверу. Рекурсивний DNS-сервер відправить IP-адресу назад на ваш комп'ютер.

Як DNS працює на практиці

Давайте подивимося, як DNS працює практично, використовуючи команду dig . dig — інструмент командного рядка для запиту серверів імен DNS. Він доступний у більшості систем Linux та MacOS.

Допустимо, ми хочемо знайти IP-адресу для www.example.com. Ми можемо використовувати команду dig для пошуку IP-адреси:

dig +short www.example.com

Опція +short вказує dig друкувати лише розділ відповіді. Висновок виглядатиме приблизно так:

Це IP-адреса для www.example.com. Але як dig знайшла цю IP-адресу? Давайте подивимося, що сталося за лаштунками.

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

Давайте подивимося, що сталося у цьому випадку.Ми можемо використовувати команду dig з опцією +trace, щоб побачити повну відповідь:

dig +trace www.example.com

Я не показуватиму тут повного висновку, оскільки він досить довгий. Але ви можете виконати цю команду самостійно і помітити різні сервери DNS, задіяні в процесі.

Налагодження проблем, пов'язаних із DNS

Якщо у вас виникли проблеми з доступом до веб-сайту, ви можете використовувати команду dig для налагодження проблеми. Давайте розглянемо кілька практичних прикладів використання команди dig.

Перевірка дозволу DNS для домену

Ви можете використовувати dig , щоб перевірити, чи доменне ім'я може бути перетворено в IP-адресу. Ось приклад:

dig example.com +short

Ця команда поверне IP-адреси, пов'язані з доменним ім'ям google.com. Опція +short використовується для відображення лише IP-адрес без додаткової інформації.

Вилучення записів DNS для домену

Ви можете використовувати dig для отримання різних типів записів DNS для доменного імені. Наприклад, щоб отримати всі записи A для домену, ви можете використовувати наступну команду:

Це поверне список усіх записів A, пов'язаних з доменом example.com .

Аналогічно, щоб отримати всі записи MX для домену, ви можете використовувати наступну команду:

Це поверне список усіх записів MX, пов'язаних з доменом example.com .

Перевірка поширення DNS-інформації

Ви можете використовувати dig для перевірки того, чи були записи DNS поширені на всі DNS-сервери. Наприклад, щоб перевірити, чи були поширені записи домену MX , ви можете використовувати таку команду:

dig example.com MX + trace

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

Перевірка валідації DNSSEC

Ви можете використовувати dig , щоб перевірити, чи правильно працює перевірка DNSSEC для доменного імені.Наприклад, щоб перевірити, чи дійсні записи домену DNSSEC, можна використовувати наступну команду:

dig example.com +dnssec

Це покаже записи, пов'язані з DNSSEC для домену, і чи є вони дійсними.

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

Докладніше про DNSSEC можна прочитати тут.

Запит на конкретний DNS-сервер

Ви можете використовувати dig для запиту певного сервера DNS на наявність DNS-записів. Наприклад, щоб запросити публічний DNS-сервер Google ( 8.8.8.8 ) для записів A для домену, ви можете використовувати наступну команду:

dig example.com A @8.8.8.8

Це надішле DNS-запит на вказаний DNS-сервер (в даному випадку 8.8.8.8), замість використання DNS-сервер за замовчуванням, налаштований на локальній машині.

Поширені помилки DNS

Існує кілька поширених помилок DNS, з якими можна зіткнутися. Ось деякі з них:

Ця помилка означає, що доменне ім'я не існує. Це може бути пов'язано з тим, що ім'я домену було введено неправильно, або з тим, що термін дії домену закінчився.

Ця помилка означає, що доменне ім'я існує, але сервер DNS недоступний. Це може бути пов'язано з тим, що DNS-сервер не працює, або з тим, що DNS-сервер недоступний через проблеми в мережі.

Ця помилка означає, що сервер DNS недоступний. Це може бути пов'язано з тим, що DNS-сервер не працює, або з тим, що DNS-сервер недоступний через проблеми в мережі.

Як очистити DNS кеш

Трапляються випадки, коли необхідно очистити кеш DNS на локальній машині. Ви можете використовувати команду ipconfig для цього в Windows і dscacheutil для цього в MacOS.

Ось команда для очищення кешу DNS у Windows:

У MacOS можна використовувати наступну команду:

dscacheutil  -flushcache

Висновок

У цій статті ми дізналися про DNS і як вона працює. Ми також довідалися, як використовувати команду dig для запиту DNS-серверів на наявність DNS-записів. Я сподіваюся, що ця стаття була вам корисною; не соромтеся поділитися нею зі своїми друзями та колегами.

Давайте вже розберемося у DNS

Люди часто спантеличені доменами. Чому мій сайт не працює? Чому ця хрень поламана, нічого не допомагає, я просто хочу, щоб це працювало! Зазвичай запитує або не знає про 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  

Тут є тільки одна цікава деталь: інформація про запит. Говориться, що ми запросили запис і отримали одну відповідь. Ось:

;;; 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

Тут сказано, що біля хоста web01.bugsplat.info. є одна адреса A: 192.241.250.244. Число 300 це TTL, або time to live (Час життя). Стільки секунд можна тримати значення у кеші до повторної перевірки. Слово IN означає Internet. Так склалося історично, це необхідно для поділу типів мереж. Докладніше про це можна почитати у документі IANA's DNS Parameters.

Решта відповіді описує саму відповідь:

;;; 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

Прапор -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

Зауважте, що запис MX MX вказує на ім'я, а не на IP-адресу.

Ще один тип, який вам швидше за все знайомий, це CNAME. Розшифровуючи як Canonical Name (Канонічне ім'я). Він пов'язує одне ім'я з іншим. Давайте подивимося на відповідь:

$dig www.petekeen.net; > DiG 9.7.6-P1 > www.petekeen.net;; Global options: +cmd;; Got answer: ;; ->>HEADER

Відразу видно, що ми отримали дві відповіді. Перший говорить, що 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 . Див. документацію.

Wildcards

Більшість серверів DNS підтримують шаблони (wildcards). Наприклад, є wildcard CNAME для *.web01.bugsplat.info вказує на web01.bugsplat.info. Тоді будь-який хост на web01 вказуватиме на web01.bugsplat.info і не потрібно створювати нові записи:

$dig randomapp.web01.bugsplat.info;; QUESTION SECTION: ;randomapp.web01.bugsplat.info. IN A;; ANSWER SECTION: randomapp.web01.bugsplat.info. 300 IN CNAME web01.bugsplat.info. web01.bugsplat.info. 15 IN A 192.241.250.244

Висновок

Сподіваюся, що тепер у вас є базове розуміння DNS. Усі стандарти описані у документах:

Є ще кілька цікавих RFC, у тому числі 4034, який описує стандарт DNSSEC і 5321, який описує взаємозв'язок DNS і email. Їх цікаво шанувати для загального розвитку.