dnsmasq & systemd Causando Picos de CPU Intermitentes

Question

Problema:

Execução do Ubuntu 17.10

Estou tentando resolver (hehe) essa questão há uma semana e, apesar de inúmeras pesquisas no Google e cerca de 20 tentativas diferentes, não consigo impedir que o dnsmasq periodicamente faça com que minha CPU aumente durante cerca de um minuto com os seguintes infratores :

• systemd-resolved
• systemd-journald
• dnsmasq

Monitorando journalctl -f Eu vejo isso toda vez que acontece:

maximum number of concurrent dns queries reached (150)

Acompanhado / precedido por um loop maluco de pedidos para algum domínio (geralmente verificação de conexão do ubuntu) como o seguinte:

query[A] connectivity-check.ubuntu.com from 127.0.0.1
forwarded connectivity-check.ubuntu.com to 127.0.1.1
forwarded connectivity-check.ubuntu.com to 127.0.0.53
query[A] connectivity-check.ubuntu.com from 127.0.0.1
forwarded connectivity-check.ubuntu.com to 127.0.0.53
query[AAAA] connectivity-check.ubuntu.com from 127.0.0.1
forwarded connectivity-check.ubuntu.com to 127.0.0.53
query[AAAA] connectivity-check.ubuntu.com from 127.0.0.1
forwarded connectivity-check.ubuntu.com to 127.0.0.53
query[A] connectivity-check.ubuntu.com from 127.0.0.1
forwarded connectivity-check.ubuntu.com to 127.0.0.53
query[AAAA] connectivity-check.ubuntu.com from 127.0.0.1
forwarded connectivity-check.ubuntu.com to 127.0.0.53

Descobri que alterar meu /etc/resolv.conf para usar nameserver 127.0.0.53 faz com que o pico se dissipar quase instantaneamente.

No entanto, como esse arquivo é atualizado regularmente pelo Network Manager, tenho que fazer isso uma vez por hora.

Configuração:

/etc/resolv.conf

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.

nameserver 127.0.0.1
search fios-router.home

/etc/NetworkManager/NetworkManager.conf

[main]
plugins=ifupdown,keyfile

[ifupdown]
managed=false

[device]
wifi.scan-rand-mac-address=no

/etc/dnsmasq.conf

// All default except this at the very end for my wildcard DNS
address=/asmar.d/127.0.0.1

/run/dnsmasq/resolv.conf

nameserver 127.0.0.53

/ run / resolvconf / interfaces:

lo.dnsmasq :

nameserver 127.0.0.1

systemd-resolved :

nameserver 127.0.0.53

/ etc / resolvconf / interface-order:

# interface-order(5)
lo.inet6
lo.inet
lo.@(dnsmasq|pdnsd)
lo.!(pdns|pdns-recursor)
lo
tun*
tap*
hso*
em+([0-9])?(_+([0-9]))*
p+([0-9])p+([0-9])?(_+([0-9]))*
@(br|eth)*([^.]).inet6
@(br|eth)*([^.]).ip6.@(dhclient|dhcpcd|pump|udhcpc)
@(br|eth)*([^.]).inet
@(br|eth)*([^.]).@(dhclient|dhcpcd|pump|udhcpc)
@(br|eth)*
@(ath|wifi|wlan)*([^.]).inet6
@(ath|wifi|wlan)*([^.]).ip6.@(dhclient|dhcpcd|pump|udhcpc)
@(ath|wifi|wlan)*([^.]).inet
@(ath|wifi|wlan)*([^.]).@(dhclient|dhcpcd|pump|udhcpc)
@(ath|wifi|wlan)*
ppp*
*

systemd-resolve --status :

Global
         DNS Servers: 127.0.0.1
          DNSSEC NTA: 10.in-addr.arpa
                      16.172.in-addr.arpa
                      168.192.in-addr.arpa
                      17.172.in-addr.arpa
                      18.172.in-addr.arpa
                      19.172.in-addr.arpa
                      20.172.in-addr.arpa
                      21.172.in-addr.arpa
                      22.172.in-addr.arpa
                      23.172.in-addr.arpa
                      24.172.in-addr.arpa
                      25.172.in-addr.arpa
                      26.172.in-addr.arpa
                      27.172.in-addr.arpa
                      28.172.in-addr.arpa
                      29.172.in-addr.arpa
                      30.172.in-addr.arpa
                      31.172.in-addr.arpa
                      corp
                      d.f.ip6.arpa
                      home
                      internal
                      intranet
                      lan
                      local
                      private
                      test

Link 5 (br-b1f5461ac410)
      Current Scopes: none
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no

Link 4 (docker0)
      Current Scopes: none
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no

Link 3 (wlp62s0)
      Current Scopes: none
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no

Link 2 (enp61s0)
      Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
         DNS Servers: 8.8.8.8
                      8.8.4.4
                      ::1

Perguntas:

How can I resolve this issue while still using my wildcard domain name?

Optional: How can I achieve this while using Google DNS?

Por favor, não recomendo aumentar as consultas de DNS concorrentes. Isso não é uma solução.

RESOLVIDO!

Veja o curso intensivo de DNS do telcoM (a resposta aceita) que me levou à solução

Veja meu acompanhamento & solução final como eu experimentei com o conhecimento adquirido a partir dessa resposta

    

Answer 1

Parece que você pode ter dnsmasq process em 127.0.0.1 e systemd-resolved process em 127.0.0.53 passando consultas entre si, causando um loop. Mesmo dnsmasq sozinho pode ser capaz de fazer um loop, pois, por padrão, ele procura em /etc/resolv.conf para encontrar os servidores DNS reais a serem usados para os nomes para os quais não tem informações.

Sua configuração de DNS provavelmente tem muitas camadas:

• Primeiro, há as informações do servidor DNS obtidas do seu provedor por DHCP ou similar.
• então, há NetworkManager , que pode ser configurado para substituir as informações e usar dnsmasq , mas não está configurado dessa maneira.
• , em vez disso, NetworkManager está configurado para usar a ferramenta resolvconf para atualizar o% real/etc/resolv.conf. E dnsmasq pode incluir uma configuração de entrada para resolvconf para substituir quaisquer serviços DNS recebidos pelo DHCP e usar 127.0.0.1, enquanto dnsmasq estiver sendo executado.
• systemd-resolved também pode incluir uma configuração de entrada para resolvconf , mas aparentemente está sendo substituída por dnsmasq .

O que eu ainda não entendo é de onde vêm os 127.0.1.1 e 127.0.0.53. Eles são talvez mencionados na configuração padrão dnsmasq no Ubuntu?

Como está escrito no comentário de /etc/resolv.conf , execute este comando para ver mais informações sobre systemd-resolved configuration:

systemd-resolve --status

Verifique também o conteúdo do diretório /run/resolvconf/interface/ : é onde a ferramenta resolvconf coleta todas as informações do servidor DNS obtidas de várias origens. O /etc/resolvconf/interface-order determinará a ordem na qual cada fonte é verificada, até que um endereço de loopback seja encontrado ou 3 servidores DNS tenham sido listados para real /etc/resolv.conf .

Como você está usando dnsmasq para configurar um domínio curinga, convém manter 127.0.0.1 em seu /etc/resolv.conf , mas convém configurar dnsmasq para não usar esse arquivo, mas obtenha os servidores DNS que deve usar em algum outro lugar.

Se /run/NetworkManager/resolv.conf contiver os servidores DNS que você recebe do seu provedor pelo DHCP, você pode facilmente usá-lo para dnsmasq adicionando esta linha à sua configuração:

resolv-file=/run/NetworkManager/resolv.conf

Isso diz a dnsmasq onde obter informações de DNS para as coisas que ainda não conhecem. Então, se você quiser usar o DNS do Google, pode configurar dnsmasq com

resolv-file=/etc/google-dns-resolv.conf

e insira as linhas de configuração do DNS do DNS do Google no formato normal para /etc/google-dns-resolv.conf .

    

Answer 2

Corrigido o meu dnsmasq systemd-resolve race com o dnsmasq config.

1. Use systemd-resolve (127.0.0.53) para dns externos, como faz o dnssec e possui servidores raiz.
2. Apenas liga o dnsmasq ao loopback para algumas configurações estáticas, poderia adicionar mais interfaces se eu precisasse dele para o dhcp.

/etc/dnsmasq.d/myconfig

#PES 20180808 dnsmasq and systemd-resolve conflict.
# dont use /etc/resolv.conf, go direct to systemd-resolve, only bind to lo
no-resolv
bind-interfaces
interface=lo
server=127.0.0.53

    

Answer 3

I originally documented this as a part of the question as I was trying various solutions. This has been cut/pasted from that question into this answer for clarity, but this answer does not stand-alone without the insight provided in telcoM's answer.

Solução:

I have made the following change according to telcoM's suggestion below.

Criado /etc/google-dns-resolv.conf com o conteúdo:

nameserver 8.8.8.8
nameserver 8.8.4.4

Adicionada resolv-file=/etc/google-dns-resolv.conf a /etc/dnsmasq.conf

After making the change and running sudo service dnsmasq restart the CPU still spiked, but now rsyslogd entered into the mix of offenders. It settled down after about a minute, but I no longer saw 127.0.1.1 in journalctl -f.

Update: After ~10 minutes, the CPU has spiked again:

Update #2: Thanks to telcoM's excellent little DNS crash-course below and skepticism over where 127.0.0.53 was coming from, I dug in a bit (see my comments on his answer) and discovered it was coming from /run/dnsmasq/resolv.conf, which had the contents nameserver 127.0.0.53. I decided to update the contents to nameserver 127.0.0.1. Now, the only IP address I see output from journalctl -f is 127.0.0.1 and have not experienced a CPU spike since (going on ~10 mins now; which is at least as long as any period of rest my CPU has enjoyed prior)!

[SOLVED] Update #3: Using 127.0.0.1 in /run/dnsmasq/resolv.conf was foolish. It totally killed my DNS resolution (it appeared to work at first because I was only accessing cached DNSes). After switching to use Google nameservers (8.8.8.8 & 8.8.4.4) DNS resolution works again, my wildcard domains continue to work, and I am not experiencing CPU spikes. I'm going to see how this behaves for about an hour as I execute my typical day-to-day activities and update again accordingly; hopefully with a SOLVED!

Update #4: This appears to be solved now by following the steps in Update #3. Thank you telcoM for all of the excellent detail that steered me in the right direction. Bounty will be awarded when available in 15 hours.