как лучше физически подключить 2 dns сервера

Мне кажется, конфиг лучше делать одинаковый.
Включить в разные коммутаторы в режиме active-backup можно. Но активный слейв переключается только при пропадании линка на интерфейсе. Можно посмотреть на balance-alb, в моей конторе пара серваков так работает.

может лучше для внутренних ресурсов отдельные днс с отдельной зоной типа .local? И вообще бы разделил авторитативные и рекурсивные днс.

Ну а внешние сервера я бы сажал в разные места на разные каналы

под убунтой 10.04

а что не 12.04 который ещё 4.5 лет будет поддерживаться? Почему именно bind 9.7

И еще, стоит ли bind готовить самому?

почему нет?

Вообще, роль днс не понятна. Это внутренние рекурсоры, внешние авторитативные, внутренние авторитативные или всё сразу?

может лучше для внутренних ресурсов отдельные днс с отдельной зоной типа .local? И вообще бы разделил авторитативные и рекурсивные днс.

Оба физических сервера рекурсивны. На них много тысяч пользователей. На отдельные dns железа пока нет. 10.04 потому что я ее освоил и знаю подводные камни. 9.7 потому что разбирался именно с ним и по известной книге под bind 9.3. В 12.04 есть кучка багов, и мне их ловить не охота. К тому же опыта с 12.04 нету, и в ней неосвоенная версия bind 9.8.1, а переходить хочу в ближайший месяц-2 от силы. А до конца срока поддержки 10.04 еще времени 3 года.

Вообще, роль днс не понятна.

Кеширующий рекурсивный для внешних и внутренных пользователей, авторитативные для нескольких зон инета, авторитативные для внутренней зоны предприятия.

почему нет?

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

Но активный слейв переключается только при пропадании линка на интерфейсе.

Я понимаю, что надо просто поиграться и посмотреть когда же будет происходить переключение (например упал line protocol, а не только если вынуть шнурок). Не создаст ли bond петли на коммутаторах?

что ты имеешь в виду под «bind готовить самому»? Зоны руками добавлять?

что ты имеешь в виду под «bind готовить самому»?

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

если ты не знаешь что это даст то не пересобирай.

Сколько запросов в секунду пролетает? (dnstop покажет). Если пара-тройка тыщ в секунду то я бы вообще не парился, даже тюнить ничего не надо.

В 12.04 есть кучка багов

например?

и да, для полного ынтырпрайза раздели bind на те которые кэширующие и те которые авторитативные. Будет надёжнее и секурнее.

Кстати, новые bind уже умеют ограничивать размер своего кэша и при этом не тормозить во время чистки? Должны, но я бы проверил. Раньше проблемы были.

например?

сходи на ланчпад. Надо быть полным идиотом, чтобы ставить новую необкатанную версию на ответственные сервера.

и да, для полного ынтырпрайза раздели bind на те которые кэширующие и те которые авторитативные.

Ты похоже в этом совсем не разбираешься. BIND довольно умный. Для каждой зоны можно явно задать нужные параметры. Сервер может быть одновременно авторитативным мастером или слэйвом для одной зоны, и при этом быть кэширующим для других зон. Кстати ответы от bind9 будут неавторитативны если что.

Будет надёжнее и секурнее.

Секурнее и надежнее от этого не будет. От этого только будет больше работы, потому что больше компьютеров. Хотя в принципе на одном компьютере можно запускать несколько демонов bind одновременно.

Кстати, новые bind уже умеют ограничивать размер своего кэша и при этом не тормозить во время чистки?

Не знаю, не пользовался самыми новыми версиями. Но на 9.7 и 9.6 тормозов не замечал. Кэш ограничить можно, как и число клиентов. Только вот смысл ограничивать кэш, когда чем он больше, тем лучше для пользователей. Вот в 9.9, есть оптимизации в распределении нагрузки.

Раньше проблемы были.

В лохматом 96-м что-ле?

сходи на ланчпад

Уже сходил, что там страшного? Ссылочку на критический баг. Пока вижу что host падает.

Секурнее и надежнее от этого не будет.

а ты посмотри security history. Кстати, если читал книжки то там этот нюанс всегда оговаривают. Например: http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_...

Только вот смысл ограничивать кэш

он может очень сильно вырасти. Хотя, может у вас нагрузки не те :). Шучу, не воспринимай близко к сердцу.

В лохматом 96-м что-ле?

Неа, гораздо позже: https://lists.isc.org/pipermail/bind-users/2008-February/069141.html

Мы от греха подальше использовали powerdns recursor.

Про свежие версии и тем более убунты все всё знают. Да я когда на лаптоп даже RHEL6 поставил (сразу после выпуска), то первое, что увидел после установки - крэш ядра. Помогла только кнопка питания. А если багов еще не нашли слишком много, то они будут.

Кстати, если читал книжки то там этот нюанс всегда оговаривают.

В общем я прочитал процентов на 80 книгу dns и bind от Ли и Альбитца 5-е издание. Естественно все пробовал и смотрел на серваках. Рхеловские доки по сравнению с этой книгой и рядом не валялись. Ну вот по ссылке твоей:

«To prevent distributed denial of service (DDoS) attacks, it is recommended that you use the allow-query-cache option to restrict recursive DNS services for a particular subset of clients only. »

Тут просто говорят админу оставить лишь свои сетки. Мощно. Или еще ограничьте кэш: max-cache-size 256M;

На этом все. Кстати ни слова про разнос на разные машины. Конечно серваки будут досить, но если упадет рекурсивный, то на авторитативные будет пофигу. Поэтому гораздо проще ограничить кэш и держать в запасе виртуалку.

он может очень сильно вырасти

так а может и не вырасти. Я даже больше скажу - у нас и не вырастает до больших объемов (~6-7 гигов примерно. памяти на dns 8 гиг, поэтому хочу переезжать, да и старое железо уже).

Петли не создаст.
Но вообще сейчас доки по бондингу посмотрел, для мультикоммутаторной топологии рекомендуют active-backup.

Переключение по дефолту будет происходить при изменении carrier state.

Рекомендую ТСу прочитать linux/Documentation/networking/bonding.txt там все подробно разжевано.

1) Мастер-сервер законфигурить интерфейсы так, чтобы если один отвалился, поднимался второй.

А смысл ? Предполагается, что интерфейс может помереть ? Ну так серверов на то и более одного. В общем, я бы смотрел вероятность события и сложность исправления. Думаю, проблемы с самим сервером более вероятны, чем с ethernet.

Стоит ли разнести dns в разные сети, и подключить через разные маршрутизаторы, хоть это и большой гемор?

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

Про свежие версии и тем более убунты все всё знают.

Т.е. ссылок на ланчпад не будет? Я так и думал.

Тут просто говорят админу оставить лишь свои сетки

Бу-га-га, security advisories ты не смотрел. А зачем, есть же умные книжки в которых написано как надо. Почему же там про резервирование днс не написали? Я бы посоветовал carp, но, видимо, я не очень разбираюсь в вопросе.

Последний совет: большой кэш помогает сэкономить трафик и немного снять нагрузку на проц. Но это не значит что действительно стоит делать многогигабайтные кэши. Вполне может оказаться что пары гиг «за глаза» потому что каждый последующий гигабайт помогает всё меньше и меньше.

В мониторинг свои днс не забудь поставить.

спасибо

не кипятись, тема не для этого. Советы про резервирование понял, спасибо.

10-15 Мбит dns трафика

неплохой объём, лучше с такими вопросами идти на nag, а не на lor. из опыта, начиная с ~8 мбит dns-трафика bind9 как рекурсор работает довольно хреново, лучше поменять на pdns-recursor, но придётся разгребать геморрой с собственными зонами, решаемо, но возня.

если же всё-таки оставаться на бинде, то собирать надо самому и следить за листом рассылки. вообще, политика ISC по отношению к community(халявщикам) мягко говоря, не в пользу халявщиков. без платного саппорта, всё довольно грустно, периодически приходится брать в руки gdb и смотреть корки, потом выпрашивать у ISC патчи(чаще всего, баг уже закрыт, но релиз ещё не скоро, доступ к репе платный)

по поводу ip, естественно нельзя завязываться на одну точку терминирования, надо либо разносить сервера по маршрутизаторам, либо делать hsrp/прочее.

самый простой способ разнести соседние ip по разным роутерам это сделать маршруты /32 через вспомогательную транспортную сетку /30

Конфиг готовлю с несколькими видами (views), чтобы внешние пользователи не видели внутренние ресурсы.

старайтесь не использовать view вообще(резолвинг одного домена по разному в зависимости от source ip), в том же bind-е есть ACL для скрытия внутренних ресурсов от внешних пользователей, но тут надо более подробное описание ситуации

ещё очень полезно иметь рекурсивные сервера исключительно для своих клиентов, это позволяет эффективно защититься от внешних L7-атак(делаете разные listen и query ip, listen ip закрываете от внешнего мира на 3ем уровне айпитаблесами или на шлюзе), от внешних школодосов(100мбит dns-запросов на несуществующие домены и подобные атаки) отлично спасает

и неплохо бы иметь возможность быстро перекинуть ip с сервера на сервер(или даже поднять динамику, но можно нарваться на флапы), т.к. некоторые dns-клиенты тупят, когда «первый» сервер недоступен

неплохой объём, лучше с такими вопросами идти на nag, а не на lor.

да вот что-то в последнее время достал тупой троллинг. В инете говно пишут. По делу почти ничего. Толковых людей знаю совсем мало. Из-за документации есть мысли вернуться на rhel-based, но как вспомню сколько возни с selinux и нестандартными пакетами... Так может ну его нафиг. А с ubuntu и debian все привычно - давно пользуюсь

работает довольно хреново, лучше поменять на pdns-recursor, но придётся разгребать геморрой с собственными зонами, решаемо, но возня.

у народа по 40 мегабит dns-ы на бинде жрут на debian6, если что. правда сетевухи надо подтюнить (txqueuelength + кой-чего еще). И памяти там не особо много.

старайтесь не использовать view вообще

Почему? Я хочу скрыть некоторые зоны in-addr.arpa и технологические зоны. Не хочу железо светить. ACL - это совсем другое - не подходит для решения задачи.

самый простой способ разнести соседние ip по разным роутерам это сделать маршруты /32 через вспомогательную транспортную сетку /30

Мысль интересная, но по-нормальному надо 2 дополнительных маршрутизатора. У меня их нету. Есть всего 2 очень производительных маршрутизатора , к которым можно подключаться. Сделать то в принципе можно и только на них, но это ад. Это ж так по-хитрому надо в ospf добавлять и кидать маршруты друг на друга. И если один маршрутизатор ляжет, то песец всей конструкции. Только если на коммутаторах смаршрутизировать. В общем я лучше забью болт на такое подключение.

Может конечно можно создавать на маршрутизаторе виртуальные маршрутизаторы, но я не умею. С виртуальными коммутаторами только немного знаком.

Из-за документации есть мысли вернуться на rhel-based, но как вспомню сколько возни с selinux и нестандартными пакетами... Так может ну его нафиг. А с ubuntu и debian все привычно - давно пользуюсь

С точки зрения конфигурирования dns-сервера не важно какой у вас дистр. apparmor и selinux на dns-сервере не нужны, делайте обычный chroot и не извращаетесь

у народа по 40 мегабит dns-ы на бинде жрут на debian6, если что. правда сетевухи надо подтюнить (txqueuelength + кой-чего еще). И памяти там не особо много.

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

Почему? Я хочу скрыть некоторые зоны in-addr.arpa и технологические зоны. Не хочу железо светить. ACL - это совсем другое - не подходит для решения задачи.

И чем тут ACL не походит?

Плохо view тем, что под каждую view строится свой кеш, что вообще говоря снижает производительность, но куда хуже это мешает переходу на другое ПО, ну т.е. это почти проприетарщина. Рано или поздно и вам bind9 поднадоест, особенно плох он как рекурсор.

С точки зрения конфигурирования dns-сервера не важно какой у вас дистр. apparmor и selinux на dns-сервере не нужны, делайте обычный chroot и не извращаетесь

Ставлю по дефолту с apparmor и не извращаюсь на костыли chroot.

ну да, жрут. если десяток-другой сегфолтов в год вас устраивают, то пожалуйста

ну сколько можно. ни единого

И чем тут ACL не походит?

Тем что в случае ACL запросы блокируются, а в VIEWS нет.

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

Мне 100 килобайт не жалко, как и мизерной потери производительности

посмотрите сами на исходники bind9 это ж нечитаемый говнокод, поддерживаемый ради получения бабла на саппорте.

Мне не интересен исходный код. Им занимаются профессионалы, и bind занимает лидирующие позиции как DNS-сервер, чего не скажешь про powerdns. Если вы всегда просматриваете исходный код программы перед установкой, то с вами что-то не то либо вы из спецслужбы.

У Торвальдса тоже сложночитаемый код, и что с того?

поддерживаемый ради получения бабла на саппорте.

значит им с голода лучше помереть, чем деньги зарабатывать.

Что-то мне вообще расхотелось хоть что-то спрашивать на лоре. ТАааааакого понапишут, такого понасоветуют.... Хавайся у бульбу, накрывайся шыферам

Тем что в случае ACL запросы блокируются, а в VIEWS нет.

Так а вам что надо? Вы же писали, что надо заблокировать некоторые зоны от любопытных, acl для этого подходит. Для запрещённых сетей будет отдаваться REFUSED

Мне не интересен исходный код

Мне тоже раньше был не интересен исходный код бинда, но после нескольких баг-репортов и долго решения проблем(которые можно лицезреть в release notes), решил всё-таки заглянуть в исходники и ужаснулся, поддерживать такой код реально сложно. Если код говённый, то и проблем в эксплуатации будет больше.

bind занимает лидирующие позиции как DNS-сервер

apache тоже занимает лидирующие позиции как веб-сервер(хотя давно уже не смотрел), но почему-то люди ищут альтернативы, пусть и менее фичастые

Так а вам что надо? Вы же писали, что надо заблокировать некоторые зоны от любопытных, acl для этого подходит. Для запрещённых сетей будет отдаваться REFUSED

Мне надо, чтобы были ответы с доменным именем, а не REFUSED. Чтобы пользователю писало не juniper такой-то, а isp-трали-вали-default-city. Для удобства работы пользователей нужно. Сколько повторять, что ACL применяется для другого!

люди ищут альтернативы, пусть и менее фичастые

я не буду им мешать и навязывать свое мнение. а вы в acl уперлись.

поддерживать такой код реально сложно

а мне не нужно поддерживать код бинда

Если код говённый, то и проблем в эксплуатации будет больше.

А с чего вы взяли, что код бинда говённый. Он будет оптимизирован, и некоторые вещи просто так без анализа не поймешь. А вообще на лоре школота сильно раскукарекалась без понимания темы. Да, можно написать простой для понимания код, но эффективность в нем хорошей не будет. Торвальдс не с проста пишет сложный поначалу для понимания код. Вам бы посмотреть как сделаны и работают системы управления железом zte. От лога глаза квадратные становятся. Например, чтобы отобразить статус лампочки нужно зайти по телнету, ввести ее на железку, проанализировать вывод и отобразить. Для понимания просто супер. А все нормальное железо хорошо работает по более сложному протоколу snmp и не срет в логи.

Кстати, спасибо огромное тебе за совет с маршрутизацией. Я сегодня подумал, порисовал, по железу побегал, и знаешь все должно получиться. Серваки рассядутся на разные маршрутизаторы. Между ними будет локалка на 4 айпишника (2 из них используются сейчас). 2 айпишника будет недоступно, но я выкручусь внутренней сеткой. Потом можно малой кровью рассесться на те промежуточные сетки, переделегировав зоны на промежуточные сети. Своих зон у нас не сильно много. Правда много обратных in-addr.arpa. В принципе вопрос об изменении серверов решаем в том числе и с RIPE, хоть этому рады и не будут.

Да с маршрутизацией можно любые вопросы решить, обращайтесь. По днс-ам у вас ещё всё впереди, удачи с биндом и вьюхами :)