Confira a segunda parte do artigo sobre DNS. Escrito por Flávio Rescia. DNS, você sabe o que é, mas sempre tem dúvidas quando precisa hospedar uma aplicação? Até então falamos apenas de solução de nomes para IP, porém não existe apenas esse tipo de resposta, essa é a principal função do DNS, porém não é a única. Agora vamos entender as entradas DNS que podem ser utilizadas e quando utilizamos: Entrada Tipo A É a que falamos até agora, serve para resolver um nome como www.xpto.com.br para um IP como 200.200.200.1 Entrada do Tipo CNAME Para facilitar a configuração são usadas entradas CNAME (do inglês Canonical Name, Apelido), que são entradas que apontam nomes DNS como www.xpto.com.br para outro nome como www.darede.com.br. (Ferrou, agora babei!) A sacada aqui é evitar a necessidade de mudar o DNS de www.xpto.com.br sempre que o IP mudar. Imagina que o site www.xpto.com.br esteja no mesmo servidor que o www.darede.com.br que aponta para 200.1.1.1, caso tenhamos que mudar nosso provedor e trocar o IP 200.1.1.1 para outro IP, como 202.1.1.1, precisaremos trocar apenas a entrada www.darede.com.br e não o www.xpto.com.br. Uma vez que www.xpto.com.br continuará apontando para www.darede.com.br. Parece bobagem? Imagina que você tenha 1000 sites apontando para www.darede.com.br e mude a operadora ! A desvantagem no uso de CNAME é que será necessário o cliente resolver duas vezes: • www.xpto.com.br > www.darede.com.br • www.darede.com.br > 200.1.1.1 Entradas CNAME hoje são muito utilizadas por serviços gerenciados (como AWS CloudFront, AWS ELB), uma vez que o serviço lhe oferece um nome e você cria um CNAME de seu domínio (como www.darede.com.br) e aponta para o nome oferecido pelo provedor do serviço. Caso os IPs da AWS mudem, nós não precisamos nos preocupar. DICA: De acordo com a RFC não é possível criar entradas do tipo CNAME para ‘naked domain’ (exemplo darede.com.br). Nesse caso temos que configurar uma entrada ‘A’ direto para o IP. Quando precisamos apontar o ‘naked domain’ para um serviço gerenciado (que não há IP fixo), temos duas opções: 1. Apontar para um servidor (esse sim com um IP fixo), e fazer um redirecionamento HTTP 301 para ele; 2. Para AWS, podemos usar uma entrada A com Alias. Alias é um recurso da AWS para criar entradas ‘A’ para serviços gerenciados AWS (como Elastic LoadBalancer, S3, CloudFront, API Gateway, etc). O AWS Route53 garante que a entrada sempre aponte para os IPs atuais do serviço gerenciado. Entrada Tipo MX Um e-mail é enviado para voce@seudominio.com.br certo? Qual o nome DNS do seu servidor de RECEBIMENTO de e-mails? seudominio.com.br? NÃO. Geralmente seudominio.com.br aponta para seu site e não para seu servidor de recebimento de e-mail. E agora? Para isso existe a entrada do tipo MX, que vem de Mail eXchange (também acho bizarro devia ser ME, kk!). O MX aponta para nossos servidores de recebimento de e-mails (SMTP/S). Esse tipo de entrada pode apontar tanto para IP quanto para nomes, e possui uma particularidade, cada entrada possui dois valores: • Nome ou IP do servidor de recebimento de e-mail; • Prioridade, que é usada para redundância de servidores; Entradas do tipo TXT Para muitos serviços que surgiram anos após a primeira versão do protocolo HYPERLINK “https://www.ietf.org/rfc/rfc1034.txt”DNSs era preciso validar se um domínio é mesmo de propriedade de determinada pessoa/empresa. Como fazer isso? Simples, lhe faço um desafio ao mantenedor do domínio. Crio um código de teste (como 123codigo) e peço para o mantenedor configurar uma entrada 123codigo.dominio.com.br, se essa entrada for criada, significa que realmente ele tem acesso ao SOA, logo posso confiar que ele é responsável por esse domínio. Mas criar uma entrada ‘perdida’ para isso, parece uma gambiarra né? Como tudo em tecnologia que parece gambiara vira padrão. As entradas do tipo TXT surgiram para isso. É possível atribuir um texto qualquer (não apenas um nome ou IP) a essa entrada, que funciona como uma variável para qualquer finalidade. O SPF que surgiu anos depois, é um exemplo de utilização de entrada TXT. Como o serviço de e-mail, que foi criado HYPERLINK “https://tools.ietf.org/html/rfc821” à HYPERLINK “https://tools.ietf.org/html/rfc821” HYPERLINK “https://tools.ietf.org/html/rfc821″décadas atrás, não possuía uma validação da origem do e-mail, qualquer um podia (e ainda pode) enviar e-mails em nome qualquer domínio. O SPF surgiu como um padrão para garantir o dono do domínio de origem possa informar ao servidor de recebimento (destino) os IPs que podem enviar e-mail em nome de @dominiodeorigem.com.br. Para isso era/é usada uma entrada TXT. Em 2014 foi criado um outro tipo de entrada DNS dedicada a SPF. Um uso típico de entradas TXT é a validação de serviços cloud, como Google, AWS e Azure se você pode mesmo usar seu domínio. Entrada Tipo PTR É o contrário de entradas do Tipo ‘A’, usada para apontar um IP (200.1.1.1) para um nome (www.xpto.com.br). Essa entrada causa muita confusão, uma vez que ela só pode ser usada pelo mantenedor do IP e não do domínio. Em geral o mantenedor do IP é o provedor de seu Link de Internet ou serviço na nuvem. Assim somente o provedor poderá configurar o reverso de seu IP, caso precise, a única forma é abrir um chamado com eles. Os usos práticos desse tipo de entrada são poucos, mas importantes: • Identificação em caso de testes como traceroute por exemplo: • Velocidade de algumas aplicações, como SSH e traceroute, uma vez que essas aplicações, de forma nativa, resolve o Reverso do IP, o que causa lentidão quando a entrada não existe por ficar tentando resolver; • Controle SPAM, novamente o e-mail kkk! Como o SMTP foi inventado antes da invenção do SPAM, ele não previu seu uso, uma das técnicas para evitar SPAM é garantir que haja um vínculo entre o mantenedor do IP e seu utilizador, a técnica é simples. Se você está em uma LAN House, não vai conseguir pedir para configurar o reverso nele, então o servidor SMTP de recebimento espera que o IP aponte para um nome, e que esse nome aponte para o próprio IP. Caso isso não aconteça, o