Чи правда, що серверу імен потрібно відповідати на запити через TCP?

Я процес налаштування моніторингу DNS-серверів кількох великих веб-хостів. Моя мета - порівняти час відповіді їхніх серверів dns, відстежуючи їх відповідь на ping.

У ході цього процесу я виявив, що сервери імен Bluehost не відповідають на ping. Я спробував отримати більше інформації, запустивши Pingdom DNS Check на bluehost.com, і це призвело до такої помилки:

Сервер імен ns1.bluehost.com (74.220.195.31) не відповідає на запити через TCP.

Сервер імен не зміг відповісти на запити, надіслані через TCP. Можливо, це пов'язано з неправильним налаштуванням сервера імен або через неправильно налаштовану фільтрацію в брандмауері. Досить поширена помилка, що DNS не потребує TCP, якщо вони не забезпечують передачу зон - можливо, адміністратор сервера імен не знає, що TCP зазвичай є вимогою.

Я хотів би знати наступне:

• Наскільки справжнє твердження правдиве?
• Які наслідки того, що сервер імен не відповідає на запити через TCP?

Текст діагностики з Pingdom абсолютно правильний. TCP призначений не лише для передачі зон.

Реалізації сервера DNS є в даний час «потрібно» (в так само , як будь-який RFC вимагає нічого) для підтримки TCP, в RFC 5966 , «DNS транспорту через TCP - Вимоги до реалізації».

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

Це означає, що якщо ваші конкретні сервери DNS не налаштовані на підтримку TCP, або якщо він заблокований, довгостроковим ефектом буде неможливість правильно підтримувати DNSSEC. Так само можуть бути заблоковані будь-які інші дані DNS, які призводять до перевищення відповідей 512 байт.

ob disclaimer: Я написав, що RFC.

EDIT RFC 5966 тепер замінено RFC 7766

він повинен підтримувати TCP та UDP - TCP призначений для розмірів відповідей> 512 байтів (які включатимуть передачу зон) (відповідно до матеріалів, які я прочитав, у будь-якому випадку. Я зазвичай включаю TCP та UDP для запуску NS ...)

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

http://cr.yp.to/djbdns/tcp.html#why (2003-01-16)

Коли надсилаються запити TCP?

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

• Ви хочете опублікувати набори записів більше 512 байт. (Це майже завжди помилка.)
• Ви хочете дозволити передачу вихідних зон, наприклад, на сторонній сервер.
• Батьківський сервер відмовляється делегувати вам ім'я, поки ви не налаштуєте послугу TCP.

Якщо ви не знаходитесь ні в одній із цих ситуацій, вам не потрібно надавати послугу TCP, і ви не повинні її налаштовувати. DNS-over-TCP набагато повільніше, ніж DNS-над-UDP, і по суті є набагато більш вразливим до атак відмови у наданні послуги. (Це стосується і BIND.)

Зауважте, що він упускає явну згадку про DNSSEC; причина полягає в тому, що, за словами DJB, DNSSEC підпадає під категорію "завжди помилка". Дивіться https://cr.yp.to/djbdns/forgery.html для отримання більш детальної інформації. DJB має альтернативний стандарт під назвою DNSCurve - http://dnscurve.org/ - який вже незалежно прийняли деякі провайдери (наприклад, OpenDNS). Цікаво: /security/45770/if-dnssec-is-so-questionable-why-is-it-ahead-of-dnscurve-in-adoption .

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

PS Зауважте, що DJB насправді практикує те, що він проповідує. Його власні сервери, (1), запускають DNSCurve, (2), не відповідають належним чином TCP. Тільки +notcpби вдалося (що за замовчуванням):

% dig +trace @ordns.he.net +notcp cr.yp.to | tail
yp.to.                  86400   IN      NS      uz5dz39x8xk8wyq3dzn7vpt670qmvzx0zd9zg4ldwldkv6kx9ft090.ns.yp.to.
yp.to.                  86400   IN      NS      uz5jmyqz3gz2bhnuzg0rr0cml9u8pntyhn2jhtqn04yt3sm5h235c1.yp.to.
;; Received 300 bytes from 216.74.32.100#53(tonic.to) in 151 ms

cr.yp.to.               600     IN      A       131.155.70.11
cr.yp.to.               600     IN      A       131.155.70.13
yp.to.                  3600    IN      NS      uz5jmyqz3gz2bhnuzg0rr0cml9u8pntyhn2jhtqn04yt3sm5h235c1.yp.to.
yp.to.                  3600    IN      NS      uz5dz39x8xk8wyq3dzn7vpt670qmvzx0zd9zg4ldwldkv6kx9ft090.yp.to.
;; Received 244 bytes from 131.155.70.13#53(uz5jmyqz3gz2bhnuzg0rr0cml9u8pntyhn2jhtqn04yt3sm5h235c1.yp.to) in 14 ms

, тоді як +tcpпомилка a (мабуть, з іншим повідомленням про помилку, залежно від того, який з його серверів буде обраний):

% dig +trace @ordns.he.net +tcp cr.yp.to | tail
yp.to.                  86400   IN      NS      uz5hjgptn63q5qlch6xlrw63tf6vhvvu6mjwn0s31buw1lhmlk14kd.ns.yp.to.
;; Received 300 bytes from 216.74.32.100#53(tonic.to) in 150 ms

;; Connection to 131.155.71.143#53(uz5dz39x8xk8wyq3dzn7vpt670qmvzx0zd9zg4ldwldkv6kx9ft090.ns.yp.to) for cr.yp.to failed: connection refused.
;; communications error to 131.155.70.13#53: end of file
;; Connection to 131.155.71.143#53(uz5dz39x8xk8wyq3dzn7vpt670qmvzx0zd9zg4ldwldkv6kx9ft090.ns.yp.to) for cr.yp.to failed: connection refused.
;; communications error to 131.155.70.13#53: end of file
;; Connection to 131.155.71.143#53(uz5dz39x8xk8wyq3dzn7vpt670qmvzx0zd9zg4ldwldkv6kx9ft090.ns.yp.to) for cr.yp.to failed: connection refused.
;; communications error to 131.193.32.147#53: end of file
;; connection timed out; no servers could be reached

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

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

Цілком можливо запустити DNS-сервер, у якого відкритий для Інтернету лише порт 53 UDP. Доступ TCP до однолітків DNS необхідний, але це невеликий список хостів.

Існує більш новий RFC596, який тепер вимагає TCP для повної реалізації DNS. Це спрямовано на виконавців. Документи спеціально не стосуються операторів, але попереджають, що заборона TCP може призвести до ряду сценаріїв відмов. У ньому детально описано широкий спектр відмов, які можуть призвести, якщо DNS через TCP не підтримується.

Були обговорені питання використання TCP для запобігання атак посилення DNS. TCP має власні ризики відмови в обслуговуванні, але розповсюдження складніше.