переопределение некоторых записей dns в bind для внутренних сетей

<p>у меня есть внутренняя сеть с dns-сервером под управлением bind, подключенным к интернету через один шлюз. мой домен "example.com" управляется внешним поставщиком dns. некоторые записи в этом домене, например "host1.example.com" и "host2.example.com", а также запись верхнего уровня "example.com", указывают на публичный ip-адрес шлюза.</p><p>я хотел бы, чтобы хосты, расположенные во внутренней сети, разрешали "host1.example.com", "host2.example.com" и "example.com" во внутренние ip-адреса вместо адреса шлюза. другие хосты, такие как "otherhost.example.com", должны разрешаться внешним dns-провайдером.</p><p>мне удалось сделать это для записей host1 и host2, определив две зоны с одним входом в bind для "host1.example.com" и "host2.example.com". однако, если я добавлю зону для "example.com", все запросы для этого домена будут разрешены моим локальным dns-сервером, и, например, запрос "otherhost.example.com" приводит к ошибке.</p><p>можно ли настроить bind для переопределения только <em>некоторых</em> записей домена и для рекурсивного разрешения остальных?</p>

<p>лучший способ - через зону политики ответа в bind 9.8.1 или новее. он позволяет вам переопределять отдельные записи в произвольных зонах (и для этого не нужно создавать целый поддомен, только одну запись, которую вы хотите изменить), он позволяет переопределять cname и т.д. другие решения, такие как unbound, не могут переопределять cname. ,.</p><p> <a href="https://www.redpill-linpro.com/sysadvent/2015/12/08/dns-rpz.html">https://www.redpill-linpro.com/sysadvent/2015/12/08/dns-rpz.html</a> </p><hr><p><strong> редактировать: </strong> давайте сделаем это правильно тогда. я задокументирую то, что я сделал, основываясь на учебнике, указанном выше.</p><p>моя ос - raspbian 4.4 для raspberry pi, но метод должен работать без изменений в debian и ubuntu или с минимальными изменениями на других платформах.</p><p>перейдите туда, где хранятся ваши файлы конфигурации bind в вашей системе - здесь это в <code>/etc/bind</code>. создайте там файл с именем <code>db.rpz</code> со следующим содержанием:</p><pre><code>$ttl 60 @ in soa localhost. root.localhost. ( 2015112501 ; serial 1h ; refresh 30m ; retry 1w ; expiry 30m) ; minimum in ns localhost. localhost a 127.0.0.1 www.some-website.com a 127.0.0.1 www.other-website.com cname fake-hostname.com. что оно делает? переопределяет ip-адрес для www.some-website.com с поддельным адресом 127.0.0.1, эффективно отправляя весь трафик для этого сайта на адрес обратной связи отправляет трафик на www.other-website.com на другой сайт под названием fake-hostname.com все, что можно поместить в файл зоны bind, вы можете использовать здесь.для активации этих изменений есть еще несколько шагов:правка named.conf.local и добавьте этот раздел:zone "rpz" { type master; file "/etc/bind/db.rpz"; }; в приведенном выше учебнике рассказывается о том, чтобы добавить больше материала к zone "rpz" { } но это не обязательно в простых установках - то, что я показал здесь, это минимум, чтобы заставить его работать на вашем локальном преобразователе.правка named.conf.options и где-то в options { } раздел добавить response-policy опция:options { // bunch // of // stuff // please // ignore response-policy { zone "rpz"; }; } теперь перезапустите bind:service bind9 restart вот и все. сервер имен должен начать переопределять эти записи сейчас.если вам нужно внести изменения, просто отредактируйте db.rpz, затем перезапустите bind снова.бонус: если вы хотите записывать dns-запросы в системный журнал, чтобы следить за ходом работы, отредактируйте named.conf.local и убедитесь, что есть раздел logging, который включает следующие операторы:logging { // stuff // already // there channel my_syslog { syslog daemon; severity info; }; category queries { my_syslog; }; }; перезапустите bind снова и все.проверьте это на машине, на которой работает bind:dig @127.0.0.1 www.other-website.com. any если вы запускаете dig на другом компьютере, просто используйте @ the-ip-address-of-bind-server вместо @ 127.0.0.1я с большим успехом использовал эту технику, чтобы переопределить cname для веб-сайта, над которым я работал, и отправить его на новый балансировщик нагрузки aws, который я только что тестировал. raspberry pi использовался для запуска bind, а rpi также был настроен для работы в качестве маршрутизатора wifi - поэтому, подключая устройства к ssid, работающему на rpi, я получал переопределения dns, необходимые для тестирования.

 <a href="http://www.unbound.net/">nbound рекурсивный dns-сервер имеет возможность переопределять отдельные записи ресурсов.посмотрите на local-zone а также local-data настройки конфигурации в <a href="http://www.unbound.net/documentation/unbound.conf.html">ручной , например:local-zone: "example.com." transparent local-data: "foo.example.com. in a 192.168.1.1" параметр transparent на local-zone говорит, что он должен делать нормальный рекурсивный поиск для любых имен, не поставляемых с local-data.

возможно, вы захотите взглянуть на "dnsmasq", который позволяет вам делать довольно умные вещи с тонкой настройкой разрешения.

то, что вы ищете, это разделенный dns, который определяется <a href="http://www.webopedia.com/term/s/split_dns.html">webopedia как:<blockquote> в раздельной инфраструктуре dns вы создаете две зоны для одного домена, одну для внутренней сети, а другую для внешней сети. разделенный dns направляет внутренние хосты на внутренний сервер доменных имен для разрешения имен, а внешние хосты направляются на внешний сервер доменных имен для разрешения имен. </blockquote>по сути, вам нужно будет сделать копию файла внешней зоны и сохранить ее на своем внутреннем dns-сервере, а затем изменить или добавить записи, необходимые специально для вашей внутренней сети. это довольно распространенная настройка, хотя может быть очень сложно синхронизировать "внешние" записи между двумя dns-серверами. если вы создаете или изменяете запись на общедоступном сервере, ее также необходимо будет создать или изменить на частном сервере.это может быть реализовано независимо от того, какую реализацию dns-сервера вы используете. в большинстве случаев у вас будет один dns-сервер, который обслуживает внешнюю сеть, и другой, который обслуживает внутреннюю сеть. с помощью bind, как и, возможно, других реализаций, вы можете иметь обе версии зоны на одном и том же сервере с помощью оператора "allow-query" в разделе зоны файла named.conf.другая возможность в bind (и я никогда не пробовал этого) состояла бы в том, чтобы установить домен example.com на внутреннем dns-сервере только с теми записями, которые вы используете для внутреннего использования. затем установите оператор "forward" с аргументом "first" (в сочетании с "forwarders"). теоретически, для этого нужно запросить ответ у внешнего dns-сервера (как установлено в "серверах пересылки", который не будет содержать ваши внутренние записи и не даст ответ о сбое. затем внутренний сервер будет искать ответ сам по себе. не конечно, если это сработает, но это мысль.

в bind я добираюсь до этих результатов, определяя зону, используя желаемое имя хоста. подход хорош, если вы хотите переопределить только несколько хостов.моя декларация зоны выглядит так:zone "override.example.com" { type master; notify no; file "zone-config/override.example.com"; }; мое определение зоны выглядит так:$ttl 4h @ in soa ns.override.example.com. root.override.example.com. ( 2009072215 ; serial 3600 ; refresh 600 ; retry 604800 ; expire 3600 ) ; minimum ; ns ns in ns ns.override.example.com. in a 192.168.1.100 ns in a 192.168.1.100 </code></pre><p>поэтому, если я запрашиваю example.com в интрасети dns и dns провайдера, я получаю один и тот же ip-адрес, но если я запрашиваю override.example.com, я получаю разные результаты, если интрасеть dns (основной) доступна.</p>

<p>использование dnsmasq делает это действительно легко. <a href="http://www.thekelleys.org.uk/dnsmasq/doc.html">http://www.thekelleys.org.uk/dnsmasq/doc.html</a> действует как сервер dns, но получает ответы от локального сервера dns. приятно то, что вы можете переопределить отдельные записи домена, не связываясь с файлами зон</p>

<p>на самом деле, есть другой, хотя, возможно, немного иной, способ сделать это. у меня такая же ситуация, у меня есть домен, который используется снаружи и внутри, и у меня есть внешние статические и динамические хосты. единственными действительно болезненными являются внешние динамические. решение, возможно, не самое элегантное, но реализуемое с помощью небольшого сценария. в основном я делаю свой собственный динамический dns-скрипт с api моего динамического dns-провайдера, я запускаю этот скрипт по cron каждые 5 минут:</p><p>1) получить мой внешний ip. это изменилось? выхода нет.</p><p>2) изменили ip, вызовите api dyndns-провайдера, с новым ip-адресом,</p><p>3) sed the db.mydomain.com с внешним ip</p><p>4) перезапустите привязку.</p><p>работает очень надежно для моей домашней сети</p>

<p>вы уже на правильном пути.</p><p>на ваших внутренних dns-серверах вам нужно определить зону для каждого узла исключения сразу под "example.com". чтобы свести к минимуму эти исключения, обычной практикой является присвоение имен всем внутренним машинам "hosta.internal.example.com", при этом dns-сервер отправляет большинство запросов на внешние dns-серверы, но является доверенным для зоны "internal.example.com". (после выполнения небольших операций обычно существует пара dns-серверов, на которые направляются клиенты, и отдельный авторитетный dns, на который эти серверы направляются для "internal.example.com".)</p><p>обычно, только когда хост должен быть доступен как снаружи, так и внутри, создаются исключения, которые вы описываете. даже тогда вы можете использовать "host1.example.com" снаружи и "host1.internal.example.com" изнутри. внутренние хосты настроены на поиск имен в "internal.example.com". существуют ситуации, когда то, что вы уже делаете, подходит, например, если сертификат для сервера идентифицирует сервер как "host1.example.com", и в этом случае вы хотите, чтобы это было имя, к которому подключаются клиенты.</p>