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.

sexta-feira, 28 de outubro de 2016

Tutorial DNS - Parte 1 - Introdução

DNS(Domain name System) é um serviço criado para resolver os nomes na Internet, "traduzi-los" para endereços IP, e vice versa. Por exemplo o endereço "www.Exemplo.com.br" deve corresponder à um determinado endereço IP. Isso facilita a vida do usuário, na verdade a Internet seria impossível sem este serviço muito simples.


 Um pouquinho de história


Nos primórdios da Internet era muito fácil se lembrar dos endereços IP de outros servidores já que havia muito poucos hosts na rede. Conforme a rede cresceu este trabalho se tornou cada vez mais dispendioso. A solução seguinte foi criar um arquivo de texto chamado "hosts" onde era colocado todos os nomes conhecidos e os respectivos endereços IP. Este arquivo era atualizado periodicamente com um número de versão para controle. A cada acesso a aplicação poderia checar o arquivo para saber qual o endereço IP correspondente ao host. Naturalmente isto também ficou absolutamente insustentável com o crescimento da rede. Então foi criado um serviço próprio para o mapeamento dos nomes em um sistema distribuído em várias zonas e domínios diferentes, o DNS.

O arquivo hosts


O arquivo hosts até hoje é usado. Na verdade ele é o primeiro a ser consultado quando digitamos um nome de domínio qualquer para acessar qualquer coisa na rede. No Windows o seu endereço é "C:\Windows\System32\Drivers\etc\hosts" e no Linux, e familiares, "/etc/hosts". Você pode abrir o arquivo e dar uma olhada. Ele quase sempre está vazio ou apenas com linhas comentadas. É possível adicionar entradas manualmente nele, para o bem ou para o mal, como descrito neste artigo aqui.

Os Root Servers


O protocolo DNS funciona mapeando zonas de cima para baixo. Cada servidor pode ser o dono, chamado servidor Autoritativo, de uma ou mais zonas. Em primeiro lugar existem os root servers, que são os servidores raiz do sistema. Ele são responsáveis pela zona primária que é referenciada com um ponto, ou melhor Root Zone. São 13 no total e cada um recebe uma letra como nome, de A até M. Eles são administrados pela IANA e distribuídos pelo globo. No site oficial é possível ver um mapa de onde eles estão localizados. Cada servidor pode ter várias cópias. No Brasil, por exemplo, temos vários exemplares do J e do L.


Você pode se perguntar o porque de ter "clones" dos root servers pelo mundo e não novos servidores até completar o alfabeto. A questão é que a cada novo servidor, seu endereço deveria ser divulgado para todos os outros no mundo. Sem falar que um único root "B", por exemplo, estando apenas em uma localidade poderia receber muito tráfego. Eles são "clonados" para manter coerência dos 13 nomes históricos e balancear o tráfego global. Seus endereços são configurados em anycast, de forma que se você precisa do root "C", chegará sempre ao mais próximo.

O trabalho dos root servers, sendo donos da zona raiz, é delegar autoridade à outros servidores das zonas do topo, chamadas Top Level Domains(TLDs). Dentro das TLDs podemos ter várias categorias como os códigos de países. Brasil com o ".br", Japão com ".jp" e assim por diante, além de outros domínios genéricos como ".com", ".gov" e ".net", etc. Repare que todo o funcionamento da Internet depende desses domínios e do trabalho dos root servers. Todo servidor DNS deve saber de cor os endereços dos root servers para iniciarem as pesquisas.
Uma questão bem atual na governança da Internet é justamente a liberação de novos TLDs. Países mais conservadores tentem à proibir domínios ".xxx" por exemplo, e outras discussões como alocação de TLDs para grandes empresas como Google e Audi. Veja na lista que várias empresas já reservaram domínios com seus nomes ou mesmo de seus produtos. A zona ".br" é de responsabilidade do Comitê gestor da Internet no Brasil e administrada pelo Nic.Br. Isto significa, basicamente, que todo domínio ".br" deve ser registrado lá.
Para ficar mais claro você pode fazer uma consulta DNS rápida para entender. Use o comando "nslookup -type=NS br.". Traduzindo você está perguntando para o seu servidor DNS quem é o NS(name server) da zona "br."(com ponto no final). Ele vai te responder com os nomes dos servidores responsáveis do Brasil.

Repare que na imagem acima, nas primeiras linhas, que quem me responde é o servidor do Google, e com o aviso "Não é resposta de autorização". Na tradução tosca do Windows, isto significa que este servidor do Google está te respondendo mas ele não é o dono da zona. Você pode perguntar diretamente para os donos e receber uma resposta autoritativa, basta adicionar o endereço de um dos servidores logo no final do comando:
Repare que quem responde é o próprio servidor dono da zona, e não há mensagem de "Não é resposta de autorização".

Servidores Autoritativos


Um servidor DNS pode ser o autoritativo de uma determinada zona. Isto significa que o servidor responsável pela zona superior lhe delegou esta autoridade. Por exemplo a empresa ABC para registrar o domínio "ABC.com.br" precisa requerer o registro da zona com a autoridade do domínio superior e indicar quais serão os servidores autoritativos da zona "ABC.com.br". Uma vez configurado o administrador pode criar os hosts dentro desta zona no arquivo do servidor autoritativo, como "www", "blog", "mail" ou "loja". Cada registro desse vai corresponder ao endereço IP do servidor que hospeda o serviço.
Por exemplo:
mail.abc.com.br  192.0.2.25     #Servidor de email
www.abc.com.br   198.51.100.42  #Servidor web
blog.abc.com.br  203.0.113.89   #Servidor do blog

  Servidores Recursivos


Os servidores chamados recursivos não respondem apenas por suas próprias zonas(se houver), mas fazem a pesquisa recursivamente em toda árvore de domínios até chegar na resposta e entregar ao usuário, sobre qualquer nome. Tudo que ele precisa saber são os endereços dos root servers, o resto flui naturalmente. É o caso dos servidores públicos do Google ou OpenDNS, que qualquer pessoa pode usar. A ideia é distribuir o volume das consultas nos servidores autoritativos já que em uma rede, ou região, vários usuários vão fazer as mesmas perguntas várias vezes. Um servidor recursivo armazena em cache cada resposta que obtém para entregar mais rápido quando solicitado novamente sobre os mesmos nomes e não ter de fazer o processo todo de novo. Geralmente usamos os DNS recursivos do nosso provedor de acesso ou mesmo através do nosso roteador doméstico, que pode fazer o mesmo papel.

Servidores autoritativos podem fazer o trabalho recursivo também e vice versa. Mas geralmente os servidores autoritativos na Internet são somente autoritativos. Isto é, respondem apenas o sobre os hosts e subdomínios dentro de sua zona.

Para fazer um teste rápido, pergunte ao servidor DNS de "globo.com" sobre o endereço IP de "www.facebook.com", e receberá uma resposta negativa de "Query refused". Mas se você perguntar sobre o "g1.globo.com", que é um host dentro de sua zona, responderá normalmente com máxima autoridade:
   nslookup www.facebook.com ns01.globo.com 
#Pergunta para ns01.globo.com quem é www.facebook.com


   nslookup g1.globo.com ns01.globo.com
#Pergunta para ns01.globo.com quem é g1.globo.com

Um servidor atuando como recursivo também pode ser o autoritativo de uma ou mais zonas sem problema algum. Por fim, veja a animação abaixo de uma pesquisa solicitada por um cliente sobre o nome "www.exemplo.com.br" ao seu servidor recursivo:

  
Quando um cliente recebe uma resposta sobre determinado nome ele também armazena em um cache temporariamente, para que não volte a perguntar ninguém sobre os mesmos nomes por um tempo. Você pode checar o cache DNS do seu computador com o comando:
 ipconfig /DisplayDNS
Ou mesmo limpá-lo:
ipconfig /FlushDNS
A resolução de nomes em geral funciona assim:

domingo, 27 de março de 2016

IPv6 - Saindo do armário

IPv6 é a nova versão do protocolo IP, que de novo não tem nada, pois a RFC do protocolo data de 1998! O problema é que houve uma grande procrastinação do IPv4 com as técnicas de mitigação do esgotamento de endereços. O IPv6 elimina o problema da falta de endereços válidos e uso de NAT em redes locais, entre outras novidades. Com 128 bits para endereçamento não faltarão endereços por toda via láctea.
Boa parte da Internet já funciona em IPv6 e a grande maioria dos dispositivos novos vêm com ele habilitado por padrão. Você já está usando IPv6 e e talvez não saiba...
Ele está lá na sua rede, os hosts tentam fechar tuneis IPv6 para atravessar o seu firewall, fazem autoconfiguração e se comunicam por IPv6, tudo debaixo do seu nariz. Então saia do armário e comece a estudar o assunto antes que seja tarde. :-)
Quando se toca no assunto o pessoal fala de lado, olha pro chão. Alguns dizem que é moleza, que basta sair do decimal e estudar números hexadecimais, ou que vai demorar muito até ser implantado. Nada mais ingênuo. O IPv6 é um protocolo totalmente novo e tem muitas diferenças do antecessor. Os endereços IPv4 estão dando os últimos suspiros, e a medida que a rede cresce o uso de NAT deixa tudo exponencialmente mais complexo e caro.


Não pretendo apresentar os detalhes do formato dos novos endereços e como manipulá-los. Esta é a parte mais fácil e você pode achar em qualquer site com documentação básica sobre IPv6. Dê uma olhada em http://ipv6.br e procure pelo curso e-learning.

Para começar veja algumas características importantes:
  • No IPv6 todas as interfaces recebem vários endereços de acordo com o escopo. Vide os tipos de endereços a seguir.
  • O conceito de máscara e a notação CIDR permanece, mas a recomendação é que todos os enlaces utilizem prefixos /64.
  • O novo endereço de loopback é 0:0:0:0:0:0:0:1/128, abreviado ::1
  • Não há endereços de rede ou broadcast, nem mesmo o conceito de broadcast, este agora na forma de endereços multicast.
  • Autoconfiguração(stateless) aprimorada. Os endereços podem ser aprendidos automaticamente por "router advertisement", assim como default gateway e servidores DNS, sendo o DHCPv6 opcional.
  • Protocolo ARP foi substituído pelo ICMPv6(neigbour discovery), que agora carrega funções indispensáveis para o funcionamento da rede.
Os endereços IPv6 são divididos basicamente nas faixas:
 - Link-local address : FE80:: /10 - Endereços não roteáveis que valem apenas no enlace. Análogos aos endereços IPv4 169.254.0.0/16.
 - Unique Local address (ULA): FC00:: /7 - Endereços análogos aos endereços IPv4 privados e podem ser usados em redes privadas livremente.
 - Global unicast: 2000::/3 - Endereços globais únicos reservados para a internet.

Você pode quebrar o gelo com um simples IPCONFIG/IFCONFIG e verá que já existe um endereço de escopo "Link-local" atribuído à sua interface na faixa "fe80::/10. Geralmente este endereço é gerado com base no seu endereço MAC, sendo os últimos 64 bits do endereço correspondentes à ele no formato EUI 64:



Repare que na primeira imagem tenho 2 endereços IPv6, um de escopo global e outro Link-local, mas que terminam iguais. Ambos gerados a partir do MAC da interface. Esta implementação pode variar dependendo do sistema operacional.
Naturalmente você pode fazer testes dentro da sua rede acessando outros hosts pelos endereços IPv6 de Link-local, a começar pelo PING:

  • No Linux com o comando "ping6":  $ ping6 fe80::20f:eaff:feae:9044
  • No Windows usando o parâmetro "-6":  > ping -6 fe80::20f:eaff:feae:9044

Você pode acessar compartilhamentos no Windows por IPv6 também, mas é um pouco mais complicado. Como os ":" do endereço tornariam o formato UNC inválido você deve substituí-los por traços e adicionar o sufixo ".ipv6-literal.net". Veja os exemplos abaixo:

Acesso pelo endereço de Loopback (::1)
Usando o endereço Link-local
O protocolo ARP foi totalmente substituído pelo ICMPv6 com o protocolo de descoberta de vizinhança(NDP - Neighbour discover protocol). Então o que seria equivalente à um "arp -a" agora é:

  • No Windows pelo "netsh": > netsh interface ipv6 show neighbors
  • No Linux: $ ip neigh
netsh interface ipv6 show neighbors

ip neigh
Uma notícia boa é que para o DNS não muda praticamente nada. Para cada consulta IPv4 ao DNS é solicitado um registro tipo "A" e para IPv6 registros tipo "AAAA". Não importa se o seu servidor DNS tem suporte ao IPv6 ou não. Você pode fazer o teste com qualquer domínio usando o comando "NSLookUp"(vale para Windows e Linux) especificando o tipo de "query" com a seguinte sintaxe:

>  nslookup [-querytype=<Tipo de registro>] <domínio> [Servidor DNS]

Exemplo:  nslookup -querytype=AAAA www.globo.com 8.8.8.8


No Linux, além do nslookup(e o dig), temos o comando "host" que pode trazer resultados mais completos:


Repare que o host "ipv6.google.com" tem apenas endereços IPv6 e obviamente apenas registros tipo "AAAA". Sendo assim você pode continuar usando seus servidores DNS de costume para navegar pela Internet IPv6. 

O próximo passo é conseguir conectividade IPv6. O problema começa quando a maioria dos provedores não ofereçe IPv6 aos clientes. As vezes ainda não implementaram na rede ou as CPE's dos assinantes não oferece suporte. A saída mais fácil para estes casos é fazer um túnel com um provedor TunnelBroker. Exemplos são o Freenet 6 e o Hurricane Eletric.
Os links acima têm tutoriais completos. No meu exemplo escolhi o Hurricane por ser mais simples e usar recursos nativos para qualquer sistema operacional(no site da HE tem tutoriais para todos eles), no caso RouterOS. Em seguida, com o túnel fechado no gateway da rede, os hosts serão configurados automaticamente por "router advertisement" e terão conectividade IPv6 de forma rápida.
Basicamente o que deve ser feito é:
  1. Estabelecer o túnel. Lembrando que o pacote IPv6 deve estar instalado no RouterOS.
  2. Configurar um endereço de escopo global para a interface de rede interna do roteador no bloco atribuído pelo provedor do túnel.
  3. "Setar" o router advertisement para que os hosts da rede aprendam os endereços segundo o prefixo anunciado.
Feito o cadastro na HE você pode criar a interface do túnel com o seu endereço IPv4 público e o endereço do servidor fornecido:


Vá em "IPv6 > Addresses" e configure o endereço IPv6 da interface do túnel com o endereço fornecido em "Client IPv6 address":


E adicione uma rota default IPv6 com o endereço em "Server IPv6 Address":


Por fim atribua um endereço do bloco "Routed /64"(vide a tabela "Routed IPv6 Prefixes" fornecida no site nas configurações do túnel) para a interface da sua rede interna habilitando o parâmetro "advertise"(para que os outros hosts aprendam a configuração). Este é o bloco designado para a sua rede. São endereços "Global unicast", por isso únicos no mundo. Sua rede será acessível por esta faixa e cada host terá um endereço "válido", eliminando o NAT.


Acesse qualquer host na rede e verá que rapidamente eles terão endereços na faixa anunciada pelo gateway. Faça um teste no site www.test-ipv6.com. Tendo acesso IPv6 você pode começar a praticar o novo protocolo e fazer a configuração do seu firewall e demais serviços.
O único problema de fazer acessos por túnel é o delay. No meu caso o túnel é fechado com um servidor em Maiami, então todo o meu tráfego v6 faz uma grande volta na América antes de chegar aos destinos, sendo em média 230ms a mais!



quinta-feira, 14 de janeiro de 2016

Script de backup (para sistemas que não têm)


90% do meu trabalho é suporte. Dou suporte à usuários, manutenção de PCs e sistemas operacionais, etc. E, é claro, sempre em pequenas e médias empresas onde há sistemas de gestão mais simples, e tudo fica a cargo do usuário, inclusive o backup. Na maioria dos casos o "servidor"  é um PC qualquer da empresa, o que faz da questão um tanto delicada.
Deixar o usuário a cargo do backup é quase insano, ainda mais em computadores comuns onde os usuários fazem as tarefas comuns. Sem falar que muitos desses sistemas simplesmente não têm ferramenta de backup! O backup é feito copiando manualmente uma pasta ou os arquivos do banco de dados.

Alguns oferecem um script de backup que pode ser agendado como tarefa do Windows, outros não. É aqui onde quero chegar. Andei trabalhando com alguns softwares que o desenvolvedor não dá qualquer suporte ao backup e os usuários acabaram fazendo bagunça na hora de copiar os arquivos. Vou dar um exemplo de script de backup de uma pasta, o qual o usuário pode fazer um backup seguro com apenas um clique (e restaurá-lo da mesma forma) e você pode programar o Windows para executar em determinado horário.

Neste exemplo, como na maioria dos sistemas, será copiada toda a pasta para um arquivo zip nomeado com a data e o horário. Você deve fazer a cópia para pelo menos 2 locais em discos diferentes e de preferência agendar a tarefa em um horário de nenhum ou pouco movimento. Depois um segundo script será criado de forma que basta arrastar o arquivo zip para ele e o backup é restaurado.

Veja o exemplo abaixo, copie no bloco de notas e salve com extensão .CMD:

@echo off
color F0
title Backup pasta do Sistema
rem Definindo variáveis de data e horário para o nome do arquivo
set year=%date:~-4,4%
set month=%date:~-10,2%
set day=%date:~-7,2%
set hour=%time:~-11,2%
set hour=%hour: =0%
set min=%time:~-8,2%

rem Definindo Endereços das pastas e arquivos
set PastaSistema=C:\Sistema
set PastaTemp=%USERPROFILE%\Temp-BKP
set PastaDestino=%USERPROFILE%\BKP-Sistema
set PastaDestino2=\\127.0.0.1\Compartilhada

set NomeArqZip=Sistema-%year%.%month%.%day%.%hour%%min%.zip

rem Verificando instalação do 7zip
set App7zipPath="%ProgramFiles(x86)%\7-Zip\7z.exe"
if not exist %App7zipPath% set App7zipPath="%ProgramFiles%\7-Zip\7z.exe"
if not exist %App7zipPath% goto NaoInstalado

rem Verificando existencia de pastas
if not exist %PastaTemp% mkdir %PastaTemp%
if not exist %PastaDestino% mkdir %PastaDestino%
if not exist %PastaSistema% goto Fim

xcopy /E /H %PastaSistema%\* %PastaTemp%\

echo.
echo -----------
echo Copiando %PastaSistema% para %PastaDestino%\
echo -----------
echo.
%App7zipPath% a %PastaDestino%\%NomeArqZip% -r %PastaTemp%\*
%App7zipPath% a %PastaDestino2%\%NomeArqZip% -r %PastaTemp%\*
echo.
echo -----------
echo %PastaSistema%\ Copiada para %PastaDestino%\%NomeArqZip% 
echo -----------
echo.

goto Fim

:NaoInstalado
 echo.
echo Aplicativo 7zip não instalado - Acesse o site oficial em:
echo  http://www.7-zip.org/

:Fim
del /a /s /f /q "%PastaTemp%\*"
rmdir /s /q "%PastaTemp%\"
echo.
echo.
echo FIM !
echo.
echo.
pause

Você deve substituir os endereços das variáveis pelas respectivas pastas do sistema e do backup. Os arquivos são copiados para uma pasta temporária e em seguida é criado o arquivo de destino. Ainda há uma segunda pasta de destino (variável PastaDestino2) por segurança. Coloquei como exemplo uma pasta compartilhada.

Com um clique duplo o backup é feito. Você pode agendar uma tarefa no Windows para fazer automaticamente. Continuando, um segundo script deve ser colocado na pasta onde ficam os backups para poder restaurá-los de maneira simples, apenas arrastando o arquivo ZIP para o script. Veja o conteúdo abaixo o salve na pasta dos backups com o nome "Arraste aqui para Restaurar o Backup":

@echo off
color F0
rem definindo path do 7zip
set App7zipPath="%ProgramFiles(x86)%\7-Zip\7z.exe"
if not exist %App7zipPath% set App7zipPath="%ProgramFiles%\7-Zip\7z.exe"
if not exist %App7zipPath% goto NaoInstalado

rem Tratando argumento
set Endereco=%1
if not defined Endereco ( echo. & echo "Arraste o arquivo para este progama" & echo. & pause & exit )

set PastaSistema=c:\Sistema
title Restaurando %1 para %PastaSistema%\

rem Restaurar arquivo indicado para a pasta do sistema
echo.
echo -----------
echo Restaurando %1 para %PastaSistema%\
echo -----------
echo.
%App7zipPath% X -aoa %1 -o%PastaSistema%\
echo.
echo -----------
echo FIM !!!
echo -----------
echo.

rem Fim
:Fim
echo.
echo.
pause
exit

rem 7zip Não encontrado
:NaoInstalado
echo.
echo ---------- 
echo.
echo 7zip nao instalado - Baixe em:
echo  http://www.7-zip.org/
echo.
echo ----------
pause
goto Fim

Novamente, altere apenas a variável "PastaSistema" e o script de restauração está pronto. Basta arrastar o arquivo ZIP para ele e pronto. Veja a imagem: