Siga a consulta DNS salto a salto para encontrar a fonte real
Um endereço de resolvedor imposto não decide qual fonte o resolvedor vê. Siga o cliente, o encaminhador e o servidor que recebe, e registe o caminho.
Dar a um cliente um endereço de resolvedor fixa onde as consultas são enviadas, não qual fonte o resolvedor verá. O encaminhamento, a reexpedição e a tradução têm cada um a sua vez entre os dois extremos. Um manual de procedimento para questões de fonte segue a consulta salto a salto e regista o que cada observador viu realmente. A ordem importa, porque uma afirmação feita antes da observação é apenas um palpite com melhor formatação.
Registe a disposição antes de recolher provas
Quatro locais podem dizer-lhe algo sobre uma fonte DNS, e nem todos dizem o mesmo. O núcleo do cliente sabe que fonte usaria, um encaminhador sabe o que enviou para montante, um dispositivo que traduz sabe o que reescreveu, e o resolvedor que recebe sabe o que chegou. Registe quais desses consegue realmente alcançar antes de recolher seja o que for.
| Observation point | What it can prove | What it cannot prove | How to read it |
|---|---|---|---|
| client kernel | which source address it would use for that resolver | anything a device in between rewrote | ip route get against the resolver address |
| forwarder | that it sent an upstream query, and from which source | what the client originally asked for | its own log and its cache state |
| translating device | that a source was rewritten, and to what | whether the query was legitimate | NAT policy and its counters |
| receiving resolver | the address that actually arrived | which client behind that address asked | a scoped capture on port 53 |
Registe também a sua expectativa, incluindo o resolvedor que julga estar em uso. Uma rota dividida pode enviar uma consulta para um local completamente diferente, e uma cache pode responder sem qualquer troca para montante, pelo que uma suposição guardada apenas na memória não sobreviverá à primeira surpresa. Mantenha o desenho declarado e o caminho observado em colunas separadas da mesma nota; quando os dois divergirem, encontrou a pergunta que vale a pena perseguir.
Verifique que processo enviou realmente a consulta
Comece pelo cliente: registe o endereço do resolvedor, o nome consultado e a hora, e depois confirme que processo a enviou. A primeira linha abaixo nomeia o processo que detém o socket UDP, e essa é a verificação que este título promete. Se esse processo for um assistente do navegador ou um ambiente de execução de contentores em vez do resolvedor do sistema, o resto do rasto descreve um caminho que ninguém pediu.
ss -tunp 'dport = :53'
dig @10.20.30.53 host.corp.example +noall +answer
ip route get 10.20.30.53Num anfitrião com várias interfaces, descubra que endereço de origem o núcleo escolhe para esse destino antes de olhar para outro lado. É o último ponto em que o caminho está totalmente sob o seu controlo, e é o valor que vai comparar com o que o resolvedor relata. Uma divergência é o sinal de que algo pelo meio reescreveu o pacote, ou de que foram enviadas duas consultas diferentes.
Mantenha os nomes de teste internos, porque um nome interno enviado a um resolvedor público não prova nada sobre o caminho interno e publica um nome que não precisava de publicar. Um navegador com DNS seguro ativado não aparecerá de todo nessa lista de sockets, e essa ausência é ela própria a resposta.
O encaminhador faz uma segunda consulta, separada
Um encaminhador transforma uma troca em duas. O pedido descendente chega, e o encaminhador envia então a sua própria consulta para montante a partir de um endereço que escolhe. A sua configuração, não o cliente, decide o que o resolvedor de montante vê.
O manual do dnsmasq vale a pena ser lido por esse motivo: documenta como um encaminhador escolhe servidores de montante e liga o seu lado de escuta, e nada nessa disposição transporta a fonte do cliente para montante. Um registo de resolvedor que mostra um endereço de gateway é, por isso, normal e não prova de falha. A ausência é igualmente fácil de ler mal, porque um acerto de cache não produz qualquer consulta para montante e parece idêntico a uma consulta que nunca chegou. Leia a configuração do encaminhador e o estado da sua cache antes de tirar qualquer das duas conclusões. Duas perguntas, dois locais onde olhar.
Leia a fonte no resolvedor que recebe
A única observação que resolve isto é feita do lado do servidor. Tudo o que se infere da lista de interfaces do cliente continua a ser uma hipótese até o resolvedor relatar o que chegou realmente.
tcpdump -ni any port 53 and host 10.20.30.53Capture no anfitrião do resolvedor, mantenha a captura curta e limitada, e guarde-a onde a política o permitir. Se a fonte observada for um endereço traduzido, a pergunta seguinte é que dispositivo fez a tradução e se a sua política é a pretendida. Uma captura responde ao que chegou; não explica por que a política o permitiu. Nomeie o observador e o salto na nota, porque uma afirmação de privacidade sobre um gateway é uma afirmação sobre esse salto e não sobre todo o caminho.
Escreva a conclusão como um caminho, não como um endereço
Registe o cliente, o resolvedor, qualquer encaminhador, a fonte observada em cada salto e a política que o rege. Esse registo responde à maioria das perguntas futuras sem outra captura. Desenhe-o como uma cadeia, porque uma lista de endereços esconde que salto produziu qual.
Junte a data, a versão do cliente e a revisão da configuração ao desenho, para que um leitor posterior possa dizer se ainda se aplica. Separe a fonte de transporte de tudo o resto que o serviço processa, porque ver um endereço de gateway não diz nada sobre o que mais é conservado. A localização de um resolvedor também não diz nada sobre que cliente perguntou. Manter essas afirmações separadas é o que torna a conclusão defensável em revisão.