Eu tenho o unbound rodando como um servidor dns de validação, caching, recursivo e o nsd3 rodando como um servidor de nomes autoritativo. Parece que todos os aspectos de ambos funcionam corretamente até que eu tente resolver um endereço que deve ser encaminhado para o nsd3. Reduzi o problema para a zona de stub que vai do unbound para o nsd3 e parece que não está resolvendo o nome 'stub-host'. De acordo com os logs, o unbound está tentando resolver o 'stub-host' usando um dns externo em vez de / etc / hosts (embora isso possa ser porque está falhando durante a pesquisa de alguma forma). Eu testei hardcoding o ip do servidor nsd3 que parece funcionar perfeitamente.
Aqui está a parte relevante da minha configuração não acoplada (a configuração completa é Aqui ):
private-domain: "test.lan"
local-zone: "0.0.10.in-addr.arpa." nodefault
stub-zone:
name: "test.lan"
stub-host: unsd_nsd3
forward-zone:
name: "."
forward-addr: 8.8.8.8 # Google Public DNS
forward-addr: 74.82.42.42 # Hurricane Electric
forward-addr: 4.2.2.4 # Level3 Verizon
Aqui está a saída de unbound com um nível de log de 3. Eu executei dig mithril.test.lan @localhost como um teste (resolve corretamente quando o nsd3 é consultado diretamente):
[1448909203] unbound[1:0] debug: validator[module 0] operate: extstate:module_state_initial event:module_event_moddone
[1448909203] unbound[1:0] info: validator operate: query unsd_nsd3. A IN
[1448909203] unbound[1:0] debug: iterator[module 1] operate: extstate:module_wait_subquery event:module_event_pass
[1448909203] unbound[1:0] info: iterator operate: query mithril.test.lan. A IN
[1448909203] unbound[1:0] info: processQueryTargets: mithril.test.lan. A IN
[1448909203] unbound[1:0] info: new pside target unsd_nsd3. A IN
[1448909203] unbound[1:0] debug: iterator[module 1] operate: extstate:module_state_initial event:module_event_pass
[1448909203] unbound[1:0] info: iterator operate: query unsd_nsd3. A IN
[1448909203] unbound[1:0] info: resolving unsd_nsd3. A IN
[1448909203] unbound[1:0] info: processQueryTargets: unsd_nsd3. A IN
[1448909203] unbound[1:0] info: sending query: unsd_nsd3. A IN
[1448909203] unbound[1:0] debug: sending to target: <.> 74.82.42.42#53
[1448909203] unbound[1:0] debug: cache memory msg=132347 rrset=132399 infra=5449 val=132392
[1448909203] unbound[1:0] debug: iterator[module 1] operate: extstate:module_wait_reply event:module_event_reply
[1448909203] unbound[1:0] info: iterator operate: query unsd_nsd3. A IN
[1448909203] unbound[1:0] info: response for unsd_nsd3. A IN
[1448909203] unbound[1:0] info: reply from <.> 74.82.42.42#53
[1448909203] unbound[1:0] info: query response was NXDOMAIN ANSWER
[1448909203] unbound[1:0] info: finishing processing for unsd_nsd3. A IN
[1448909203] unbound[1:0] debug: validator[module 0] operate: extstate:module_state_initial event:module_event_moddone
[1448909203] unbound[1:0] info: validator operate: query unsd_nsd3. A IN
[1448909203] unbound[1:0] debug: iterator[module 1] operate: extstate:module_wait_subquery event:module_event_pass
[1448909203] unbound[1:0] info: iterator operate: query mithril.test.lan. A IN
[1448909203] unbound[1:0] info: processQueryTargets: mithril.test.lan. A IN
[1448909203] unbound[1:0] debug: out of query targets -- returning SERVFAIL
[1448909203] unbound[1:0] debug: return error response SERVFAIL
[1448909203] unbound[1:0] debug: validator[module 0] operate: extstate:module_wait_module event:module_event_moddone
[1448909203] unbound[1:0] info: validator operate: query mithril.test.lan. A IN
[1448909203] unbound[1:0] debug: cache memory msg=132557 rrset=132624 infra=5449 val=132392
Como uma nota lateral, estou executando tanto o unbound como o nsd3 em seus próprios contêineres do docker a partir de uma imagem de base do debian e os vinculei. Eu posso resolver unsd_nsd3 muito bem dentro do contêiner não acoplado. Aqui está o / etc / hosts no container não acoplado:
172.17.0.6 a79a91df9ec5
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
172.17.0.5 docker_nsd3 89a74b365c88 unsd_nsd3
172.17.0.5 unsd_nsd3 89a74b365c88
Eu fiquei sem ideias sobre como avançar a partir daqui. Alguma ajuda seria apreciada.
Não consolidado não usa / etc / hosts . Não consolidado só pode resolver o nome do stub unsd_nsd3 enviando upstream. Você precisará configurar local-zone e local-data para refletir o conteúdo de seu / hosts ou usar um IP para o stub.
Para facilitar a migração, o tarball de origem tem um script perl, contrib/build-unbound-localzone-from-hosts.pl , que gera um arquivo de inclusão. O nome da zona local precisa ser definido dentro do script antes do exec