Віктор Турський про програмування / навігатор

Мережі та інтернет / крок 03

Як працює Інтернет: рекурсивний пошук у DNS

середній 13:56 дивитися на YouTube ↗

Розділи

Про що це відео

Другий епізод про DNS відповідає на питання, яке лишилося невирішеним після першого: чи кожен DNS-сервер у світі тримає записи про кожен сайт? Ні. Автор проходить — спершу на дошці, потім наживо в терміналі — як працює рекурсивна резолюція. Він бере конкретний наскрізний приклад: ви купуєте itquiz.com у реєстратора, орендуєте сервер у хмарного провайдера (DigitalOcean/Google Cloud/Amazon — «неважливо») і додаєте A-запис в адмінці реєстратора, щоб відвідувачі потрапляли на вашу машину. Головна загадка: резолвер вашого провайдера ніколи не чув про itquiz.com — як він знаходить правильний авторитетний сервер?

Головне

  • Резолвер, з яким спілкується ваш браузер (DNS провайдера, кешувальний резолвер на домашньому роутері чи 8.8.8.8), майже ніколи не є тим сервером, де ви додали запис. Він мусить знайти відповідь.
  • Ієрархію проходять зверху вниз: кореневі сервери (root servers) (зона .) знають nameserver’и для зон TLD (.com, .org, .edu…); сервери TLD (.com) повертають NS-записи для itquiz.com; ті вказують на авторитетний DNS-сервер (у його випадку Cloudflare), який власне зберігає A-запис. Резолюція крок за кроком повертає NS-записи, а вкінці — A-запис.
  • Резолвер стартує з root hints — IP-адрес ~13 кореневих серверів, зашитих у його конфіг, тож він завжди знає, звідки почати.
  • Він доводить кожен крок вручну через dig +norecurse: нерекурсивний запит до 8.8.8.8 не повертає нічого (Google його не закешував); dig . NS дає 13 кореневих серверів; беремо IP кореневого, питаємо його про NS-сервери .com (відповідь включає IP в additional section, щоб зекономити round-trip), питаємо сервер .com про NS itquiz.com (отримуємо два nameserver’и Cloudflare + їхні IPv4/IPv6), а тоді вже питаємо Cloudflare про A-запис. Робити це вручну — це рівно те, що 8.8.8.8 робить під капотом автоматично.
  • dig +trace автоматизує весь рекурсивний обхід із вашої локальної машини і друкує кожен хоп (root → .com TLD → авторитетний), тож ви можете спостерігати за процесом.
  • Кешування + TTL: оскільки кожен пошук — це багато інтернет-round-trip’ів, сервери кешують. Кожен запис несе TTL у секундахitquiz.com показав 300с (5 хв), але 24 год теж поширено. Ви задаєте його в адмінці реєстратора. Якщо TTL 24 год і ви змінюєте IP, зміна поширюється не одразу: різні резолвери закешували в різний час, тож одні побачать її за хвилини, інші — аж за повний TTL. Часті зміни IP → малий TTL; стабільні IP → великий TTL.

Теми відео

Частина цих треків