DNS faz o mundo girar, é também coisas muito interessantes. Tipicamente DNS apenas funciona, mas há momentos em que você quer fazer algo especial ou você não está recebendo os resultados que você acha que deveria. Este documento é para aquelas épocas.


Índice
1. DiG
2. Quem é o seu DNS?
3. Sublinha do cliente EDNS
3.1. Construção de escavação
A. Sobre mim

1. DiG

Você ainda está usando o nslookup para consultar o DNS? Pare! O utilitário nslookup tem alguma funcionalidade básica, mas uma vez que você vai além da resolução simples que você realmente quer começar a usar escavação do pacote de software ISC BIND . Você verá que a maioria das seções neste documento funcionam com dig .


2. Quem é o seu DNS?

Você sabe qual é o seu servidor DNS? Isso é fácil, basta executar o gato /etc/resolv.conf . Exceto que você está usando DHCP que muitas vezes irá definir o servidor DNS para localhost (127.0.0.1). Você pode apenas executar dig 127.0.0.1 | Grep ‘; SERVER ‘ , mas que, essencialmente, exibe a mesma coisa. OK, sabemos que temos o DHCP ativado eo DHCP está configurando o servidor DNS, então precisamos encontrar a concessão DHCP. Vamos procurar em / var / lib / dhcp / , localizar o arquivo mais novo (já que podemos ter contratos de outras redes), encontrar a especificação do servidor DNS e descobrir a entrada mais recente usando o comando svelte cat $ (find / var / lib / Dhcp / -maxdepth 1 -type f -printf “% T @% p \ n” | sort -n | tail -n 1 | cut -d ” -f 2-) | Grep domain-name-servers | Cauda -n1 . E nosso servidor DNS é … nosso roteador em 192.168.0.1? Ou talvez o nosso servidor DNS corporativo em 10.abc? Isso não está certo.

Mesmo se você tiver acesso ao roteador que você está falando (o que você faz em casa, mas nem sempre no trabalho), você pode se surpreender ao descobrir que o endereço IP listado não é o endereço IP que o seu servidor DNS é realmente Configurado com. Tomemos o serviço DNS do Google como exemplo. Você configurou o seu servidor DNS para ser 8.8.8.8, no entanto, este é um endereço IP Anycast que significa que a solicitação é encaminhada para um datacenter local. Se você estiver em Nova York, 8.8.8.8 provavelmente vai para o seu datacenter da Carolina do Norte. Se você estiver em Estocolmo, vai para Hamina, Finlândia. Mesmo com um endereço IP você não tem idéia de onde seu servidor DNS realmente é.

Por que isso importa? Muitas empresas usam a localização do seu servidor DNS para descobrir onde o mapear. Se você está sentado no Arizona eo site que você está tentando alcançar tem datacenters em NYC e LA, você provavelmente será enviado para o LA datacenter. O problema é o DNS centralizado. Se você estiver trabalhando em seu escritório na Califórnia, mas sua sede corporativa está em Londres, há uma chance decente de todos os seus pedidos DNS sair do escritório de Londres. Isso significa que as empresas que usam o DNS para escolher o datacenter mais próximo irá mapeá-lo para Londres em vez de Califórnia e seu desempenho irá sofrer. Portanto, conhecer o seu servidor DNS é o primeiro passo para solucionar problemas de desempenho.

Especialmente se você estiver tendo problemas de desempenho com uma Rede de Entrega de Conteúdo como a da Akamai. Isso é bastante comum para que a Akamai tenha uma ferramenta para ajudá-lo a descobrir o seu servidor DNS. Se você executar dig + short whoami.akamai.net a resposta que você receber será o endereço IP Akamai viu o seu pedido. Você pode querer tentar isso algumas vezes, muitas pessoas usam uma rotação round robin DNS para que você possa vê-lo aparecendo de várias partes da Internet aleatoriamente.

Uma ferramenta adjunta é curl whatismyip.akamai.com (ou o menos recomendado wget -qO- whatismyip.akamai.com – curl: wget :: dig: nslookup) que irá mostrar o seu endereço IP público. Para encontrar uma estimativa aproximada quanto ao desempenho que você obtém em CDNs, você pode usar uma ferramenta como esta para descobrir o quão longe seu endereço IP é do seu DNS. Não é tão preciso quanto o serviço EdgeScape da Akamai, mas é um pouco mais barato …


3. Sublinha do cliente EDNS

A missão do Google é tornar a Internet mais rápida. Eles também são uma espécie de Rede de Entrega de Conteúdo própria, eles o encaminharão para o datacenter mais próximo . Eles entendem o problema do DNS centralizado e Wilmer van der Gaast submeteu um rascunho do IETF para ajudar a corrigir esse problema. Eu incentivo-o verificar para fora a uma página Internet mais rápida do Internet para figurar para fora como este trabalha.

Uma vez que ninguém realmente lê o link, em poucas palavras, digamos que você use o Google DNS. Você envia uma solicitação de DNS para 8.8.8.8 e ela chega ao servidor Google mais próximo. O problema é que você está na África do Sul e atinge o datacenter da Bélgica. Servidor DNS do Google vê que você está procurando http://www.acceleratedwebsite.com para que ele pede ao servidor DNS em acceleratedwebsite.com para onde ir. Desde que acceleratedwebsite.com vê um endereço de IP de Bélgica que o encaminham para seu datacenter de Paris.

Agora vamos supor que acceleratedwebsite.com suporta esta opção edns-client-subnet. Quando eles recebem o pedido de DNS do Google, eles ainda vêem um endereço IP da Bélgica, mas também vêem uma sub-rede que representa sua localização na África do Sul. Eles usam este sudafricano subnet para encaminhá-lo para o seu servidor em Joanesburgo.

O problema com esta solução é que o servidor de DNS local precisa suportá-lo e o que quer que esteja fazendo a decisão onde você deve ser mapeado precisa suportá-lo. Seu ISP local provavelmente não suporta esta extensão, mas eles também provavelmente colocar seu servidor DNS muito perto de você para que não importa. Seu DNS do trabalho provavelmente não suporta este tampouco, e podem ter um usuário centralizado do DNS. No entanto, tanto o Google DNS quanto o OpenDNS suportam isso.

Ele também precisa de buy-in do serviço fazendo a decisão de mapeamento. A maioria dos sistemas caseiros usa uma solução GTM (Global Traffic Manager) de um fornecedor que provavelmente ainda não suporta este rascunho. Infelizmente, o maior jogador CDN lá fora (Akamai) também não o suporta. No entanto, alguns jogadores como CDNetworks e outros nesta lista fazer. Se o site que você está tentando acessar usa um desses participantes e você está usando o Google DNS ou OpenDNS você estará razoavelmente certo de obter um bom mapeamento.

A única coisa que ninguém pode corrigir é roteamento ruim em redes corporativas. Alguns escritórios realmente roteiam todo o tráfego para a sede antes de chegarem à Internet. O melhor que você pode fazer então é ser mapeado perto da sede. A maioria das VPNs também não suporta o roteamento de horizonte dividido, isso significa que se você estiver viajando ao redor do mundo, poderá obter downloads razoáveis até que você se conecte à VPN em que ponto todo o tráfego vai para o concentrador de acesso VPN ao qual você se conectou. Para ajudar a corrigir isso, eu não uso uma VPN, mas sim confiar em um túnel SSH com um proxy SOCKS – mas estou em uma minoria que têm o conhecimento para fazê-lo e que trabalham em uma empresa com um servidor público SSH.


3.1.Construção de escavação

Quer saber se o seu DNS suporta a extensão do Google? Ou apenas quer descobrir qual servidor alguém seria encaminhado para? Você pode recompilar dig para fazer isso. Eu vou assumir Ubuntu Precise para isso, mas ele deve funcionar bem com pequenos ajustes na maioria das distribuições.

Primeiro, você precisará configurar as dependências. Execute o sudo apt-get install build-essencial libssl-dev para começar.

Crie um diretório em algum lugar e copie esses arquivos para ele. Agora execute estes comandos:

  Tar -vzxf bind-9.9.1 * .tar.gz
 Cd bind-9.9.1 * /
 Patch -p0 -F3 <../bind-9.7.3-dig-edns-client-subnet.diff
 ./configure
 faço

Agora você pode executar bin / dig / dig @ ns1.google.com http://www.google.com + client = 130.89.89.130 para verificar se ele funciona. Se você gosta dele, você pode copiá-lo para o seu caminho, mas certifique-se de substituir o escavação existente (o que significa que se Ubuntu atualizações por qualquer motivo você vai ter o sabor Ubuntu) ou colocá-lo em algum lugar antes / usr / bin / No seu caminho, caso contrário, você estará executando a versão interna. Outra opção é renomeá-lo para dig-client para manter as coisas separadas.

Depois de mover o arquivo binário para fora, você pode excluir o diretório com o patch eo código-fonte.

Anúncios