RFC, який вимагає, щоб сервери DNS відповідали на невідомі запити домену

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

dig @NS3.DNSOWL.COM somedomainthatdoesntexist.org
...
;; connection timed out; no servers could be reached

Оглядаючи інші популярні служби доменних імен, я бачу, що така поведінка є досить унікальною, оскільки інші провайдери повертають RCODE 5 (ВІДМОВА):

dig @DNS1.NAME-SERVICES.COM somedomainthatdoesntexist.org
dig @NS-284.AWSDNS-35.COM somedomainthatdoesntexist.org
dig @NS21.DOMAINCONTROL.COM somedomainthatdoesntexist.org

Усі повертають щось подібне:

;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 64732

або

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 31219

Повернення REFUSEDабо NXDOMAINнегайно підходить IMHO, на відміну від простого відмови від запиту на поверсі серверної кімнати.

Коли я скаржуюся своєму провайдеру на те, що їхні сервери не відповідають, вони просять мене цитувати RFC про порушення їх серверів. Я знаю, що дивно, що вони просять мене довести, що їх сервери повинні відповідати на всі запити, але так і нехай.

Запитання :

• Згідно з моїм умовою, якщо немає дублікатів ідентифікаторів запиту або якихось відповідей DOS, сервер повинен завжди відповідати на запит. Це правильно?
• Який RFC та конкретний розділ слід навести, щоб підтримати мою умову?

Мені погано не відповідати на запит DNS. Більшість клієнтів відмовляться і повторно передають той же запит або на той самий DNS-сервер, або на інший сервер. Вони не тільки сповільнюють роботу клієнтів, але й викликають повторний пошук тих же запитів власними або іншими серверами залежно від авторитетних серверів імен та записів NS.

У RFC 1536 та 2308 я бачу багато інформації про негативне кешування з міркувань продуктивності та припинення повторної передачі того ж запиту. У 4074 році я бачу інформацію про повернення порожньої відповіді з RCODE 0, тому клієнт знає, що немає інформації ipv6, яка повинна змусити клієнта запитати про RR, що є ще одним прикладом порожньої відповіді.

Але я не можу знайти RFC, який говорить про те, що сервер DNS повинен відповісти на запит, ймовірно, тому, що він мається на увазі.

Конкретна проблема виникає, коли я переміщую свій домен (і пов'язані з ним записи DNS) на їхні сервери або перші X хвилини після того, як я зареєструю новий домен у їх сервісі. Існує відставання між часом зміни авторитетних серверів імен (що досить проклято в ці дні) та їх серверами, які починають обслуговувати мої записи DNS. Протягом цього часу клієнти DNS вважають, що їхні сервери є авторитетними, але вони ніколи не відповідають на запит - навіть із a REFUSED. Я розумію, що відставання є нормальним, але я не згоден з рішенням не відповідати на запити DNS. Для запису я розумію, як обійти ці обмеження в їхній системі, але я все ще працюю з ними, щоб покращити їхні послуги, щоб вони більше відповідали протоколу DNS.

Дякую за допомогу.

Редагувати:

Протягом декількох місяців після публікації цього повідомлення та мого зв’язку з моїм провайдером вони змінили свої сервери, щоб повернутися NXDOMAINдо невідомих доменів.

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

Але це все ще є цікавим питанням, на який потрібно відповісти, тому я збираюся взяти на себе тріщину.

Основна функціональність DNS-серверів охоплена документами RFC 1034 та RFC 1035 , які в сукупності утворюють STD 13 . Відповідь повинна або надходити з цих двох RFC, або бути уточнена більш пізньою RFC, яка її оновлює.

Перш ніж ми продовжимо, тут є масштабна гріха поза сферою DNS, яку потрібно викреслити: обидві ці RFC передують BCP 14 (1997), документ, який уточнив мову МОЖА, ПОВИНЕН, ПОТРІБНО тощо.

• Стандарти, які були автором до формалізації цієї мови, МОЖАЛО використовувати чітку мову, але в декількох випадках - не. Це призвело до розбіжних реалізацій програмного забезпечення, масової плутанини тощо.
• STD 13, на жаль, винен тим, що він тлумачить у кількох сферах. Якщо мова не є твердим у зоні дії, часто потрібно знаходити уточнюючу RFC.

З цим не вийде, почнемо з того, що має сказати RFC 1034 §4.3.1 :

• Найпростіший режим для сервера - нерекурсивний, оскільки він може відповідати на запити, використовуючи лише локальну інформацію: відповідь містить помилку, відповідь або направлення на якийсь інший сервер, "ближче" до відповіді. Усі сервери імен повинні реалізовувати нерекурсивні запити.

...

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

• Помилкова авторитетна назва, яка вказує на те, що ім'я не існує.

• Тимчасове вказівка ​​на помилку

• Деякі поєднання:

  RR, які відповідають на запитання, разом із зазначенням, дані надходять із зони чи кешовані.

  Посилання на сервери імен, у яких є зони, ближче предків до імені, ніж сервер, що надсилає відповідь.

• RR, які сервер імен вважає, виявляться корисними для запитувача.

Мова тут досить твердий. Не існує "має бути", але "буде". Це означає, що кінцевий результат повинен бути або 1) визначеним у списку вище, або 2), дозволеним пізнішим документом на треку стандартів, який змінює функціональність. Мені невідомо жодної такої багатослівності, що існує для ігнорування запиту, і я б сказав, що на розробника потрібно знайти мову, яка спростує дослідження.

Зважаючи на часту роль DNS у сценаріях зловживань мережею, нехай не можна сказати, що програмне забезпечення сервера DNS не забезпечує ручки для вибіркового скидання трафіку на підлогу, що технічно це буде порушенням. Однак це не є поведінкою за замовчуванням або з дуже консервативними типовими умовами; Прикладами обох може бути користувач, який вимагає від програмного забезпечення скинути певне ім’я ( rpz-drop.), або певні числові пороги перевищені (BIND max-clients-per-query). На моєму досвіді це майже не чує, щоб програмне забезпечення повністю змінило поведінку за замовчуванням для всіх пакетів таким чином, що порушує стандарт, якщо тільки варіант не підвищує толерантність до старих продуктів, що порушують стандарт. Це не так.

Коротше кажучи, цей RFC може і дійсно порушуватися на розсуд операторів, але зазвичай це робиться з якоюсь точністю. Вкрай рідко повністю ігнорувати розділи стандарту, як це зручно, особливо коли професійний консенсус (наприклад: BCP 16 §3.3 ) помиляється на користь того, що він небажаний створювати непотрібне навантаження на систему DNS в цілому. Зважаючи на це, непотрібні спроби скасувати всі запити, щодо яких немає авторитетних даних, є менш бажаними.

Оновлення:

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

Якщо сервер імен не піддається атаці, він повинен відповідати на всі запити, спрямовані на нього в результаті наступних делегацій. Додатково код не повинен припускати, що не існує делегування на сервер, навіть якщо він не налаштований для обслуговування зони. Зламані делегації - це поширене явище в DNS, а отримання запитів для зон, для яких сервер не налаштований, не обов'язково є вказівкою на те, що сервер піддається атаці. Оператори батьківської зони повинні регулярно перевіряти відповідність делегуючих записів NS відповідним записам делегованої зони та виправляти їх, коли вони не є [RFC1034]. Якби це робилося регулярно, випадки розбиття делегацій були б значно нижчими.

Ця відповідь буде оновлена, коли статус цього документа зміниться.

Коли ви переносите авторитетний DNS для домену до нового провайдера, ви завжди (завжди!) Повинні явно протестувати проти нового постачальника (і переконатися, що він надсилає точні, налаштовані записи), перш ніж змінювати інформацію про реєстрацію вашого домену (whois) щоб вказати на нові авторитетні сервери DNS.

Приблизно, кроки, які ви будете робити:

1. Налаштуйте все на новому постачальнику DNS. Ви повинні створити та заповнити всі зони.

2. Переконайтесь, що нові авторитетні сервери працюють правильно. Запросіть їх явно:

   dig @new-ns.example.com mydomain.com
   

   З вашого запитання, як здається, вони не відповідають на ці запити? Але, ви сказали, "невідомі домени", яких не повинно бути в даний момент, вони повинні бути повністю налаштовані в їхній системі (і відповідати записом, які ви налаштували).

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

3. Переключіть авторитетні сервери імен з вашим реєстратором домену (whois), залишивши старого постачальника DNS і працює до тих пір, поки трафік не припинить його (дайте йому принаймні 24 години).

Якщо новий постачальник абсолютно не може заповнити записи перед переключенням, то те, як вони відповідати, насправді не матиме значення - вказівка ​​користувачів на авторитетних, які повністю відмовляються від запиту, матиме час простою для вашого домену так само, як якщо б ви були не отримуючи жодної відповіді.