Usando DNSMasq para resolução de nome de host local


9

Estou trabalhando na criação de uma intranet doméstica para mim e meus colegas de quarto. Minha idéia é que poderemos armazenar coisas como contas de serviços públicos anteriores em um local mais acessível do que uma gaveta na cozinha etc. De qualquer forma, tenho o Apache 2 rodando em um Raspberry Pi, na minha LAN e se eu usar seu endereço IP, eu posso acessar as páginas servidas no Pi. Como estou fazendo esse projeto mais para aprender sobre redes e fornecer um serviço ao meu apartamento, pensei que seria legal se minha rede pudesse fornecer resolução de nome de host para minha LAN. Então, em vez de apontar meu navegador para 192.168.1.151o endereço IP do Pi, eu poderia apontá-lo para oberon(seu nome de host) e visualizar as páginas da web servidas pelo Pi.

Agora eu sabia que não era a primeira pessoa a querer fazer isso, então comecei pesquisando no Google. Esta pergunta, também no Unix e Linux, me ajudou imensamente: Como tornar uma máquina acessível a partir da LAN usando seu nome de host . Neste ponto, eu tentei de tudo na resposta verificada. Pensei em usar o hostsarquivo, mas isso significaria que eu teria que dizer aos meus colegas de quarto para configurar suas máquinas, o que eu não quero que eles façam. Tentei reservar uma concessão de DHCP para o Pi no meu roteador (um NETGEAR WNR1000v2 (também conhecido como N150)) e, enquanto a reserva funcionava, a resolução do nome do host não. Isso me frustra porque eu disse ao meu roteador o IP do Pi e seu nome de host, mas ele ainda não fornece essas informações aos clientes na minha LAN.

Com esses dois métodos não funcionando, decidi instalar dnsmasqno Pi. Parecia simples de configurar e eu ficaria feliz em aprender uma nova ferramenta. Eu instalei e ele está funcionando muito bem (parece). Eu posso digou nslookupapelidos do Pi (que eu definidos em /etc/hostsa oberone homenet) e obter os resultados corretos. Posso fazer o mesmo com nomes da Internet como yahoo.come obter respostas corretas porque configurei o Google 8.8.8.8e 8.8.4.4como servidores de backup /etc/dnsmasq.conf. Veja isso:

me@oberon~$ dig oberon

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> oberon
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10787
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;oberon.                                IN      A

;; ANSWER SECTION:
oberon.                 0       IN      A       192.168.1.151

;; Query time: 10 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Oct  6 18:59:18 2013
;; MSG SIZE  rcvd: 40

Observe que o SERVERis 127.0.0.1: oberonestá pesquisando seu próprio endereço IP por conta própria. Isto é o que eu esperava ver. Saída é a mesma se eu fizer dig oberon @localhost. Por causa dessa saída, estou pensando que dnsmasqestá funcionando bem. Portanto, para elevar o nível a outro nível, desejo que todos os clientes na minha LAN possam digitar oberonseu navegador e serem levados para oberona página de índice. Por isso, sei que preciso configurar meu roteador (desculpas se isso se afastar do território estritamente Unix e Linux).

Eu tenho um Netgear WNR1000v2 com o qual estou bastante familiarizado. Eu configurei o encaminhamento de porta para que eu possa fazer o SSH no Pi e também procurei em outras configurações. Sei que antes de iniciar este projeto, eu estava recebendo meus servidores DNS do meu ISP, mas agora quero usá-los principalmente, mas também 192.168.1.151como última verificação. Então, mudei a configuração de DNS do meu roteador para o seguinte:

A nova configuração de DNS do meu roteador.  Confie em mim quando digo que as duas primeiras entradas são fornecidas pelo meu ISP

Portanto, com essa configuração, eu esperava poder fazer nslookup oberonno meu desktop (Windows) e obter um resultado de 192.168.1.151. Mas isso não acontece. Isto é o que acontece:

C:\Users\me>nslookup oberon
Server:  UnKnown
Address:  fe80::226:f2ff:fefa:bea

*** UnKnown can't find oberon: Non-existent domain

A redefinição ou dnsflushingo adaptador de rede na minha máquina Windows não altera nada.

Agora, aqui está o porquê de eu arrancar meu cabelo aqui:

C:\Users\me>nslookup oberon 192.168.1.151
Server:  oberon.lan
Address:  192.168.1.151

Name:    oberon
Address:  192.168.1.151

Claramente, dnsmasqestá funcionando muito bem. Se eu disser à minha caixa do Windows 192.168.1.151para resolver o nome oberon, tudo estará bem (o .landomínio fazia parte da configuração de dnsmasq, então esperava vê-lo lá). Se eu conseguir que meu roteador diga à minha máquina Windows para usar 192.168.1.151quando fizer consultas de DNS, eu devo ser bom!

Portanto, parece-me que o problema está no meu roteador, mas não consigo descobrir o que fazer além de alterar os servidores DNS para incluir 192.168.1.151como já tenho. Alguém pode me ajudar aqui? Vou tentar fornecer qualquer informação adicional desejada.


Tente colocar o pi como primeiro servidor DNS, funciona então?
terdon

1
O roteador é o lugar certo para fazer isso. Se, por algum motivo, você não conseguir que seu roteador sirva um nome para o Pi, execute o dnsmasq no Pi e faça com que o roteador sirva o Pi, pois o servidor DNS funcionaria. Parece que seu problema está configurando seu roteador corretamente.
Gilles 'SO- stop be evil'

Você está renovando a concessão do DHCP no cliente após atualizar as configurações de DNS no roteador? A configuração do DNS é enviada na concessão do DHCP, portanto, é necessário obter uma nova concessão para obter as novas configurações. Como uma solução alternativa, você também pode procurar no mDNS / zeroconf / avahi.
Patrick

Respostas:


2

Seu problema está no seu entendimento equivocado da maneira como esses servidores DNS são usados. Não sei os detalhes exatos do método que o Windows usa para escolher qual servidor DNS consultar, mas aposto que é o primário> secundário> terciário / sempre /. E mesmo que não fosse e tenha sido de rodízio, você ainda estará consultando um servidor inútil 2 das 3 vezes.

O que acontecerá é que o servidor principal será consultado. Se atingir o tempo limite, que pode ser um ou dois segundos, o próximo servidor será consultado. O DNS não é um sistema de "consenso". Se um dos servidores remotos estiver sendo consultado, ele descobrirá o resultado de que seu nome de host com autoridade NÃO existe, da perspectiva dele como um servidor DNS da Internet.

Você precisa de seu próprio DNS da LAN como servidor DNS primário. Os outros formariam servidores de backup adequados, mas eu consideraria simplesmente abandoná-lo completamente.

Além disso, seu DNS reverso (pesquisa de IP para nome) é resolvido como "hostname.lan", mas seus testes de resolução direta são apenas com o nome do host. Você também deve ter a resolução de encaminhamento para hostname.lan configurada em algum lugar. Embora possa haver muitas pesquisas futuras de "nome a endereçar" para um host, há uma expectativa de que haja uma pesquisa inversa do IP em um nome, que por sua vez tenha um nome correspondente ao registro IP. Nem sempre é crítico e apenas faz com que os arquivos de log se lamentem às vezes, mas algumas coisas são mais sensíveis a isso do que outras.

Além disso, não se esqueça de remover qualquer bodgery de arquivo de hosts que você colocou no lugar depois de fazer tudo funcionar (não sei se isso é relevante para o dnsmasq, nunca usei, tenho uma configuração semelhante, mas mais complicada, usando o nome ISC-BIND servidor, que você pode configurar o encaminhamento para outros servidores, como você está usando, ou simplesmente usá-lo como um servidor DNS sem encaminhamento, com a resolução completa de nomes - que é o que eu configurei).

Desnecessário dizer que, como você primeiro especulou que está muito longe de fazer isso, quase todas as LANs corporativas razoavelmente desenvolvidas e muitas LANs domésticas super-desenvolvidas terão esse tipo de configuração.


1
Obrigado pela sua ajuda iain! Entendo o que você está dizendo sobre como o DNS não é um sistema de consenso, por isso defino o Pi como o servidor DNS primário no meu roteador. Renovei a concessão do DHCP na minha máquina Windows. No entanto, nslookup oberonainda não funciona. Uma coisa que não mencionei no texto da minha postagem original foi que, quando nslookupfalha, ele diz que o servidor usado era um fe80endereço IPv6 - que eu sei que é um endereço de link-local reservado. Mas não sei o que isso significa para o DNS. Minha caixa do Windows está se consultando? dnsflushnão altera esse comportamento.
procurando

E quanto vale a resolução de nomes de host da LAN também não funciona nos meus dispositivos iOS. Ainda não os mencionei porque tenho muito mais poder introspectivo com o Windows, mas se meus problemas realmente surgissem estritamente do Windows, não esperaria que esses dispositivos tivessem o mesmo problema.
precisa

Além disso, para aliviar suas preocupações com o .landomínio, configurei dnsmasqpara expandir automaticamente nomes de host simples a serem adicionados .lan. Running nslookup oberon.lan 192.168.1.151retorna o resultado esperado deName: oberon.lan Address: 192.168.1.151
c.anna

Gostaria de saber se existe um "windowsismo" no trabalho ou algo assim, nomear seus hosts diretamente no domínio de nível superior ('oberon.') É meio estranho, oberon.lan faz muito mais sentido. Uma coisa a ter em atenção é que sufixos de domínio e 'domínios de pesquisa' são frequentemente anexados a um nome para resolvê-lo, por exemplo, "oberon" pode ser resolvido e encontrado como "oberon.lan" se lan estiver nos domínios de pesquisa. No entanto, as consultas acima parecem não mostrar que esse é o caso, a escavação tem especificamente o período final nos nomes de host, mas esteja ciente disso ao testar!
Iain

Hmm, depois de corrigir o DNS primário, você precisará re-dhcp windows (redefinir o adaptador deve fazê-lo); em seguida, verifique ipconfig /allse o servidor DNS correto está sendo usado; se estiver certo, talvez seja necessário fazer o flushdns. Mas não consigo pensar em mais nada, deve funcionar.
precisa saber é o seguinte

1

Talvez um pouco tarde, mas desativar o ipv6 no meu adaptador sem fio fez o truque.


Voto positivo: sempre uma boa ideia. A menos que o sistema esteja nu e exija isso. Até agora (setembro de 2017), há muito pouco equipamento de usuário doméstico que atenda a essa categoria, se houver.
SDsolar 29/09/17
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.