Início / ubuntu / Perguntas / 1531438
Accepted
Sun Bear
Asked: 2024-10-29 10:49:26 +0800 CST

Por que a interface: 0.0.0.0 está causando falha ao reiniciar o unbound.service?

  • 772

unbound.serviceé executado sem erro quando estes 3 arquivos padrão (criados após a instalação do unbound) são usados:

root@DNS:/etc/unbound# cat unbound.conf
# Unbound configuration file for Debian.
#
# See the unbound.conf(5) man page.
#
# See /usr/share/doc/unbound/examples/unbound.conf for a commented
# reference config file.
#
# The following line includes additional configuration files from the
# /etc/unbound/unbound.conf.d directory.
include-toplevel: "/etc/unbound/unbound.conf.d/*.conf"
root@DNS:/etc/unbound# cat unbound.conf.d/remote-control.conf 
remote-control:
  control-enable: yes
  # by default the control interface is is 127.0.0.1 and ::1 and port 8953
  # it is possible to use a unix socket too
  control-interface: /run/unbound.ctl
root@DNS:/etc/unbound# cat unbound.conf.d/root-auto-trust-anchor-file.conf 
server:
    # The following line will configure unbound to perform cryptographic
    # DNSSEC validation using the root trust anchor.
    auto-trust-anchor-file: "/var/lib/unbound/root.key"

No entanto, quando esses 3 arquivos são removidos e o conteúdo é /etc/unbound/unbound.conffeito para conter

# unbound.conf(5) config file for unbound(8).
server:
    directory: "/etc/unbound"
    username: "unbound"
    # make sure unbound can access entropy from inside the chroot.
    # e.g. on linux the use these commands (on BSD, devfs(8) is used):
    #      mount --bind -n /dev/urandom /etc/unbound/dev/urandom
    # and  mount --bind -n /dev/log /etc/unbound/dev/log
    #chroot: "/etc/unbound"
    # logfile: "/etc/unbound/unbound.log"  #uncomment to use logfile.
    pidfile: "/etc/unbound/unbound.pid"
    # verbosity: 1      # uncomment and increase to get more logging.
    # listen on all interfaces, answer queries from the local subnet.
    interface: 0.0.0.0
    interface: ::0
    access-control: 10.0.0.0/8 allow
    #access-control: 2001:DB8::/64 allow

unbound.servicefalha ao reiniciar usando service unbound restart. por exemplo

root@DNS:/etc/unbound# service unbound restart
Job for unbound.service failed because the control process exited with error code.
See "systemctl status unbound.service" and "journalctl -xeu unbound.service" for details.
root@DNS:/etc/unbound# systemctl status unbound.service
× unbound.service - Unbound DNS server
     Loaded: loaded (/usr/lib/systemd/system/unbound.service; disabled; preset: enabled)
     Active: failed (Result: exit-code) since Mon 2024-10-28 16:01:59 UTC; 18s ago
   Duration: 50min 13.453s
       Docs: man:unbound(8)
    Process: 3385 ExecStartPre=/usr/libexec/unbound-helper chroot_setup (code=exited, status=0/SUCCESS)
    Process: 3388 ExecStartPre=/usr/libexec/unbound-helper root_trust_anchor_update (code=exited, status=0/SUCCESS)
    Process: 3391 ExecStart=/usr/sbin/unbound -d -p $DAEMON_OPTS (code=exited, status=1/FAILURE)
    Process: 3393 ExecStopPost=/usr/libexec/unbound-helper chroot_teardown (code=exited, status=0/SUCCESS)
   Main PID: 3391 (code=exited, status=1/FAILURE)
        CPU: 168ms

Oct 28 16:01:59 DNS systemd[1]: unbound.service: Scheduled restart job, restart counter is at 5.
Oct 28 16:01:59 DNS systemd[1]: unbound.service: Start request repeated too quickly.
Oct 28 16:01:59 DNS systemd[1]: unbound.service: Failed with result 'exit-code'.
Oct 28 16:01:59 DNS systemd[1]: Failed to start unbound.service - Unbound DNS server.

Para solucionar o problema, comentei cada linha, seguido de descomentei cada linha até que unbound.servicefalhou ao reiniciar. Descobri que a linha interface: 0.0.0.0é a causa do erro. Não consigo descobrir o que 0.0.0.0está causando o problema. Por que esse endereço IP está causando esse problema?

Sistema:

  • Versão não consolidada: 1.19.2
  • SO: Linux DNS 6.1.63 #218 SMP Qui Nov 30 20:48:04 CST 2023 aarch64 aarch64 aarch64 GNU/Linux no Ubuntu Server 24.04.1
  • unbound -Vsaída:
root@DNS::/etc/unbound# unbound -V
Version 1.19.2

Configure line: --build=aarch64-linux-gnu --prefix=/usr --includedir=${prefix}/include --mandir=${prefix}/share/man --infodir=${prefix}/share/info --sysconfdir=/etc --localstatedir=/var --disable-option-checking --disable-silent-rules --libdir=${prefix}/lib/aarch64-linux-gnu --runstatedir=/run --disable-maintainer-mode --disable-dependency-tracking --with-pythonmodule --with-pyunbound --enable-subnet --enable-dnstap --enable-systemd --enable-cachedb --with-libhiredis --with-libnghttp2 --with-chroot-dir= --with-dnstap-socket-path=/run/dnstap.sock --disable-rpath --with-pidfile=/run/unbound.pid --with-libevent --enable-tfo-client --with-rootkey-file=/usr/share/dns/root.key --disable-flto --enable-tfo-server
Linked libs: libevent 2.1.12-stable (it uses epoll), OpenSSL 3.0.13 30 Jan 2024
Linked modules: dns64 python cachedb subnetcache respip validator iterator
TCP Fastopen feature available


BSD licensed, see LICENSE in source package for details.
Report bugs to [email protected] or https://github.com/NLnetLabs/unbound/issues

Atualizar:

root@DNS:/etc/unbound# unbound -d -vv -c /etc/unbound/unbound.conf
[1730176049] unbound[4263:0] notice: Start of unbound 1.19.2.
[1730176049] unbound[4263:0] error: can't bind socket: Address already in use for 0.0.0.0 port 53
[1730176049] unbound[4263:0] fatal error: could not open ports
networking

2 respostas

  1. Best Answer
    error: can't bind socket: Address already in use for 0.0.0.0 port 53

    Isso provavelmente ocorre porque systemd-resolvedo stub DNS listener do está escutando no mesmo endereço/porta (como sugerido também na sua pergunta anterior).

    O curso lógico de ação seria:

    1. Configurando o Unbound para iniciar em uma porta diferente (mesmo uma alta, apenas para teste), adicionando, digamos, port: 3000a /etc/unbound/unbound.conf;
    2. Concluindo a configuração do Unbound;
    3. Iniciando sem limites: 
      systemctl start unbound
    4. Testando a resolução de DNS na porta #3000 usando dig -p3000 [...];
    5. Quando tudo estiver funcionando, desabilite systemd-resolvedo listener do , remova port: 3000e /etc/unbound/unbound.confreinicie ambos systemd-resolvede o Unbound.

    Para desabilitar systemd-resolvedo listener do , crie um diretório /etc/systemd/resolved.conf.dcontendo um arquivo chamado, por exemplo, 10-disable-listener.confcontendo o seguinte:

    [Resolve]
DNSStubListener=no

    Então, para reiniciar ambos systemd-resolvede Unbound:

    systemctl restart systemd-resolved unbound
    • 2

  2. Agradeço ao @kos pela resposta .

    Após resolver o problema da porta, outro problema que surgiu foi que o arquivo /etc/unbound/unbound.lognão tinha a permissão de arquivo correta, dado que "unbound"and not "root"foi declarado como o username:em /etc/unbound/unbound.conf. Portanto, o unbound.serviceainda falhou ao iniciar.

    Para resolver esse problema, fiz o seguinte:

    1. Parado e desabilitado unbound.service.

      systemctl stop unbound.service
systemctl disable unbound.service

    2. Criei um novo usuário chamado unboundcomo membro principal de um novo grupo chamado unboundusando este comando:

      useradd -r -U -u 997 -c Unbound -d /etc/unbound/ -s /sbin/nologin unbound

    3. Alterou a associação de grupo do diretório /etc/unbounde todos os seus arquivos e diretórios filhos de rootpara unboundcom este comando:

      chgrp -hR unbound /etc/unbound/

    4. Concedeu permissão de gravação para a associação de grupo do diretório /etc/unbounde todos os seus arquivos e diretórios filhos:

      chmod -R g+w /etc/unbound/

    Executar o comando unbound -d -vv -c /etc/unbound/unbound.confpara iniciar o serviço no modo de depuração confirmou que a /etc/unbound/unbound.logfalha de permissão foi resolvida. Depois disso, reiniciei unbound.servicecom o comando systemctl restart unbound.service.

    • 1

relate perguntas