Как я могу управлять всеми своими доменами с минимальной конфигурацией?
Это канонический вопрос об администрировании DNS-сервера.
У меня есть сто или около того доменов. Все эти домены должны быть настроены одинаково, но кажется огромной тратой времени на настройку новой зоны и / или файла зоны для каждого из этих доменов. Должен быть лучший способ автоматизировать это!
Я думаю, что я на что-то... если я создаю зону под названием .или используйте какую-либо другую функцию в моем программном обеспечении DNS, чтобы всегда возвращать определенный IP при A запись запрашивается, это, кажется, приближает меня к желаемому конечному результату. Мой сервер отвечает на запросы авторитетно, и им намного легче управлять!
Это прекрасно работало, пока программа проверки имен не начала проверять эти домены. Я понял, что могу устранить большинство ошибок, добавив NS записи, но мое программное обеспечение не позволит мне поставить более одного SOA запись в том же файле зоны.
Как мне обойти это множество SOA проблема записи?
4 ответа
Если я не неправильно понимаю вопрос, я делаю это регулярно с BIND, и, кажется, это нормально, если каждая зона абсолютно идентична.
На моем основном сервере имен у меня есть named.conf записи, которые указывают на общий файл зоны, например
zone "example.com" {
type master;
file "primary/example.GENERIC";
};
zone "example.co.uk" {
type master;
file "primary/example.GENERIC";
};
а затем файл зоны primary/example.GENERIC который говорит, например,
;; Start of Authority
@ IN SOA ns.teaparty.net. dns.gatekeeper.ltd.uk. (
2004091201 ; serial number YYYYMMDDNN
28800 ; refresh 8 hours
7200 ; retry 2 hours
864000 ; expire 10 days
3600 ) ; min ttl 1 day
;;
;; Name Servers
IN NS ns.teaparty.net.
IN NS ns2.teaparty.net.
И я не знаю никаких проблем с этими зонами вообще. Я открыт для того, чтобы мне сказали, что я неправильно понял вопрос или что мои домены на самом деле не работают, но до тех пор я думаю, что это работает для меня.
Обратите внимание, что вы не можете использовать тот же трюк на дополнительном устройстве; каждая зона потребует отдельного файла для хранения. Но так как содержимое этого файла будет заполняться и обновляться в соответствии с исходными данными зоны от основной, это не так уж сложно.
Есть несколько ярлыков, которые вы можете использовать, чтобы сделать вашу жизнь проще:
Если вы используете Bind или подобное программное обеспечение, которое использует файлы для хранения данных зоны: укажите ваши зоны на один и тот же файл, например:
zone "example.net" {
type master;
file "/etc/bind/zone/default.zone";
};
zone "example.org" {
type master;
file "/etc/bind/zone/default.zone";
};
Поскольку вы можете использовать определенные сокращения DNS, вы можете создать универсальный файл зоны:
$TTL 1h ; default expiration time of all resource records without their own TTL value
@ IN SOA ns1.example.com. username.example.com. (
20140218131405 ; Serial number YYYYMMDDHHMMSS
28800 ; Refresh 8 hours
7200 ; Retry 2 hours
604800 ; Expire 7 days
86400 ; Minimum TTL 1 day )
@ IN NS ns1.example.com. ; ns1.example.com is a primary nameserver
@ IN NS ns2.example.com. ; ns2.example.com is a backup nameserver
@ IN MX 10 mail.example.com. ; mail.example.com is the mailserver
@ IN MX 20 mail2.example.com. ; the secondary mailserver
@ IN A 192.0.2.1 ; IPv4 address for the bare domain
IN AAAA 2001:db8:10::1 ; IPv6 address for the bare domain
www IN A 192.0.2.1 ; www.domain
IN AAAA 2001:db8:10::1 ; IPv6 address for www.domain - note by starting the line with a blank it becomes the continuation of the previous record and this IPv6 record applies to www
wwwtest IN CNAME www ; wwwtest is an alias for www
Это использует тот факт, что имена файлов в файлах зон не заканчиваются точкой . всегда расширяются с $ORIGIN который в свою очередь неявно установлен на имя зоны. И @ - это сокращение от $ORIGIN.
Вместо того, чтобы поддерживать отдельные файлы зон вручную, включите метод программного взаимодействия с вашими серверами имен.
Я использовал PowerDNS, который позволяет использовать RDMS в качестве серверной части, которая очень хорошо вписывается в стек LAMP, который мы использовали в то время. Облачные сервисы, такие как Amazon Route 53, также предоставляют веб-API.
Но даже почтенный Bind также поддерживает динамическое обновление, которое представляет собой метод добавления, замены или удаления записей на главном сервере путем отправки ему специальной формы DNS-сообщений. Формат и значение этих сообщений определены в RFC 2136.
Динамическое обновление включается включением allow-update или update-policy пункт в заявлении зоны. Для получения дополнительной информации обратитесь к Справочному руководству администратора Bind.
Короткий ответ
Если вы ищете установку "нулевой конфигурации" в BIND, она не существует. Настройка корневой зоны (.) кажется хорошей идеей, но это не так, и вам нужно найти решение, которое не включает взлом DNS для удовлетворения ваших потребностей.
Длинный ответ
В прошлом году мы несколько раз получали варианты этого вопроса.
Ответ здесь довольно прост: вы не можете настроить определение одной зоны. Любое программное обеспечение, которое позволяет вам определять или синтезировать несколько SOA Записи в этом контексте являются неисправным программным обеспечением, а выполнение сломанных вещей не является темой для ServerFault. Вам либо нужно выбрать программное обеспечение DNS, которое упростит вам это управление, либо вам нужно придумать другую стратегию, не включающую этот конкретный ярлык.
Определенно, есть некоторые приемы, которые вы можете использовать, чтобы упростить жизнь... на примере BIND довольно распространено определение нескольких зон, которые ссылаются на один и тот же файл зоны шаблона. Это совершенно законное и проверочное программное обеспечение не найдет в этом ничего плохого: см. Ответ MadHatter. Большинство людей пропускают это решение, потому что все еще "слишком много" для добавления объявления зоны при каждом приобретении нового домена, но для этого типа хостинга нет опции "настроить его один раз и уйти".
Более новые версии BIND поддерживают опцию под названием allow-new-zones что позволит вам динамически создавать определения зон на лету с помощью нового rndc addzone функциональность. Возможно, вы захотите взглянуть на это и посмотреть, соответствует ли он вашим потребностям.
Кроме того, что предложенные решения, ваши варианты несколько ограничены. Иногда вы просто застряли на работе, если программное обеспечение не работает так, как вы этого хотите.
Когда вы говорите "домены должны быть настроены одинаково", вы имеете в виду, что они должны содержать одинаковые записи ресурсов? В этом случае не будет DNAME RR для всех доменов кроме одного будет более чистым решением?
Я не могу справиться с задачей @MadHatter импортировать тот же файл шаблона, оставаясь строго в рамках вашего вопроса. Я могу предложить только аналогичный подход для LDAP бэкэнд (в моем случае используется с powerDNS): добавьте associatedDomain атрибуты для соответствующих записей SOA и NS, например:
dn: dc=vanitydomains,ou=DNS,dc=myDIT
objectClass: dNSDomain2
objectClass: domainRelatedObject
dc: vanitydomains
associatedDomain: vanitydomain.ORG
associatedDomain: vanitydomain.NET
associatedDomain: vanitydomain.COM
associatedDomain: vanitydomain.INFO
sOARecord: NS1.example.com sysadmin.example.com 2011100701 28800 1800 2592000 10800
dNameRecord: example.com
nSRecord: NS1.example.com
nSRecord: NS2.example.com