Como posso gerenciar todos os meus domínios com configuração mínima?

A menos que eu esteja entendendo mal a pergunta, faço isso regularmente com o BIND e parece estar bem, desde que cada zona seja absolutamente idêntica.

No meu servidor de nomes primário, tenho named.confentradas que apontam para o arquivo de zona genérico, por exemplo

zone "example.com" {
        type master;
        file "primary/example.GENERIC";
};

zone "example.co.uk" {
        type master;
        file "primary/example.GENERIC";
};

e, em seguida, um arquivo de zona primary/example.GENERICque diz, por exemplo

;; 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.

E não estou ciente de nenhum problema com essas zonas. Estou aberto a ouvir que entendi mal a pergunta ou que meus domínios de fato não funcionam, mas até então acho que funciona para mim.

Observe que você não pode usar o mesmo truque no secundário ; cada zona exigirá que um arquivo diferente seja armazenado. Mas como o conteúdo desse arquivo será preenchido e atualizado por transferências de zona do primário, isso não é um grande problema.

Resposta curta

Se você está procurando uma configuração de "configuração zero" no BIND, ela não existe. Configurar uma zona raiz ( .) parece uma boa ideia, mas não é, e você precisa encontrar uma solução que não envolva quebrar o DNS para atender às suas necessidades.

Resposta longa

Recebemos variantes dessa pergunta várias vezes no ano passado.

A resposta é bem simples aqui: você não pode configurar uma única definição de zona. Qualquer software que permita definir ou de outra forma sintetizar vários SOAregistros nesse contexto é um software corrompido , e fazer coisas incorretas não está no tópico do ServerFault. Você precisa escolher um software DNS que torne esse gerenciamento mais simples para você ou precisa criar uma estratégia diferente que não envolva esse atalho específico.

Definitivamente, existem alguns truques que você pode usar para tornar a vida mais fácil...usando o BIND como exemplo, é bastante comum definir várias zonas que fazem referência ao mesmo arquivo de zona de modelo. Isso é perfeitamente legal e o software de validação não encontrará nada de errado com isso: veja a resposta de MadHatter. A maioria das pessoas ignora essa solução porque ainda é "muito trabalhoso" adicionar uma declaração de zona toda vez que um novo domínio é adquirido, mas não há opção "configure uma vez e vá embora" para esse tipo de hospedagem.

As versões mais recentes do BIND oferecem suporte a uma opção chamada allow-new-zonesque permite criar definições de zona dinamicamente em tempo real por meio da nova rndc addzonefuncionalidade. Você pode querer dar uma olhada nisso e ver se ele atende às suas necessidades.

Além das soluções sugeridas, suas opções são um tanto limitadas. Às vezes, você fica preso em fazer o trabalho se o software não faz as coisas da maneira que você deseja.

Existem vários atalhos que você pode usar para facilitar sua vida:

Se você usar o Bind ou software semelhante que usa arquivos para armazenar os dados da zona: aponte suas zonas para o mesmo arquivo, por exemplo:

zone "example.net" {
    type master;
    file "/etc/bind/zone/default.zone";
};

zone "example.org" {
    type master;
    file "/etc/bind/zone/default.zone";
};

Como você pode usar certas abreviações de DNS, pode criar um arquivo de zona universal:

$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

Isso faz uso do fato de que os nomes de host em arquivos de zona que não terminam com um ponto .são sempre expandidos com o $ORIGINque, por sua vez, é implicitamente definido como o nome da zona. E @é uma abreviação de $ORIGIN.

Em vez de manter arquivos de zona individuais manualmente, habilite um método para interagir programaticamente com seus servidores de nomes.

Usei o PowerDNS, que permite um RDMS como back-end, que se encaixa muito bem com a pilha LAMP que estávamos usando na época. Serviços em nuvem como o Amazon Route 53 também expõem APIs da web.

Mas mesmo o venerável Bind também suporta atualização dinâmica , que é um método para adicionar, substituir ou excluir registros em um servidor mestre enviando a ele uma forma especial de mensagens DNS. O formato e o significado dessas mensagens são especificados na RFC 2136 .

A atualização dinâmica é habilitada incluindo uma allow-updateou uma update-policycláusula na declaração de zona. Para obter mais informações, consulte o Manual de Referência do Administrador de Bind .

Quando você diz "os domínios precisam ser configurados de forma idêntica", você quer dizer que eles precisam manter os mesmos registros de recursos? Nesse caso, um DNAMERR para todos, exceto um domínio, não seria uma solução mais limpa?

Não consigo superar o truque de @MadHatter de importar o mesmo arquivo de modelo enquanto permaneço estritamente dentro do escopo de sua pergunta. Só posso oferecer uma abordagem semelhante para back- LDAPend (no meu caso, usado com powerDNS): adicione os associatedDomainatributos para os registros SOA e NS relevantes, assim:

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