Prolongar
/
O que esse fluxo de dígitos binários tem a ver com DNS? Nada, na verdade - mas boa sorte em encontrar uma bela foto em algum lugar que tenha!
Santo Heston
comentários do leitor
121
com 76 pôsteres participantes, incluindo o autor da história
Compartilhe esta história
Compartilhar no Facebook
Compartilhar no Twitter
Compartilhe no Reddit
Se você deseja ser um administrador de sistema ou administrador de rede de qualquer tipo, existe uma tecnologia fundamental que você realmente precisa entender - DNS, o Sistema de Nomes de Domínio. Houve um tempo em que um administrador de sistema sem aspirações em gerenciar serviços acessíveis pela Internet poderia sobreviver sem entender o DNS, mas esse tempo é muito, muito passado.
Você não pode aprender tudo o que há para saber sobre DNS em um único artigo. Mas não é isso que estamos procurando fazer hoje; em vez disso, queremos dar a você um guia claro e conciso sobre a estrutura e o significado da parte mais importante do Sistema de Nomes de Domínio: um arquivo de zona, como visto no BIND, o Berkeley Internet Name Daemon.
Arquivo de zona de amostra
Prolongar
/
Este arquivo de zona de amostra não contém todos os tipos de registro possíveis, mas é um bom começo.
Jim Salter
Origem e TTL
Acima, temos um pequeno, mas completo exemplo de um arquivo de zona típico - na verdade, é uma versão anônima de um arquivo de zona de produção em um domínio que eu gerencio. Vamos analisá-lo linha por linha.
$ ORIGIN tld. $ TTL 5m
Sempre que você vê um
$ ORIGIN
linha em um arquivo de zona, este é um atalho que permite ao BIND saber que qualquer referência de nome de host não terminada após essa linha deve ser presumida para terminar no argumento seguinte
$ ORIGIN
. Neste caso, é
.tld
—O domínio de nível superior fictício para
example.tld
.
A próxima linha,
$ TTL 5m
, declara que as linhas a seguir terão um tempo de vida de cinco minutos. Esse valor relativamente curto significa que os resolvedores DNS remotos devem armazenar em cache os registros recuperados dessa zona por cinco minutos antes de solicitá-los novamente. Se você estiver relativamente certo de que seu DNS para um determinado domínio não mudará com muita frequência, pode considerar aumentar esse valor para reduzir o número de vezes que hosts remotos devem consultar seu servidor de nomes - mas lembre-se de que um TTL mais longo também significa períodos mais longos de tempo de inatividade, quando você deve fazer uma alteração em seu DNS (ou fazer uma alteração que o interrompa acidentalmente).
Ambos
$ ORIGIN
e
$ TTL
podem ser definidos várias vezes na mesma zona - cada vez que você os redefine, você altera seus valores para quaisquer linhas abaixo dos novos valores no mesmo arquivo de zona.
Registro SOA
exemplo IN SOA ns1.example.tld. hostmaster.example.tld. (90; série 4h; atualização 15m; repetir 8h; expirar 4m); TTL de cache negativo
O primeiro registro real em nosso arquivo de zona de amostra - ou em qualquer arquivo de zona normal - é o registro SOA, que nos indica o início de autoridade para o domínio. Também é facilmente o tipo de registro mais confuso em todo o sistema DNS.
Para qualquer lista de registro, incluindo este registro SOA, o primeiro argumento é o nome do host ao qual o registro se aplica - neste caso,
exemplo
. Lembre-se de como definimos
$ ORIGIN tld
na primeira linha do arquivo de zona? Isso significa que este nome de host não terminado
exemplo
se expande para
example.tld
—Então, estamos definindo o SOA para o FQDN (nome de domínio totalmente qualificado)
example.tld.
Estamos nos referindo a este nome de host
exemplo
como "não terminado" porque não termina em um ponto. Se quiséssemos contornar o
$ ORIGIN
definir e referir-se a um FQDN diretamente, terminaríamos com um ponto final - por exemplo,
example.tld.
seria o FQDN aqui,
com
o ponto final.
O próximo argumento que vemos é
NO
, abreviação de "Internet". Esta é a classe de registro. Existem outras classes de registro DNS, mas você pode facilmente seguir toda a sua carreira sem ver uma delas (como
CH
, para o Caos) em produção. A classe de registro é opcional; se omitido, BIND irá assumir que o registro que está sendo especificado é da classe
NO
. Nós recomendamos
não
omitindo-o, no entanto, para que algo não mude e todos os seus arquivos de zona sejam corrompidos repentinamente após uma atualização do BIND!
Os próximos dois argumentos são FQDNs - pelo menos, eles se parecem com isso. O primeiro FQDN é realmente um FQDN e deve ser o FQDN do servidor de nomes primário para o próprio domínio - neste caso,
ns1.example.tld.
Observe que você
posso
use nomes de host não terminados aqui - por exemplo, poderíamos apenas ter usado
ns1.example
para este argumento, que teria se expandido para
ns1.example.tld.
graças ao nosso
$ ORIGIN .tld
linha, mas provavelmente é melhor ser explícito aqui.
O segundo FQDN,
hostmaster.example.tld.
, não é realmente um FQDN. Em vez disso, é uma forma perversa de reescrever um endereço de e-mail.
@
é um caractere reservado em arquivos de zona, e o BIND original usa a primeira seção deste "FQDN" como a parte do usuário de um endereço de e-mail - então, isso se traduziria no endereço
hostmaster@example.tld
. Isso é
incrivelmente
comum ver isso bagunçado em arquivos de zona da vida real - felizmente, não importa muito. Não temos conhecimento de literalmente ninguém que realmente use esse recurso de uma zona DNS para entrar em contato com alguém.
Continuando, nós temos
serial
,
refrescar
,
tentar novamente
,
expirar
, e
TTL negativo
para a zona entre parênteses. Observe que os comentários que você vê aqui, rotulando-os, não são obrigatórios - e na vida real, você raramente os verá. Preferimos fortemente colocar esses comentários em arquivos de zona de produção para facilitar sua leitura, mas o BIND em si não se importa!
serial
—Este é um número de série simples para o arquivo de zona, que deve ser incrementado cada vez que o conteúdo da zona for alterado. Se você não atualizar o serial do arquivo de zona, suas alterações na zona não serão detectadas por resolvedores de DNS que já armazenaram registros em cache de sua zona! Antigamente, esse formato era AAMMDDnn - mas esse formato não é mais necessário ou, em alguns casos, até mesmo suportado. Basta iniciar suas zonas com serial
1
, incremento para
2
na próxima vez que você fizer uma alteração na zona e assim por diante.
refrescar
- após esse período de tempo, os servidores de nomes secundários devem consultar o servidor de nomes primário para este registro SOA, para detectar mudanças no número de série. Se o número de série tiver aumentado, todos os registros armazenados em cache deverão ser invalidados e obtidos novamente no servidor de nomes primário.
tentar novamente
- se o servidor de nomes primário não responder a uma solicitação SOA, um servidor de nomes secundário deve esperar esse tempo antes de tentar consultar o servidor de nomes primário novamente.
expirar
—Se o servidor de nomes primário falhou em responder à solicitação SOA de um servidor de nomes secundário para este período de tempo, o servidor de nomes secundário deve parar de oferecer resolução DNS para o domínio inteiramente.
TTL de cache negativo
- isso controla por quanto tempo uma resposta "negativa" - por exemplo, "Não tenho o registro que você está pedindo" - deve ser armazenada em cache.
Propaganda
Uma das áreas mais comuns de confusão no registro SOA é o efeito do
refrescar
,
tentar novamente
, e
expirar
argumentos têm. Esses argumentos não afetam os resolvedores DNS de forma alguma - apenas os servidores de nomes autorizados secundários para o domínio. se você não tiver um ou mais servidores de nomes secundários para seu domínio, que usam a replicação BIND para recuperar atualizações do primário, esses argumentos não terão nenhum efeito.
Uma observação final: as versões mais antigas do BIND exigiam que todos esses tempos fossem em segundos ... mesmo quando o intervalo de tempo real fosse em dias ou semanas. BIND9 - lançado há quase 20 anos, em outubro de 2000 - oferece suporte a sufixos de tempo legíveis, como "m" para minutos, "h" para horas e "d" para dias.
Por favor
use esses sufixos legíveis por humanos ao gravar arquivos de zona; ninguém deveria ter que usar uma calculadora para descobrir que 86.400 segundos é um dia!
Registros NS
IN NS ns1.example.tld.IN NS ns2.example.tld.
Nesses dois registros, definimos os nomes de host, que são servidores de nomes autorizados para nossa zona. Mais uma vez, usamos FQDNs terminados em ponto para esses registros. Mais uma vez, nós
poderia
usaram nomes de host não terminados—
ns1.example
e
ns2.example
—E confiou em nosso
$ ORIGIN .tld
para expandi-los. Fazer isso tornaria a zona mais confusa e difícil de ler, no entanto.
Observe que o registro NS especifica
nomes de host
, não endereços IP. Essa é uma fonte comum de confusão para iniciantes em DNS e é importante fazer a coisa certa. Vocês
não pode
especifique um endereço IP vazio como o servidor de nomes para um domínio; você absolutamente deve especificar um nome de host aqui.
Por fim, observe que não especificamos o próprio nome de domínio em nenhuma das linhas - isso porque o herdamos do
SOA
registro acima. Começamos essa linha com
exemplo
, que se expande para
example.tld
. Como não especificamos outro nome de host, esses novos
NS
os registros também se aplicam a esse nome de host por padrão.
No mundo real, você também pode ver arquivos de zona com
$ ORIGIN example.tld.
, e começando o SOA e possivelmente outras linhas com o caractere reservado especial
@
. Quando você vê
@
como um nome de host em um arquivo de zona, isso significa apenas que você está usando o
$ ORIGIN
sem quaisquer qualificadores adicionais.
Registro (s) MX
IN MX 10 mail.example.tld.
Neste domínio simples, temos um único servidor de e-mail, e é
mail.example.tld.
O registro MX informa apenas a quem deseja enviar e-mail para qualquer endereço em
example.tld
para fazer sua conexão SMTP com o nome do host especificado neste registro.
O argumento anterior—
10
neste caso - é a prioridade numérica do servidor de e-mail neste registro específico. Números mais baixos significam prioridade mais alta. Quando vários servidores SMTP estão disponíveis para um domínio, você verá vários
MX
registros também, cada um com uma prioridade diferente. Em teoria, os servidores de e-mail de prioridade mais alta sempre devem ser tentados primeiro, e os servidores de e-mail de prioridade mais baixa tentam apenas se o servidor de prioridade mais alta falhar.
Servidores SMTP bem comportados seguem este protocolo, mas os spammers têm a tendência de visar deliberadamente os servidores de e-mail de baixa prioridade primeiro, operando na teoria de que os servidores de alta prioridade podem ser gateways anti-spam, e os servidores de menor prioridade podem ser os vazios , servidor final não filtrado. Os spammers são uma merda.
Registro (s)
IN A 127.0.0.1
Os registros A são a parte de um arquivo de zona que realmente faz o que a maioria das pessoas pensa que o DNS faz - eles traduzem um nome de host em um endereço IPv4 vazio. Neste caso, este é apenas um arquivo de amostra - e nosso
UMA
registro para
example.tld
simplesmente resolve para localhost, no mesmo princípio que os números de telefone nos filmes semp
re começam com a troca555
. Na vida real, é claro, você colocaria o endereço IP do servidor que esperava responder quando
ping example.tld
, aponte um navegador da Web para
https: //example.tld/
, e assim por diante.
Neste arquivo de zona simples, temos apenas um único
UMA
registro para
example.tld
. Na vida real, você pode encontrar vários - pode haver vários servidores de gateway capazes de responder às solicitações da Web para
https: //example.tld/
; e se sim, cada um obteria seu próprio registro A em sua própria linha.
Registro (s) TXT
IN TXT "v = spf1 a mx a: mail.example.tld a: www.example.tld? All"
Esse
TXT
, ou registro de texto, ainda está na seção principal de nosso arquivo de zona, sob o nome do host
example.tld
. Portanto, seu escopo é todo
example.tld
domínio. Você pode colocar quase tudo em um
TXT
registro; este específico é um
SPF
registro, formatado para fornecer aos servidores de e-mail informações sobre quais máquinas estão autorizadas a emitir e-mails em nome de
example.tld
.
Nesse caso, estamos dizendo que estamos usando a versão SPF1 de formatação. Em seguida, informamos a qualquer pessoa que consultar este registro que qualquer
UMA
registro para
example.tld
está autorizado a enviar correio em seu nome, assim como qualquer
MX
para o domínio e, finalmente, que os endereços IP associados ao
UMA
registros para
mail.example.tld
e
www.example.tld
estão autorizados a enviar correio. Finalmente,
?tudo
diz que se qualquer outra máquina disser que deseja enviar e-mail de algum endereço em
example.tld
, deve ser permitido ... mas deve ser examinado mais de perto do que os hosts especificamente autorizados.
Nomes de host, subdomínios e CNAMEs abaixo de example.tld
$ ORIGIN example.tld.ns1 EM A 127.0.0.2ns2 EM A 127.0.0.3www EM CNAME example.tld.mail EM AAAA :: 1mail EM A 127.0.0.4
Agora que definimos tudo o que precisamos para o domínio, podemos começar a adicionar registros para quaisquer nomes de host e subdomínios
abaixo
example.tld
em si. A primeira coisa que fazemos aqui é mudar nosso
$ ORIGIN
para
example.tld.
Mais uma vez, observe aquele ponto de terminação final - se você esquecer, as coisas vão ficar realmente estranhas e você vai arrancar os cabelos se perguntando por que nenhum de seus registros resolve corretamente!
Nós vemos
UMA
registros aqui para
ns1
,
ns2
, e
correspondência
. Esses
UMA
registros funcionam da mesma maneira que o
UMA
registro para o próprio domínio - estamos dizendo ao BIND para qual endereço IP resolver as solicitações desse nome de host.
Nós também temos um
AAAA
registro para
mail.example.tld.
-
AAAA
registros são como
UMA
registros, mas são para resolver IPv6 em vez de IPv4. Mais uma vez, escolhemos em nosso exemplo usar um endereço de host local. Você precisa estar familiarizado com
AAAA
registros se você espera configurar seu próprio servidor de e-mail - o Google parou de se comunicar com servidores de e-mail sem funcionar totalmente o DNS IPv6 há alguns anos!
Propaganda
O último tipo de registro que vemos aqui é
CNAME
, abreviação de nome canônico. Este é um alias - permite que você diga ao BIND para sempre resolver solicitações para o
CNAME
d host usando o registro A ou AAAA especificado no argumento de destino. Nesse caso,
www IN CNAME example.tld.
significa que o endereço IP para
example.tld
em si também deve ser entregue se alguém pedir
www.example.tld.
CNAME
discos são úteis, mas são um pouco descolados. Vale lembrar que cada nível de
CNAME
necessita de outra pesquisa DNS - neste caso, uma máquina remota que pediu para resolver
www.example.tld
seria dito "por favor, olhe para cima
example.tld.
para encontrar sua resposta ", e então precisaria emitir um
separado
Solicitação de DNS para o
UMA
registro associado com
example.tld.
Se você tem
CNAME
está apontando para
CNAME
está apontando para
CNAME
s, você introduzirá latência desnecessária nas solicitações de seus recursos e seu domínio parecerá "lento" e "lento" para os usuários!
Existem outras limitações em
CNAME
registros. Lembre-se de como dissemos isso
MX
e
NS
os registros devem apontar para nomes de host, não para endereços IP brutos? Mais especificamente, eles devem apontar diretamente para
UMA
registros, não para
CNAME
registros. Se você tentar definir
MX mail.example.tld.
seguido pela
mail.example.tld. CNAME example.tld.
, seu arquivo de zona será quebrado, e
MX
as tentativas de pesquisa retornarão erros.
Ferramentas do comércio
Se você estiver gerenciando seu próprio DNS, precisará ser proficiente no uso de ferramentas de linha de comando para consultar o servidor DNS diretamente e ver como ele responde às solicitações - é difícil ter certeza se o problema é DNS ou qualquer outra coisa apenas por colocando
https: //example.tld/
em um navegador e vendo o que acontece.
escavação
you @ box: ~ $ dig @ 127.0.0.1 NS example.tld; << >> DiG 9.16.1-Ubuntu << >> NS example.tld ;; opções globais: + cmd ;; Resposta obtida: ;; - >> CABEÇALHO <
Se você tiver acesso ao subsistema Linux, Mac ou Windows para Linux, de longe a melhor ferramenta de linha de comando é
escavação
. Usando
escavação
é tão simples quanto especificar um servidor a ser consultado, o tipo de registro que você deseja procurar e o FQDN ao qual deve estar associado.
No exemplo acima, perguntamos ao servidor DNS em
127.0.0.1
para mostrar a todos nós
NS
registros associados com
example.tld
. Além das respostas que queríamos, obtivemos uma tonelada de informações de diagnóstico - o servidor DNS que consultamos não retornou um
ERRO
quando questionado, diz que é autorizado para o domínio em questão e assim por diante.
Você também pode fornecer um
+ curto
argumento se você quiser
escavação
calar a boca e dar a resposta que você está procurando sem todos os diagnósticos detalhados:
you @ box: ~ $ dig + short @ 127.0.0.1 NS example.tldns1.example.tld.ns2.example.tld.
Esteja ciente, porém, que se não houver respostas disponíveis para um
+ curto
consulta - por exemplo, se você digitar o nome do domínio - você não obterá nenhuma resposta, mesmo que o servidor DNS consultado retorne um erro.
you @ box: ~ $ dig + short @ 127.0.0.1 NS example.tmdyou@box: ~ $
Se você quer descobrir
porque
você não obteve uma resposta, você precisa perder o
+ curto
argumento para descobrir.
nslookup
Se você não tem acesso a
escavação
, geralmente você pode conviver com
nslookup
. Mais comumente, esta é uma solução alternativa semi-amaldiçoada para usuários sentados em uma caixa do Windows sem acesso ao subsistema do Windows para Linux, cygwin ou alguma outra forma de obter acesso a ferramentas mais avançadas do que as fornecidas pela CLI do Windows.
nslookup
geralmente é invocado sem argumentos e consultado no modo interativo. Aqui está um exemplo de sessão:
C: \> nslookup> servidor 127.0.0.1 Servidor padrão: 127.0.0.1 Endereço: 127.0.0.1 # 53> example.tldServer: 127.0.0.1 Endereço: 127.0.0.1 # 53 Resposta não autorizada: Nome: example.tldAddress: 127.0. 0,1
Pela configuração
servidor 127.0.0.1
, nós especificamos para
nslookup
para usar essa máquina como o servidor DNS para consultar. Você não precisa especificar isso; se você não,
nslookup
usará tudo o que o resolvedor DNS padrão em sua máquina faria.
Depois de definir opcionalmente o
servidor
, você pode simplesmente digitar um nome de host vazio em
nslookup
prompt interativo de, e ele retornará qualquer
UMA
ou
AAAA
registros que ele pode encontrar para esse nome de host.
Se você quiser consultar o servidor remoto por um tipo diferente de registro, você precisará usar um
definir tipo
comando.
> set type = ns> example.tldServer: 127.0.0.1Address: 127.0.0.1 # 53Resposta não autorizada: example.tld nameserver = ns1.example.tld.example.tld nameserver = ns2.example.tld.Respostas autoritativas podem ser encontrado em:> set type = mx> example.tldServer: 127.0.0.1Address: 127.0.0.1 # 53Resposta não autorizada: example.tld mail exchangeger = 10 mail.example.tld.Respostas autoritativas podem ser encontradas em: example.tld nameserver = ns2.example.tld.example.tld nameserver = ns1.example.tld.mail.example.tld endereço de internet = 127.0.0.4> sair
Nos exemplos acima, usamos
definir tipo = ns
e
definir tipo = mx
para consultar o servidor DNS remoto para
NS
e
MX
registros para
example.tld
. Funciona e você obtém suas respostas ... mas a sintaxe é complicada, há menos informações de diagnóstico disponíveis, é muito menos programável e se você for como nós, provavelmente amaldiçoará a coisa antiquada uma ou duas vezes antes de você está feito.
A maneira correta de sair de
nslookup
o modo interativo é o comando
saída
. Felizmente, você nunca precisará procurar informações sobre um domínio de nível superior também denominado
saída
—Ou se você fizer isso, você terá uma ferramenta melhor disponível do que
nslookup
quando você faz.
Conclusões
Esperançosamente, você aprendeu algo valioso hoje sobre como o DNS funciona e como suas informações são armazenadas. Embora o BIND não seja a única plataforma de servidor DNS por aí - em particular, os administradores do Windows precisarão trabalhar com o DNS do Active Directory - as lições aprendidas aqui se aplicam quase igualmente a todas as plataformas e aplicativos.
Embora o formato de armazenamento possa mudar um pouco de servidor para servidor - como um controlador de domínio do Active Directory que literalmente armazena zonas dentro do próprio Active Directory, em vez de um arquivo de texto simples - os tipos de registro são universais e a formatação, pelo menos, quase universal.
Se você é um administrador de sistema iniciante ou entusiasta que está interessado em executar seu próprio servidor DNS, recomendo enfaticamente fazê-lo - e usar a plataforma original quando o fizer; BIND no Linux ou BSD. A carga do sistema para rodar um servidor de nomes é quase inexistente em qualquer escala, exceto verdadeiramente massiva; uma caixa Digital Ocean ou Linode de $ 5 pode realizar o trabalho muito bem.
Além da alegria absoluta de aprender como gerenciar essas coisas, você também pode achar que valoriza a capacidade de definir seus TTLs absurdamente curtos - a maioria dos servidores DNS gerenciados não permite um TTL de menos de 30m, e a maioria tentará o padrão você a TTLs de até uma semana. Isso é ótimo para uma zona DNS, que já está configurada corretamente e não precisa ser alterada ... mas se o seu endereço IP mudar e o DNS precisar mudar junto com ele, um TTL de cinco minutos é muito, coisa muito boa para se ter.
