Модул 1 · 1.4
Пътуването на една DNS заявка
Модул 1: Какво е DNS? · Време за четене: 8 минути
Цел на урока: След този урок ще можете стъпка по стъпка да обясните как резолвер намира отговор и къде по пътя отговорите се запомнят.
Основни понятия: резолвер (рекурсивен), root сървър, TLD сървър, авторитетен (authoritative) DNS сървър, препращане (делегация), кеш
Два вида DNS сървъри
В урок 1.1 видяхте, че DNS е разпределена система: никой не знае всичко. Как тогава Вашият браузър все пак получава адреса на www.example.com? За това си сътрудничат два вида сървъри:
- Авторитетните DNS сървъри (на английски authoritative) знаят отговора за своята собствена част. DNS сървърите на
example.comзнаят записите наexample.com. Те не търсят нищо за други. - Резолверите (наричани също рекурсивни резолвери) търсят отговора вместо Вас. Те питат отново и отново, докато го получат. Вашият интернет доставчик има резолвер, а има и публични резолвери като тези на Quad9, Cloudflare или Google.
Самият Ви компютър почти нищо не търси сам. Той има малък stub резолвер, който предава заявката на резолвера на Вашата мрежа и получава отговора обратно.
Пътуването, стъпка по стъпка
Да предположим: резолверът още нищо не е запомнил и Вие питате за A записа на www.example.com.
- Вашият компютър пита резолвера: „Какъв е A записът на www.example.com?“
- Резолверът пита root сървър. Всеки резолвер има вграден малък списък с адресите на root сървърите. Root сървърът не знае нищо за
example.com, но знае кой управлява.com. Той отговаря с препращане: „За това трябва да отидете при DNS сървърите на com: a.gtld-servers.net, b.gtld-servers.net, и така нататък.“ - Резолверът пита DNS сървър на .com. Той също не знае IP адреса на
www.example.com, но знае кои DNS сървъри имаexample.com. Отново препращане: „Питайте ns1.hosting.example или ns2.hosting.example.“ - Резолверът пита DNS сървър на example.com. Той е авторитетен за този домейн и дава отговора: „www.example.com има A запис 192.0.2.10.“
- Резолверът дава отговора на Вашия компютър. Вашият браузър се свързва с 192.0.2.10.
Препращане от по-високо ниво към DNS сървърите на по-ниско ниво се нарича делегация. Root делегира .com на Verisign, .com делегира example.com на DNS сървърите, посочени от притежателя на домейна. За .bg домейн процесът е абсолютно същият, само че root препраща към DNS сървърите на .bg (Register.BG). За .nl домейн root препраща към DNS сървърите на .nl (SIDN, уебсайтът на регистъра на .nl в Нидерландия, например ns1.dns.nl). Това ще видите сами в задачата в края на този урок. Затова е толкова важно DNS сървърите при регистъра да са верни (урок 2.1).
Кешът: не всеки път цялото пътуване
Ако при всяка заявка всеки резолвер отново започваше от root, root сървърите щяха да получават невъобразимо количество заявки. Това не се случва, защото резолверът запомня отговорите за известно време. Тази памет се нарича кеш.
Колко дълго може да се запомни отговор, е записано в самия отговор: TTL (time to live), в секунди. TTL от 3600 означава: този отговор може да се запомни за един час. Запомнят се и препращанията. Резолвер, който току-що е научил кои DNS сървъри има .com, не трябва следващия път отново да пита root за това.
Ако друг потребител при същия доставчик попита минута по-късно за www.example.com, резолверът отговаря веднага от кеша си. Без пътуване, без чакане.
Кешове се намират на повече места:
- в резолвера на Вашия доставчик или публичния резолвер, който използвате;
- във Вашата операционна система (Windows, macOS, Вашия телефон);
- във Вашия браузър;
- понякога във Вашия рутер.
Това е бързо и ефективно, но има последица, с която по-късно често ще се сблъсквате: ако промените запис, кешовете продължават да дават стария отговор, докато изтече техният TTL. Затова един човек вече вижда промяна, а друг все още не. Модул 6 разглежда това подробно.
Root сървърите
Има 13 имена за root сървърите: от a.root-servers.net до m.root-servers.net. Те се управляват от дванадесет различни организации. Зад всяко име стоят много сървъри по целия свят, на стотици места, които споделят един и същ адрес (това се нарича anycast). Вашият резолвер автоматично се свързва с най-близкия. По същия начин работят и TLD DNS сървърите, като тези на .com и .bg. Благодарение на това DNS е бърз и продължава да работи, дори ако някъде сървър спре да функционира.
Къде може да възникне проблем
Ако познавате пътуването, можете по-добре да разберете проблемите:
- Делегацията не е вярна. При регистъра са посочени DNS сървъри, които (вече) не познават домейна. Резолверът не може да продължи на стъпка 4. Отговорът е грешка или изобщо няма отговор.
- Авторитетният сървър дава различен отговор от очаквания. Тогава сте променили записа на различно място от там, където се намират DNS сървърите (урок 2.1).
- Кешът все още има стария отговор. Тогава нищо не е счупено. Трябва да изчакате изтичането на TTL или да изчистите собствения си кеш.
- DNSSEC не е валиден. Валидиращ резолвер проверява подписите по пътя. Ако веригата не е вярна, той отказва отговора (урок 8.1).
С инструмента dig +trace можете сами да проследите пътуването, от root до авторитетния сървър. Това ще научите в урок 8.2. Онлайн инструментите също могат да го направят.
Обобщение
- Авторитетните DNS сървъри знаят отговора за своя собствен домейн; резолверите търсят отговора вместо Вас.
- Резолвер започва от root, получава препращане към TLD, после към DNS сървърите на домейна, и там получава отговора.
- Такова препращане се нарича делегация.
- Отговорите се запомнят в кешове, толкова дълго, колкото казва TTL; затова промените не се виждат навсякъде веднага.
- Има 13 имена на root сървъри, но благодарение на anycast зад тях стоят много сървъри по целия свят.
Тест
Задача
Задача Z1.4: Проследяване на пътуването. Проследете пътуването за www.sidn.nl, с dig +trace www.sidn.nl или онлайн инструмент, който показва trace. Попълнете: (1) един DNS сървър на nl., който срещате по пътя, (2) един авторитетен DNS сървър на sidn.nl.
Допълнително четене
Тези статии описват ситуацията при WebOké. При други доставчици работи по сходен начин.