sábado, 19 de novembro de 2016

Tutorial DNS - Parte 3 - Resource records

A segunda parte desta série apresentou alguns detalhes mais técnicos sobre a mecânica do serviço de DNS. Para completar vamos entender os tipos de registros DNS e suas aplicações.

Resourse records

O serviço de DNS é composto por um conjunto de tipos de registros chamados "Resourse records". Cada um possui um código numérico que é transmitido no cabeçalho do pacote DNS. Um usuário ou um recursivo fazendo uma pesquisa pode querer saber vários tipos de informações diferentes sobre um host ou uma zona, como por exemplo seu endereço IPv6, IPv4, ou quem é o autoritativo daquela zona.
Outro exemplo didático são os servidores de email. Quando enviamos um email para ´"fulano@blogger.com" o nome do endereço de email sugere um usuário "fulano" dentro de um domínio. Você poderia pensar, a princípio, que a mensagem seria enviada ao servidor "blogger.com" ou algo do tipo, mas na grande maioria das vezes não é nem de longe assim. É necessário perguntar para o dono(servidor autoritativo) da zona "blogger.com" quem é o "Mail exchanger"(servidor de email) daquela zona. Este "Mail exchanger" quase sempre é um servidor completamente fora daquela zona, que pode ser hospedado em outro grupo de serviços na Internet.
Vejamos os principais tipos de registros DNS:

SOA - ID 6

SOA significa "start of authority". É o cabeçalho principal de uma zona. Nele é informado o servidor autoritativo primário da zona, email de contato do administrador e informações de tempo de vida aplicável nas pesquisas.

A e AAAA - IDs 1 e 28 - Endereço IPv4 e IPv6

Estes são os registros principais do sistema. Um registro tipo A informa o(s) endereço(s) IPv4 do host, da mesma maneira o AAAA(quad A) para IPv6. O DNS é sempre comparado à um catálogo telefônico, você pesquisa por um nome e ele informa seu endereço numérico. Este procedimento é feito exatamente usando os registros tipo A e AAAA. Veja o exemplo abaixo:
Zona: empresa.com.br.
www A 192.0.2.50     #End. IPv4 do host "www.empresa.com.br"
www AAAA 2001:db8:faca::50   #End. IPv6 de "www.empresa.com.br"
mail A 192.0.2.82     #End. IPv4 de "mail.empresa.com.br"
mail AAAA 2001:db8:faca::82  #End. IPv6 de"mail.empresa.com.br"
smtp CNAME mail.empresa.com.br. #"smtp.empresa.com.br" é um apelido do host "mail.empresa.com.br"

CANAME - ID 5 - Alias, apelido, alcunha

É possível dar apelidos à hosts no DNS. Por exemplo posso dizer que "smtp.exemplo.com" é um apelido para o host "email.exemplo.com.br" sem problema algum. O primeiro é apenas um alias para um outro host que não necessariamente está na mesma zona DNS. Você diz qual o apelido e à quem ele pertence indicando o seu FQDN. Veja o exemplo do Gmail:
O host "www.gmail.com" na verdade é um alias para "googlemail.l.google.com". Repare que são domínios diferentes.

MX - ID 15 - Mail exchanger ou servidor de email

Um outro registro importante é o MX, que indica os servidores de email que respondem por determinada zona. Naturalmente isto dá uma camada de flexibilidade na estrutura DNS, o seu servidor de email não precisa nem mesmo ser um host na sua estrutura, pode ser totalmente terceirizado. Por exemplo quando enviamos um email para "fulano@globo.com", para que a mensagem seja entregue, o remetente pergunta quem é o servidor de email responsável pelo domínio "globo.com", que na verdade são servidores da locaweb. Veja:

NS - ID 2 - Name Server

Este registro indica quem é o NS(Servidor de nomes) responsável pela zona. Quando você registra um domínio ".br", por exemplo, e indica os seus servidores DNS autoritativos, o que acontece é que no arquivo da zona ".br" os seus servidores são registrados como NS da sua zona. Veja mais um teste com o nslookup perguntando à um servidor da zona ".br" sobre o NS de "planalto.gov.br":
Estes são os "donos" da zona "planalto.gov.br", e seus respectivos endereços IP são dados como GLUE records.

Você pode ver uma lista detalhada dos resourse records no artigo da Wikipedia.

A ferramenta NSlookup

Como vê nas imagens acima, você pode sempre fazer os testes usando o comando NSLOOKUP e especificando o tipo de record que deseja, com a seguinte sintaxe:

nslookup -type="Tipo de registro" "nome do host/Domínio" [Servidor DNS]

Repare que o ultimo parâmetro é opcional. Se você não especificar qual servidor DNS vai perguntar será usado o indicado na configuração do computador.
Exemplo, vamos perguntar para o servidor autoritativo da zona ".COM.BR" quem são os autoritativos da sub-zona "GLOBO.COM.BR":
 
 Ele me devolve os nomes dos servidores e seus respectivos endereços IP(Glue Records).
Em outro exemplo pergunto ao servidor do OpenDNS qual é o endereço IPv6 de "www.facebook.com.br".

Novamente temos um caso de alias. O nome solicitado é um apelido do host de FQDN "star-mini.c10r.facebook.com".
O NSLOOKUP é nativo em Windows e Linux. Existem também os comandos "host" e "dig", nativos no pinguim.

Transição para o IPv6 - Happy eyeballs e DNS64

Como vivemos numa época de transição para o novo protocolo algumas coisas devem ser feitas para amenizar o choque. Uma delas é o algorítimo "Happy eyeballs". Quando um cliente solicita o endereço IP de um host e recebe ambos endereços(IPv4 e IPv6), e este host também tiver conectividade IPv4 e IPv6(dual stack), o algorítimo vai determinar qual conexão é mais vantajosa, para o cliente obter uma melhor experiência.
Por outro lado temos o DNS64, que é um serviço para usuários exclusivos de IPv6 se comunicarem com hosts IPv4, usado em conjunto com o NAT64. Veja este vídeo. Basicamente o que ele faz é gerar endereços IPv6 no formato do NAT64(prefixo 64:ff9b::/96) para hosts que tenham apenas endereços IPv4. A segunda parte do processo é feita pelo gateway NAT64, deixando tudo transparente para os clientes IPv6. Esta técnica já é amplamente usada em operadoras móveis fora do Brasil, onde a escassez de IPv4 é bem maior. O Google também oferece um serviço de DNS64 público, veja aqui.


Faltou falar sobre registros PTR para resoluções reversas. Esta parte merece um outro texto mais completo apenas sobre DNS reverso. Fica para uma outra oportunidade.

domingo, 6 de novembro de 2016

Tutorial DNS - Parte 2 - Detalhes mais técnicos

Na primeira parte deste tutorial falei sobre os fundamentos básicos do serviço de DNS. Os servidores podem ser autoritativos, sendo "donos" de uma ou mais zonas, e/ou recursivos, respondendo consultas por domínios diversos.Na sequência temos mais alguns detalhes do seu funcionamento.

GLUE Records

Quando um servidor recursivo está fazendo uma consulta ele pode se deparar com um pequeno problema. Tomemos o exemplo em que o usuário quer saber o endereço IP de "joaolucasmacedo.blogspot.com.br". Se ele já não tem este registro salvo em cache ele vai começar a pesquisa perguntando à algum servidor raiz pelo nome. Como eles não podem responder diretamente pela zona "blogspot.com.br" vão indicar pelo menos os servidores responsáveis pela zona ".br", que são "A.dns.br", "B.dns.br", "C.dns.br", até o "E.dns.br". Em seguida o recursivo vai perguntar à um destes pela zona blogspot.com.br.
Mas existe um pequeno detalhe. Qual o endereço IP de "A.dns.br" por exemplo? Para continuar a pesquisa ele terá que fazer outra pesquisa pelo nome "A.dns.br", para saber seu endereço IP, para conseguir perguntar sobre a zona "blogspot.com.br". Então ele perguntará ao root sobre "A.dns.br", e receberá a mesma resposta:
 - Olha, eu não sei quem é "A.dns.br", mas pergunte ao dono da zona ".br", que é "A.dns.br".

Vejamos um possível "diálogo" entre eles:
Recursivo: Quem é "joaolucasmacedo.blogspot.com.br?
Root server: Não sei, mas pergunte ao dono da zona ".br". É o "A.dns.br".
Recursivo: Quem é "A.dns.br"?
Root server: Não sei, mas pergunte ao dono da zona ".br". É o "A.dns.br".
Recursivo: Quem é "A.dns.br"?
Root server: Não sei, mas pergunte ao dono da zona ".br". É o "A.dns.br".
( ... )
 O processo não teria fim. Você não sabe o endereço IP de um servidor de uma zona, e este servidor é um host dentro da própria zona, à exemplo de A.dns.br, que é um host dentro da própria zona em que ele tem autoridade.
Por isso quando uma sub-zona é delegada à um outro servidor também devem ser registrados os seus endereços IP. Cada servidor autoritativo, quando informa sobre outro servidor de nomes autoritativo de uma zona abaixo dele, já responde com o nome do dito cujo e seu respectivo endereço IP.
 - Olha, não sei que é "joaolucasmacedo.blogspot.com.br", mas pergunte ao dono da zona ".br". É o "A.dns.br" que tem o IP 200.160.0.10 .
Isto é chamado de GLUE record. Sem este detalhe o processo seria impossível. Por isso mesmo os servidores já devem saber "de fábrica" os endereços IP dos root servers.

Você pose simular uma pesquisa recursiva usando o comando NSLOOKUP, percorrendo a árvore de domínios e encontrando os servidores autoritativos de cada sub-zona.
Exemplo:  nslookup joaolucasmacedo.blogspot.com.br j.root-servers.net
Perguntando ao root server J sobre "joaolucasmacedo.blogspot.com.br"
Naturalmente ele não me dá a resposta, mas uma dica("Saved by"), informando os servidores da zona ".br" e seus respectivos endereços IP(GLUE records). Em seguida você pode fazer a pergunta para qualquer um dos servidores indicados:
nslookup joaolucasmacedo.blogspot.com.br a.dns.br
Perguntando à "a.dns.br" sobre "joaolucasmacedo.blogspot.com.br"
Da mesma maneira ele não me responde diretamente mas dá a dica para os donos da zona.
"Olha, segundo meus registros, esta zona "blogspot.com.br" é dos servidores abaixo. Pergunte à eles .'-)."
Repare que não há GLUES neste caso, já que a zona dos servidores indicados está fora do escopo da zona dos servidores ".br". Estes serão informados pelos servidores da zona ".com". Caso necessário outra pesquisa análoga será feita até descobrir os endereços IP dos servidores do Google informados na figura acima.
Por fim, agora que sabemos quem é a autoridade máxima da zona "blogspot.com.br", podemos perguntar diretamente à ele o endereço IP de "joaolucasmacedo.blogspot.com.br". Escolha qualquer um dos servidores indicados e execute o comando:
nslookup joaolucasmacedo.blogspot.com.br ns3.google.com
Veja que temos algumas informações interessantes. Ele informa 2 endereços, um IPv6 e outro IPv4. E ainda, que na verdade, "joaolucasmacedo.blogspot.com.br" é um ALIAS(apelido, codinome, alcunha) para o host "blogspot.l.googleusercontent.com". Os detalhes dos tipos de registros serão explicados nos próximos artigos.

A porta 53

Como vimos, o serviço de DNS é extremamente simples, mas gera várias requisições recursivamente gerando um tráfego considerável. Por isso o sistema é distribuído em várias camadas e utilizamos servidores fazendo cache. É mais inteligente que as solicitações sejam feitas por pacotes UDP para agilizar o processo. Cada solicitação DNS é feita saindo de uma porta qualquer(acima de 1023) direcionada à porta 53/UDP do servidor. Naturalmente, servidor responde com pacotes originados na porta 53 destinados à porta de origem do cliente. Se a resposta do servidor ultrapassar o tamanho de um pacote UDP, um flag no cabeçalho DNS é definido para que o cliente saiba que é uma resposta truncada, e que vem mais pela frente.
A porta 53/TCP também é usada, mas geralmente entre servidores DNS para sincronizar as informações de zonas. Por exemplo um servidor mestre atualizando os registros no escravo.
Outra alternativa, não muito comum, é usar conexões TCP para consultas de clientes. Acaba não sendo muito utilizado na prática por consumir ainda mais recursos do servidor, mas é uma coisa que vem sendo repensada ultimamente porque as respostas com endereços IPv6 tornam-se maiores, como aquelas usando DNS-SEC, que vêm com chaves de segurança.
É comum os administradores de rede bloquearem a saída de pacotes à porta 53 para impedir que os clientes da rede usem outros servidores que não os desejados. Da mesma forma filtrarem tráfego na porta 53/TCP para impedir sincronização entre servidores DNS que não os da estrutura da empresa.

Servidores Master e Slave

 Você deve ter reparado que para cada zona existem vários servidores autoritativos. Um deles é tido como "Master" e outro(s) como "Slave"(escravo). As zonas são declaradas e configuradas normalmente em um servidor mestre, em seguida a declaração é feita nos escravos. Os escravos são informados de que, nesta condição, a configuração é obtida do servidor mestre para cada zona que ele atua como slave. Cada alteração feita é sincronizada entre eles para garantir redundância e balanceamento. Esta operação é feita na porta 53/TCP. Sendo slave o servidor precisa apenas ser informado do endereço IP do seu mestre, e para quem faz solicitações à ele as respostas são dadas normalmente de forma autoritativa.
Veja um trecho o arquivo de configuração do Bind de um servidor slave:
zone "examplo.com.br" { 
 type slave; 
 masters { 198.51.100.1; }; 
};
A zona é declarada com o endereço IP do servidor meste.

Zonas reversas

Outra funcionalidade do serviço de DNS é fazer o inverso, traduzir endereços IP para nomes de domínio. Se o cliente já sabe o endereço IP, mas quer ter certeza de que determinado nome está associado àquele endereço pode fazer a pesquisa reversa. Isto é de suma importância para servidores de email por exemplo. Se ele recebe um email do servidor de endereço IP 192.0.2.55 dizendo ser uma mensagem de "obama@whitehouse.gov", ele precisa ter certeza de que este endereço IP realmente pertence ao servidor de email do domínio "whitehouse.gov", caso contrário a mensagem é caracterizada como SPAM.
Primeiramente o endereço IP é colocado de forma invertida e adicionado a zona "in-addr.arpa", assim: "55.2.0.192.in-addr.arpa".
Esta zona "in-addr.arpa" é especial e específica pare resoluções reversas. A pesquisa é feita da mesma maneira que uma pesquisa normal.
Se as zonas dos nomes de domínio são delegadas a partir dos servidores raiz, os endereços IP são delegados a partir dos registros regionais de internet(RIRs). Cada bloco de endereços IP é atribuído à um registro(como o Lacnic), os registros regionais atribuem sub-blocos à empresas(sistemas autônomos) ou à registros nacionais, como o Nic.br. Por exemplo o endereço IP 200.160.0.10, que é do servidor "A.dns.br", é derivado do bloco 200. Então a zona "200.in-addr.arpa" é delegada aos servidores reversos do Lacnic.
Para tirar a prova pergunte à um root server sobre o servidor de nomes(NS) da zona "in-addr.arpa":
nslookup -type=NS in-addr.arpa a.root-servers.net
Tendo agora os endereços dos servidores raiz da zona reversa("in-addr.arpa") podemos perguntar à eles sobre o autoritativo da zona "200.in-addr.arpa", e ao responsável desta zona qual é o autoritativo da zona "160.200.in-addr.arpa", e assim por diante até chegar no servidor reverso que contém a informação direta do host solicitado e seu endereço IP. Tudo depende de que os sistemas autônomos responsáveis por determinados blocos de endereços IP deleguem aos servidores DNS recursivos as zonas reversas adequadamente.
A tarefa de "amarrar" cada bloco de endereços IP aos usuários dele, e cada endereço à um host dentro da sua rede é bem cuidadosa e foge do escopo deste artigo. Não é necessário alongar muito mais por aqui. Primeiro porque os blocos de endereços IPv4 são extremamente fragmentados, o que pode causar confusão. Em segundo lugar, nem todos os endereços IP são mapeados com nomes DNS. Seria uma tarefa irracional e desnecessária, sem falar sobre os endereços IPv6 que são virtualmente infinitos. A zona reversa para IPv6 é a "ip6.arpa".
Abaixo apresento uma figura com 2 consultas DNS reversas sobre o host "a.dns.br":
Para consultas do tipo reversa você pode usar o parâmetro "-type=PTR" seguida do nome em zona reversa.
E ainda outra imagem com a consulta reversa para o IPv6 do mesmo host:

Caso não tenha ficado claro para você, apresento o esquema de forma enumerada usando o primeiro exemplo do endereço IP 192.0.2.55:
1) O DNS recursivo inverte o IP e adiciona o sufixo ".in-addr.arpa", tornando 192.0.2.55 em "55.2.0.192.in-addr.arpa".
2) O DNS recursivo solicita à um root server o registro reverso(PTR).
O root server envia o endereço do autoritativo de conta da zona do bloco classe A 192("192.in-addr.arpa"). Geralmente o DNS de um RIR(Registro Internet regional).
3) o DNS recursivo pergunta ao DNS do RIR pele registro reverso "55.2.0.192.in-addr.arpa". O servidor do RIR vai enviar os dados do autoritativo da organização que recebeu os sub-blocos. Geralmente o provedor de acesso ou conteúdo.
4) O DNS recursivo pergunta ao servidor do provedor pelo registro PTR de "55.2.0.192.in-addr.arpa".
O servidor do provedor vai finalmente informar o nome. Ou então, caso os IPs estiverem alocados para um cliente, informará os servidores DNS reversos deste cliente.
5) Finalmente o DNS recursivo pergunta ao servidor DNS da organização sobre o nome de "55.2.0.192.in-addr.arpa". Então o servidor da organização responsável pelo bloco de endereços IP responde com o nome adequado.

O Whois

Whois é um serviço complementar ao DNS que fornece informações de contato sobre domínios registrados na Internet. Ele trabalha similar ao DNS, mas na porta 43, e com uma hierarquia de servidores começando pela IANA. O serviço de whois serve para que saibamos quem, ou qual empresa, registou determinado domínio e quais as informações para entrarem em contato com eles, e ainda os servidores DNS autoritativos da zona. Você pode usar o serviço de whois via web em algum site que o ofereça, como no Registro.br, ou mesmo executando o comando whois no Linux. No Windows não há comando nativo, mas podemos usar o executável do Sysinternals Suite, disponível aqui:
Ele informa a empresa responsável pelo domínio e informações de contato como email do administrador, servidores DNS e até o CNPJ.
Muito se discute sobre a questão da privacidade, cada país de acordo com a sua zona(.BR por exemplo) tem políticas para as informações que devem ser disponibilizadas no serviço.