dns сервер (master,slave) через nat

Возьми NS-ы в амазоне (почти бесплатно). Или поставь там же, на EC2, на публичных адресах (почти бесплатно). С NAT наешся приключений.

Доп. внешние NS меня не интересуют. У меня и так есть 2 блока внешних адресов.

С NAT наешся приключений.

Что за приключения? Гугление показывает только варианты с кривыми руками.

кроме ната еще рассматривается варианты с ipvs и с выделением отдельных адресов для dns-серверов.

ИМХО только еще одна точка отказа в виде шлюза появляется и всё.

Что за приключения? Гугление показывает только варианты с кривыми руками.

Сам по себе NAT - приключение. Если есть возможность не связываться с ним - лучше не связываться. «Кривые руки» - это отмазка. Сам NAT - один большой костыль, который обязательно вылезет боком. Причем тогда, когда это меньше всего ждёшь. Особенно в DNS, от нормальной работы которого зависит, как правило, слишком многое.

Поднять нормальный DNS-сервер в инете стоит или ноль, или очень мало. Это гораздо меньше любого мелкого геморроя, который может всплыть с NAT'ом.

Т.е. если тебе «на потрахаться», то занимайся, конечно. А если надо, что б настроил раз и забыл - см. выше.

Я честно говоря сильно удивлен вопросом именно от вас. Вы не простудились? :) Проблемы будут ровно в еще одной прослойке и все с ней связанной. А все проблемы самой прослойки имхо вы лучше всех местных знаете.

Да, не любишь ты нат :) Ты и conntrack наверно везде отключил :)

То, что conntrack - зло, это можно понять, а вот то, что нат в современных ядрах является источником гемороя - это странно слышать.

Причина возникновения этого вопроса следующая - я не встречал упоминаний о таком варианте работы dns-сервера. С точки зрения НАТа в протоколе проблем нет. Значит это либо никому не было нужно, либо есть какие-то подводные камни. Вот и хотелось бы услышать еще чье-то мнение.

Хочется ведь совсем простую и понятную вещь - авторитетный dns-сервер для нескольких доменов в виде контейнера, который можно было бы при необходимости быстро перекинуть с одного сервера на другой.

Мне кажется тут вариант «никому не было нужно». НАТ в несколько udp пакетов погоды сделать не должен. Кроме как доп. нагрузки на сам роутер особенно в случае ддос.
ЗЫ Честно говоря я лично никогда не пробовал натить dns. Может и есть подводные камни, но вся теория говорит что их быть не должно. :)
ЗЫЫ Если уж натим почту/вэб/впн/etc то в чем может возникнуть проблема в днс? (это прям риторический вопрос к вам лично :)

У меня были сомнения из-за пула udp-сокетов, которые использует isc bind.

Просто перед тем, как переделывать работающую вещь, нужно хорошенько подумать, чтоб потом еще раз не переделывать.

Заодно соблюдаем старинный индейский ритуал :)

Да, не любишь ты нат :) Ты и conntrack наверно везде отключил :)

Именно. Зато везде включил ipv6 :)

То, что conntrack - зло, это можно понять, а вот то, что нат в современных ядрах является источником гемороя - это странно слышать.

Я такого не говорил. Наверное, твой вопрос задел чё-то в глубинах моей души, а не просто conntrack/nat/геморрой. Сам по себе свой dns-сервер для обслуживания публичных доменов - тут меня начинает крутить и перекручивать. Столько с ними горя хлебанул... А ещё и за NAT - вообще слов нету, одна боль-боль-гроб-кладбище.

Сам по себе свой dns-сервер для обслуживания публичных доменов - тут меня начинает крутить и перекручивать. Столько с ними горя хлебанул...

А можно для общего образования несколько примеров «горя»?

Ну, например, у нас были свои ДНС на базе powerdns + свой кастомный бэкенд. Сервис мы делали, в общем.

В powerdns оказалась бага с кастомными бэкендами, очень иногда оно путало ответы от разных тредов бэкендов. Это выливалось в то, что какой-то из наших суб-партнёров, использовавший наши сервисы, кэшировал кривой ответ и не мог достучаться до наших серверов. Мы, само собой, стучали по голове в попытках понять, что происходит.

Было еще прекрасное, когда для того, что б подтвердить, что наш ДНС- сервис работают хорошо, туда перенесли ключевой домен. Когда что-то легло (не помню уж что конкретно), не ходили даже алерты, потому что они пытались достучаться до того же самого домена, в попытках отправить алерты. О проблеме узнали от партнёров.

Всё это припудрено тем, что обычно в корпоративной сети стоит локальный кэширующий DNS, поэтому все используемые нами зоны всегда гарантированно есть в кэше. Поэтому саппорт в начале даже не может понять, где проблема - если у клиентов чё-то не пашет, а у нас всё прекрасно. Потом, в какой-то момент протухает TTL и всё отваливается и у нас.

Поэтому, с какого-то момента, было принято решение не держать свои сервисы на своих ДНС. Использовали какой-то момент ДНС-ы resellerclub'а, но их там то ли DDoS'ят регулярно (по их словам), то ли они просто криворукие, но по факту они пару раз в год могут лежать по несколько часов. Опять-таки - кто успел в кэш себе взять даных - не понимает проблем остальных. Обратная ситуация та же - кто себе закэшировал состояние «данных по зоне нет», тот и после поднятия зоны в пределах negative ttl не даёт клиентам работать.

Поэтому для важных сервисов - только ДНС в одном из крупных сервисов использовали Amazon и Google). Плюс домены, относящиеся к мониторингу - в третьем сервисе. Плюс мониторинг по заведомо несвязанным каналам (а то тоже был факап - и мейлы, и смс шли через домен в одной подзоне. И всё легло - написал выше).

Если посмотреть, кто хостит DNS гугля, то там не гугль ни разу. Что, собственно, подтверждает моё мнение. Хотя уж они-то могли бы себе сделать сервис вполне.

Надо просто уметь делегировать. Даже если я - программист, я запросто отказываюсь от «ещё одного скриптика» в пользу публичного сервиса/софта, доказавшего надёжность (как минимум, его надёжность должна быть выше, чем надёжность моего скрипта).

Я раз в несколько лет смотрю, нет ли замены isc bind как авторитетного сервера со split-dns. Пока нет :)

Да есть замена. В гугле стоит нормальный UnknownDNS, прилично пашет.

:)

Спасибо за развернутый ответ. Но из всего этого я могу сделать вывод что все уперлось в powerdns. У меня не сильно промышленные масштабы, нцать мастеров, нцать слэйвов, нцать форвардов, работает на бинде дофига лет, вроде пока все живо, проблемы были только с ддос.