LINUX.ORG.RU
Форум — Admin  

Как разделить DNS-домен?


0

0

Одна и та же зона company.ru есть на внешнем DNS и на внутреннем DNS
Некоторые (их мало) записи во внутреннем DNS имеют те же имена, что и на внешнем, но другие значения
На внутреннем DNS по сравнению с внешним довольно много записей добавляется с частными адресами + всякие CNAME'ы и пр. SRV-записи
Тем не менее процентов 80 содержимого внешнего и внутреннего DNS совпадают

Вопрос: как получать на внутреннем DNS зону с внешнего DNS, но не в чистом виде, а применяя изменения? То есть хочется ПРОПАТЧИТЬ зону с внешнего DNS после её получения. У меня сейчас работает Shell-скрипт, который «патчит», но делает он это по Крону. Вопрос в том, как привязать запуск скрипта к событию автоматического обновления зоны внутренним DNS с внешнего DNS? То есть хочу сделать обычную NOTIFY-репликацию + внесение изменений в полученную зону «на лету».

View не предлагать, этот механизм предлагает мне в большинстве случаев изменять оба представления зоны (внешнее и внутреннее), что крайне неудобно (тем более, что в файлах зон нет оператора include и я не могу вынести common-часть в самостоятельный файл).

★★★★★
← /usr/lib/libbz2.so.1.0: ELF file OS ABI invalid при попытке запуска приложения
/usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.9' not found →

Мда, INCLUDE есть, прошу прощения. Только он не поможет в данном случае: нужно будет мутить какие-то грабли с RSYNC'ом или что-то такое...

DRVTiny ★★★★★
() автор топика

Вынесите все внутренние сервисы в отдельную зону типа in.company.ru

ventilator ★★★
()

pdns+lua или что-то в этом духе.

Но, имхо, лучше просто пересмотреть политику использования днс.

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

Домен должен быть один, верх идотизма создавать какие-то непонятные хреновины типа in.domain.ru Компания одна - что изнутри, что снаружи, чего ради должно мняться пространство имён-то, только потому что кто-то не так написал RFC?

На самом деле я придумал решение в соотв. с RFC:

Нужно использовать на мастер-сервере, находящемся за NAT'ом внутри сети, вьюшки внутреннюю и внешнюю. Всё, что у них общего есть, вынести во включаемые файлы зон (см. $INCLUDE). А вместо rndc reload можно использовать простейший скрипт, который сначала синкрементит серийник в указанной зоне/ах, а затем уже сделает rndc reload. Во вне корпоративной сети ставится подчинённый сервер, который будет качать зоны с внешней вьюхи, именно этот сервер будут выставлен в интернет всем желающим назло.

Всё! Таким образом, никаких косяков с обновлением зон у slave'а не будет, а сама процедура редактирования зон будет немногим сложнее обычной (отличается по сути только тем, что нужно сначала определить, в common или в different-части находится нужная запись).

DRVTiny ★★★★★
() автор топика
Ответ на: комментарий от power

Да, и это... объясните мне почему зря-то? Потому что ВАМ так проще?

DRVTiny ★★★★★
() автор топика
Ответ на: комментарий от DRVTiny

>Домен должен быть один, верх идотизма создавать какие-то непонятные хреновины типа in.domain.ru Компания одна - что изнутри, что снаружи, чего ради должно мняться пространство имён-то, только потому что кто-то не так написал RFC?

Ага, и удалять гланды напрямую — глупость. Организм один — что прямая кишка, что горло, чего ради их называть по-разному? Неужели теперь всегда гланды напрямую удалять, только потому что кто-то не осилил удаление через задницу?

nnz ★★★★
()
Ответ на: комментарий от DRVTiny

По твоей же логике почему разные зоны должны иметь одинаковое имя?

Ну и я сделал проще. Все сервисы компании находятся в приватной сетке а если что нужно то тупо openvpn кидается и всё.

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

Почему разные-то? Зоны одна, большая часть адресов совпадает, просто нужно скрыть внутренние адреса на внешнем DNS.

DRVTiny ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← /usr/lib/libbz2.so.1.0: ELF file OS ABI invalid при попытке запуска приложения
Admin
/usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.9' not found →