Почему почта и DNS не живут дома — и итог цикла про домашнюю инфраструктуру

Когда дома есть белый адрес и сервер, который держит полтора десятка сайтов, напрашивается следующий шаг: поднять там же почту и DNS для своих доменов. Я проверил, насколько это реально, — и решил не делать. Ниже почему, с проверками, которые стоит провести до такого решения. А в конце — итог всего цикла.

Это четырнадцатая, заключительная часть цикла «Домашняя инфраструктура».

Почта: технически можно, практически не стоит

Обычно домашний адрес для почты не годится сразу: провайдеры закрывают исходящий 25-й порт, а адреса домашних пулов стоят в списках «здесь не должно быть почтовых серверов». Проверил оба пункта — и неожиданно всё оказалось открыто.

Порт 25

С сервера подключился к 25-му порту трёх крупных почтовых систем — все ответили приветствием 220. Исходящий порт открыт, для домашнего подключения это редкость.

timeout 5 bash -c 'exec 3<>/dev/tcp/mx.example.com/25; IFS= read -r line <&3; echo "$line"'
# 220 mx.example.com ESMTP …

Чёрные списки — с контрольной проверкой

Проверка адреса в списке — это DNS-запрос: адрес задом наперёд плюс зона списка. Важно сначала убедиться, что проверка вообще работает: у каждого списка есть контрольные адреса — 127.0.0.2 обязан значиться, 127.0.0.1 обязан быть чист. Без этого «не найден» может означать «список не отвечает вам».

check() { dig +short "$1.$2"; }
check 2.0.0.127 zen.spamhaus.org     # контроль: должен вернуть 127.0.0.x
check 1.0.0.127 zen.spamhaus.org     # контроль: пусто
check 22.113.0.203 zen.spamhaus.org  # наш адрес 203.0.113.22 задом наперёд

Список	Наш адрес
Spamhaus ZEN (включая PBL — «домашние пулы»)	чист
SpamCop	чист
Barracuda	значится — снимается заявкой за 1–2 дня, влияет только на тех получателей, кто его спрашивает

Обратную DNS-запись провайдер делает по заявке. То есть формально все условия выполнены.

Почему всё равно нет

• почта не прощает простоя. Пропал свет или интернет на полдня — отправляющие серверы будут повторять доставку, но часть писем отскочит, а часть уйдёт в спам после возвращения: репутация нового адреса строится месяцами и теряется быстро;
• памяти нет. Полноценный почтовый комплект вроде mailcow хочет от 6 ГБ и полтора десятка контейнеров — на сервере 3 ГБ на всё;
• это отдельная работа: SPF, DKIM, DMARC, антиспам, обновления, слежение за очередью. Для пары ящиков — несоизмеримо.

Варианты по нарастанию сложности: SMTP ящика на домене у почтового хостинга (для писем с сайтов — об этом подробно в части про почту цикла «Сервер для WordPress»), транзакционный почтовый сервис, свой почтовый сервер на дешёвом VPS — но не дома. Мостом на время подойдёт отправка через локальный postfix с DKIM в одном маленьком контейнере, около 50 МБ памяти.

DNS дома: ещё хуже идея

Авторитетный DNS на домашнем сервере — это значит, что при пропаже света или интернета домен перестаёт резолвиться вообще. Не «сайт недоступен», а «такого имени нет»: ни заглушки, ни приёма почты где-то ещё, ни переадресации. К тому же регистраторы требуют минимум два DNS-сервера в разных сетях. DNS-хостинг у регистратора или специализированного провайдера бесплатен и надёжнее любого дома.

Как переносить зону, если всё же переезжаете

1. сайты переносить, не трогая NS-записи: меняется только адрес в записях A;
2. при смене DNS-провайдера — сначала воссоздать у нового все записи (включая MX, TXT, CAA), проверить их прямыми запросами к его серверам и только потом менять NS у регистратора;
3. регистратор и DNS-хостинг — разные услуги. Чтобы сменить DNS, переносить домен к другому регистратору не нужно.

Итог цикла

Старый ноутбук на i3 с 4 ГБ памяти держит полтора десятка сайтов, свой журнал работ и сторожей — и для внешнего посетителя он не медленнее арендованного хостинга. Но работает это не потому, что «поставил Docker и всё». Каждая часть цикла — место, где что-то молча не работало:

• fail2ban 13 дней не банил никого, а до этого забанил хозяина;
• ноутбук-сервер выключался от короткого нажатия кнопки;
• белый адрес на роутере выглядит серым, а «тормоза» дома оказались VPN на моём компьютере;
• свежая Ubuntu оставила пароли в SSH и сдвинула часы на три часа;
• traefik 2 не увидел Docker 29, а stop не выключал сайты;
• переезд 14 сайтов: переменные утекали между сайтами, кодировка ломалась от прав;
• DNS дома: заглушка провайдера сломала приставку;
• первые 48 часов: поисковик нашёл тестовую копию, ИИ-краулеры — папку загрузок;
• SSH из поездки: по имени не подключалось, по адресу — сразу;
• Wi-Fi: две сети с одним именем вместо роуминга;
• камера держала канал в облако, приставка откатывала прошивку;
• нагрузка: процесс, забытый на 21 час, и load без процессора;
• удалённый сервер «падал» от полного диска, а защита заперла систему.

Общий вывод у всех частей один: «работает» надо проверять тем путём, каким пользуется человек, — снаружи, по имени, в реальном режиме, — и смотреть не на статус «зелёный», а на то, происходит ли то, ради чего это всё. Остальное — детали, которые я собрал в этих четырнадцати частях, чтобы вам не пришлось находить их так же.

Из того, что пока в планах: память 4 → 12 ГБ на этом же ноутбуке (с проверкой без простоя на memtest), резервные копии домашнего сервера на компьютер, который ночью выключен, и своя запись с камеры. Об этом — когда будет сделано и проверено.