Por que todas as minhas consultas ao DNS são resolvidas para 192.168.1.251?

Question

Todas as minhas consultas em uma máquina na minha rede começaram subitamente a resolver para 192.168.1.251.

Esta máquina foi usada como o servidor DNS por outras máquinas, então eu notei isso assim que começou a acontecer e mudei todas as outras máquinas para usar 8.8.8.8 diretamente, o que funciona.

As máquinas estão todas em um IP 192.168.0.x.

Ele executa o dnsmasq, que eu reiniciei sem efeito e então parei, novamente, sem diferença.

/etc/resolv.conf tinha entradas para 127.0.0.1 e o IP do roteador, eu mudei para apenas um para 8.8.8.8 e não há nada em / etc / hosts para um IP 192.168.1.251. / p>

Qualquer ideia seria apreciada!

$ dig google.co.uk @8.8.8.8

; <<>> DiG 9.7.0-P1 <<>> google.co.uk @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49227
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;google.co.uk.          IN  A

;; ANSWER SECTION:
google.co.uk.       0   IN  A   192.168.1.251

;; Query time: 0 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Jan  6 20:22:03 2011
;; MSG SIZE  rcvd: 46


$ uname -a
Linux america 2.6.32-27-generic #49-Ubuntu SMP Wed Dec 1 23:52:12 UTC 2010 i686 GNU/Linux

Editar: Isso parece começar a funcionar sem qualquer sinal de que as alterações tenham afetado o comportamento. Eu ainda não sou o mais sábio, mas incluindo os arquivos abaixo para completar (e no caso de voltar!)

$ cat /etc/hosts
127.0.0.1   localhost
127.0.0.1   america

192.168.0.1 england
192.168.0.2 america
192.168.0.3 germany
192.168.0.4 france
192.168.0.5 sweden

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts

$ cat /etc/resolv.conf 
# Generated by NetworkManager
#nameserver 127.0.0.1
nameserver 8.8.8.8
#nameserver 4.2.2.2

$ cat /etc/nsswitch.conf 
# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the 'glibc-doc-reference' and 'info' packages installed, try:
# 'info libc "Name Service Switch"' for information about this file.

passwd:         compat
group:          compat
shadow:         compat

hosts:          files mdns4_minimal [NOTFOUND=return] dns mdns4
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis

$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination  

    

Answer 1

Bom sofrimento. Eu tive esse problema em um computador, achando que o NetworkManager tinha colocado 192.168.1.251 como um servidor de nomes em /etc/resolv.conf mesmo que toda a minha rede fosse 192.168.0.0/24. Meu palpite era que isso tinha a ver com a caixa Wi-Fi NetGear WNC2001 que eu havia conectado à porta ethernet daquela caixa do Linux. Mas hoje, enquanto trabalhava no Windows XP em um T60p usado que acabei de comprar, descobri que ele tinha obtido corretamente um endereço IP do meu roteador sem fio, mas que havia configurado o servidor DNS para 192.168.1.251 !! Não WNC2001 nesta caixa. Parecia uma grande coincidência que dois computadores totalmente diferentes na minha rede, de alguma forma, configurariam incorretamente o seu servidor DNS para 192.168.1.251! Eu fiz um "ipconfig / renew" na caixa do Windows e ele configurou corretamente os servidores DNS para aqueles fornecidos pelo meu roteador (um D-Link DIR-628). Eu decidi procurar "DNS 192.168.1.251" e encontrei este site. Este é o primeiro site que eu verifiquei. Sou muito curioso. Verificará alguns outros hits.

    

Answer 2

Estamos tendo problemas semelhantes nesta unidade de coworking; Um potencial culpado é um transceptor sem fio Netgear WNCE2001, que (por necessidade) tem um servidor DHCP embutido, mas só deve servir as solicitações para o link com fio.

O gerente teve um mau comportamento hoje e teve que reconfigurá-lo. Normalmente, conecta um telefone Skype à rede sem fio aqui.

Aqui a página que descreve alguns dos comportamentos: link

    

Answer 3

Você está em um hotspot de Wi-Fi e não "concordou com os termos"?

    

Answer 4

Uma explicação possível poderia ser iptables + dnsmasq (ou outro servidor de nomes) que foi desonesto.

• bind, dnsmasq, alguns outros servidores de nomes estão rodando localmente, respondendo 192.168.1.251 a tudo que você pede.
• O iptables reescreve os pacotes de saída na porta udp 53 para chegar em algum lugar local onde o servidor de nomes bobo escuta / ansers

O raciocínio por trás disso é: Você usa dig para solucionar problemas e instruir a escavação com a opção @ para ir diretamente para 8.8.8.8, dig agora deve ignorar nameserver (s) listados em /etc/resolv.conf. Como o próprio dig implementa um resolvedor e gera consultas em si, envia-o para 8.8.8.8 e analisa / imprime respostas, isso deve eliminar qualquer coisa funky na configuração do resolvedor da libc na caixa (que praticamente todo o resto usa).

Isso sugeriria que:

• o google configurou mal seus servidores de nomes para fornecer respostas falsas, o que é improvável
• algo ao longo do caminho entre você e 8.8.8.8 intercepta e redireciona consultas de DNS e gera uma resposta falsa, no entanto, como suas outras máquinas na mesma rede com seu resolvedor apontado para 8.8.8.8 obtém resultados saudáveis, isso não é provável ou
• algo nesse computador intercepta consultas DNS de saída e as direciona para outro lugar que gera respostas bobas / erradas

Então, eu verificaria se há alguma coisa na cadeia OUTPUT da tabela nat redirecionando o tráfego de DNS para algum lugar onde ele não deveria ir? (iptables -t nat -n -v -L OUTPUT).

Você pode reproduzir esse comportamento com algo como:

$ dnsmasq -p 5353 -A /#/192.168.1.251
$ iptables -t nat -I OUTPUT 1 -p udp --dport 53 -j REDIRECT --to-port 5353
# All locally generated requests outbound on udp port 53 gets sent to
# dnsmasq running on port 5353 which'll answer 192.168.1.251 to pretty much
# everything
$ dig @8.8.8.8 google.co.uk

; <<>> DiG 9.7.1-P2 <<>> @8.8.8.8 google.co.uk
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9993
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;google.co.uk.                  IN      A

;; ANSWER SECTION:
google.co.uk.           0       IN      A       192.168.1.251

;; Query time: 0 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue Jan 11 01:09:01 2011
;; MSG SIZE  rcvd: 46

    

Answer 5

Palpite: Inapropriado DNS curinga? Nas dicas de raiz?

* 3600 IN A 192.168.1.251