O Sistema de Nomes de Domínio (DNS) desempenha um papel importante na Internet. Ele converte nomes canônicos em endereços IP e é vital no roteamento de tráfego na rede. A resolução do DNS é um vasto tópico e isso não poderá ser abordado completamente neste artigo. Em vez disso, mencionarei as etapas mais importantes para tornar um site ao vivo de um servidor onde você comprou uma conta de hospedagem.

Resolução DNS

1. Você precisa registrar um site como o newdomain.com, NewDomain.org, newDomain.Biz, NewDomain.hospedagem, etc. Hoje em dia, existem muitos novos TLD como .trabalhar, .hospedagem etc. De qualquer um dos registradores de domínio. Os mais comuns são como o Godday.com, domínio.com, namecheap.com, Bluehost.com
2. Depois de comprar o nome de domínio do registrador acima, agora precisamos encontrar uma conta de hospedagem (pode ser uma hospedagem/ revendedor compartilhada ou um servidor VPS/ dedicado) . Se você estiver tendo uma conta compartilhada/revendedora, principalmente eles nos fornecerão um par de servidores de nomes que devem ser usados ​​para apontar o domínio para seus servidores. Se você estiver comprando um VPS/servidores dedicados, talvez tenhamos que configurar o servidor com o servidor DNS para o qual usamos principalmente pacotes nomeados ou vinculados.
3. Se você estiver usando os próprios servidores de nome do registrador, precisará criar todos os registros DNS manualmente nesse painel. Se você estiver usando uma hospedagem compartilhada CPALE / PLESK, principalmente eles terão todos os registros DNS criados ao criar a conta e você só precisa apontar os servidores de nome do provedor de hospedagem no final do registrador.
4. Uma vez apontado, pode levar até 24 a 72 horas para propagar as mudanças em toda a Internet.

Compreendendo os registros do DNS

Os registros DNS são configurações que nos ajudam a apontar um domínio e a variedade de serviços para os servidores ou endereço IP adequados. Os registros do DNS atuam como um instrutor como esse domínio está apontando para esse IP, que o subdomínio está apontando para outro IP etc. Sem os registros DNS adequados, os humanos terão que se lembrar do endereço IP e lembrar que um iPaddress será uma tarefa tediosa e é como a importância do DNS entra para reproduzir.

Não precisamos lembrar um endereço IP, pois sempre será um problema para os humanos usarem o endereço IP para acessar o site. É por isso que registramos o nome de domínio e usamos o DNS para apontá -lo corretamente para o servidor de hospedagem. Antes que os servidores ou pacotes DNS fossem criados, um terá que digitar o endereço IP no navegador e ter que lembrar o mesmo. Com a introdução do IPv6, é literalmente impossível lembrar o endereço IP, mesmo para aqueles que têm a melhor capacidade de memória.

Existem mais de 70 registros DNS e você pode ler o link abaixo para todos os registros DNS possíveis e seus detalhes

https: // www.IANA.Org/atribuições/DNS-Parameters/DNS-Parameters.xml

Estou discutindo os registros abaixo que são mais necessários para um leigo realizar seu site e fluxo de e -mail sem problemas.

1. Record SOA
2. Valor TTL
3. Uma gravação
4. AAAA RECORD
5. Registro NS
6. MX RECORD
7. Registro txt
8. Record SPF
9. Record DKIM
10. DMARC Record
11. PTR RECORD
12. CNAME RECORD
13. Record SRV
14. RP RECORD
15. DNSKEY RECORDs

1. Record SOA (início da autoridade)

O SOA Record é o mais importante e ainda não tão popular registro. É um registro obrigatório para um arquivo de zona DNS funcionar e dar resultados a nós. Este registro específico terá o nome da zona, endereço de email da pessoa responsável que lida com o arquivo de zona do domínio, número de série atual, servidor de nomes primário ou principal para a zona e alguns elementos de tempo que são medidos e exibidos em segundos.

Abaixo está um recorde de SOA de amostra

domínio.com. 86400 na SOA NS1.domínio.com. Proprietário.domínio.com. (
2017100505; número de série
3600; atualizar
7200; tente novamente
1209600; expire
86400)
O formato exato para isso é o abaixo
@ Em SOA primário-name-server hostmaster-email (
número de série
Time-to-frhresh
Time-to-Retristion
Time-to-Expire
mínimo-ttl)

Servidor de nome primário: Ele mostra o servidor de nomes que contém os registros DNS originais.

HostMaster-Eail: Endereço de e -mail do proprietário responsável pelo domínio. Um periodo ".”Será usado substituindo um @ símbolo. Para endereço de e -mail que possui um “.”Já está escapar com um“/”.

Número de série : É o número da versão da zona e continuará aumentando com cada atualização do arquivo de zona.

Time-to-refresch: Este valor mostra a hora de esperar a verificação de uma atualização de número de série. Isso é necessário principalmente quando você está tendo um cluster secundário de DNS ou DNS, que precisa verificar uma atualização no arquivo mestre e precisa ser copiado o mais recente para os outros servidores no cluster. Aplica -se apenas àqueles que têm DNS secundário ou configuração de cluster.

Time-T-Retion: Ele determina quanto tempo um servidor de nomes deve esperar para tentar novamente a atualização se a última tentativa falhar.Aplica -se apenas àqueles que têm DNS secundário ou configuração de cluster.

Tempo de Expiro: Ele determina quanto tempo devemos precisar esperar antes de considerar os dados dos servidores de nomes secundários ou de outro cluster inválidos e parar de responder às consultas para a respectiva zona.

mínimo-ttl: Quanto tempo um servidor de nomes ou resolvedor deve cache uma resposta negativa.

2. TTL (tempo de viver) Valor

O valor TTL é o horário em segundos em que os registros de DNS serão armazenados em cache por um servidor ou nomes externos do DNS e, depois, deve atualizá -lo em cache e ter o valor mais recente . A principal importância disso é enquanto você planeja uma migração e precisa de mudanças no DNS sem o tempo de inatividade do DNS. Mudanças nos servidores de nomes sempre podem causar tempo de inatividade, pois não temos controle sobre aqueles. Portanto, antes da migração, alteramos o valor TTL para 300 segundos 1 - 2 dias antes, para que, após a migração, alteramos os nomes do servidor no final do registrador e também alteraremos os IPs de todos os arquivos de zona em servidor antigo para novos IPs Para que ele comece a resolver o novo servidor nos dois casos, ou seja, se o DNS chegar ao servidor antigo, apontará o domínio desse servidor para o novo servidor e, se os servidores de nomes recém -atualizados forem levados, também começará a carregar a partir de novo servidor.

Se nenhum valor TTL não for mencionado, esse será o principal valor padrão para todos os registros do DNS, a menos que tenhamos outro valor especificado nos registros.

Entrada de amostra
$ TTL 14400

3. Uma gravação

Um registro também é conhecido como registros de endereço ou registros de host. Isso é usado principalmente para apontar o domínio/subdomínio etc. para o endereço IP do servidor. Um registro resolve apenas um endereço IP e nenhum outro argumento /variável está lá no registro A. A registros são usados ​​apenas para apontar para um endereço IPv4.

Amostra Um registro é o abaixo um
domínio.com. 14400 em um 192.168.1.1

Também podemos usar um registro DNS curinga que carregará todos os subdomínios em um IP

*.domínio.com 14400 em um 192.168.1.1

4. AAAA RECORD

O registro AAAA é o mesmo que o registro e o objetivo acima e o uso deste registro é o mesmo. A única diferença é usada para apontar o domínio para um IP IPv6 e se o domínio também estiver tendo uma versão IPv6, precisamos ter esse registro tão bem apontado .

A amostra AAAA Record é o abaixo

domínio.com 14400 em AAAA 0133: 4237: 89BC: CDDF: 0123: 4267: 89AB: CDDF

5. NS (Nome Server) registro

A situação ideal será o servidor de nomes no nível do registrador e o arquivo da zona DNS são os mesmos e os registros NS incompatíveis podem causar alguns problemas com alguns ISP, mas normalmente que a incompatibilidade não é esse problema. Portanto, os registros do servidor de nomes primários devem estar lá no arquivo de zona de registrador e DNS no servidor mencionado no registrador.

Entrada de amostra
domínio.com. 86400 em NS NS1.MainDomain.com.
domínio.com. 86400 no NS NS2.MainDomain.com.

Quando você está tendo os servidores de nomes para o mesmo domínio, adicione um registro para esses servidores de nomes .No exemplo acima, ele está usando outro servidor de nomes Registerd, como NS1.MainDomain.com. Mas se você deseja usar NS1.domínio.Com como servidor NameNeServer em Registrador e servidor, você precisa configurar registros host no Registar (que é o registro de cola) e precisa adicionar os registros abaixo também

NS1 14400 em um 192.168.1.1
NS2 14400 em um 192.168.1.1

6. MX (Record

Este é outro registro DNS importante que determina o destino de seus e -mails recebidos em um domínio. Quando alguém envia um e -mail para uma conta de e -mail sob um domínio, o servidor remoto enviará e -mails para o servidor mencionado nos registros MX e com o menor valor em prioridade que de fato está tendo a maior prioridade

Amostra de registros MX

domínio.com 14400 em MX 10 Mail_1.domínio.com
domínio.com 14400 em MX 20 Mail_2.domínio.com
domínio.com 14400 em MX 30 Mail_3.domínio.com

Neste exemplo, se Mail_1.domínio.com está baixo, o correio será entregue para Mail_2.domínio.com. Se Mail_2.exemplo.com também está inativo, o e -mail será entregue para Mail_3.domínio.com.Isso é usado principalmente quando você possui domínio adicionado em vários servidores e o e -mail configurado neles. Mas esses e -mails serão espalhados por esses servidores e você pode precisar verificá -los manualmente.

Se você estiver usando os registros MX com o mesmo nome de domínio, precisar. Como o abaixo . Mas se você estiver usando aplicativos do Google, Outlook etc., não é necessário adicionar um registro adicional para aqueles que você não tem o controle sobre eles e aqueles devem ser adicionados por esses fornecedores.

Mail_1 14400 em um 192.168.1.1
Mail_2 14400 em um 192.168.1.2
Mail_3 14400 em um 192.168.1.3

7. Registro txt (texto)

Um registro txt ou registro de texto na verdade não tem nenhuma função na funcionalidade de domínios e geralmente é usado para exibir algumas informações ou usar algumas verificações, como quando você se inscreve com o Google Apps ou o Outlook Mail Service, então eles pedirão que você adicione um Registro txt que eles pedem (um código exclusivo) para que possam verificar a propriedade do domínio. Os registros SPF/DKIM também são baseados no TXT, mas eles têm uma funcionalidade para executar. Eles também podem ser usados ​​como uma opção para autenticar sua propriedade enquanto adiciona à conta do webmaster do Google e outros serviços relacionados ao Google também.

Abaixo está uma amostra de entrada DNS para verificação do Google

domínio.com. 300 em txt google-site-verification = gbmnbtgtiz_esmkjbkt-pxlH50m

8. Registro de SPF (Quadro de Política de Política do remetente)

O SPF Record é basicamente um registro TXT, que normalmente publica todos os servidores de email designados para um domínio ou subdomínio. O uso principal deste registro é provar a legitimidade dos e -mails e evitar e -mails falsificados. Um servidor de correio de destino pode rejeitar e -mails se não forem dos servidores de correio registrados ou mencionados com base neste registro.

Entrada de amostra
domínio.com. Em txt "v = spf1 +a +mx +ip4: 192.168.1.5 -TO "

Isso diz que esse domínio enviará e -mails legítimos apenas de um registro, MX Record Servers e também do IP 192.168.1.5 e todos os outros podem ser rejeitados . Com o registro SPF acima, o servidor de recebimento verá todos os servidores e iPaddress mencionados no SPF. Se o endereço IP corresponder, a verificação será passada e, se não for, falhará (a mensagem será rejeitada automaticamente) e se usarmos "~ all", que é uma falha suave que será marcada como falha, mas não será rejeitado.

Você pode consultar mais sytanx deste link.

9. DKIM (DOMAINKEYS Identificou Mail) registro

Este também é um registro txt que é um protocolo de autenticação por e -mail, que é um pouco mais complicado que o SPF. Este registro é criado para um subdomínio que possui um seletor único para a chave e depois terá um “.”Ao adicionar esse registro, ele adicionará uma assinatura digital aos cabeçalhos da mensagem de e -mail. Esta assinatura é validada usando a chave pública publicada pelo registro DKIM. Isso é um pouco complicado e, se você estiver no cpanel, eles provam uma opção para fazer isso facilmente usando uma opção de ativação de um clique.

Entrada de amostra
padrão._domainkey 14400 em txt "v = dkim1; k = rsa;
p = miibijanbgkqhkig9w0baqefaAocaq8amiibcgkcaqeamdb9e2q41olc0zdtsno2ik4khvmumkv98n1y0
FehuccfuiuiuuiuiuuiuiuuicfhdyeytrytryuytytyfyfyfytrytryTryTrytrytryTrytdybq3xatuaej
qgr0zfay6rsu ++ gqgf8zrpjjd+o3acqrzt4zt8d7uhye6ctgcv3kqed5i2dtspodizwey8reyshjmdcvulrjydp "
UWJ5PRHFKWY7EC0ZNGGTOPMLBYXIPRX0Q/obs9TlLAS785XJMNWJUBYYJC6V5JUQ+TRYHWA28TWM/L6/EICYNBZE
fwx8oHqsbflt0dnsrhq9exx0udmmbddd0zwoktx+wb7itg0hppvqne8jwkexqidaqab \;

10. DMARC Record

O registro DMARC funciona apenas se houver SPF e Skim Records adequados. É uma política de seu processo de autenticação por correio e como o servidor receptor deve lidar com o correio se isso violar a política. Quando um e -mail recebido vem no servidor remoto, ele consultará seu registro DMARC e verifique se eles consultam as perguntas abaixo

> São os e -mails que os e -mails dkim assinam os adequados ?
> A mensagem veio de um nome de host IP/servidor autorizado, conforme mencionado pelo registro SPF.
> Se o cabeçalho dos e -mails recebidos tem alinhamento no PRPoper conforme o RFC 5322.

Entrada de amostra

_dmarc.domínio.com. Em txt "v = dmarc1 \; p = nenhum \; rua = correio: [email protected] \;
RUF = Mailto: [email protected] \; pct = 100 "

_dmarc.domínio.com: Subdomínio que é configurado para autenticação de DMARC sozinho.

v = dMarc1: Versão dmarc em uso.

p = nenhum: menciona o tratamento preferido da política

Rua =Mailto: [email protected] : Relatórios aggregados são enviados para este

ruf =Mailto: [email protected] : Relatórios Forencsic devem ser enviados para esta conta de email

PCT = 100: Esta é a porcentagem de e -mails que o proprietário deseja ter o registro verificado e usado para atualizações de política

DMARC/SPF/DKIM é todo necessário para uma autenticação adequada para serviços de correio

11. Registro de ptr (ponteiro)

Os registros PTR também são conhecidos como DNs reversos para o IP. Os registros da PTR são normalmente configurados no nível do provedor de hospedagem ou do provedor de servidores. Os registros da PTR nos ajudam a combinar um endereço IP com um domínio ou um subdomínio (normalmente para um nome de domínio totalmente qualificado do FQDN) que ajudará a funcionar as consultas DNS reversas para funcionar corretamente.

Portanto, como pré -requisito para definir DNS reverso para um IP, agora um dia de hospedagem / provedores de servidores pede primeiro para configurar um registro para o domínio / subdomínio para esse IP e, uma vez feito, o data center configurará os RDNs (DNS reverso registro).

12.Registro cname (nome canônico)

O CNAME Register ajuda a apontar um domínio ou subdomínio para outro domínio ou subdomínio.

Entrada de amostra:
NewDomain.com 14400 no domínio CNAME.com.
Correio 14400 no CNAME Mail.domínio.com.

Exemplo 1, está apontando o newdomain.com o domínio.com onde o segundo exemplo está apontando correio.NewDomain.com enviar.domínio.com. Com esses registros, quando um pedido chega ao NewDomain.com, ele encontrará um registro CNAME para o domínio.com. Depois disso, começará uma nova pesquisa para o domínio.com e ele enviará a solicitação ao domínio.com e o mesmo é o caso do segundo registro também.

13.Registro SRV (serviço)

O registro SRV nos ajuda a apontar para um serviço específico que está em execução em seu domínio ou subdomínio para um domínio de destino. Isso nos ajuda a direcionar o tráfego para serviços específicos, como servidor de bate -papo ou serviços de mensagens para o servidor ANOTHR.

Entrada de amostra:

_SIPFEDERATRLS._tcp. 3600 em SRV 100 1 5061 Sipfed.on-line.Lync.com.
_serviço._protocolo.exemplo.com 3600 em SRV 10 0 5060 Serviço.exemplo.com
_serviço._proto.nome. TTL Classe SRV Prioridade de peso alvo.

Serviço : O nome dos serviços deve ser iniciado com um sublinhado “_” e será seguido por um “.”Serviço pode ser qualquer coisa como _Chat, _xmpp, _sipfederationTls (que é usado para servidores do Microsoft Exchange) etc.

Protocolo:O nome do protocolo também deve estar começando com um sublinhado e depois um “.”Nesse caso, é“ _tcp.”E nos diz que é um protocolo TCP que está em uso.

Nome : Nome ou nome de domínio é o domínio que receberá o tráfego original para este serviço.

Prioridade : É o primeiro número mencionado nos exemplos acima (100 e 10, respectivamente) ajuda a definir a prioridade para o servidor de destino e menor número significa maior prioridade. Isso é semelhante à prioridade do registro do MX e funciona da mesma forma que podemos configurar outro recorde como recolocar também com outra prioridade.

Peso : Se criarmos registros semelhantes com a mesma prioridade, o fator decisivo será esse valor específico. O peso é 1 e 0, respectivamente, nos exemplos acima.

Porto: Isso mostra a porta TCP ou UDP na qual o serviço está em execução.

Alvo : Este é o subdomínio ou domínio alvo para o qual esse serviço será redirecionado e deve ter um registro válido de A / AAAA para que esse tráfego seja redirecionado para lá.

14. RP (Pessoa Responsável) Registro

Normalmente, isso não é necessário hoje em dia, pois há um endereço de e -mail associado ao registro SOA. Mas se algum domínio desejar ter precisar mencionar especificamente, além da conta de e -mail de registro SOA padrão, podemos adicionar um registro de RP.

15. DNSKEY RECORD

O DNSKEY RECORD contém uma chave pública que será usada pelos resolvedores para verificar as assinaturas do DNSSEC.

Entrada de amostra

domínio.com. 300 em Dnskey 257 3 5 z10wdrihgjggiugiugkuoikhpoupysyrsyrdfytpopo
ipoeUofzcndfn2AVD ==
Nome TTL Classe RRTYPE FAGNS_FILE

Nome : é o nome de domínio ou nome de host normalmente

EM : Representar a classe de registro e o padrão está dentro (o que significa internet)

Tipo de registro: Tipo de registro é o tipo de registro e, neste caso, será DNSKEY

Bandeiras : Flags arquivados está em um formato com fio, que é um personagem de 2 bytes. Os valores possíveis são 0, 256 e 257. Se o valor for 256, significa que o DNSKey Record detém o ZSK (chave de sinalização da zona) paga e se o valor for 257, ele contém KSK (componente-chave de assinatura da chave. Em suma.

Protocolo: Isso sempre tem um valor de 3, para DNSSEC.

Chave pública : Public Key é os dados principais e, neste caso, é “Z10WDRIHGJGGIUGIUGKUOIKHPOUPTYRYRSYRSDYTFYTPOPOIPOOOFZCNDFN2AVD ==”

Algoritmo: Nos ajuda a identificar public_keys usando algoritmos diferentes e abaixo são os mais utilizados

• 1 = rsa/md5
• 2 = Diffie-Hellman (isso não é suportado por Bind)
• 3 = DSA
• 4 = reservado
• 5 = rsa/sha1
• 6 = dsa/sha1/nsec3
• 7 = rsa/sha1/nsec3
• 8 = RSA/SHA-256
• 10 = RSA/SHA-512

Conclusão

Espero que isso realmente ajude todos vocês a entender o DNS e garantir que sua hospedagem esteja configurada corretamente.