O novo alerta continua aparecendo: o servidor retornou o erro NXDOMAIN, atenuando a possível violação de DNS DVE-2018-0001

Acabei de instalar um novo Ubuntu Server 18.04. Defino meu nome de host hostnamectl set-hostname ****.openbayou.bize defino /etc/hosts:

127.0.0.1 localhost
[ip address] ****.openbayou.biz hostname
# The following lines are desirable for IPv6 capable hosts
[ip6 address] *****.openbayou.biz hostname
::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

Também instalei o OSSEC para monitorar novos arquivos, erros e alterações no meu servidor e agora estou recebendo estes alertas:

Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018- 
0001, retrying transaction with reduced feature level UDP.`

Agora está se repetindo:

systemd-resolved[3195]: message repeated 4 times: [ Server returned error 
NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction 
with reduced feature level UDP.]

Procurei online uma solução e ninguém está relatando esse problema.

Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018- 0001, retrying transaction with reduced feature level UDP.

O mesmo erro aconteceu com a minha máquina desktop, não sei se também se aplica ao servidor.

Parece que meu sistema tinha a configuração antiga no local, resultando em um conflito entre dois serviços: resolvconfe systemd-resolved.

O link simbólico /etc/resolv.confapontou para../run/resolvconf/resolv.conf

Alterá-lo para apontar para o /run/systemd/resolve/resolv.confqual é gerenciado pelo systemd, corrigi-lo para mim.

Leia mais aqui .

Espero que tenha ajudado.

Perguntei no OSSEC GitHub sobre esse erro e eles recomendaram a criação de uma regra para ignorar os erros do NXDOMAIN. adicionar à/var/ossec/rules/local_rules.xml

<rule id="234567" level="0">
 <program_name>systemd-resolved</program_name>
 <match>Server returned error NXDOMAIN</match>
 <description>Usless systemd-resolvd log message</description>
</rule>

Este aviso é registrado por resolvido pelo sistema, sempre que um nome não puder ser resolvido pelo sistema DNS (por exemplo, nslookup www.kjfoiqaefah34876asdf.com). Isso pode ser tolerado e não há motivo para se alarmar. Isso não é erro e nada precisa ser corrigido.

Redirecionar /etc/resolv.conf para /run/systemd/resolve/resolv.conf está errado, porque dessa maneira systemd-resolved é ignorado e o aplicativo com a solicitação DNS com defeito fala diretamente com o servidor de nomes e não com o systemd-resolved esboço mais. Dessa forma, systemd-resolved não percebe mais os eventos NXDOMAIN e, portanto, não pode mais registrá-los.

Os eventos NXDOMAIN são causados ​​por pacotes, que tentam acessar servidores não existentes durante a inicialização do sistema.

Notei a mesma coisa em um servidor Ubuntu 18.04 que foi atualizado recentemente para 18.04.1.

Parece que a resolução do sistema registra essa mensagem sempre que obtém qualquer resposta NXDOMAIN. No meu caso, tenho o postfix em execução. Portanto, recebo muitos NXDOMAINS quando servidores aleatórios se conectam sem o registro PTR definido.

Você pode testá-lo com

systemd-resolve securelogin.example.com

Então você deve ver a mensagem de log aparecer.

Com isso em mente, parece ser um erro relativamente inócuo e você pode ignorá-lo.

Meu entendimento, depois de ler as respostas anteriores e outras páginas da Web, como o erro NXDOMAIN do Ubuntu 18.04, resolvido pelo sistema, é que isso é mais um aviso do que um erro e não há nada que eu possa fazer do meu lado.

Portanto, concordo com aqueles que dizem que não devemos tentar fazer algo do nosso lado para que essas mensagens não sejam mais produzidas. Se tivermos sucesso, é provável que tenhamos alterado a maneira normal como o sistema resolve as solicitações de DNS.

No entanto, como tenho milhares deles (também estou em uma área de trabalho - não é um servidor), não os quero no meu arquivo syslog. Portanto, seguindo https://www.rsyslog.com/doc/v8-stable/configuration/filters.html e número par prefixo para arquivos de configuração , eu adicionei um arquivo nomeado 10-resolv.confcom uma única linha :msg, contains, "Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP" ~no diretório /etc/rsyslog.d .

O nome 10-resolv.confnão é importante, mas deve preceder todos os outros nomes de arquivos no diretório em ordem alfabética. O comando :msg, contains, <message-part> ~diz que todas as mensagens que contêm <parte da mensagem> devem ser ignoradas: o til ~no comando diz para descartar a mensagem.

Nota adicionada: como escrevi esta resposta, instalei alguns pacotes (por outros motivos) e a mensagem de erro não é mais produzida conforme verificado journalctl -u systemd-resolved -f. Um pacote instalado que pode explicar o desaparecimento desta mensagem é libnss-resolve.

Resumo:

A mensagem de erro NXDOMAIN significa que um domínio não existe.

Alguns ISPs iniciaram o seqüestro de DNS ou o redirecionamento de DNS para mensagens de erro NXDOMAIN. É a prática de redirecionar a resolução de nomes DNS (Sistema de Nomes de Domínio) para outros servidores DNS ou servidores Web.

Comumente usado para exibir anúncios ou coletar estatísticas.

Essa prática viola o padrão RFC para respostas DNS (NXDOMAIN).

Phishing: ataques de script entre sites podem ocorrer devido a seqüestros maliciosos.

Censura: provedores de serviços DNS para bloquear o acesso aos domínios selecionados.

Mostrado aqui: https://www.dnsknowledge.com/whatis/nxdomain-non-existent-domain-2/

Consegui me livrar da mensagem e, finalmente, também consegui me conectar ao meu servidor samba, alterando o nome do servidor para em server.domainvez de apenas server.

Isso parece relacionado ao EDNS. A diferença entre usar stub-resolv.confe resolv.confé options edns0.

Mecanismos de extensão para DNS (EDNS) é uma especificação para expandir o tamanho de vários parâmetros do protocolo DNS (Domain Name System) que tinham restrições de tamanho que a comunidade de engenharia da Internet considerou muito limitada para aumentar a funcionalidade do protocolo.

https://en.wikipedia.org/wiki/Extension_mechanisms_for_DNS

Mais detalhes nesta edição: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1766969

Parece que você pode simplesmente desativar essa "opção".

Problema

Embora possa haver outras circunstâncias em que esse erro ocorrerá, posso definitivamente dizer que já o vi vomitar na saída de:

systemctl status systemd-resolved

... quando systemd-resolvednão está configurado.

E uma VM do Ubuntu 18.04 do Azure não está systemd-resolvedconfigurada pronta para uso (a partir de hoje, 20191008).

Solução:

Configure systemd-resolved.

Como fazer com a mini systemd-resolvedconfiguração:

NOTA : As instruções a seguir foram preparadas usando o Ubuntu 18.04

Edite a hostsdiretiva /etc/nsswitch.confanexando o resolveque define o systemd-resolved como a primeira fonte de resolução de DNS que será consultada:

hosts:          resolve files dns

Edit /etc/systemd/resolved.conf. Algumas configurações sugeridas:

[Resolve]
DNS=8.8.8.8 8.8.4.4
#FallbackDNS=
#Domains=
#LLMNR=no
#MulticastDNS=no
#DNSSEC=no
Cache=yes
DNSStubListener=yes

Reiniciar systemd-resolved:

sudo systemctl restart systemd-resolved

Quando você verificar systemd-resolvedo status da próxima vez , o erro agora deve ser limpo:

systemctl status systemd-resolved

E a resolução do DNS agora deve se comportar da maneira esperada.