LINUX.ORG.RU
ФорумAdmin

bind9 - делегирование субдомена только для локалки

 , ,


0

1

В мануале к FreeIPA говорится что views / split-horizon - это плохо.

Хорошо, но как на уровне acl без view решить такую задачу:

Есть сервер ns1.example.com, который отвечает за зону example.com. Делегирую зону ipa.example.com на контроллер доменов FreeIPA ipa.example.com:

# cat example.com
$TTL    604800
@       IN      SOA     ns1.example.com. root.example.com. (
                         2019091601     ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
;
@       IN      NS      ns1.example.com.
@       IN      NS      ns2.example.com.
ipa     IN      NS      ipa.example.com.

ns1     IN      A       x.x.x.x
ns2     IN      A       x.x.y.y
ipa     IN      A       192.168.1.1

И как мне без view сделать так, чтобы клиенты извне не видели мои серые адреса при разрешении ipa.example.com ?

★★★★★

Раздели wan и lan на разные зоны. Раздай пермишены зонам.

targitaj ★★★★★ ()

В мануале к FreeIPA говорится что views / split-horizon - это плохо.

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

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

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

Problems:

* Using one name for multiple different machines (e.g. public vs. internal) is confusing.

* DNS caching on clients causes problems for machines roaming between different DNS views.

* DNSSEC deployment is harder to maintain when views are involved.

Technically it is much cleaner to put all internal names in a sub-domain like int.example.com. (while example.com. is the public-facing domain) and restrict access to this sub-domain using ACL as described in the previous section.

Turbid ★★★★★ ()
Последнее исправление: Turbid (всего исправлений: 1)
Ответ на: комментарий от Turbid

Снаружи есть доступ к ipa:53? Фильтровать на фаерволах, натах, или allow-query, allow-query-cache. Если нет, то никто и не увидит снаружи эту зону.

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

И 2. Зачем вообще в внешней зоне указывать делегирование на чисто внутр зону? Видимость внутр зон обнспечивается внутренними резолверами, а не корневыми серверами.

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

2. Зачем вообще в внешней зоне указывать делегирование на чисто внутр зону? Видимость внутр зон обнспечивается внутренними резолверами, а не корневыми серверами.

Вот это резонно, кстати. Наверно я слишком заморочился.

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

Когда внутренняя зона видна снаружи, можно слать письма с @inernal.zone. Я бы сделал view и не мучался. Перечисленные проблемы - чепуха.

Или вообще не параноился и пусть host.internal.zone резолвится в 192.168.1.1 снаружи, ничего сильно страшного тут нет.

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

Eсли сделать «* mx» и «* a» (некоторые сервера пытаются резолвить домен из from)

sergej ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.