Як я можу керувати всіма своїми доменами з мінімальною конфігурацією?

Це канонічне запитання щодо адміністрування сервера 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.

І я взагалі не знаю жодних проблем із цими зонами. Мені відкрито сказати, що я неправильно зрозумів питання, або що мої домени насправді не працюють, але до цього часу я думаю, що це працює на мене.

Зверніть увагу, що ви не можете виконати один і той же трюк на другорядних ; кожна зона буде вимагати інший файл повинен бути збережений. Але так як вміст цього файлу буде заповнюватися і постійно актуальний по зонні пересилання від основної, це не величезна угода.

Існує ряд ярликів, якими можна полегшити життя:

Якщо ви використовуєте 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функціоналу. Ви можете поглянути на це і побачити, чи відповідає вашим потребам.

Крім запропонованих рішень, ваші варіанти дещо обмежені. Іноді ти просто зациклюється на виконанні роботи, якщо програмне забезпечення не робить речі так, як ти хочеш.

Якщо ви говорите "домени потрібно налаштувати однаково", ви маєте на увазі, що вони повинні зберігати однакові записи про ресурси? У такому випадку, чи не DNAMERR для всіх, крім одного домену, не буде чистішим рішенням?

Я не можу перемогти трюк від імпортування одного і того ж файлу шаблону від @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