>_Dns 1.1

O DNS (Domain Name System – Sistema de Nomes de Domínios) é um sistema de gerenciamento de nomes hierárquico e distribuído operando segundo duas definições:

  • Examinar e atualizar seu banco de dados.
  • Resolver nomes de domínios em endereços de rede (IPs).

Pequena introdução teórica

No final dos anos 70, a introdução do protocolo TCP/IP e consequentemente a rápida expansão da ARPAnet tornou obsoleto o sistema de atualização manual e centralizado do arquivo HOSTS.TXT, que continha uma tabela associando todas informações sobre os hosts da ARPAnet, incluindo seus endereços. Era simples mantê-lo para poucas centenas de máquinas, mas tornou-se impraticável para milhares e milhares que se conectavam a rede em um processo exponencial de crescimento. Dainte desse problema, a direção da ARPAnet contratou pesquisadores para desenvolver uma solução queatendesse às seguintes especificações:

  • Permitir administração local e ao mesmo tempo publicação global
  • Garantir univocidade do nome do hosts através de uma distribuição hierárquica de domínios

Em 1984 foi liberado o Domain Name System, descritos nas RFC’s 882 e 883. Atualmente estas RFC’s foram suplantadas pelas de números 1034 e 1035, além de RFC’s suplementares de segurança, administração, atualização dinâmica de servidores de nome, e muitas outras.

  • Banco de dados hierárquico e distribuído representado no formato de uma árvore invertida e 127 níveis
  • Namespace de até 63 caracteres
  • É capaz de associar outras informações a um host e não só seus endereços IP’s
  • Arquitetura clente/servidor
  • Os clientes são chamados resolvers, e costumam ser bibliotecas do sistema operacional (libresolv no Linux) compartilhadas entre os mais diversos programas, como o ping ou navegador web
  • Do outro lado estão os servidores de nome DNS (DNS nameserver)
  • A raiz da árvore tem nome nulo ou ” “, por isso é representada simplemente por um ponto(.)
  • Os nós abaixo do domínio raiz chamados domínios de npivel mais eleveado (top level domains)
  • Sua quantidade e nomes são impostos pela ICANN (Internet Coporation for Assigned Names and Numbers)
  • Eles são divididos em gTLD e ccTLD, onde temos respectivamente os domínios genériocos com, edu, gov, mil, etc; e os códigos de países (country-code), sempre com duas letras
  • A ICANN delega, de acordo com tratados internacionais, a responsabilidade pela administração de um ccTLD
  • No caso do Brasil, essa responsabolidade pertence atualmente ao CGI.br, mais especificamente ao REGISTRO.br
  • Uma vez delegado um dompinio, sua nova autoridade pode delegar subdomínios sem necessitar notificar a entidade resnposável pelo domínio pai
  • Um subdomínio está para um subdiretório assim como um domínio esta pra um diretório, e um host está para um arquivo

Finalmente, vale a pena mencionar que os arquivos HOSTS.TXT foi portado paa ambiente Unix como /etc/hosts. Este arquivo é normalmente o primeiro a ser consultado pelo resolvedor, que irá buscar por um servidor de nomes apenas em caso de o host não ser encontrado no arquivo /etc/hosts.

Resolução

Solução DNS é o processo pelo qual um programa consulta dados a respeito de um hostname. Na grande maioria das vezes, consulta-se o endereço IP deste host, para então efetuar algum tipo de conexão à algum serviço, como HTTP, SMTP, POP, dentre inúmeros outros.

O processo de resolução, a partir do primeiro nameserver consultado, pode ser:

  • Recursiva

A resolução recursiva (recursive lookup) faz uso do servidor de nomes para resolver a informação desejada. Ou seja, o “resolver” envia a pergunta ao servidor de nomes e espera que este resolva a informação através da cooperação com outros servidores de nomes.

Tomando um navegador web como exemplo, a resolução para acesso a uma website tem as seguintes etapas:

1 – Usário solicita acesso a www.vandocouto.com.br

2 – Navegador checa se já conhece o endereço IP do hostname solicitado (cache do browser)

3 – Se não conhece, o navegador passa a solicitação para a biblioteca de resolução (resolver)

4 – O resolver procura o hostname solicitado no arquivo /etc/hosts local

5 – Se não encontrar, ele checa o arquivo /etc/resolv.conf  para saber a quias nameserveers deve solicitar a informção

5 – O servidor de nomes acionado consulta seu cahce, se houver

6 – O resolver repassa a solicitação ao primeiro nameserver da lista, e logo após para p próximo até o fim da lista, aguradando por uma resposta de qualquer um deles

7 – O servidor de nomes acionado consulta seu cache, se houver

8 – Se não encontrar em seu cache, o servidor em questão vai diretamente ao servidor raiz e transfere a consulta ( www.vandocouto.com.br

9 – O servidor raiz não faz cache, e também não é autoridade sobre zonas de baixo nível, então ele apenas respodne uma parte da questão: “não sei quem é, mas sei quem pode responder melhor: br”

10 – O servidor de nomes reenvia a consulta para o servidor .br ( www.vandocouto.com.br)

11 – .br retorna o mesmo tipo de respota,  porém como uma dica mais próxima. ” não sei quem é, mas sei quem pode responder melhor: com.br”

12 – Passo 10 e 11 são efetuados mais uma vez, e agora a resposta é “não sei que é, mas sei quem pode responder melhor vandocouto.com.br”

13 – Após repetir o passo 10, finalmente a resposta será da autoridade sobre o dompinio vandocouto.com.br. Vai ser respondido o IP, jutnamente ao TTL do registro, ou será respondido “inexistente”

14 – O servidor de nomes fará cache da resposta, ao mesmo tempo que a repassa para o resolvedor original

15 – O resolvedor repassa a resposta para o navegador

16 – O navegador incia uma conexão HTTP com o IP descoberto

  • Iterativa

No processo de resolução iterativa o resolver tem o papel principal, questionando um servidor de nomes de cada vez até concluir a resolução com sucesso ou insucesso.
Cada servidor inquirido responde com a sua melhor resposta possível, mas sem contactar qualquer outro servidor de nomes. Em função dessa resposta o resolver decide que outro servidor deve contactar para resolver a informação. O processo repete-se até a resposta recebida ser a desejada ou não permitir qualquer outra iteração do processo.

Enquanto o servidor cache do exemplo acima executa um processo recursivo de consultas sucessivas descendo a árvore até a autoridade capaz de respodner definitivamente ao questionamento apresentado, os servidores “.” , “br”, “com.br”, apenas informam que conhecem alguém mais preciso que eles. Essa é uma consulta iterativa. Iteração, nesse caso, significa “apontar para o mais próximo conhecido”.

/etc/hosts

Derivado do arquivo HOSTS.TXT original, aquele que era atualizado e distribuído antes do surgimento do Domain Name System, o arquivo /etc/hosts continua tendo um papel muito importante no processo de resolução. No passo a passo descrito anteriormente, observe que ele é a primeira fonte de consulta do resolver.

Este comportamento pode ser modificado através do arquivo /etc/nsswitch, porém, isso só seria feito em um cenário muito particular. Podemos considrear que quase a totalidade dos sistema *nix vão seguir a ordem de resolução padrão.

Sendo assim, é bom conhecer a sintaxe desse arquivo:

endereço_ip hostname_canonico [aliases..]
192.168.0.2    vandocouto.com.br.   vandocouto

São possíveis um endereço IP por linha, seguido de um endereço canônico e opcionalmente aliases. O nome de host canônico pode ser qualquer nome no formato DNS, porém, em alguns casos, como o de servidores de e-mails, é adequado que os IPs presentes nesta máquina tenham um FQDN pertinente. Full-Qualified Domain Name é um hostname que identifica sem ambiguidade a posição daquele nó dentro da árvore DNS.

Por essa razão, um FQDN deve terminar com um “.”, que representa a raiz da árvore. O aliases podem ser outros hostnames canônicos, ou simples sufixo, para simplificar a escrita de determinados endereços. Após a instalação do sistem, o arquivo hosts costuma conter uma entrada referente ao IP da interface loopback, e uma entrada para cada outra interface presente na máquina para qual um endreço foi atribuído.

Por exemplo:

127.0.0.1 localhosts
192.168.0.2 vandocouto.com.br. vandocouto

Pde ser acrescentadas quantas entradas forem necessárias, inclusive para IPs externos. Atualmente, os sistemas baseados em Debian já contém entradas para endereçamento IPv6, que seguem a mesma lógica.

Práticas Dirigidas

# aptitude install dnsutils

Caso já tenha o pacote instalado, verifique com o comando dpkg -L

  • nslookup

A ISC diz literalmente, no manual de utilização do BID: “Devido a sua interface misteriosa e frequente comportamento inconsistente, nós não recomendamos o uso do nslookup. Usem porém o dig no lugar dele”

Porém, o pacote é mantido pela própria ISC em nome da legião de administradores que se habituaram a utilizar o nslookup como ferramenta de solução de problemas.

Dentre suas vantagens está o fato de ter uma biblioteca de resolução independente do sistema (resolvedor), e consultar um servidr por vez, dentre os listados no resolv.conf. Pode deixaar a consulta mais lenta, mas torna a triagem mais controlável. Dentre os problemas mais crônicos do nslookup estão: resposta confusas e erros indefinidos.

server NOME

Considera como default o servidor especificada pelo NOME.

lserver NOME

Este argumento usa o servidor inicial para procurar informações sobre o domínio especificado pelo NOME.

root
Troca o servidor default pelo servidor root do domínio.

finger [Usuário] [>FileName]
Conecta-se com o processo finger no host corrente. O host corrente é definido quando uma procura prévia por um host aconteceu com sucesso e retornou informações sobre o endereço da máquina. Este comando pode ser direcionado para que a saída seja um arquivo texto.

ls [Opção] Domínio [>Filename]
Lista as informações disponíveis para op dominio especificado. Este comando pode ser direcionado para que a saída seja um arquivo texto. O parametro Opção pode ser os seguintes :

* -t QreryType onde a QueryType pode ser: (A – endereço do host internet, CNAME – nome canônico para um alias, HINFO – informações sobre a CPU e tipo de sistema operacional, KEY – chave de segunça, MINFO – lista informações dobre o mailbox ou mail, MX – trocador de mail, NS – servidor de nome para o named zone, PTR – se a pesquisa for pelo endereço internet é convertido para o nome da máquina, SIG – registro de assinatura, SOA – informações sobre o domínio, TXT – informações sobre textos, UINFO – informações sobre usuário, WKS – supporta serviços well-known)
* -a Lista aliases dos hosts do domínio.
* -d Lista todos os registros do domínio.
* -h Lista informações da CPU e sistema operacional.
* -s Lista serviços well-known dos hosts do domínio.

exit – Abandona o programa NSLOOKUP.

Comando Descrição
SET Q=MX Define o tipo de consulta para o MX (MaileXchange) que exibe todos os servidores de e-mail designados para um domínio.
SET Q=A Define o tipo de consulta para A (Endereço) que exibirá o endereço para o nome digitado (por ex.: WWE.SYMANTEC.COM).
SET Q=PTR Define o tipo de consulta para PTR (PoinTeR) que irá exibir o nome do endereço digitado (por ex.: 127.0.0.1).
SERVER <nome_servidor/IP> Pede ao NSLOOKUP para obter informação do servidor especificado (SERVER 127.0.0.1).
HELP Exibe uma lista dos comandos e opções disponíveis.
  • Host

O comando host é concebido para dar respostas objetias, limitando-se na maioria dos casos a uma só linha. Porém , respostas mais detalhadas podem ser obtidas com a utilização de parâmetros.

Ao contrário do dig, o host consulta a search list do arquivo /etc/resolv.conf.

  • dig

O comando dig é o acrônimo para domain information groper, que siginifica algo como “aquele que busca por informações de domínio no escuro”, e ao mesmo tempo, a palara dig em inglês significa literalmente “escavar”. Ele é ocomando de pesquisa mais poderoso no pacote de utilitários BIND.

No dig há dezenas de opções e incontáveis combinações entre elas, por isso consultar o man, e sobretudo, ter um forte domínio do funcionamento do sistema de nomes de domínio é necessário para dominá-las.

O dig não utiliza a opção search do /etc/resolv.conf, por isso é necessário utilizar FQDN em todas as buscas.

DESCRIÇÃO

dig (domain groper informação) é uma ferramenta flexível para interrogar servidores de DNS nome. Ele realiza pesquisas de DNS e exibe as respostas que são devolvidos a partir do servidor de nome (s) que foram consultados. A maioria dos administradores de DNS usam cavar para solucionar problemas de DNS por causa de sua flexibilidade, facilidade de uso e clareza de saída. Outras ferramentas de pesquisa tendem a ter menos funcionalidades do que cavar.

Apesar de cavar é normalmente utilizado com os argumentos de linha de comando, ele também tem um modo de operação do lote para a leitura dos pedidos de pesquisa de um arquivo. Um breve resumo de seus argumentos de linha de comando e opções é impresso quando a opção-h é dada. Diferentemente das versões anteriores, a execução de escavação BIND9 permite pesquisas múltiplas para ser emitida a partir da linha de comando.

A menos que seja dito para consulta um servidor de nome específico, vai tentar cavar cada um dos servidores listados no arquivo / etc / resolv.conf.

Quando não houver argumentos de linha de comandos ou opções são dadas, irá realizar uma consulta de NS “. (A raiz).

É possível configurar por usuário padrão para cavar via $ (HOME) /. Digrc.

Este arquivo é lido e todas as opções em que são aplicados antes da linha de comando argumentos.

SIMPLES USO

digite o comando
dig @ servidor

Onde:

Servidor é o nome ou o endereço IP do servidor de nome para consulta. Isso pode ser um endereço IPv4 em notação decimal com ponto ou um endereço IPv6 na notação delimitadores. Quando o argumento fornecido é um servidor host, dig resolve esse nome antes de consultar o servidor de nome. Se nenhum argumento servidor é fornecida, o comando dig irá consular o arquivo /etc/resolv.conf.  Nome é o nome do registro de recurso que deve ser observado.Tipo indica o tipo de consulta é necessário â € “ANY, A, MX, SIG, tipo, etc pode ser qualquer tipo de consulta válido. Se nenhum tipo de argumento é fornecida, o dig irá realizar uma pesquisa para um registro.

OPÇÕES

opção
-b define o endereço IP de origem da consulta de endereço.

opção
-c. classe é válida qualquer classe, tais como HS para registros Hesíodo ou CH para registros Chaosnet.

opção
-f faz com que o dig opere em modo batch, lendo uma lista de pedidos de pesquisa para o processo a partir do nome do arquivo. O arquivo contém um número de consultas, um por linha. Cada entrada no arquivo deve ser organizado da mesma forma que seria apresentado como consultas.

opção
-p é usado. # porta é o número da porta que vai escavar enviar suas consultas DNS em vez do número da porta padrão 53. Esta opção deve ser usada para testar um servidor de nome que tenha sido configurado para escutar para consultas sobre um número de porta não-Stan dard.

opção
-t define o tipo de consulta com o tipo. Pode ser qualquer tipo de consulta válida que é apoiado em BIND9. O tipo de consulta padrão “A”, a menos que a opção-x é fornecido para indicar uma pesquisa inversa. Uma transferência de zona pode ser solicitado, especificando o tipo de AXFR. Quando uma transferência de zona incremental (IXFR) é necessária, o tipo é definido como IXFR = N. A transferência de zona incremental conterá as mudanças feitas para a zona uma vez que o número de série no zoneâ € ™ s registro SOA foi N.

opção
-x. addr é um endereço IPv4 em notação decimal com ponto ou uma vírgula delimitado endereço IPv6. Quando esta opção for usada, não é necessário fornecer o nome, classe e tipo de argumentos. o dig  automaticamente realiza uma pesquisa para um nome como 11.12.13.10.in addr.arpa e define o tipo de consulta e de classe para PTR e de, respectivamente. Por padrão, os endereços IPv6 são pesquisados que utilizam o domínio IP6.ARPA e rótulos binários, tal como definido na RFC 2874.

opção
-k. Você também pode especificar a chave TSIG-se na linha de comando usando a

opção
-y, nome é o nome da chave TSIG ea chave é a chave real. A chave é uma seqüência de base 64 codificado, geralmente gerada pelo keygen-DNSSEC (8). Cuidados devem ser tomados ao usar a opção-y em sistemas multi-utilizador como a chave pode ser visível na saída do ps (1) ou no SHELLA € ™ s de arquivo histórico. Ao usar a autenticação TSIG com escavação, o nome do servidor que é consultado precisa saber a chave e algoritmo que está sendo usado. No BIND, isso é feito através de chave apropriada e as declarações do servidor no named.conf.

Ferramentas de teste de DNS disponíveis:

  1. blacklist: – Verifica se o IP ou host está listado em alguma das 101 blacklist cadastradas
  2. smtp: – Teste o seu servidor de e-mail’s SMTP (especificamente a porta 25)
    Verifica se você está com open relay (relay aberto); Testa o tempo de conexão com o servidor; Verifica se o IP resolve o nome do host corretamente; e também se o DNS confere com o Banner SMTP.
  3. mx: – Exibe os registros MX referentes ao domínio de e-mail pesquisado;
  4. a: – Retorna o ip correspondente ao domínio pesquisado IPV4.
  5. aaaa: – Retorna o ip corresondente ao domínio pesqusado IPV6.
  6. spf: – Verifica no cabeçalho de internet se o SMTP utilizado para enviar a mensagem, está autorizado na relação de IP’s que respondem pelo domínio do remetente.
  7. txt: – O mesmo que o item anterior;
  8. ptr: – teste de DNS reverso
  9. cname:Canonical names;
  10. scan: – Um scanner de portas que exibe quais estão abertas e quais estão fechadas;
  11. whois: – Informações sobre quem é o proprietário do domínio;
  12. arin: – Informações sobre o bloco de IP referenciado.
  13. soa: – Informações sobre autoridade do domínio, e-mail do responsável e DNS primário.

Buscando por registros de endereços IP, entrega de e-mails, autoridade sobre o domínio e dados adicionais.

Faça de cada lágrima de dor,
uma gotinha de coragem em busca pela felicidade!

autor desconhecido

>_Dns 1.1
Tagged on:

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

%d blogueiros gostam disto: