Início / ubuntu / Perguntas / 1531592
Accepted
Sun Bear
Asked: 2024-10-30 21:29:40 +0800 CST

Como verificar se todos os IPs de domínio resolvidos são de um resolvedor DNS externo quando o Unbound está configurado para encaminhar consultas de domínio?

  • 772

Configurei o Unbound para:

  1. ouvir consultas de domínio em todas as interfaces em uma LAN,
  2. encaminhar essas consultas de domínio para um resolvedor DNS externo via TLS,
  3. receber os IPs de domínio resolvidos do resolvedor DNS externo e devolvê-los aos clientes correspondentes.

Como verifico se tal configuração está funcionando? Especialmente, como verifico que:

  1. O Unbound encaminhou as consultas de domínio para o resolvedor DNS externo desejado via TLS?
  2. Os IPS de domínio resolvidos são do resolvedor DNS externo e não são resolvidos pelo Unbound?

Abaixo estão dois resultados de digging google.com. Como posso usar esses resultados para fazer as verificações mencionadas acima?

root@DNS:/etc/unbound# dig google.com A @192.168.1.50 -p 3000

; <<>> DiG 9.18.28-0ubuntu0.24.04.1-Ubuntu <<>> google.com A @192.168.1.50 -p 3000
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22452
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;google.com.            IN  A

;; ANSWER SECTION:
google.com.     300 IN  A   142.251.175.138
google.com.     300 IN  A   142.251.175.100
google.com.     300 IN  A   142.251.175.113
google.com.     300 IN  A   142.251.175.101
google.com.     300 IN  A   142.251.175.139
google.com.     300 IN  A   142.251.175.102

;; Query time: 12 msec
;; SERVER: 192.168.1.50#3000(192.168.1.50) (UDP)
;; WHEN: Wed Oct 30 14:04:16 UTC 2024
;; MSG SIZE  rcvd: 135

root@DNS:/etc/unbound# dig google.com A @192.168.1.50 -p 3000

; <<>> DiG 9.18.28-0ubuntu0.24.04.1-Ubuntu <<>> google.com A @192.168.1.50 -p 3000
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39764
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;google.com.            IN  A

;; ANSWER SECTION:
google.com.     300 IN  A   142.251.175.139
google.com.     300 IN  A   142.251.175.113
google.com.     300 IN  A   142.251.175.100
google.com.     300 IN  A   142.251.175.101
google.com.     300 IN  A   142.251.175.138
google.com.     300 IN  A   142.251.175.102

;; Query time: 184 msec
;; SERVER: 192.168.1.50#3000(192.168.1.50) (UDP)
;; WHEN: Wed Oct 30 14:05:30 UTC 2024
;; MSG SIZE  rcvd: 135

Abaixo estão os logs unbound.logcom verbosity: 3depois de reiniciar o unbound.servicee executar o comando dig acima duas vezes. Posso ver que o resolvedor DNS externo é mencionado, mas não consigo entender qual linha mostra que ele resolveu o domínio e retorna os resultados para unbound.

[1730296502] unbound[6506:0] info: service stopped (unbound 1.19.2).
[1730296502] unbound[6506:0] info: server stats for thread 0: 0 queries, 0 answers from cache, 0 recursions, 0 prefetch, 0 rejected by ip ratelimiting
[1730296502] unbound[6506:0] info: server stats for thread 0: requestlist max 0 avg 0 exceeded 0 jostled 0
[1730296502] unbound[6506:0] info: server stats for thread 1: 0 queries, 0 answers from cache, 0 recursions, 0 prefetch, 0 rejected by ip ratelimiting
[1730296502] unbound[6506:0] info: server stats for thread 1: requestlist max 0 avg 0 exceeded 0 jostled 0
[1730296502] unbound[6506:0] info: server stats for thread 2: 0 queries, 0 answers from cache, 0 recursions, 0 prefetch, 0 rejected by ip ratelimiting
[1730296502] unbound[6506:0] info: server stats for thread 2: requestlist max 0 avg 0 exceeded 0 jostled 0
[1730296502] unbound[6506:0] info: server stats for thread 3: 0 queries, 0 answers from cache, 0 recursions, 0 prefetch, 0 rejected by ip ratelimiting
[1730296502] unbound[6506:0] info: server stats for thread 3: requestlist max 0 avg 0 exceeded 0 jostled 0
[1730296503] unbound[6658:0] debug: module config: "subnetcache validator iterator"
[1730296503] unbound[6658:0] notice: init module 0: subnetcache
[1730296503] unbound[6658:0] warning: subnetcache: serve-expired is set but not working for data originating from the subnet module cache.
[1730296503] unbound[6658:0] warning: subnetcache: prefetch is set but not working for data originating from the subnet module cache.
[1730296503] unbound[6658:0] debug: subnetcache: option registered (8)
[1730296503] unbound[6658:0] notice: init module 1: validator
[1730296503] unbound[6658:0] notice: init module 2: iterator
[1730296503] unbound[6658:0] debug: target fetch policy for level 0 is 3
[1730296503] unbound[6658:0] debug: target fetch policy for level 1 is 2
[1730296503] unbound[6658:0] debug: target fetch policy for level 2 is 1
[1730296503] unbound[6658:0] debug: target fetch policy for level 3 is 0
[1730296503] unbound[6658:0] debug: target fetch policy for level 4 is 0
[1730296503] unbound[6658:0] debug: Forward zone server list:
[1730296503] unbound[6658:0] info: DelegationPoint<dns.quad9.net.>: 0 names (0 missing), 4 addrs (0 result, 4 avail) parentNS
[1730296503] unbound[6658:2] debug: Forward zone server list:
[1730296503] unbound[6658:2] info: DelegationPoint<dns.quad9.net.>: 0 names (0 missing), 4 addrs (0 result, 4 avail) parentNS
[1730296503] unbound[6658:0] debug: cache memory msg=66104 rrset=66104 infra=7952 val=66400 subnet=74536
[1730296503] unbound[6658:1] debug: Forward zone server list:
[1730296503] unbound[6658:1] info: DelegationPoint<dns.quad9.net.>: 0 names (0 missing), 4 addrs (0 result, 4 avail) parentNS
[1730296503] unbound[6658:0] info: start of service (unbound 1.19.2).
[1730296503] unbound[6658:2] debug: cache memory msg=66104 rrset=66104 infra=7952 val=66400 subnet=74536
[1730296503] unbound[6658:3] debug: Forward zone server list:
[1730296503] unbound[6658:3] info: DelegationPoint<dns.quad9.net.>: 0 names (0 missing), 4 addrs (0 result, 4 avail) parentNS
[1730296503] unbound[6658:1] debug: cache memory msg=66104 rrset=66104 infra=7952 val=66400 subnet=74536
[1730296503] unbound[6658:3] debug: cache memory msg=66104 rrset=66104 infra=7952 val=66400 subnet=74536
[1730297056] unbound[5388:0] debug: subnetcache[module 0] operate: extstate:module_state_initial event:module_event_new
[1730297056] unbound[5388:0] info: subnetcache operate: query google.com. A IN
[1730297056] unbound[5388:0] debug: validator[module 1] operate: extstate:module_state_initial event:module_event_pass
[1730297056] unbound[5388:0] info: validator operate: query google.com. A IN
[1730297056] unbound[5388:0] debug: iterator[module 2] operate: extstate:module_state_initial event:module_event_pass
[1730297056] unbound[5388:0] info: resolving google.com. A IN
[1730297056] unbound[5388:0] info: resolving (init part 2):  google.com. A IN
[1730297056] unbound[5388:0] info: resolving (init part 3):  google.com. A IN
[1730297056] unbound[5388:0] info: processQueryTargets: google.com. A IN
[1730297056] unbound[5388:0] info: sending query: google.com. A IN
[1730297056] unbound[5388:0] debug: sending to target: <google.com.> 216.239.38.10#53
[1730297056] unbound[5388:0] debug: cache memory msg=70045 rrset=100203 infra=29147 val=67208 subnet=74536
[1730297056] unbound[5388:0] debug: iterator[module 2] operate: extstate:module_wait_reply event:module_event_reply
[1730297056] unbound[5388:0] info: iterator operate: query google.com. A IN
[1730297056] unbound[5388:0] info: response for google.com. A IN
[1730297056] unbound[5388:0] info: reply from <google.com.> 216.239.38.10#53
[1730297056] unbound[5388:0] info: query response was ANSWER
[1730297056] unbound[5388:0] info: finishing processing for google.com. A IN
[1730297056] unbound[5388:0] debug: validator[module 1] operate: extstate:module_wait_module event:module_event_moddone
[1730297056] unbound[5388:0] info: validator operate: query google.com. A IN
[1730297056] unbound[5388:0] debug: subnetcache[module 0] operate: extstate:module_wait_module event:module_event_moddone
[1730297056] unbound[5388:0] info: subnetcache operate: query google.com. A IN
[1730297056] unbound[5388:0] debug: cache memory msg=70045 rrset=100203 infra=29147 val=67208 subnet=74536
[1730297130] unbound[5379:0] debug: subnetcache[module 0] operate: extstate:module_state_initial event:module_event_new
[1730297130] unbound[5379:0] info: subnetcache operate: query google.com. A IN
[1730297130] unbound[5379:0] debug: validator[module 1] operate: extstate:module_state_initial event:module_event_pass
[1730297130] unbound[5379:0] info: validator operate: query google.com. A IN
[1730297130] unbound[5379:0] debug: iterator[module 2] operate: extstate:module_state_initial event:module_event_pass
[1730297130] unbound[5379:0] info: resolving google.com. A IN
[1730297130] unbound[5379:0] info: resolving (init part 2):  google.com. A IN
[1730297130] unbound[5379:0] info: resolving (init part 3):  google.com. A IN
[1730297130] unbound[5379:0] info: processQueryTargets: google.com. A IN
[1730297130] unbound[5379:0] info: sending query: google.com. A IN
[1730297130] unbound[5379:0] debug: sending to target: <com.> 2001:503:83eb::30#53
[1730297130] unbound[5379:0] debug: cache memory msg=78073 rrset=130165 infra=41184 val=69264 subnet=74536
[1730297130] unbound[5379:0] debug: iterator[module 2] operate: extstate:module_wait_reply event:module_event_noreply
[1730297130] unbound[5379:0] info: iterator operate: query google.com. A IN
[1730297130] unbound[5379:0] info: processQueryTargets: google.com. A IN
[1730297130] unbound[5379:0] info: sending query: google.com. A IN
[1730297130] unbound[5379:0] debug: sending to target: <com.> 192.41.162.30#53
[1730297130] unbound[5379:0] debug: cache memory msg=78073 rrset=130165 infra=41184 val=69264 subnet=74536
[1730297130] unbound[5379:0] debug: iterator[module 2] operate: extstate:module_wait_reply event:module_event_reply
[1730297130] unbound[5379:0] info: iterator operate: query google.com. A IN
[1730297130] unbound[5379:0] info: response for google.com. A IN
[1730297130] unbound[5379:0] info: reply from <com.> 192.41.162.30#53
[1730297130] unbound[5379:0] info: query response was REFERRAL
[1730297130] unbound[5379:0] info: processQueryTargets: google.com. A IN
[1730297130] unbound[5379:0] info: sending query: google.com. A IN
[1730297130] unbound[5379:0] debug: sending to target: <google.com.> 216.239.32.10#53
[1730297130] unbound[5379:0] debug: cache memory msg=78073 rrset=132972 infra=41184 val=69414 subnet=74536
[1730297130] unbound[5379:0] debug: iterator[module 2] operate: extstate:module_wait_reply event:module_event_reply
[1730297130] unbound[5379:0] info: iterator operate: query google.com. A IN
[1730297130] unbound[5379:0] info: response for google.com. A IN
[1730297130] unbound[5379:0] info: reply from <google.com.> 216.239.32.10#53
[1730297130] unbound[5379:0] info: query response was ANSWER
[1730297130] unbound[5379:0] info: finishing processing for google.com. A IN
[1730297130] unbound[5379:0] debug: validator[module 1] operate: extstate:module_wait_module event:module_event_moddone
[1730297130] unbound[5379:0] info: validator operate: query google.com. A IN
[1730297130] unbound[5379:0] debug: subnetcache[module 0] operate: extstate:module_wait_module event:module_event_moddone
[1730297130] unbound[5379:0] info: subnetcache operate: query google.com. A IN
[1730297130] unbound[5379:0] debug: cache memory msg=78333 rrset=133364 infra=41492 val=69414 subnet=74536
networking

2 respostas

  1. Você pode deixar tsharkem execução no servidor enquanto resolve nomes de um cliente usando dig:

    sudo tshark -i eth0 -Y'ip.src == 192.168.1.50 and dns.qry.type == 1'

    no servidor (substituindo eth0pela interface usada pelo Unbound para se comunicar com o resolvedor externo) e, por exemplo

    dig @192.168.1.50 -p3000 askubuntu.com A

    no cliente.

    • -Y'ip.src == 192.168.1.50 and dns.qry.type == 1': configura um filtro para exibir apenas solicitações DNS do tipo 1 (A) provenientes do IP 192.168.1.50 (o servidor)

    Ao configurar tsharkdessa forma, qualquer solicitação DNS tipo 1 (A) proveniente do IP 192.168.1.50 (o servidor) que passar pela interface eth0no servidor será exibida, permitindo que você entenda facilmente se uma solicitação foi encaminhada ou resolvida pelo próprio Unbound porque o próprio Unbound era autoritativo para o nome/o nome foi armazenado em cache.

    Por exemplo, se eu deixar sudo tshark -i wlo1 -Y'ip.src == 192.168.1.93 and dns.qry.type == 1'em execução em um terminal e executar dig askubuntu.com Aem outro terminal, isso aparece (minha máquina está em 192.168.1.93 e está configurada para resolver nomes consultando 192.168.1.254):

    % sudo resolvectl flush-caches && sudo tshark -i wlo1 -Y'ip.src == 192.168.1.93 and dns.qry.type == 1'
Running as user "root" and group "root". This could be dangerous.
Capturing on 'wlo1'
    4 2.092316755 192.168.1.93 → 192.168.1.254 DNS 84 Standard query 0xa9f9 A askubuntu.com OPT
1 packet captured
    • 2
  2. Best Answer

    Descobri uma maneira de verificar isso por meio de checking /etc/unbound/unbound.log. O arquivo /etc/unbound/unbound.confdeve declarar esses atributos.

    server:
    # For debugging
    verbosity: 4   # default is 1
    log-time-ascii:     yes
    log-queries:        yes
    log-replies:        yes
    log-tag-queryreply: yes
    #log-destaddr:       yes  # not working
    log-local-actions:  yes
    log-servfail:       yes

    unbound.logconteria registros informando que:

    1. A consulta é encaminhada para DNS externo via TLS.

      info: sending query: cnn.com. A IN
debug: sending to target: <.> 9.9.9.9#853
...
debug: the query is using TLS encryption, for dns.quad9.net
...
debug: SSL connection to dns.quad9.net authenticated ip4 9.9.9.9 port 853 (len 16)

    2. O DNS externo respondendo:

        debug: process_response: new external response event
  ...
  info: response for cnn.com. A IN
  info: reply from <.> 9.9.9.9#853

    3. O endereço IP do domínio consultado:

        ;; ANSWER SECTION:
  cnn.com.   43  IN  A   151.101.195.5
  cnn.com.   43  IN  A   151.101.67.5
  cnn.com.   43  IN  A   151.101.131.5
  cnn.com.   43  IN  A   151.101.3.5

    Os logs mostrados na minha pergunta não continham essas linhas, pois não foram gerados usando esses atributos.

    • 2

relate perguntas