Що таке DNS? Пояснення концепцій системи доменних імен, сервера DNS та IP-адрес

Вступ

До кінця цієї статті ви повинні краще зрозуміти:

  1. Що таке DNS і що він робить
  2. Що роблять DNS-сервери
  3. Як працюють адреси Інтернет-протоколу (IP) у контексті DNS

Важливі поняття

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

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

Психічні моделі дають вам систему відліку, коли речі стають трохи дивними та незнайомими.

Тож давайте закладемо основи.

  • Запит та відповідь. Це коли Річ 1 просить щось у Речі 2, а Реч 2 відповідає на цей запит. Подобається це:
  • Взаємозв'язки батьків і дочірніх вузлів та графіки, які виглядають так (лише складніше).
  • Повідомлення. Це не запит та відповідь, оскільки відповіді немає. У світі DNS форматування та вміст повідомлень залежать від використання.
  • Відносини клієнт-сервер. Найпростішими словами, сервер - це програмний чи апаратний пристрій, який забезпечує функціональність інших програмних чи апаратних пристроїв, які називаються «клієнтами».

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

Що таке DNS?

Система доменних імен (DNS) відображає зручні для читання доменні імена (в URL-адресах або адресах електронної пошти) на IP-адреси. Наприклад, DNS перекладає та відображає домен freecodecamp.org на IP-адресу 104.26.2.33.

Щоб допомогти вам повністю зрозуміти цей опис, у цьому розділі докладно:

  • Історичний контекст розвитку DNS - які проблеми це було та IP-адреси вирішення?
  • Доменні імена
  • IP-адреси

Історичний контекст

У 1966 році Агентство перспективних дослідницьких проектів (ARPA), державне агентство США, заснувало комп’ютерну мережу ARPAnet. Простіше кажучи, подумайте про ARPAnet як про першу ітерацію того, що ми сьогодні знаємо як Інтернет.

Основні цілі ARPAnet включали

“(1) забезпечення надійного зв’язку навіть у випадку часткової несправності обладнання або мережі, (2) можливість підключення до різних типів комп’ютерів та операційних систем і (3) будучи спільним зусиллям, а не монополією, контрольованою одним корпорація. Для того, щоб забезпечити надійний зв'язок внаслідок несправності обладнання, ARPANET був розроблений таким чином, що жодна точка або посилання не були критичнішими, ніж будь-які інші. Це супроводжувалося побудовою надлишкових маршрутів та використанням на ходу перенаправлення даних, якщо якась частина мережі вийшла з ладу ».

Проблеми

DNS і TCP / IP мали вирішальне значення при вирішенні двох проблем з ARPAnet:

Для ARPAnet існувало одне розташування (файл під назвою HOSTS.TXT), що містив усі зіставлення імен та адрес для кожного хосту в мережі.

“HOSTS.TXT підтримувався Мережевим інформаційним центром SRI (що називається“ NIC ”) і розповсюджувався з одного хоста, SRI-NIC. [*] Адміністратори ARPAnet зазвичай надсилали свої зміни до NIC і періодично передавали FTP до SRI- NIC та схопив поточний файл HOSTS.TXT. Їхні зміни було зведено до нового файлу HOSTS.TXT один-два рази на тиждень ».

З цією організацією було три проблеми:

  1. Трафік і завантаження - розповсюдження файлу стає занадто великим для відповідального хоста.
  2. Зіткнення імен - кожен хост повинен мати унікальне ім'я, і ​​не було централізованого органу, який заважав би користувачам мережі додавати хост із суперечливим (не унікальним) ім'ям, тим самим "порушуючи всю схему".
  3. Послідовність - акт оновлення файлу та забезпечення того, щоб усі хости мали найновішу версію, став неможливим або, принаймні, дуже складним.

По суті, HOSTS.TX був єдиною точкою відмови, тому весь процес тут не мав достатнього масштабу після певної кількості хостів. ARPAnet потребував децентралізованого та масштабованого рішення. DNS це було. Джерело

Зв'язок між хостом і хостом в одній і тій же мережі був недостатньо надійним. TCP / IP допоміг вирішити цю проблему.

  1. Протокол управління передачею (TCP) забезпечує заходи забезпечення якості процесу перетворення повідомлень (між хостами) в пакети. Протокол TCP орієнтований на підключення, що означає встановлення зв'язку між хостом джерела та хостом призначення.
  2. Інтернет-протокол (IP) визначає спосіб передачі повідомлень (пакетів) між хостом джерела та хостом призначення. IP-адреса - це унікальний ідентифікатор для певного шляху, який веде до хоста в мережі.
  3. TCP та IP тісно співпрацюють, тому їх зазвичай називають "TCP / IP".
  4. Хоча я не буду заглиблюватися в це в цій статті, як TCP, так і Протокол користувальницьких датаграм (UDP) використовуються на рівні передачі даних DNS. UDP швидший, набагато менш надійний і не вимагає з'єднань; TCP повільніший, набагато надійніший, але потребує з’єднань. Вони використовуються у міру необхідності та доречності в DNS; зайве говорити, що включення TCP до APRAnet було цінним доповненням до рівня передачі даних.

На початку 1980-х років DNS та TCP / IP (і, отже, IP-адреси) були стандартними операційними процедурами для ARPAnet.

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

Тепер, коли у нас є деякий історичний контекст, давайте перейдемо до вивчення більше про доменні імена та IP-адреси.

Доменні імена

У контексті DNS доменне ім'я забезпечує зручний спосіб вказувати на нелокальні ресурси. Це може бути веб-сайт, поштова система, сервер друку або будь-який інший сервер, доступний в Інтернеті. Доменне ім’я може бути не просто веб-сайтом!

"Мета доменних імен полягає у забезпеченні механізму іменування ресурсів таким чином, щоб імена могли використовуватися в різних хостах, мережах, сімействах протоколів, інтернетах та адміністративних організаціях".

Доменне ім’я набагато легше запам’ятати та ввести в термінал чи Інтернет-браузер, ніж IP-адресу.

Доменне ім’я є частиною Єдиного локатора ресурсів (URL), але терміни не є синонімами . URL-адреса - це повна веб-адреса ресурсу, тоді як доменне ім’я - це назва веб-сайту і є підкомпонентом кожної URL-адреси.

Незважаючи на те, що між URL-адресами та іменами доменів існують технічні відмінності, веб-браузери зазвичай ставляться до них однаково, тож ви потрапите на веб-сайт, якщо введете повну веб-адресу або просто ім’я домену.

Домени верхнього рівня та домени другого рівня

У будь-якому даному домені є дві частини: домен верхнього рівня (TLD) та домен другого рівня (SLD). Частини доменного імені стають більш конкретними при переміщенні праворуч (кінець) вліво (початок).

Спочатку це може заплутати. Наприклад, давайте подивимось на “freecodecamp.org”

  • URL: //www.freecodecamp.org
  • Доменне ім'я: freecodecamp.com
  • TLD: орг
  • SLD: freecodecamp

На початку існування ARPAnet була доступна обмежена кількість доменів верхнього рівня, включаючи домени com, edu, gov, org, arpa, mil та 2-літерні коди країн. Спочатку ці домени верхнього рівня були зарезервовані для установ, що беруть участь у ARPAnet, але пізніше деякі з них стали доступними на комерційних ринках.

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

Домени другого рівня - це домени, доступні для індивідуального придбання через реєстратори доменів (наприклад, Namecheap).

IP-адреси

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

Як зазначалося раніше, IP-адреса - це унікальний ідентифікатор певного шляху, який веде до хосту в мережі. Я хотів би зробити посилання на аналогію телефонного номера та телефону: номер телефону не відображає сам телефон, це лише спосіб зв’язатися з людиною за допомогою телефону.

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

Як і доменне ім'я, організація IP-адрес має ієрархічну структуру. На відміну від доменних імен, IP-адреси стають більш конкретними, рухаючись зліва направо. Це приклад IPv4 нижче:

Діаграма показує, що 129.144 - це частина мережі, а 50.56 - частина хосту адреси IPv4.
  • Мережа: унікальний номер, призначений вашій мережі
  • Хост: ідентифікує хост (машину) в мережі

Якщо потрібна більша конкретність, адміністратори мережі можуть підмережі адресного простору та делегувати додаткові номери.

Скільки існує IP-адрес?

IPv4 був першою ітерацією IP, яку ARPAnet використовував у виробництві. Розгорнута на початку 80-х, вона все ще є найбільш поширеною версією IP. Це 32-розрядна схема, і тому вона може підтримувати трохи більше 4 мільярдів адрес.

Але почекайте, чи достатньо цього? Ні.

IPv6 має 128-бітну схему, яка дозволяє йому підтримувати 340 немільйонних адрес. Він також пропонує покращення продуктивності IPv4.

Приклад адреси IPv4:

  • 104.26.2.33 (freeCodeCamp)

Приклад адреси IPv6:

  • 2001: db8: a0b: 12f0 :: 1 (стислий формат і не вказує на freeCodeCamp)

Як працює система доменних імен?

Отже, ми дізналися про доменні імена! Ми дізналися про IP-адреси! Тепер, як вони відносяться до системи доменних імен?

Перш за все, вони вписуються у простір імен.

Простір імен доменів

Як випливає з мови домену верхнього рівня та домену другого рівня, простір імен базується на ієрархії

“... з ієрархією, яка приблизно відповідає організаційній структурі, і іменами з використанням". " як символ для позначення межі між рівнями ієрархії ". Джерело

Цей графік дерева з коренем вгорі найкраще ілюструє структуру:

Давайте розберемо це, починаючи зверху.

У верхній частині цього графіку відзначено "." називається "коренем".

«Авторитетні сервери імен, що обслуговують кореневу зону DNS, широко відомі як„ кореневі сервери “, є мережею із сотень серверів у багатьох країнах світу. Вони налаштовані в кореневій зоні DNS як 13 іменованих повноважень. "

Кореневий домен має мітку нульової довжини.

Відтепер кожен вузол (крапка) на графіку має унікальну мітку довжиною до 63 символів.

Першим рівнем нижче від кореня є TLD: com, org, edu та gov. Зверніть увагу, що цей графік не містить повного списку TLD.

Нижче TLD розташовані SLD, домени другого рівня. Нащадки кожного вузла називаються «субдоменами», які досі вважаються частиною батьківського домену. Наприклад, у freecodecamp.org freecodecamp (SLD) є субдоменом org (TLD).

Залежно від ієрархії веб-сайту, можуть бути домени третього, четвертого, п’ятого рівня. Наприклад, у hypothetical-subdomain.freecodecamp.org гіпотетичний-субдомен - це домен третього рівня та субдомен freecodecamp. Так далі і так далі, принаймні до 127 рівнів, що є максимально дозволеним DNS.

Хто керує простором імен?

Чи не було б шаленим намагатися, щоб одна людина або організація керувала всім? Так би. Особливо тому, що однією з головних цілей проектування DNS було сприяння розподіленому децентралізованому управлінню системою в цілому.

Я хотів би сказати вам, що відповідальних людей називають «Королями простору імен», але на жаль.

Кожен домен (або субдомен) у просторі імен домену є або є частиною зони , “частиною простору імен, що управляється автономно”. Отже, простір імен розбито на зони.

Відповідальність за ці зони управляється шляхом делегування та адміністрування.

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

Наприклад, Реєстр громадських інтересів адмініструє доменне ім'я org і працює з 2003 року. Реєстр громадських інтересів може делегувати відповідальність іншим сторонам щодо управління субдоменами org, скажімо freecodecamp. І тоді той, хто адмініструє freecodecamp, може покласти відповідальність за субдомени freecodecamp (наприклад, hypothethical-subdomain.freecodecamp.com) іншій стороні.

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

Це підводить нас до однієї з найбільш фундаментальних концепцій в системі доменних імен.

Сервери доменних імен

"Програми, що зберігають інформацію про доменний простір імен, називаються серверами імен."

На цьому етапі корисно, принаймні спочатку, думати про взаємовідносини клієнт-сервер. Сервери імен доменів є "серверною" стороною відносин клієнт-сервер. Сервери імен можуть завантажувати одну, сотні чи навіть тисячі зон, але вони ніколи не завантажують весь простір імен. Після того, як сервер імен завантажив всю зону, він називається авторитетним для цієї зони.

Щоб зрозуміти, чому сервери імен функціонують так, як корисно, корисно зрозуміти «клієнтську» частину відносин.

Розгадувачі

У DNS клієнт (запитувач інформації) називається "вирішувачем", що спочатку може здатися відсталим. Чи не сервер, який вирішує запит, не буде називатися "вирішувачем?" Я теж так думав, але це не так. Найкраще просто запам’ятати це і рухатися далі.

Розробники, як правило, фактично включаються в більшість операційних систем, тому додатки, встановлені в ОС, не повинні з'ясовувати, як робити низькорівневі запити DNS.

DNS-запити та відповіді на них є типами DNS-повідомлень і мають власний протокол передачі даних (зазвичай UDP). Розробники відповідають за допомогу програмам, встановленим в ОС, перекладати запити на дані, пов’язані з DNS, у запити DNS.

Таким чином, вирішувачі відповідають за упаковку та відправлення запитів на дані. Після того, як вирішувач отримає відповідь (якщо взагалі), він передає її назад оригінальному додатку, що запитує, у форматі, що витрачається на запитуючу програму.

Повернутися до серверів імен

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

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

Типи запитів

Тип запиту? Так, існує кілька типів запитів DNS. Але спочатку, що зазвичай є у запиті DNS? Це запит на інформацію, зокрема про IP-адресу, пов’язану з іменем домену.

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

Якщо вам це потрібно, ви також можете зробити запит щодо доменного імені, якщо у вас є лише IP-адреса. Це називається зворотним пошуком DNS.

Як тільки запит потрапить на сервер імен, що містить бажані файли даних, запит може бути вирішений. Сервери імен пов’язані з кількома файлами даних, усі або деякі з яких можуть бути використані для вирішення запиту.

Ресурсні записи (RR)

Це файли даних у просторі імен домену. Ці файли даних мають певні формати та вміст.

Найпоширеніші RR:

  • Запис: якщо ви не чули про жодні інші RR, крім цієї, це мало б сенс. Ймовірно, це найвідоміший RR і містить IP-адресу даного домену.
  • Запис CNAME: якщо ви не чули про жодні інші RR, крім цього та запису A, це також мало б сенс. "C" означає "канонічний" і використовується замість запису A для призначення псевдоніма домену.
  • Запис SOA: цей запис містить адміністративну інформацію про нього, включаючи електронну адресу адміністратора. Підказка: якщо ви адмініструєте зону, переконайтесь, що тут є дійсна адреса електронної пошти, щоб люди могли зв’язатися з вами, якщо це потрібно.
  • Інші важливі типи записів ресурсів (RR) - PR, NS, SRV та MX. Прочитайте про них тут.

Кешування та час для життя (TTL)

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

Але після того, як ця інформація кешована, вона є як статичною, так і ізольованою, а тому ризикує застаріти. Отже, усі записи ресурсів мають значення, яке називається часом життя (TTL), яке диктує, як довго ці дані можна кешувати. Коли цей час закінчується (досягає нуля), сервер імен видаляє запис.

Важливе зауваження: TTL не застосовується до серверів імен, авторитетних для зони, що містить запис ресурсу. Це стосується лише сервера імен, який кешував цей запис ресурсу.

День у житті запиту

У цій статті ми висвітлили багато підстав, і це дуже важко для концепцій. Щоб пов’язати все це разом і зробити це реальним, ось день (образний день) у житті запиту.

То чому мені все це потрібно знати?

Існує так багато причин, щоб ознайомитися з поняттями, пов’язаними з DNS та IP-адресами.

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

Висновок

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

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

  • Реалізації серверу імен
  • Пересилання
  • (Докладніше про) мітки вузлів
  • Первинні та вторинні відносини сервера імен
  • Алгоритми ретрансляції
  • Балансування навантаження
  • Плюс, інші загальні теми про те, як функціонує Інтернет, такі як:
  • Всесвітня мережа
  • HTTP
  • FTP
  • Шар протоколів зв'язку: рівень зв'язку, рівень IP, транспортний рівень, рівень Інтернету тощо.

Для тих з вас, хто все ще читає іхочу дізнатись більше про DNS, я в першу чергу рекомендую “DNS і BIND, 5-е видання”, написане Cricket Liu та опубліковане O’Reilly Media. Це безцінно.

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

Ресурси

  1. RFC 1034: ІМЕНИ ДОМЕНІВ - ПОНЯТТЯ ТА ПОСЛУГИ
  2. RFC 1035: ІМЕНИ ДОМЕНІВ - ВПРОВАДЖЕННЯ ТА СПЕЦИФІКАЦІЯ
  3. RFC 1122: Вимоги до Інтернет-хостів - рівні зв'язку
  4. Детальніше про цілі проектування DNS від Connected: Internet Encyclopedia
  5. Як Інтернет народився від ARPAnet для Інтерпретатора, від The ​​Conversation
  6. Вивчення відео-курсу DNS, автор Cricket Liu, від O'Reilly Media

Трохи про мене

Я Хлоя Такер, художник і розробник у Портленді, штат Орегон. Як колишній педагог, я постійно шукаю стику навчання та викладання, або технологій та мистецтва. Зв’яжіться зі мною у Twitter @_chloetucker та перевірте мій веб-сайт за адресою chloe.dev.