Hetzner и eDNS

[dadv]

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

Детально проблема расписана в базе знаний ISC (наш случай - пункт 4. DNS queries/responses using EDNS are allowed, but UDP fragmentation and reassembly is broken), но решение достаточно простое - настроить свой DNS-сервер сообщать другим серверам не посылать требующие фрагментации ответы. Этакий аналог TCP adjust mss, но для DNS через UDP. Более крупные ответы будут доставляться сразу по TCP вместо UDP.

Для сервера BIND достаточно прописать в секции options:

options {
  edns-udp-size 1432;
}

Comments

[mikkotlv.livejournal.com]

Аналогично, я также давно закрыл фрагментированные пакеты UDP в администрируемом ЦОДе. Спасибо за солюшен, буду информировать клиентов в случае проблем.

[dadv.livejournal.com]

Какую проблему решает такая фильтрация?

[dmarck.livejournal.com]

DDoS mitigation при невозможности тречить UDP flows, очевидно?

[dadv.livejournal.com]

А зачем нужен трекинг UDP?

[dmarck.livejournal.com]

не UDP как такового, а UDPflows: в фрагментах же нет номера порта

[dadv.livejournal.com]

Это ясно, что нету номера порта и что речь о потоках. Зачем нужно трекать потоки?

[dmarck.livejournal.com]

чтобы порезать "плохие" фрагменты, которыми чаcnj DDoS'ят, пропуская "хорошие"

[dadv.livejournal.com]

Но ведь режут-то не плохие фрагменты, а все и всегда - есть ли DDoS или нет его. Лекарство не должно быть хуже болезни.

[dmarck.livejournal.com]

Ну, мы об одном и том же, в общем-то ;)

мы решили промежуточным способом: фрагменты сильно зарейтлимитили

[(Anonymous)]

Я не вижу смысла передавать внутрь сети куски атак методом NTP/DNS-усиления. Которая будет грузить аплинки рэков или порты кастомеров.

[dadv.livejournal.com]

Но ведь это гробит не только флуд, но и полезный трафик, а какой смысл в "лекарстве", которое вредит?

[mikkotlv.livejournal.com]

По моей статистике 1-2 недовольных кастомеров в год, воспринимаю это как неизбежное зло.

[dadv.livejournal.com]

А ведь можно было не ломать eDNS и довольно просто.

[victor-sudakov.livejournal.com]

А вот такую ситуацию не прокомментируешь? В качестве форвардера указан DNS сервер небезызвестного SkyDNS. Если запрашиваешь "dig @193.58.251.251 ya.ru a", ответ получаешь. Если запросить "dig @193.58.251.251 ya.ru any" - то будет

;; Truncated, retrying in TCP mode.
;; connection timed out; no servers could be reached

это можно как-то полечить на клиентской стороне?

drill про то же самое пишет:
;; WARNING: The answer packet was truncated; you might want to
;; query again with TCP (-t argument), or EDNS0 (-b for buffer size)

С ключом -t разумеется всё получается, но в случае BIND, работающего через forwarder, что-то идет не так.

[victor-sudakov.livejournal.com]

Или по-другому спрошу. Почему TCP запросы от моего бинда к SkyDNS (см. пример запроса "ANY ya.ru" в ftp://ftp.sibptus.ru/pub/vas/ya.ru.pcap ) остаются безответными?

[dadv.livejournal.com]

Ну я же дал в посте ссылку на https://kb.isc.org/article/AA-01219/0/Refinements-to-EDNS-fallback-behavior-can-cause-different-outcomes-in-Recursive-Servers.html

Там всё в деталях расписано.

[victor-sudakov.livejournal.com]

Я читал эту ссылку, но к моему случаю оно не очень применимо, или я не могу сообразить, как применить.

Если я убираю форвардер на SkyDNS из named.conf, всё начинает замечательно работать. Т.е. описанные в статье проблемы (зарезаны TCP запросы, зарезаны UDP фрагменты и т.п.) на моей сети не присутствуют, это форвардер что-то ломает.

Я сделал 95.170.158.163 временно открытым и рекурсивным для всего мира, вдруг кто-то захочет попробовать "dig @95.170.158.163 www.nasa.gov any"

[dadv.livejournal.com]

Я не очень понял, что значит фраза "форвардер что-то ломает".
TCP может быть сломан где угодно на трассе между источником и приёмником пакетов.

Вообще я в сети уже встречал жалобы на то, что у SkyDNS сломан TCP.

[victor-sudakov.livejournal.com]

Я не очень понял, что значит фраза "форвардер что-то ломает".

Давай попробую еще раз изложить. Пользователи ходят к серверу 95.170.158.163, а он в свою очередь ходит к серверу 193.58.251.251.

Если из конфигурации сервера 95.170.158.163 убрать строчку
forwarders {193.58.251.251 ;}, то у пользователей всё нормально резолвится. Стоит только эту строчку обратно включить, у них перестают работать часть запросов, например "www.nasa.gov any".

Вообще я в сети уже встречал жалобы на то, что у SkyDNS сломан TCP

Вопрос в том, как именно сломан и можно ли что-то на моей стороне с этим сделать, или хотя бы продемонстрировать им какой-то test case. Так-то TCP на 193.58.251.251 вполне ходит, в ftp://ftp.sibptus.ru/pub/vas/ya.ru.pcap есть примеры TCP трафика.

[dadv.livejournal.com]

Сломан, разумеется, не вообще TCP, а именно DNS over TCP. И сломан именно как у тебя - tcp-коннект устанавливается, но оттуда ничего не приходит в ответ на запрос, таймаут. Собственно, никакого другого test case и не нужно, это и предъявляй им.

[victor-sudakov.livejournal.com]

OK, написал им в техподдержку. Деньги-то заплачены сравнительно немалые, 900 руб/год. Будет что толковое от них - сообщу. Текст обращения был такой:

Обнаружилось, что сервер 193.58.251.251 не отвечает на запросы по TCP.

$ dig -b 95.170.158.163 @193.58.251.251 ya.ru a +tcp

; <<>> DiG 9.9.5 <<>> -b 95.170.158.163 @193.58.251.251 ya.ru a +tcp
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

Прилагаю файл WireShark с примером обмена, из которого видно, что запрос отправляется, а ответа нет.

[victor-sudakov.livejournal.com]

Пожаловался я в support. Они запросили пакетный дамп с этим же запросом на разные DNS сервера: 1 яндекc 77.88.8.8, 2 на гугл 8.8.8.8, 3 на локальный DNS провайдера.

Не успел я это всё собрать и выслать, как и через SkyDNS всё чудесным образом заработало. Всё равно, конечно, выслал запрошенное.