Який порт використовує DNS? Порт 53, і коли не він

Який порт DNS використовує для звичайного пошуку?

Звичайний запит, той тип, який ваш браузер надсилає десятки разів на хвилину, іде на порт 53 одним UDP-пакетом і так само повертається. RFC 1035 називає UDP «рекомендованим методом для стандартних запитів в інтернеті», бо він не потребує рукостискання: один пакет туди, один назад, готово. Саме тому DNS здається миттєвим, коли працює, і саме тому одного втраченого пакета досить, щоб усе виглядало зламаним, адже UDP не повторює запит автоматично за вас. Це робить резолвер на вашому пристрої чи роутері, зазвичай звертаючись до другого налаштованого сервера, якщо перший мовчить.

Коли DNS використовує TCP замість UDP?

Дві ситуації переводять обмін DNS на порт 53 TCP. Перша - передавання зони, коли вторинний nameserver забирає повну копію зони з первинного. RFC 1035 прямо каже, що «UDP не прийнятний для передавання зон», бо ця операція потребує надійного, впорядкованого потоку, а не одного пакета «якнайкраще». Друга - відповідь, що не вміщується в чинний розмір UDP-повідомлення. Тоді сервер повертає обрізаний UDP-пакет із виставленим бітом TC (truncated), і сумісний резолвер, помітивши цей біт, повторно надсилає той самий запит через TCP, щоб отримати повну відповідь. Ви можете самі змусити це відбутися й одразу побачити повну відповідь:

dig +tcp example.com

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

Що таке обмеження в 512 байтів і що його змінило?

RFC 1035 зафіксував розмір UDP-повідомлення на рівні 512 байтів, разом із заголовком, не рахуючи самих заголовків IP чи UDP. У 1987 році це число було щедрим, коли DNS-відповідь була жменькою записів адрес. Воно перестало бути щедрим, коли підписи DNSSEC, довші імена хостів і записи з багатьма IP-адресами стали звичайною справою, бо підписана відповідь із записом RRSIG нерідко сама собою перевищує 512 байтів.

RFC 6891, опублікований 2013 року, підняв цю стелю, не чіпаючи сам протокол передавання: EDNS0 додає псевдозапис OPT, що дає змозі резолверу заявити «найбільший UDP payload, який можна зібрати й доставити в мережевому стеку запитувача», і сам RFC пропонує 4096 байтів як практичну відправну точку. Резолвер і сервер, що обидва підтримують EDNS0, можуть обмінюватися відповідями в кілька разів більшими за старе обмеження в 512 байтів через один-єдиний UDP-пакет, і переходять на TCP, лише коли навіть цього ліміту не вистачає. Майже кожен резолвер, яким сьогодні хтось користується, зокрема й вбудований у вашу операційну систему, типово говорить EDNS0, тож це оновлення вже відбулося без жодної дії з вашого боку.

Чому брандмауери, що дозволяють лише UDP 53, спричиняють реальні проблеми

Правило брандмауера, написане роки тому і жодного разу не переглянуте, часто звучить як «дозволити UDP порт 53, заборонити все інше, пов’язане з DNS». Це правило блокує запасний шлях через TCP, потрібний протоколу, і виявлену несправність легко неправильно діагностувати, бо більшість пошуків і далі спокійно працюють. Провалюються лише ті, що перевищують ліміт UDP, і провалюються вони так, що виглядає це випадково: домен зазвичай визначається нормально, а потім раптом зависає з тайм-аутом, особливо коли задіяна валідація DNSSEC, оскільки резолвер, що виконує валідацію, змушений разом із самою відповіддю отримувати ще й записи RRSIG та DNSKEY.

На практиці це означає, що зони з підписом DNSSEC і будь-який набір записів із багатьма значеннями (наприклад, домен із десятком поштових серверів) стають ненадійними за брандмауером, що дозволяє лише UDP, тоді як усе інше виглядає цілком здоровим. Блокування вихідного TCP 53, або блокування лише в одному напрямку, - один із найпоширеніших самостійно спричинених збоїв DNS, і він рідко проявляється у базовій перевірці з’єднання, бо така перевірка зазвичай пробує лише UDP.

DNS over TLS і DNS over HTTPS: різні порти, ті самі пошуки

Два новіші транспорти переносять ті самі DNS-запити й відповіді, але зовсім прибирають їх із порту 53. DNS over TLS, визначений у RFC 7858, загортає кожен запит у TLS-сеанс на порту 853 TCP, обраному саме так, щоб мережевий оператор і далі бачив, що відбувається DoT (і міг це заблокувати), навіть не розшифровуючи трафік, оскільки сам порт уже дає чіткий сигнал.

DNS over HTTPS, визначений у RFC 8484, іде далі. Він надсилає DNS-запити як звичайні HTTPS-запити на порту 443, тому самому порту, що й будь-який інший сайт, який ви відвідуєте, і RFC називає «можливість змішувати трафік DoH з іншим HTTPS-трафіком у тому самому з’єднанні» навмисною властивістю. Саме в цьому весь сенс DoH: мережа, що перевіряє чи фільтрує лише за портом, не здатна відрізнити DNS-пошук від будь-якого іншого HTTPS-запиту, бо це той самий протокол на тому самому порту. Chrome, Firefox і Edge усі типово можуть надсилати DNS у такий спосіб уже зараз, тому блокування «порту 53» у мережі більше не гарантує, що ви заблокували DNS. Це гарантує лише блокування класичного транспорту; браузер із увімкненим DoH продовжує визначати імена через 443 незалежно від цього.

Що таке mDNS на порту 5353?

Multicast DNS - це інший протокол з подібною назвою. RFC 6762 визначає його як пристрої, що «надсилають DNS-подібні UDP-запити й відповіді через IP Multicast на UDP порт 5353», адресовані до multicast-групи 224.0.0.251 (або її еквівалента в IPv6, FF02::FB), а не до конкретного сервера. Тут узагалі немає центрального nameserver-а: кожен пристрій у локальному сегменті мережі слухає порт 5353 і відповідає за власне ім’я. Так принтер чи розумна колонка стають доступними як device.local без потреби комусь налаштовувати для них DNS-запис. Він навмисно обмежений локальним зв’язком і не має жодного стосунку до визначення публічного доменного імені, тож трафіку mDNS ніколи не потрібно виходити за межі вашого роутера.

Як перевірити, чи досяжний порт 53

Почніть із прямого запиту до відомо справного резолвера, це покаже, чи взагалі працюють звичайні UDP-пошуки:

nslookup example.com 8.8.8.8
dig example.com @1.1.1.1

Якщо це вдається, але ви підозрюєте, що заблоковано запасний шлях через TCP, примусьте TCP і порівняйте:

dig +tcp example.com @1.1.1.1

UDP-запит, що вдається, поки примусова версія через TCP завершується тайм-аутом, - вагома ознака того, що щось між вами й резолвером відкидає саме TCP 53, і це точнісінько та несправність, описана вище. Перевірити фактичну доступність порту з-за меж власної мережі допоможе наш інструмент перевірки порту: наведіть його на порт 53 вашого резолвера чи nameserver-а, і він відкриє справжнє TCP-з’єднання з іншої мережі, підтверджуючи, чи досяжний TCP 53 узагалі. Читайте результат з одним застереженням: перевірка порту тестує TCP, тож успіх там підтверджує, що запасний шлях відкритий, але нічого не каже про UDP, для якого немає рукостискання, яке можна перевірити так само. Для самого запиту, зокрема порівняння відповідей кількох публічних резолверів і різних регіонів одночасно, запустіть інструмент DNS-запиту.

Часті запитання

Чи потрібно відкривати TCP 53 разом з UDP 53?

Так, для вихідного трафіку до резолвера. Брандмауер, що дозволяє лише UDP 53, нормально обробить більшість запитів, а тоді непередбачувано провалюватиметься на більших, зазвичай підписаних DNSSEC, відповідях, яким потрібен запасний шлях через TCP.

Чи блокує заборона порту 53 увесь DNS-трафік?

Уже ні. Вона блокує класичний транспорт UDP/TCP. DNS over HTTPS працює на порту 443 і виглядає як будь-який інший HTTPS-запит, а DNS over TLS - на власному порту 853, тож браузер чи застосунок з увімкненим будь-яким із них і далі визначатиме імена.

Чи DNS over HTTPS - той самий протокол, що й звичайний DNS?

Запити й відповіді - ті самі DNS-записи й коди, визначені RFC 1035. Змінюється лише транспорт: замість сирого UDP- чи TCP-пакета на порту 53 той самий запит загортається в HTTPS-запит на порту 443.

Чому dig іноді використовує TCP без явної вказівки?

Коли UDP-відповідь повертається обрізаною, з виставленим бітом TC, сумісний зі стандартом клієнт автоматично повторно надсилає запит через TCP, щоб отримати повну відповідь. Найчастіше це трапляється на доменах з увімкненим DNSSEC або з багатьма записами одного типу.

Чи mDNS на порту 5353 - те саме, що DNS мого провайдера?

Ні. mDNS працює лише в межах локального сегмента мережі, не має центрального сервера й визначає імена на кшталт device.local для пристроїв на тому самому лінку. Він жодним чином не бере участі у визначенні публічного домену на кшталт example.com.

Який нормальний розмір payload EDNS0 сьогодні?

RFC 6891 пропонує 4096 байтів як практичне значення за замовчуванням, і більшість сучасних резолверів заявляють щось у цьому діапазоні, далеко вище початкової стелі в 512 байтів, переходячи на TCP лише тоді, коли навіть цього недостатньо.