Choose your future

Стандартная ситуация: локальная сеть с маршрутизатором, один публичный IP, для выхода в мир используется NAT. Плюс на маршрутизаторе работает кеширующий DNS-сервер для локальной сети. Всё работает.

Однажды на одном из хостов локальной сети поселяется сервис, которому требуется пробросить статический диапазон портов UDP с внешнего IP. Казалось бы, какие могут быть проблемы?

А ведь DNS-сервер, выполняя запросы к внешним серверам, для исходящих запросов сам использует динамические UDP-порты и ожидает ответ на них. Например, ISC BIND под FreeBSD использует sysctl net.inet.ip.portrange.hifirst и net.inet.ip.portrange.hilast для определения диапазона таких эфемерных портов, по умолчанию это 49152-65535. Пока этот диапазон не пересекается с диапазоном проброшенных внутрь локалки портов, всё будет в порядке. Но стоит лишь пробросить, скажем, порты 40000-65535, и наступает катастрофа. В случае FreeBSD проброс портов "имеет приоритет выше" (выполняется раньше, чем доставка локальным приложениям) и проброс-то работать будет, но DNS-сервер остается без DNS-ответов на свои запросы, которые теперь уходят по пробросу локальному хосту, которому они и не нужны вовсе. И вся локальная сеть остаётся без локального DNS-сервиса.

Решением будет либо изменить диапазон проброшенных портов, если это допустимо для сервера в локальной сети, а если нет - изменить диапазон эфемерных портов для DNS-сервера. Кроме изменения системного дефолта, ISC BIND позволяет задать этот диапазон в собственной конфигурации:

use-v4-udp-ports { range 10000 30000; };

Аналогично для IPv6. Для защиты от некоторых типов атак, BIND каждый раз выбирает случайный порт из диапазона и рекомендуется, чтобы диапазон был достаточно большим, минимум 16384 портов (14 бит энтропии).

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

Несколько лет уже пользуюсь услугами австралийского регистратора crazydomains.com.au, оплачивая их картой Visa. Недавно обнаружил, что у них идёт аукцион невиданой щедрости - домены в зоне .info по 2 AUD за год (1 австралийский доллар = 1.0234 доллара США), причём можно оплатить сразу за 10 лет.

Взял себе домен в .info на 10 лет, заплатив $20. Обещали делегировать за 48 часов, реально еле уложились в неделю, заставив немного поволноваться за судьбу двадцатки.

Пламенный привет NIC.RU, берущему за .info по $20 в год, то есть в десять раз больше.

Регистрация домена второго уровня в зоне .net стоила $7 - меньше 220 рублей, поэтому я принес австралийскому регистратору сразу $14 за два года. Самостоятельно, без партнерских программ.

Продление бывшего GENERIC-домена третьего уровня, безальтернативно переданного в RU-CENTER, будет стоить 360 рублей в год, более чем на 60% дороже, если не через партнеров. А регистрация 450 рублей. Откуда взялись такие цены, мне непонятно.

1. Из named's security.log:

05-Dec-2010 15:34:03.723 error: client 193.0.0.63#45773: view external: zone transfer 'A.X.ru/AXFR/IN' denied

И так по всем зонам третьего уровня, для которых сервер прописан в качестве NS, причем не у регистратора какого-нибудь, а просто в зоне второго уровня у меня же.

# host 193.0.0.63
63.0.0.193.in-addr.arpa domain name pointer hostcount.ripe.net.