DNS: как заставить локальный сервер накладывать результаты на авторитетный сервер?
У меня есть домен, для которого я контролирую DNS, и он размещен в Интернете. У меня также есть внутренняя сеть с NAT (192.168.0.0/24) с доступом в Интернет, которую я также контролирую. В этой внутренней сети у меня также есть преобразователь DNS. Программное обеспечение DNS на обоих - PowerDNS.
Я хочу, чтобы DNS-преобразователь во внутренней сети мог добавлять / изменять записи запросов и результатов, которые поступают с авторитетного сервера. Например, на полномочном сервере может быть одна запись для animal.example.com:
animal.example.com. IN AAAA 2001:140:283::1
Однако мне бы хотелось, чтобы внутренние клиенты, выполняющие поиск в DNS для animal.example.com, могли получить в ответ следующее:
animal.example.com. IN AAAA 2001:140:283::1
animal.example.com. IN A 192.168.0.2
Очевидно, я мог бы настроить внутренний DNS-сервер так, чтобы он притворялся авторитетным, например, example.com, но это потребует изрядных усилий, чтобы синхронизировать основной DNS-сервер и внутренний DNS-сервер для записей, которые одинаковы между обе. Если бы внутренний DNS-сервер каким-то образом можно было сделать подчиненным основного DNS-сервера, но при этом иметь возможность добавлять свои собственные результаты, это было бы идеально.
Это возможно?
Я думаю, вам нужна настройка DNS с разделенным горизонтом, однако PowerDNS не поддерживает ее напрямую (в отличие от Bind или DJBDNS). Официальный ответ автора здесь: http://mailman.powerdns.com/pipermail/pdns-users/2006-September/003779.html
Я никогда не считал, что DNS с разделением горизонта особенно сбивает с толку, особенно если файлы четко разложены в файловой системе, например ./master-interal/domain.com ./master-external/domain.com
Единственный вариант, который они предлагают, - это запустить два разных экземпляра PowerDNS на сервере, прослушивающем разные порты. Я предполагаю, что тогда вы могли бы использовать iptables для перенаправления трафика на порт 53 в зависимости от того, какой экземпляр подходит.
На самом деле, если я было для этого я бы использовал Lua Script с рекурсором, который искажает данные в postresolve.
Однако я действительно рекомендую что-то другое: просто используйте отдельную авторитетную зону, такую как internal.example.com, где вы используете AXFR example.com от авторитетных серверов, и просто добавьте свои локальные данные RFC1918.
Таким образом, вы все еще можете отлаживать авторитетную зону, как будто она находится в Интернете, из вашей локальной сети, и использовать внутренние данные.
О сценариях Lua для PowerDNS Recursor: http://doc.powerdns.com/recursor-scripting.html
Я настоятельно рекомендую вам не идти по этому пути, поскольку он чрезвычайно запутанный, сложный и трудный для управления. Вместо этого вы должны создать отдельный внутренний домен, например inside.example.com. Затем, если ваш внешний DNS-сервер также находится во внутренней сети, вы должны настроить его как авторитетный для обоих доменов. Однако, если ваш внешний DNS-сервер находится вне вашей внутренней сети, вам следует настроить внутренний DNS-сервер как авторитетный для inside.example.com. Затем ваш внутренний DNS-сервер должен пересылать все остальные запросы на внешний DNS-сервер.
Я понимаю, что обратная сторона этого заключается в том, что вам нужно изменить домен на всех ваших внутренних машинах, но выполнение этой предварительной работы сейчас избавит вас от многих проблем в будущем.
Разделение DNS через рекурсор PowerDNS
После того, как я некоторое время возился с моей Fedora 20, я, кажется, заставил ее работать. Я нигде не нашел полного практического руководства, поэтому краткое описание минимальной настройки:
Мы хотим решить webserver.dyndns.org для доступа к веб-сервису на нем как из Интернета, так и из локальной сети.
Из Интернета
Машина а в Интернете решает webserver.dyndns.org на IP-адрес IPisp. Behing IPisp это маршрутизатор с NAT, который перенаправляет порт 80 на IP-адрес LAN IPx, таким образом делая веб-сервис доступным в Интернете.
Естественно, это делается путем регистрации IP-адреса. IPisp на полномочном сервере имен для домена dyndns.org, который в случае службы, такой как DynDns, выполняется с помощью ddclient работает на маршрутизаторе или где-то в локальной сети и поэтому не представляет здесь интереса.
Из локальной сети
Машина б в локальной сети решает webserver.dyndns.org на IP-адрес IPx, чтобы веб-сервис стал доступен непосредственно в локальной сети. Кроме того, предполагая, что все машины в локальной сети названы в соответствии с bar.localdomain, имя webserver.localdomain должен также решить IPx. Мы также хотим иметь обратный поиск для хорошей оценки, разрешая IPx к webserver.dyndns.orgвнутри локальной сети (в Интернете, IPx ничего не решает и IPisp преобразуется в произвольную строку, сгенерированную интернет-провайдером.)
Мы предполагаем pdns-recursor работает на отдельной машине с IP IPdns, но мы также можем запустить его на веб-сервере (на том же IP-адресе, что и IPx или по псевдониму), или иметь только одну машину в локальной сети.
Машина «b» может быть настроена статически или динамически через DHCP; видеть dhclient и dnsmasq и возможно avahi. NetworkManager также входит сюда, потому что он может перезаписать /etc/resolv.conf; пока предположим статическую конфигурацию.
Также предположим:
IPx = 192.168.1.1
IPdns = 192.168.1.2
IPbar = 192.168.1.3
Затем:
/etc/resolv.conf на любой машине:
nameserver 192.168.1.2
domain localdomain
Конфигурация для pdns-recursor:
/etc/pdns-recursor/recursor.conf в основном сводится к:
setuid=pdns-recursor
setgid=pdns-recursor
allow-from=127.0.0.0/8, 192.168.1.0/8, ::1/128, fe80::/10
auth-zones=webserver.dyndns.org=/etc/pdns-recursor/[webserver.dyndns.org].zone, localdomain=/etc/pdns-recursor/[localdomain].zone, 168.192.in-addr.arpa=/etc/pdns-recursor/[168.192.in-addr.arpa].zone
local-address=192.168.1.2
Приведенные выше ссылки очень сильно урезаны файлы зоны (их настоящие имена не важны):
В /etc/pdns-recursor/[168.192.in-addr.arpa].zone (обратите внимание на отсутствие точки в конце имени записи - это относительное имя, а не абсолютное: 1.1 средства 1.1.168.192.in-addr.arpa). Это работает с «IN» или без него.
1.1 IN PTR webserver.dyndns.org.
2.1 IN PTR dns.localdomain.
3.1 IN PTR b.localdomain.
В /etc/pdns-recursor/[webserver.dyndns.org].zone (обратите внимание на точку в конце имени записи - это абсолютное имя, а не относительное)
webserver.dyndns.org. IN A 192.168.1.1
В /etc/pdns-recursor/[localdomain].zone
webserver IN A 192.168.1.1
dns IN A 192.168.1.2
b IN A 192.168.1.3
После перезапуска pdns-recursor, можно проверить с помощью dig выполнив эти команды:
PDNS=192.168.1.2
# Test unknwon domain resolution and webserver resolution
dig @$PDNS www.cnn.com | grep -A1 ";; ANSWER SECTION:"
dig @$PDNS webserver.dyndns.org | grep -A1 ";; ANSWER SECTION:"
# Test responses for localdomain
dig @$PDNS unknown.localdomain | grep -A1 ";; ANSWER SECTION:"
dig @$PDNS webserver.localdomain | grep -A1 ";; ANSWER SECTION:"
dig @$PDNS b.localdomain | grep -A1 ";; ANSWER SECTION:"
dig @$PDNS dns.localdomain A | grep -A1 ";; ANSWER SECTION:"
# Test responses for localdomain if the domain is omitted
dig +search @$PDNS webserver | grep -A1 ";; ANSWER SECTION:"
# Test reverse resolution
dig @$PDNS -x 192.168.1.1 | grep -A1 ";; ANSWER SECTION:"
dig @$PDNS -x 192.168.1.2 | grep -A1 ";; ANSWER SECTION:"
dig @$PDNS -x 192.168.1.3 | grep -A1 ";; ANSWER SECTION:"
dig @$PDNS -x 192.168.1.4 | grep -A1 ";; ANSWER SECTION:"
Использовать Труба в PowerDNS. Я создал несколько систем на Python.
PipeBackend:
PipeBackend в первую очередь предназначен для быстрой разработки новых серверных программ без тесной интеграции с PowerDNS. Это позволяет конечным пользователям писать серверные части PDNS на любом языке.