Eu tenho um servidor dedicado rodando no subdomínio. Eu quero configurar subdomínios como DNS. Basicamente, eu uso example.com como meu domínio principal da empresa. Provavelmente terei mais de um servidor dedicado e quero que sejam s1, s2etc.
Redirecionei server.example.compara outro provedor de DNS por meio de entradas NS
server.example.com NS ns1.hostingcompany.example.com
server.example.com NS ns2.hostingcompany.example.com
E lá eu configurei as seguintes entradas:
servers.example.com NS ns1.hostingcompany.example.com.
servers.example.com NS ns2.hostingcompany.example.com.
s1.servers.example.com NS ns1s1.servers.example.com.
s1.servers.example.com NS ns2s1.servers.example.com.
ns1s1.servers.example.com A 192.0.2.1
ns2s1.servers.example.com A 192.0.2.2
s1.servers.example.com A 192.0.2.1
Mas, servers.example.comnão tem um registro. Eu o ignorei, pois queria usá-lo apenas como entrada de DNS de agrupamento .
Tudo parece funcionar, exceto meu servidor de ligação local na empresa. Não reconhece s1.servers.example.come nenhum dos subdomínios. Quando mudo para o google DNS, parece funcionar bem.
A pergunta é, se esta configuração é adequada e funcionará?
Nota: Talvez eu não entenda como as entradas NS funcionam, até onde eu entendo é quando o servidor NS existe na entrada do domínio, apontando para outro servidor DNS é considerado "Não me pergunte, pergunte a outro servidor" e os registros A não são necessários nesta cadeia.
A menos que eu esteja seriamente enganado, vejo dois problemas aqui.
A primeira é banal. Estou escrevendo esta resposta algumas horas depois de você ter postado a pergunta. Isso significa que a nova configuração de DNS pode ainda não ter sido propagada por todo o sistema DNS. Dependendo das várias entradas TTL na configuração do domínio, isso pode levar um dia. Um estágio típico desse processo é que alguns servidores DNS já atendem a novas informações, enquanto outros atendem a informações antigas.
A segunda é a sua configuração. Não consigo ver por que você tem as seguintes entradas:
Pelo que entendi sua pergunta, não
s1.servers.example.comé um subdomínio, mas apenas um host. Mas você o está tratando como um subdomínio, pois o delega explicitamente a um servidor de nomes. Isso é muito incomum, e você provavelmente deve deixar de lado essas quatro linhas. A estrutura básica deve ficar assim:Diga ao mundo quais servidores de nomes são responsáveis/autoritários por resolver todos os nomes que estão no
servers.example.comnamespace. Você fez isso nas duas primeiras linhas que postou em sua caixa de código.Em seguida, basta adicionar entradas (registros A) para todos os seus hosts à configuração desses servidores de nomes. A menos que esses servidores de nomes se repliquem, você deve adicionar as respectivas entradas a ambos . Você fez isso
s1na última linha que postou em sua segunda caixa de código.Não deve haver mais nada a fazer. Pessoalmente, eu adicionaria uma entrada adicional para
servers.example.comsi mesma, talvez apenas apontando paras1.servers.example.com, porque a experiência mostra que as pessoas tentarão esse nome de host e ficarão preocupadas se não puder ser resolvido.Um registro não é obrigatório em geral, mas é bom tê-lo lá pelo menos para manter a dica de como alcançá-lo em caso de subdomínio (você precisa saber onde está ns1.sub.example.com que está lidando com example.com - você sabe qual foi a primeira galinha ou ovo? / você não pode pedir ns1.sub.example.com caso ainda não conheça example.com :-) ).
Tem que haver registros SOA ( S tar Of zone A uthority ) e é bastante comum ter pelo menos um registro NS ( N ame S erver ). Tecnicamente, o NS é necessário para delegação relacionada a outro subdomínio, pois o registro NS "importante" para a zona está localizado na zona superior (caso você peça NS, você está no final solicitando diretamente na zona, mas para alcançá-lo você está usando NS da zona superior).
Para imaginação vamos supor esta estrutura (example.com, example.net e 192.0.2.0/24 é para fins de documentação e o resto é real no sistema DNS - é claro reduzido a um dos muitos registros ...):
Neste exemplo, há informações consistentes para delegação de NS para example.com na zona diretamente e na zona superior.
Caso seja diferente, não é um problema, mas para procurar o servidor autoritativo, o da zona superior (com.) será usado, mas no caso de recursão regular, o registro da zona diretamente será retornado ... o que é tecnicamente usado pode ser mostrado. Isso pode ser um problema no caso de você migrar a zona para outro servidor DNS - até que o servidor DNS anterior esteja ativo, tudo está bem e parece bom, mas uma vez desligado, a zona não é alcançável ...
A zona "superior" é mantida através do registrador (geralmente algum formulário da web), mas a zona diretamente (sua zona) é mantida em qualquer lugar onde você apontar o registro NS (servidor do registrador, servidor do terceiro lado ou seu próprio servidor DNS).
Para ver o registro na zona superior você pode usar este comando (no caso do servidor DNS example.com so com.):
Para obter o conteúdo da zona example.com você pode usar (pedindo, por exemplo, servidor DNS público do google):
Caso a delegação esteja funcionando em geral, mas não no local, acho que você definiu localmente a zona DNS para example.com (por exemplo, para obter IP interno em vez de público), então mesmo você fez a delegação NS para o subdomínio sua instância local da zona DNS example.com não tem idéia sobre isso - você precisa adicioná-lo também lá.
Ao lado dele, você não precisa de delegação NS extra para cada subdomínio. Caso você não precise de um servidor DNS de subdomínio extra, mesmo o servidor DNS "principal" pode lidar com isso.
Este é o conteúdo válido da zona para example.com
Caso você precise de delegação apenas servidores "level" podem ser suficientes:
Portanto, caso você não precise de um servidor DNS extra para algum propósito especial diretamente em s1.servers.example.com, este registro da pergunta não é realmente necessário:
Sua configuração está correta, exceto:
Como você delegou o domínio
s1.servers.example.coma outros servidores de nomes, é tarefa deles definir essa entrada. Uma exceção constitui os registros de cola , que devem estar na zona pai. Você pode usá-los para dar um nome mais racional aos servidores de nomes delegados: