Será que agora vou saber o que estou fazendo quando crio aquela entrada TXT, ou CNAME quando sigo um procedimento?

Se você está lendo esse nosso primeiro artigo, deve estar com aquela pulga atrás da orelha, aquele sentimento de:

“Será que agora vou saber o que estou fazendo quando crio aquela entrada TXT, ou CNAME quando sigo um procedimento?”.

Fique tranquilo, após a leitura, terá todos os conceitos práticos necessários para saber exatamente o que está fazendo quando tiver que realizar qualquer mudança no DNS.

E provavelmente você deve ter tido aula (ou apenas passou na prova) em seu curso técnico ou universitário, mas na hora de pôr a mão na massa no DNS, prefere pedir para alguém ou seguir aquela ‘receitinha’. Vamos acabar com isso hoje!

Todos que estão lendo devem saber para que serve DNS: traduzir nome para IP, para que usemos nomes e não IP em uma aplicação como browser, shell, cliente de e-mail ou qualquer outro software. Você verá que é muito mais que isso.

E muitos devem ter visto (na apresentação do professor) o desenho abaixo:

Esqueça ele, por enquanto. Provavelmente você nunca terá que se preocupar com esse conceito, para 99% dos profissionais de TI são dispensáveis, mesmo sendo o único que todo professor ensina =D!

Primeiro, é importante entender a realidade em que o DNS foi feito e quais problemas ele tenta resolver. Abaixo uma lista de verdades que explicam muita coisa:

  • DNS foi criado na década de 1980, quando os recursos computacionais eram muito mais limitados que hoje;
  • Foi criado para o controle ser centralizado;
  • E a carga maior ser descentralizada.

O segundo conceito, importante, é:

Existem dois tipos de servidores DNS:

  1. O que todos usam sempre, o DNS ‘Resolver’ e
  2. O que temos medo de mexer, o ‘SOA’.

O Servidor Resolver (do inglês “Resolvedor”) é aquele que configuramos em nossa placa de rede (ou recebemos via DHCP). Usamos para resolver/consultar nomes DNS de qualquer domínio, para que possamos navegar na Internet ou fazer uso das nossas aplicações. Subir um servidor DNS é muito simples, o roteador WIFI que temos em casa quase sempre faz essa função de servidor DNS para nós. A nossa operadora sempre nos oferece ao menos 2 servidores DNS de consulta, para nosso uso da Internet contratada.

Quando configuramos um Servidor Resolver?

  • No roteador da nossa casa;
  • Quando vamos compartilhar Internet em nossas impressoras (isso pode inclusive ajudar no desempenho quando fazemos cache, pois evita consulta na Internet de requisições repetidas).

Já os servidores SOA são os servidores responsáveis por responder para Internet (para os servidores de Resolver) cada nome de nosso domínio para IPs. Por exemplo, o domínio darede.com.br que temos registrado para nosso uso, precisa de servidores SOA, também ao menos dois, para que possamos apontar entradas DNS como www, mail, smtp, etc, para os IPs onde essas aplicações rodam.

Mas por que sempre ao menos dois? Nem vou responder

Nosso servidor DNS de consulta pode verificar algum outro DNS de consulta, como os do provedor, ou resolver diretamente usando o protocolo WHOIS.

Esse ai (WHOIS) foi outro que dá aquela dor no estômago quando vê né? Saaaabe o que é…. mas não sabe explicar? 😉

WHOIS é um protocolo utilizado principalmente para: “Informar aos servidores DNS Resolvers quem são os SOA de determinado domínio”. Aqui vem a sacada do DNS. Existem bilhares de entradas nos milhares de SOA, a IANA que controla a internet precisa apenas ter o controle de qual SOA reponde por cada domínio, enquanto nós ficamos responsáveis pelo SOA e suas centenas de entradas.

Muitos devem conhecer, mas usando serviços como os abaixo, conseguimos saber quem (who is) o servidor SOA do domínio xpto.com.br, além de outras informações do mantenedor do domínio:

Uma vez que o Servidor Resolver sabe quem manda no domínio (xpto.com.br), ele faz a consulta diretamente para o SOA. E agora a pergunta é: “Eu sei que você manda no domínio xpto.com.br. Quem é o www?”

Então, o fluxo de uma consulta DNS no dia a dia da Internet fica o seguinte:

  • Cliente pergunta a seu servidor DNS Resolver: “Qual IP de www.darede.com.br?”
  • Servidor DNS Resolver 1, que tem encaminhamento para outro Servidor DNS Resolver (2), pergunta: “Qual IP de www.darede.com.br?”
  • Servidor DNS Resolver 2, que não faz encaminhamento, utiliza o protocolo WHOIS para questionar: “Quem é o SOA de darede.com.br?”
  • Com os IPs do SOA, o Servidor DNS Resolver 2 pergunta à um dos SOAs: Eu sei que você é SOA de darede.com.br, qual o IP de www?”
  • Agora que o Servidor DNS Resolver 2 sabe o IP de www.darede.com.br, ele informa o cliente (ou ao Servidor DNS Resolver 1) qual é o IP e pode ou não configurar para cachear esse nome”

Registrar: O Registrar é o órgão responsável por manter a concessão dos domínios usados na Internet. É ele quem configura o WHOIS Server de modo que os servidores DNS Resolvers possam ‘descobrir’ os SOAs de cada domínio.

No Brasil, possuímos apenas um registrar, o registro.br, é nele que registramos o domínio para podermos usá-lo. Em outros países podem existir diversos Registrars, nos EUA, por exemplo, os provedores de hospedagem de sites são os próprios registrar. Já por aqui, no Brasil, os provedores de hospedagem de site fazem apenas o papel de SOA, servidor de e-mail, servidor de páginas web, etc.

Agora que entendemos o fluxo das consultas DNS na Internet, sabemos que funciona assim, como abaixo:

  • Os clientes consultam seu DNS Resolver procurando pelo IP de www.xpto.com.br;
  • O WHOIS mantém os SOAs que respondem para cada domínio;
  • O SOA mantém a tabela de nomes e IPs do domínio xpto.com.br;
  • Os Servidores DNS Resolvers consultam WHOIS (Quem é) SOA de xpto.com.br;
  • Os Servidores DNS Resolvers consultam ao SOA qual o IP de www.xpto.com.br;
  • Cliente faz a requisição (HTTP, POP, SMTP, etc) ao IP de www.xpto.com.br

Até então, falamos apenas de solução de nomes para IP, mas não existe apenas esse tipo de resposta. Essa é a principal função do DNS, porém, não é a única.

Fique ligado porque no próximo artigo vamos entender as entradas DNS que podem ser utilizadas e quando utilizamos 😉

foto-flavio-rescia-dias
Flavio Rescia Dias
CTO & Co-Fundador da Darede


flavio.rescia@darede.com.br

Atuando desde 2006 no mercado de tecnologia, Flávio Rescia é um dos fundadores da Darede, empresa de consultoria de serviços de TI, na qual atua como CTO. Ele possui diversas especializações no setor, sendo a última a Certificação AWS Solutions Architect – Professional.

OUTRAS PUBLICAÇÕES

Arquitetura Docker

Por Thiago Marques O pai ta on!! Até agora entendemos o que é um container, como o Docker funciona sob esse modelo e como utilizar

Nós usamos cookies para garantir e oferecer a melhor experiência de navegação em nosso site! Mais informações