dadv: (chuck)
Choose your future ([personal profile] dadv) wrote2015-12-17 12:29 am
Entry tags:

Hetzner и eDNS

Оказалось, что немецкий хостер-лоукостер 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;
}

[identity profile] mikkotlv.livejournal.com 2015-12-17 05:59 am (UTC)(link)
Аналогично, я также давно закрыл фрагментированные пакеты UDP в администрируемом ЦОДе. Спасибо за солюшен, буду информировать клиентов в случае проблем.
Edited 2015-12-17 06:03 (UTC)

[identity profile] dadv.livejournal.com 2015-12-17 09:42 am (UTC)(link)
Какую проблему решает такая фильтрация?

[identity profile] dmarck.livejournal.com 2015-12-17 11:39 am (UTC)(link)
DDoS mitigation при невозможности тречить UDP flows, очевидно?

[identity profile] dadv.livejournal.com 2015-12-17 12:24 pm (UTC)(link)
А зачем нужен трекинг UDP?

[identity profile] dmarck.livejournal.com 2015-12-17 12:26 pm (UTC)(link)
не UDP как такового, а UDPflows: в фрагментах же нет номера порта

[identity profile] dadv.livejournal.com 2015-12-17 12:29 pm (UTC)(link)
Это ясно, что нету номера порта и что речь о потоках. Зачем нужно трекать потоки?

[identity profile] dmarck.livejournal.com 2015-12-17 12:34 pm (UTC)(link)
чтобы порезать "плохие" фрагменты, которыми чаcnj DDoS'ят, пропуская "хорошие"

[identity profile] dadv.livejournal.com 2015-12-17 12:39 pm (UTC)(link)
Но ведь режут-то не плохие фрагменты, а все и всегда - есть ли DDoS или нет его. Лекарство не должно быть хуже болезни.

[identity profile] dmarck.livejournal.com 2015-12-17 12:43 pm (UTC)(link)
Ну, мы об одном и том же, в общем-то ;)

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

(Anonymous) 2015-12-19 03:22 pm (UTC)(link)
Я не вижу смысла передавать внутрь сети куски атак методом NTP/DNS-усиления. Которая будет грузить аплинки рэков или порты кастомеров.

[identity profile] dadv.livejournal.com 2015-12-19 07:27 pm (UTC)(link)
Но ведь это гробит не только флуд, но и полезный трафик, а какой смысл в "лекарстве", которое вредит?

[identity profile] mikkotlv.livejournal.com 2015-12-21 03:40 am (UTC)(link)
По моей статистике 1-2 недовольных кастомеров в год, воспринимаю это как неизбежное зло.

[identity profile] dadv.livejournal.com 2015-12-21 07:12 am (UTC)(link)
А ведь можно было не ломать eDNS и довольно просто.

[identity profile] victor-sudakov.livejournal.com 2015-12-26 04:39 pm (UTC)(link)
А вот такую ситуацию не прокомментируешь? В качестве форвардера указан 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, что-то идет не так.

[identity profile] victor-sudakov.livejournal.com 2015-12-26 04:51 pm (UTC)(link)
Или по-другому спрошу. Почему TCP запросы от моего бинда к SkyDNS (см. пример запроса "ANY ya.ru" в ftp://ftp.sibptus.ru/pub/vas/ya.ru.pcap ) остаются безответными?

[identity profile] dadv.livejournal.com 2015-12-27 05:18 am (UTC)(link)
Ну я же дал в посте ссылку на https://kb.isc.org/article/AA-01219/0/Refinements-to-EDNS-fallback-behavior-can-cause-different-outcomes-in-Recursive-Servers.html

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

[identity profile] victor-sudakov.livejournal.com 2015-12-27 06:21 am (UTC)(link)
Я читал эту ссылку, но к моему случаю оно не очень применимо, или я не могу сообразить, как применить.

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

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

[identity profile] dadv.livejournal.com 2015-12-28 08:39 am (UTC)(link)
Я не очень понял, что значит фраза "форвардер что-то ломает".
TCP может быть сломан где угодно на трассе между источником и приёмником пакетов.

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

[identity profile] victor-sudakov.livejournal.com 2015-12-28 09:41 am (UTC)(link)
Я не очень понял, что значит фраза "форвардер что-то ломает".

Давай попробую еще раз изложить. Пользователи ходят к серверу 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 трафика.

[identity profile] dadv.livejournal.com 2015-12-28 10:35 am (UTC)(link)
Сломан, разумеется, не вообще TCP, а именно DNS over TCP. И сломан именно как у тебя - tcp-коннект устанавливается, но оттуда ничего не приходит в ответ на запрос, таймаут. Собственно, никакого другого test case и не нужно, это и предъявляй им.

[identity profile] victor-sudakov.livejournal.com 2015-12-28 10:50 am (UTC)(link)
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 с примером обмена, из которого видно, что запрос отправляется, а ответа нет.
Edited 2015-12-28 10:52 (UTC)

[identity profile] victor-sudakov.livejournal.com 2016-01-03 06:50 am (UTC)(link)
Пожаловался я в support. Они запросили пакетный дамп с этим же запросом на разные DNS сервера: 1 яндекc 77.88.8.8, 2 на гугл 8.8.8.8, 3 на локальный DNS провайдера.

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