Это Канонический вопрос об администрировании DNS-сервера.
У меня около сотни доменов. Все эти домены должны быть настроены одинаково, но настройка новой зоны и / или файла зоны для каждого из этих доменов кажется огромной тратой времени. Должен быть лучший способ автоматизировать это!
Я думаю, я что-то нахожу ... если я создам зону под названием ., или используйте другую функцию в моем программном обеспечении DNS, чтобы всегда возвращать определенный IP-адрес, когда A требуется запись, это, кажется, приближает меня к желаемому конечному результату. Мой сервер авторитетно отвечает на запросы, и им намного проще управлять!
Это отлично работало, пока программное обеспечение для проверки серверов имен не начало проверять эти домены. Я понял, что могу исправить большинство ошибок, добавив NS записей, но мое программное обеспечение не позволяет мне ставить более одного SOA запись в том же файле зоны.
Как мне обойти это множественное SOA проблема с записью?
Если я не неправильно понимаю вопрос, я делаю это регулярно с помощью 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.
И вообще никаких проблем с этими зонами не знаю. Я открыт для того, чтобы услышать, что я неправильно понял вопрос или что мои домены на самом деле не работают, но до тех пор я думаю, что это работает для меня.
Обратите внимание, что вы не можете проделать тот же трюк на вторичном; каждая зона воля требуется, чтобы в нем был сохранен другой файл. Но поскольку содержимое этого файла будет заполняться и обновляться с помощью зоны xfers из основного, это не имеет большого значения.
Есть ряд ярлыков, которые можно использовать, чтобы облегчить себе жизнь:
Если вы используете 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.
Но даже почтенный Бинд тоже поддерживает динамическое обновление который представляет собой метод добавления, замены или удаления записей на главном сервере путем отправки ему специальной формы сообщений 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 backend (в моем случае используется с 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