- bind,
- dns,
- hetzner,
- networking,
- udp
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; }
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
мы решили промежуточным способом: фрагменты сильно зарейтлимитили
no subject
(Anonymous) 2015-12-19 03:22 pm (UTC)(link)no subject
no subject
no subject
no subject
;; 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, что-то идет не так.
no subject
no subject
Там всё в деталях расписано.
no subject
Если я убираю форвардер на SkyDNS из named.conf, всё начинает замечательно работать. Т.е. описанные в статье проблемы (зарезаны TCP запросы, зарезаны UDP фрагменты и т.п.) на моей сети не присутствуют, это форвардер что-то ломает.
Я сделал 95.170.158.163 временно открытым и рекурсивным для всего мира, вдруг кто-то захочет попробовать "dig @95.170.158.163 www.nasa.gov any"
no subject
TCP может быть сломан где угодно на трассе между источником и приёмником пакетов.
Вообще я в сети уже встречал жалобы на то, что у SkyDNS сломан TCP.
no subject
Давай попробую еще раз изложить. Пользователи ходят к серверу 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 трафика.
no subject
no subject
no subject
Не успел я это всё собрать и выслать, как и через SkyDNS всё чудесным образом заработало. Всё равно, конечно, выслал запрошенное.