Server returned error nxdomain

I’m running an Ubuntu server (18.04.1) and since a couple of days I see these messages in the syslog:

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

At the time of those messages I’m not able to reach my server from the outside world, only from my internal lan.
It takes a couple of minutes and then the server is reachable again from its domain name.

Output of syslog:

11/5/18
1:51:02.000 PM  
Nov  5 13:51:02 server systemd-resolved[1059]: message repeated 12 times: [ Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP.]
host =  server source = /var/log/syslog sourcetype =    syslog
11/5/18
1:50:59.000 PM  
Nov  5 13:50:59 server systemd-resolved[1059]: Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP.
host =  server source = /var/log/syslog sourcetype =    syslog
11/5/18
1:50:39.000 PM  
Nov  5 13:50:39 server snapd[1255]: stateengine.go:102: state ensure error: Get https://api.snapcraft.io/api/v1/snaps/sections: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
host =  server source = /var/log/syslog sourcetype =    syslog
11/5/18
1:44:20.000 PM  
Nov  5 13:44:20 server systemd-resolved[1059]: message repeated 5 times: [ Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP.]
host =  server source = /var/log/syslog sourcetype =    syslog
11/5/18
1:44:20.000 PM  
Nov  5 13:44:20 server systemd-resolved[1059]: Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP.
host =  server source = /var/log/syslog sourcetype =    syslog
11/5/18
1:15:24.000 PM  
Nov  5 13:15:24 server systemd-resolved[1059]: Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP.
host =  server source = /var/log/syslog sourcetype =    syslog
11/5/18
1:15:24.000 PM  
Nov  5 13:15:24 server systemd-resolved[1059]: Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP.
host =  server source = /var/log/syslog sourcetype =    syslog
11/5/18
1:07:27.000 PM  
Nov  5 13:07:27 server systemd-resolved[1059]: message repeated 5 times: [ Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP.]
host =  server source = /var/log/syslog sourcetype =    syslog
11/5/18
1:07:27.000 PM  
Nov  5 13:07:27 server systemd-resolved[1059]: Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP.
host =  server source = /var/log/syslog sourcetype =    syslog
11/5/18
12:49:57.000 PM 
Nov  5 12:49:57 server systemd-resolved[1059]: message repeated 12 times: [ Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP.]

I couldn’t find a proper answer by Googling this error message.

Can anyone help me?

In new installations of Mint 20, the following regression is experienced with the result of 50+ NXDOMAIN errors within seconds of booting and then the error continuing, resulting in tens of thousands of occurrences in error logs.

Errors:
Sender: systemd-resolve

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

While some may consider this as a «nuisance», the systemd conflicts of 3 different resolvers existing in new builds creates an out of compliance to standards scenario that also (appears out of the blue) to have an uncommented file that forcefully injects Google DNS (without user knowledge or consent and where it should never exist) while also creating a potential security vulnerability.

The result is endless journal spamming to unmanageable levels (an error that repeats endlessly yet neither describes what is going on, nor why it is occurring).

This test build has existed for only 24-hours and there are already over 3,000 occurrences of this error being reported in journals.

See: https://bugs.launchpad.net/ubuntu/+sour … ug/1727237
https://github.com/systemd/systemd/pull/8608

Sources:

/usr/share/linuxmint/mintsystem/templates/resolv.conf <— Unauthorized Google DNS Offender
/lib/systemd/resolv.conf <— Internal
/run/systemd/resolve/resolv.conf <— Accurate Uplink DNS
/etc/resolv.conf symbolic link
/usr/bin/systemd-resolve <— (Nemo reports as «Link to unknown») Broken symbolic link or insufficient permissions?

While none of this seems to display results outside the norms of systemd specifications (except that google «Fix»), there doesn’t appear to be any errors in resolvectl status output indicating no adapter errors nor internal routing errors which would mean there shouldn’t be any NXDOMAIN errors reporting to logs at all. As the logs don’t report the offending source, it is impossible to identify the offending source without tracing to identify.

In the case of testing this with a DNSSEC LAN disabled router, the output appears normal.

Global
       LLMNR setting: no                  
MulticastDNS setting: no                  
  DNSOverTLS setting: no                  
      DNSSEC setting: no                  
    DNSSEC supported: no                  
          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 3 (wlp2s0)
      Current Scopes: DNS        
DefaultRoute setting: yes        
       LLMNR setting: yes        
MulticastDNS setting: no         
  DNSOverTLS setting: no         
      DNSSEC setting: no         
    DNSSEC supported: no         
  Current DNS Server: 192.168.1.1
         DNS Servers: 192.168.1.1
          DNS Domain: ~.         
                      local.tld  

Link 2 (enp3s0f1)
      Current Scopes: DNS        
DefaultRoute setting: yes        
       LLMNR setting: yes        
MulticastDNS setting: no         
  DNSOverTLS setting: no         
      DNSSEC setting: no         
    DNSSEC supported: no         
  Current DNS Server: 192.168.1.1
         DNS Servers: 192.168.1.1
          DNS Domain: ~.         
                      local.tld  

Given this reality, there should be no NXDOMAIN errors as DNSSEC is never enabled in the first place.

See: https://wiki.archlinux.org/index.php/Systemd-resolved

Results: /etc/systemd/resolved.conf

#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.
#
# Entries in this file show the compile time defaults.
# You can change settings by editing this file.
# Defaults can be restored by simply deleting this file.
#
# See resolved.conf(5) for details

[Resolve]
#DNS=
#FallbackDNS=
#Domains=
#LLMNR=no
#MulticastDNS=no
#DNSSEC=no
#DNSOverTLS=no
#Cache=no-negative
#DNSStubListener=yes
#ReadEtcHosts=yes

When using a DNSSEC enabled router:
With Gigabit Wired Enabled — 2 Errors are reported at boot
With Wireless Enabled 4 Errors are reported at boot
With Both Wired & Wireless Enabled at boot 6 Errors are reported (default configuration).
Inexplicable results.

Separate; but noteworthy:
Linux Mint 20 enables IPv6 in all connections by default and even where no upstream IPv6 exists, creates IPv6 addresses for all NICs.
When IPv6 is forcibly disabled, those IPv6 addresses remain assigned with no ability found to delete them.

Страницы: [1] 2  Все   Вниз

0 Пользователей и 1 Гость просматривают эту тему.

Страницы: [1] 2  Все   Вверх

Что такое DNS и как работает?

Чтобы понять, что Ошибка NXDOMAIN есть, мы должны сначала вспомнить, что DNS есть и как это работает. Можно сказать, что DNS-серверы действуют как переводчики, позволяя нам просматривать Интернет без запоминания большого количества цифр.

При входе на веб-страницу мы обычно переходим в адресную строку браузера и пишем там имя и адрес. Например, мы пишем redeszone.net. Мы можем это сделать благодаря DNS-серверы которые переводят это сообщение, которое мы пишем, на соответствующий IP-адрес. Таким образом, нам не нужно запоминать, что это за IP-адрес, а просто имя, которое мы пишем.

Таким образом, DNS-серверы действуют как посредники, чтобы иметь возможность отвечать на запросы что мы делаем. Есть много DNS-серверов, которые мы можем использовать. Бывают платные и бесплатные. Некоторые даже могут помочь нам повысить безопасность, поскольку они настроены на фильтрацию возможных вредоносных страниц, а не на отправку содержимого. Иногда смена серверов нашего интернет-оператора может помочь улучшить скорость.

Теперь, иногда в этом типе услуг могут быть проблемы и сбой при поиске в Интернете. Вот тут и возникает ошибка NXDOMAIN, о которой мы и поговорим.

Когда мы пытаемся войти на веб-страницу и получаем сообщение об ошибке с указанием NXDOMAIN, это означает, что имя домена не может быть разрешено. Это логически означает, что мы не можем перемещаться по сайту, к которому пытаемся получить доступ.

Отображаемое сообщение может незначительно отличаться. Например, в Google Chrome в браузере появившееся сообщение будет DNS_PROBE_FINISHED_NXDOMAIN . Это означает, что страница, на которую мы пытаемся войти, загружается некорректно.

Возможные причины ошибки NXDOMAIN

Эта ошибка может возникать по разным причинам. Иногда это может быть в наших силах исправить, а в других случаях это зависит от сервера сайта. Посмотрим, что за Основные причины составляют:

• DNS-сервер не работает
• Проблема с DNS-клиентом
• VPN мешает
• Установленные средства безопасности
• Неправильные настройки DNS
• Проблемы с браузером

Как исправить ошибку NXDOMAIN

К счастью, мы можем принять во внимание определенные шаги, чтобы решить Ошибка NXDOMAIN . Это, как мы уже упоминали, может произойти в любом браузере, который мы используем, поэтому совет, который мы собираемся дать, является общим, и мы можем применить его в любом случае.

Некоторые проблемы, вызывающие эту ошибку, мы не сможем решить с нашей стороны, например, когда они присутствуют на стороне сервера.

Изменить DNS

Проблемы такого типа могут быть связаны с ошибками DNS-серверы что мы используем. Мы уже упоминали, что можем использовать много разных, как бесплатных, так и платных.

В случае появления такого типа сообщения мы можем попробовать выбрать другой общедоступный DNS, чем те, которые мы используем. Мы можем легко изменить их в Windows, через настройки сети. Для этого заходим в Конфигурацию, Cеть и Интернет, мы вводим Параметры смены адаптера и там выбираем интересующую нас сеть, нажимаем Свойства и откроется окно для изменения IP-адреса и DNS.

Избегайте использования VPN

Мы также видели, что причиной ошибки NXDOMAIN является то, что мы используем VPN и это создает конфликт. Мы можем временно приостановить работу этого инструмента и проверить, действительно ли это связано с этой проблемой.

Если мы обнаружим, что это действительно VPN, мы можем либо не использовать его, либо переключиться на другую службу.

Проверьте, не мешает ли какой-либо антивирус или брандмауэр

Также могло случиться, что антивирус или брандмауэр которые мы используем, создавали проблемы. Мы уже знаем, что инструменты безопасности необходимы для предотвращения сетевых проблем, но они также могут вызвать определенные сбои при неправильной конфигурации.

Обеспечьте бесперебойную работу браузера

Конечно браузер должен работать правильно . Вы должны быть осторожны, например, если используете плохо настроенные расширения. Мы должны убедиться, что все, что окружает браузер, работает правильно, и, таким образом, исправить возможные ошибки, вызывающие эту проблему, чтобы правильно разрешить доменные имена.

Перезагрузить систему

Это базовое решение, но во многих случаях оно может решить проблемы такого типа. Мы должны перезапуск и наш компьютер, и сам роутер. Таким образом, мы можем исправить подобные и подобные ошибки.

В конечном счете, это некоторые варианты, которые мы должны решить, когда появляется ошибка NXDOMAIN.