In Ubuntu 24.10 systemd-resolved often goes comatose and stops resolving everything. The following messages are logged:

Apr 21 12:50:27 localhost systemd-resolved: [🡕] DNSSEC validation failed for question optimizationguide-pa.googleapis.com IN DS: failed-auxiliary
Apr 21 12:50:27 localhost systemd-resolved: [🡕] DNSSEC validation failed for question optimizationguide-pa.googleapis.com IN SOA: failed-auxiliary
Apr 21 12:50:27 localhost systemd-resolved: [🡕] DNSSEC validation failed for question optimizationguide-pa.googleapis.com IN A: failed-auxiliary
Apr 21 12:50:27 localhost systemd-resolved: [🡕] DNSSEC validation failed for question optimizationguide-pa.googleapis.com IN AAAA: failed-auxiliary

The bug is known however still not fixed in this version of Ubuntu: https://github.com/systemd/systemd/issues/34896

Let's say I have inside of my hosts file an entry for foobar, how do I find out if that file is used or if a remote DNS is answering the resolution for foobar? Do any of the basic utilities give back that information? dig +trace isn't showing me what I want to know dig +trace localhost ; > DiG 9.10.3-P4-Ubuntu > +trace localhost ;; global options: +cmd ;; Received 28 bytes from 127.0.0.53#53(127.0.0.53) in 0 ms dig +trace google.com ; > DiG 9.10.3-P4-Ubuntu > +trace google.com ;; global options: +cmd ;; Received 28 bytes from 127.0.0.53#53(127.0.0.53) in 0 ms I would expect it to tell me that the lookup is resolving to hosts for localhost and my dns server (whichever one) for google.com. If I make a call internally using [getaddrinfo(3)](https://en.wikipedia.org/wiki/Getaddrinfo) is it hitting the hosts file or the upstream dns server when resolving localhost.

**Update** After uninstalling and re-installing systemd-resolved, the issue seems to have righted itself. I do not understand why, but I did notice that the /etc/resolv.conf does not get modified after installing systemd-resolved for the second time, where it was modified the first time I installed the package. **Problem:** I'm trying to follow the Home-Assistant supervised installer instructions here on my Orange Pi Zero running Debian. This was set up from a netboot image. After installing the systemd-resolved package, the system can no longer look up website addresses. Uninstalling the package resolves the issue. This is the error: Temporary failure resolving 'deb.debian.org' **Observations:** This did not happen when using an Armbian image for my unit, but Home-Assistant does not support Armbian, so I am trying with Debian instead. I can't ping web addresses (or .locals on my network), but I can ping IP addresses. **Working vs expected working:** Expected (working before installing systemd-resolved) jodie@orangePiZero:~$ wget -O homeassistant-supervised.deb https://github.com/home-assistant/supervised-installer/releases/latest/download/homeassistant-supervised.deb --2023-11-22 00:00:49-- https://github.com/home-assistant/supervised-installer/releases/latest/download/homeassistant-supervised.deb Resolving github.com (github.com)... 20.87.245.0 Connecting to github.com (github.com)|20.87.245.0|:443... connected. HTTP request sent, awaiting response... 302 Found Location: https://github.com/home-assistant/supervised-installer/releases/download/1.5.0/homeassistant-supervised.deb [following] --2023-11-22 00:00:50-- https://github.com/home-assistant/supervised-installer/releases/download/1.5.0/homeassistant-supervised.deb Reusing existing connection to github.com:443. HTTP request sent, awaiting response... 302 Found Location: https://objects.githubusercontent.com/github-production-release-asset-2e65be/183216119/905cc380-f350-4a95-ac33-a2749b7858fa?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20231121%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20231121T220050Z&X-Amz-Expires=300&X-Amz-Signature=21a10eb8987bbe62d3a2826be9ba66ed9476dbbe6015990ad0fb53b46db6224f&X-Amz-SignedHeaders=host&actor_id=0&key_id=0&repo_id=183216119&response-content-disposition=attachment%3B%20filename%3Dhomeassistant-supervised.deb&response-content-type=application%2Foctet-stream [following] --2023-11-22 00:00:50-- https://objects.githubusercontent.com/github-production-release-asset-2e65be/183216119/905cc380-f350-4a95-ac33-a2749b7858fa?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20231121%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20231121T220050Z&X-Amz-Expires=300&X-Amz-Signature=21a10eb8987bbe62d3a2826be9ba66ed9476dbbe6015990ad0fb53b46db6224f&X-Amz-SignedHeaders=host&actor_id=0&key_id=0&repo_id=183216119&response-content-disposition=attachment%3B%20filename%3Dhomeassistant-supervised.deb&response-content-type=application%2Foctet-stream Resolving objects.githubusercontent.com (objects.githubusercontent.com)... 185.199.108.133, 185.199.109.133, 185.199.110.133, ... Connecting to objects.githubusercontent.com (objects.githubusercontent.com)|185.199.108.133|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 6504 (6.4K) [application/octet-stream] Saving to: ‘homeassistant-supervised.deb’ homeassistant-supervised.d 100%[=======================================>] 6.35K --.-KB/s in 0.002s 2023-11-22 00:00:51 (2.50 MB/s) - ‘homeassistant-supervised.deb’ saved [6504/6504] Not working: jodie@orangePiZero:~$ wget -O homeassistant-supervised.deb https://github.com/home-assistant/supervised-installer/releases/latest/download/homeassistant-supervised.deb --2023-11-22 17:11:35-- https://github.com/home-assistant/supervised-installer/releases/latest/download/homeassistant-supervised.deb Resolving github.com (github.com)... failed: Temporary failure in name resolution. wget: unable to resolve host address ‘github.com’ **Network setup:** I have a tp-link home router set with a DHCP address reservation for this device's MAC address. It's on the same subnet as my other devices and does not specify a different DNS server. I can still ssh into the device (which is how I'm primarily setting it up) **Question:** Is there a configuration I need to set for DNS to work with systemd-resolved? **Requested info:** Contents of /etc/resolv.conf before installing systemd-resolved: nameserver 192.168.0.1 nameserver 0.0.0.0 Contents after first install: # This is /run/systemd/resolve/stub-resolv.conf managed by man:systemd-resolved(8). # Do not edit. # # This file might be symlinked as /etc/resolv.conf. If you're looking at # /etc/resolv.conf and seeing this text, you have followed the symlink. # # This is a dynamic resolv.conf file for connecting local clients to the # internal DNS stub resolver of systemd-resolved. This file lists all # configured search domains. # # Run "resolvectl status" to see details about the uplink DNS servers # currently in use. # # Third party programs should typically not access this file directly, but only # through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a # different way, replace this symlink by a static file or a different symlink. # # See man:systemd-resolved.service(8) for details about the supported modes of # operation for /etc/resolv.conf. nameserver 127.0.0.53 options edns0 trust-ad search . Contents after uninstall and re-install: nameserver 192.168.0.1 nameserver 0.0.0.0 Contents of /etc/nsswitch.conf before installing systemd-resolved: # /etc/nsswitch.conf # # Example configuration of GNU Name Service Switch functionality. # If you have the glibc-doc-reference' and info' packages installed, try: # `info libc "Name Service Switch"' for information about this file. passwd: files systemd group: files systemd shadow: files systemd gshadow: files systemd hosts: files dns networks: files protocols: db files services: db files ethers: db files rpc: db files netgroup: nis Contents after first install of systemd-resolved: # /etc/nsswitch.conf # # Example configuration of GNU Name Service Switch functionality. # If you have the glibc-doc-reference' and info' packages installed, try: # `info libc "Name Service Switch"' for information about this file. passwd: files systemd group: files systemd shadow: files systemd gshadow: files systemd hosts: files resolve [!UNAVAIL=return] dns myhostname networks: files protocols: db files services: db files ethers: db files rpc: db files netgroup: nis Contents after uninstall and re-install of systemd-resolved # /etc/nsswitch.conf # # Example configuration of GNU Name Service Switch functionality. # If you have the glibc-doc-reference' and info' packages installed, try: # `info libc "Name Service Switch"' for information about this file. passwd: files systemd group: files systemd shadow: files systemd gshadow: files systemd hosts: files resolve [!UNAVAIL=return] dns myhostname networks: files protocols: db files services: db files ethers: db files rpc: db files netgroup: nis **Other info** This is the result of running resolvectl status: jodie@orangePiZero:~$ resolvectl status Failed to get global data: Connection timed out This is the output of systemctl status systemd-resolved: jodie@orangePiZero:~$ systemctl status systemd-resolved ● systemd-resolved.service - Network Name Resolution Loaded: loaded (/lib/systemd/system/systemd-resolved.service; enabled; preset: enabled) Active: active (running) since Tue 2023-11-21 23:09:21 SAST; 24min ago Docs: man:systemd-resolved.service(8) man:org.freedesktop.resolve1(5) https://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients Main PID: 577 (systemd-resolve) Status: "Processing requests..." Tasks: 1 (limit: 1075) Memory: 2.3M CPU: 847ms CGroup: /system.slice/systemd-resolved.service └─577 /lib/systemd/systemd-resolved

I tried to use host command for my blog jfeatures.com and getting error (SERVFAIL). I am using google domains for the blog and it is powered by github pages. $ host jfeatures.com jfeatures.com has address 185.199.111.153 jfeatures.com has address 185.199.108.153 jfeatures.com has address 185.199.109.153 jfeatures.com has address 185.199.110.153 > Host jfeatures.com not found: 2(SERVFAIL) jfeatures.com mail is handled by 20 alt2.gmr-smtp-in.l.google.com. jfeatures.com mail is handled by 40 alt4.gmr-smtp-in.l.google.com. jfeatures.com mail is handled by 5 gmr-smtp-in.l.google.com. jfeatures.com mail is handled by 10 alt1.gmr-smtp-in.l.google.com. jfeatures.com mail is handled by 30 alt3.gmr-smtp-in.l.google.com. alt2.gmr-smtp-in.l.google.com has address 142.250.141.14 alt4.gmr-smtp-in.l.google.com has address 64.233.171.14 gmr-smtp-in.l.google.com has address 142.251.10.14 alt1.gmr-smtp-in.l.google.com has address 173.194.202.14 alt3.gmr-smtp-in.l.google.com has address 142.250.115.14 If I specify the DNS server, it seems to work as expected. Following is result of host jfeatures.com 8.8.8.8 host jfeatures.com 8.8.8.8 Using domain server: Name: 8.8.8.8 Address: 8.8.8.8#53 Aliases: jfeatures.com has address 185.199.109.153 jfeatures.com has address 185.199.111.153 jfeatures.com has address 185.199.110.153 jfeatures.com has address 185.199.108.153 jfeatures.com mail is handled by 10 alt1.gmr-smtp-in.l.google.com. jfeatures.com mail is handled by 30 alt3.gmr-smtp-in.l.google.com. jfeatures.com mail is handled by 40 alt4.gmr-smtp-in.l.google.com. jfeatures.com mail is handled by 5 gmr-smtp-in.l.google.com. jfeatures.com mail is handled by 20 alt2.gmr-smtp-in.l.google.com.

Currently I'm using the "hosts" file for this, but that's getting harder to maintain over multiple workstations... I'd like to setup a nameserver in our local network which can overwrite or append hosts to existing domains. Eg. sql.ourdomain.tld is defined in the "master dns" SOA dns.ourdomain.tld with IN A 80.90.100.200 and I like to overwrite it with IN A 192.168.15.5 in our local nameserver. So its "answer locally first, forward every NXDOMAIN to a different resolver" I guess there is such a solution because "pihole" does similar things.

I'm using LXC containers, and resolving CONTAINERNAME.lxd to the IP of the specified container, using:

sudo resolvectl dns lxdbr0 $bridge_ip
sudo resolvectl domain lxdbr0 '~lxd'

This works great! But the changes don't persist over a host reboot - how can I make them do so? I'm on Pop!_OS 22.04, which is based on Ubuntu 22.04. (I've described 'things I've tried' as answers to this question, which have varying degrees of success.)

I have a weird issue. I have an ESP32 embedded device running an mDNS server which I assign a hostname to. For the record, i've included this code for the ESP32 device below. When I ping this hostname from my Ubuntu PC on the same local network,this hostname becomes local and it is not actually pinging the device. No matter what I change the hostname to on the esp device, this happens. In this case i've named it audio-server and I ping it as follows : ping audio-server.local PING audio-server.local (127.0.0.1) 56(84) bytes of data. 64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.026 ms 64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.048 ms 64 bytes from localhost (127.0.0.1): icmp_seq=3 ttl=64 time=0.048 ms 64 bytes from localhost (127.0.0.1): icmp_seq=4 ttl=64 time=0.044 ms What exactly is going on here? static void mdns_delegate_hostname(void) { esp_err_t err = ESP_OK; char *delegated_hostname = "audio-server"; esp_netif_t *intf = esp_netif_get_default_netif();; while (intf == NULL) { ESP_LOGE(TAG, "ERROR ! netif is NULL"); intf = esp_netif_get_default_netif(); sleep(2); } mdns_ip_addr_t addr4, addr6; addr4.addr.type = ESP_IPADDR_TYPE_V4; esp_netif_ip_info_t info; esp_netif_get_ip_info(intf, &info); ESP_LOGI(TAG, "IP Address of device is : " IPSTR "\n", IP2STR(&info.ip)); addr4.addr.u_addr.ip4 = info.ip; addr6.addr.type = ESP_IPADDR_TYPE_V6; esp_netif_get_ip6_linklocal(intf, &addr6.addr.u_addr.ip6); addr4.next = &addr6; addr6.next = NULL; ESP_LOGI(TAG, "Setting delegated hostname to %s\n", delegated_hostname); err = mdns_delegate_hostname_add(delegated_hostname, &addr4); if (err != ESP_OK) { ESP_LOGE(TAG, "ERROR Setting delegated hostname to %s\n", delegated_hostname); return; } err = mdns_service_add_for_host(NULL, "_http", "_tcp", delegated_hostname, 80, NULL, 0); if (err != ESP_OK) { ESP_LOGE(TAG, "ERROR adding service for host %s\n", delegated_hostname); } }

I have an application which has an mDNS server running on an ESP32 device. Its hostname is esp32-mdns.local. I can ping this hostname from Windows. However, it is not possible from my Ubuntu 22.04 system. I have re-installed the avahi daemon and the utils again. When I do avahi-browse --all : avahi-browse -all + wlp0s20f3 IPv6 192-168-178-1 Microsoft Windows Network local + wlp0s20f3 IPv6 fritz-box Microsoft Windows Network local + wlp0s20f3 IPv4 192-168-178-1 Microsoft Windows Network local + wlp0s20f3 IPv4 fritz-box Microsoft Windows Network local + wlp0s20f3 IPv6 ESP32-WebServer1 Web Site local + wlp0s20f3 IPv6 ESP32-WebServer Web Site local + wlp0s20f3 IPv4 ESP32-WebServer1 Web Site local + wlp0s20f3 IPv4 ESP32-WebServer Web Site local Then avahi-resolve --name esp32-mdns.local : avahi-resolve --name esp32-mdns.local esp32-mdns.local 192.168.178.71 So, the name is getting resolved, but when I ping it : ping esp32-mdns.local ping: esp32-mdns.local: Name or service not known I can ping the IP address directly, but not the hostname. Here is my /etc/avahi/avahi-daemon.conf file. Am I missing something? Or what could be the issue? Thanks. # avahi is distributed in the hope that it will be useful, but WITHOUT # ANY WARRANTY; without even the implied warranty of MERCHANTABILITY # or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public # License for more details. # # You should have received a copy of the GNU Lesser General Public # License along with avahi; if not, write to the Free Software # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 # USA. # See avahi-daemon.conf(5) for more information on this configuration # file! [server] #host-name=foo #domain-name=local #browse-domains=0pointer.de, zeroconf.org use-ipv4=yes use-ipv6=yes #allow-interfaces=eth0 #deny-interfaces=eth1 #check-response-ttl=no #use-iff-running=no #enable-dbus=yes #disallow-other-stacks=no #allow-point-to-point=no #cache-entries-max=4096 #clients-max=4096 #objects-per-client-max=1024 #entries-per-entry-group-max=32 ratelimit-interval-usec=1000000 ratelimit-burst=1000 [wide-area] enable-wide-area=yes [publish] #disable-publishing=no #disable-user-service-publishing=no

# scenario I want to use a mostly relatively light-weight way of associating IP addresses with hostnames. For this, I've installed Avahi and mdns/nss on my Fedora distro. I've like to use the pseudo-tld ".o" as a local domain, and not the default ".local". In /etc/nsswitch.conf I've made sure that mdns4 is set:

hosts:      files myhostname mdns4 [NOTFOUND=return] resolve [!UNAVAIL=return] dns

In /etc/avahi/avahi-daemon.conf I changed one line and left everything unchaged:

domain-name=o

As my host name is desk this should make the domain desk.o available. That's my understanding, anyway. Finally, in /etc/avahi/hosts, I've set one IP-hostname relation:

192.168.0.1 router.o

# expected behavior Assuming my machine's name is desk, I'd expect the domain desk.o to be available. Furthermore, I have machines in my network, which are unable to have their own Avahi running on them, so I'd use /etc/avahi/hosts to annouce those IP addresses, etc. One reason being, I have a pretty old network printer, which simply can't run Avahi, and I just have to use either the IP or something like Avahi (or just an entry in /etc/hosts). So with the hosts file above, I'd expect router.o to be resolved to 192.168.0.1, etc. # observed behavior I've restarted Avahi after making any changes (systemctl restart avahi-daemon.service), but the way thing work is a little strange: When running getent hosts desk.local I get this:

2a02:xxxx:xxxx:xxxx:xxxx:xxxx:8878:583d desk.local
fe80::f990:519a:4ba5:9f22 desk.local

*(first IP partially obfuscated. Where there's an x, there were just hex digits)* I'm fine with this (mostly), I wouldn't expect to desk.local be still available, but I'm assuming it's some sort of default that I can't get rid of (for now). When running getent hosts desk.o I get:

127.0.0.1       desk.o

This is fine, as long as it's only on this machine, but it's a little odd to me, the FQDN hostname resolved to this. When running getent hosts router.o I get nothing. Just no output. # questions So, apparently Avahi is ignoring /etc/avahi/hosts? I've restarted Avahi after making changes to that file, so I was assuming it'd be re-read. Is Avahi not "publishing" the set hostnames to itself? How to make Avahi and my system behave as I'd expect? Or am I having a fundamental thinking error here? ---- Ideally, an Avahi-hostname file would be somewhere in my $HOME, such that I don't have to adjust a system-wide hostname file for Avahi, if that makes sense. If that won't work, it's fine, since that'd go against the way hostname resolution works in principle, I suppose. What kinda surprised me a little, is that desk.o is getting resolved (not as I'd expect it, really), but at least it resolves to *something* so it's at least partially working.

I upgraded a few machines to Debian Buster and everything went well so far—although when running apt upgrade before apt full-upgrade I ran into a Temporary failure in name resolution. This was fixable and only an issue during the process and did not occur when doing a one-step apt dist-upgrade. However one machine shows this behaviour in spite of being fully upgraded. I get ~# LANG=C ping google.com ping: google.com: Temporary failure in name resolution When I add google.com to /etc/hosts everything is fine. My /etc/nsswitch looks like ~# cat /etc/nsswitch.conf passwd: files systemd group: files systemd shadow: files gshadow: files hosts: files dns networks: files protocols: db files services: db files ethers: db files rpc: db files netgroup: nis My /etc/resolv.conf points to googles nameserver at the moment and the very server is pingable ~# cat /etc/resolv.conf nameserver 8.8.8.8 ~# ping -c1 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_seq=1 ttl=53 time=22.8 ms --- 8.8.8.8 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 22.800/22.800/22.800/0.000 ms systemd-resolved is inactive and should not be an issue if I am interpreting the content of my /etc/nsswitch correctly. Could there be another point I missed?

After upgrading Debian11/KDE to Debian12, restarting and running sudo apt-get upgrade it shows errors like Could not resolve ftp.XX.debian.org. These also show when running sudo apt-get update. I then tried to open websites in the Firefox-esr browser and it can't open any (it shows the "Hmm. We're having trouble finding that site." error). I can't ping any sites either, it shows "*Name or service not known*". So it has problems resolving domain names with DNS. ---- **Details** and what I tried: I tried sudo mv /etc/resolv.conf /etc/backup.resolv.conf. DNS still works on a Debian11 machine and it worked before upgrading to Debian12. The nftables firewall rules are the same as before. The time was off by minutes again but I corrected it so it shouldn't be off by more than seconds. At the end of upgrading at 99% I tried to open the browser when it asked me to replace a certain config file, this caused a black screen (once during updating the screen could not get woken up too) and logged me out so I had to finish upgrading with sudo dpkg --configure -a which seemed to have worked. Maybe I need to check if the upgrading worked. Right now I can't use the Internet on that machine while NetworkManager displays it's properly connected and my router page also shows the device as connected. * grep ^hosts /etc/nsswitch.conf shows hosts: files mdns4_minimal [NOTFOUND=return] dns mymachines * /etc/resolv.conf contains #Generated by NetworkManager nameserver: 1.1.1.1 (I already tried adding nameserver 1.0.0.1 beneath it which didn't help) * nmcli c show | grep -i dns shows the below for the Internet connection (not the VPN connection). On the Debian11 machine where DNS still works those values are different: it does not have connection.dns-over-tls. I think **dns-over-tls** likely has to do with the problem. It's also configured in the router that is used by multiple machines of which only the Debian12 machine can't reach websites. I use IPv4-only for good reasons and a VPN.

connection.mdns:                        -1 (default)
connection.dns-over-tls:                -1 (default)
ipv4.dns:                               1.1.1.1
ipv4.dns-search:                        --
ipv4.dns-options:                       --
ipv4.dns-priority:                      0
ipv4.ignore-auto-dns:                   yes
ipv6.dns:                               --
ipv6.dns-search:                        --
ipv6.dns-options:                       --
ipv6.dns-priority:                      0
ipv6.ignore-auto-dns:                   no
IP4.DNS:                             1.1.1.1

----- **Why** is that and how to solve this problem?

I'm running a program which does (in its source code):

gethostbyname("whatever");

and I want it to use the local machine's address instead. I can't change the source. If I were root, it would be easy-peasy - I would just alias this name in /etc/hosts. But - is there something I can do as a _non_host_ user for the same effect on my gethostbyname() call? /etc/nsswitch.conf has:

hosts:      files nis dns myhostname

in case it matters.

I have an embedded linux device hosting an access point, I set it up like this:

sudo apt install dnsmasq-base -y
nmcli connection add type wifi ifname wlan0 con-name access_point autoconnect yes ssid my_ssid
nmcli connection modify access_point 802-11-wireless.mode ap 802-11-wireless.band bg ipv4.method shared
nmcli connection modify access_point wifi-sec.key-mgmt wpa-psk
nmcli connection modify access_point wifi-sec.psk "my_password"
nmcli connection up access_point

I am able to connect to the access point and get an IP address. I am then able to ssh to the device hosting the access point using IP like:

ssh user@IP

I want to host a small web server on the embedded device that devices can access while connected to the access point. I would like to be able to hit the server with a hostname rather than an IP. Is this possible with only making changes to the embedded device, I don't want each device that connects to the access point to have to put an entry in their hosts file for example.

I am using VirtualBox on Windows now. The network is roughly like this: [Fedora 37 VM] -- NAT network -- [Windows Host] ---- intranet ---- internet I use DNS on intranet to resole host.domain names like both some.host.on.intranet and www.yahoo.co.jp . On my windows host, this is OK. But I am not so luky on my Fedora VM. shao@fedora Music $ resolvectl status Global Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported resolv.conf mode: stub Link 2 (enp0s3) Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6 Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported Current DNS Server: 10.0.2.1 DNS Servers: 10.0.2.1 10.3.1.24 192.168.3.1 DNS Domain: intra.somedomain.co.jp Link 3 (docker0) Current Scopes: none Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported My primary DNS is 10.0.2.1, which is OK, same as my Windows host. I can resovle www.yahoo.co.jp on Linux VM. shao@fedora Music $ ping www.yahoo.co.jp PING edge12.g.yimg.jp (183.79.250.251) 56(84) bytes of data. 64 bytes from 183.79.250.251: icmp_seq=1 ttl=54 time=17.4 ms 64 bytes from 183.79.250.251: icmp_seq=2 ttl=54 time=20.5 ms When I try to resolve host.domain on intranet. I got: shao@fedora Music $ ping dev-dm-energy101z.dev.jp.local ping: dev-dm-energy101z.dev.jp.local: Temporary failure in name resolution What makes me confuse is that I can 'dig' that host.domain name. shao@fedora Music $ dig @10.0.2.1 dev-dm-energy101z.dev.jp.local ; > DiG 9.18.11 > @10.0.2.1 dev-dm-energy101z.dev.jp.local ; (1 server found) ;; global options: +cmd ;; Got answer: ;; WARNING: .local is reserved for Multicast DNS ;; You are currently testing what happens when an mDNS query is leaked to DNS ;; ->>HEADER 10.0.2.1.53: 7945+ [1au] A? www.yahoo.co.jp. (44) 10:40:31.284623 enp0s3 Out IP 10.9.9.4.35216 > 10.0.2.1.53: 59710+ [1au] AAAA? www.yahoo.co.jp. (44) 10:40:31.292909 enp0s3 In IP 10.0.2.1.53 > 10.9.9.4.45466: 7945 2/0/1 CNAME edge12.g.yimg.jp., A 183.79.217.124 (88) ... 10:45:14.514350 enp0s3 Out IP 10.9.9.4.54319 > 10.0.2.1.53: 3623+ [1au] A? dev-dm-energy101z.dev.jp.local. (71) 10:45:14.531879 enp0s3 In IP 10.0.2.1.53 > 10.9.9.4.54319: 3623 1/0/1 A 100.67.254.168 (75) But when I 'ping intranet_host' , tcpdump -i any -nn udp keeps silence. Did I miss some config? Any hint will help, thanks in adance. =========================================================== 2023-03-15: I found something interesting. Fedora just refuses to resolve host.domain names end in local, like: stg-zed2-jpe2.stg.jp.local or dev-dm-energy.dev.jp.local. Is there a convention of DNS likes that?

I've setup the Debian package dropbear-initramfs to unlock my homeservers disk over SSH. Unfortunately, the router assigns a different IP to the server on every boot and its DNS does not know the server by its hostname at initramfs stage. Once I unlocked the disk and the server completed boot, I can resolve its hostname.

I recently updated my system, but noticed that on reboot, systemd-resolved always fails. So I cannot access any websites even though I have internet connection. I have included an error message that I'm getting (I could not find any other post mentioning this exact error either). Is anyone facing the same problem or has a fix? I think it is an issue with DNS resolution and as temporary workaround I'm including a nameserver in /etc/resolv.conf. But since this is a temporary fix and I wanted to know if there's a way to fix systemd-resolved since it worked fine before updating the system. Below is version of systemd

➜  ~ resolvectl --version
systemd 251 (251.10-588.fc37)

**tl;dr:** accessing [0.0.0.0](https://en.wikipedia.org/wiki/0.0.0.0) :port (eg. curl http://0.0.0.0:443 ) gets redirected(internally) to 127.0.0.1:port (where port is any port number) (eg. the previous curl command is the same as curl http://127.0.0.1:443 ); **why** does this happen and **how** to block connections destined to 0.0.0.0 ? **UPDATE2:** I've found a way to block it by patching the Linux kernel (version 6.0.9):

lang-patch

--- .orig/usr/src/linux/net/ipv4/route.c
+++ /usr/src/linux/net/ipv4/route.c
@@ -2740,14 +2740,17 @@ struct rtable *ip_route_output_key_hash_
 	}
 
 	if (!fl4->daddr) {
-		fl4->daddr = fl4->saddr;
+			rth = ERR_PTR(-ENETUNREACH);
+			goto out;
+                        /* commenting out the rest:
+		fl4->daddr = fl4->saddr; // if you did specify src address and dest is 0.0.0.0 then set dest=src addr
 		if (!fl4->daddr)
-			fl4->daddr = fl4->saddr = htonl(INADDR_LOOPBACK);
+			fl4->daddr = fl4->saddr = htonl(INADDR_LOOPBACK); // if you didn't specify source address and dest address is 0.0.0.0 then make them both 127.0.0.1
 		dev_out = net->loopback_dev;
 		fl4->flowi4_oif = LOOPBACK_IFINDEX;
 		res->type = RTN_LOCAL;
 		flags |= RTCF_LOCAL;
-		goto make_route;
+		goto make_route; END of COMMENTed out block */
 	}
 
 	err = fib_lookup(net, fl4, res, 0);

Result: Where do packets sent to IP 0.0.0.0 go?:

$ ip route get 0.0.0.0
RTNETLINK answers: Network is unreachable

...they don't! A client attempts to connect from 127.1.2.18:5000 to 0.0.0.0:80

$ nc -n -s 127.1.2.18 -p 5000 -vvvvvvvv -- 0.0.0.0 80
(UNKNOWN) [0.0.0.0] 80 (http) : Network is unreachable
 sent 0, rcvd 0

(if you didn't apply kernel patch, you will need a server like the following for the above client to be able to successfully connect: (as root, in bash)while true; do nc -n -l -p 80 -s 127.1.2.18 -vvvvvvvv -- 127.1.2.18 5000; echo "------------------$(date)";sleep 1; done) Patched ping(ie. a ping that doesn't set destination address to be the same as the source address when destination address is 0.0.0.0, ie. comment out the 2 lines under // special case for 0 dst address that you see [here](https://unix.stackexchange.com/a/99346/543696)) :

$ ping -c1 0.0.0.0
ping: connect: Network is unreachable

instant. However, if specifying source address, it takes a timeout(of 10 sec) until it finishes:

$ ping -I 127.1.2.3 -c1 -- 0.0.0.0
PING 0.0.0.0 (0.0.0.0) from 127.1.2.3 : 56(84) bytes of data.

--- 0.0.0.0 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

----------------- **UPDATE1:** The **why** part is explained [here](https://unix.stackexchange.com/q/419880/86440) but I'm expecting a little bit more details as to why does this happen, for example(thanks to user with nickname anyone on liberachat #kernel channel):

$ ip route get 0.0.0.0
local 0.0.0.0 dev lo src 127.0.0.1 uid 1000
    cache

This shows that somehow packets destined for 0.0.0.0 get routed to the localhost interface lo and they get source ip 127.0.0.1 (if I'm interpreting this right) and because that route doesn't appear in this list:

$ ip route list table local
local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1
local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1
broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1
local 169.254.6.5 dev em1 proto kernel scope host src 169.254.6.5
broadcast 169.254.6.255 dev em1 proto kernel scope link src 169.254.6.5
local 192.168.0.17 dev em1 proto kernel scope host src 192.168.0.17
broadcast 192.168.255.255 dev em1 proto kernel scope link src 192.168.0.17

it means that it must be somehow internal to the Linux kernel. ie. hardcoded To give you an idea, here's how it looks for an IP that's on the internet (I used quad1 as an example IP):

$ ip route get 1.1.1.1
1.1.1.1 via 192.168.1.1 dev em1 src 192.168.0.17 uid 1000
    cache

where 192.168.1.1 is my gateway, ie.:

$ ip route
default via 192.168.1.1 dev em1 metric 2
169.254.6.0/24 dev em1 proto kernel scope link src 169.254.6.5
192.168.0.0/16 dev em1 proto kernel scope link src 192.168.0.17

Because iptables cannot be used to sense (and thus block/drop) such connections destined to 0.0.0.0 that get somehow routed to 127.0.0.1, it might prove difficult to find a way to block them... but I'll definitely try to find a way, unless someone already knows one. @Stephen Kitt (in the comments) suggested a way to block hostnames that reside in /etc/hosts, so instead of: 0.0.0.0 someblockedhostname you can have 127.1.2.3 someblockedhostname 127.1.2.3 someOTHERblockedhostname (anything other than 127.0.0.1, but you can use the same IP for every blocked hostname, unless you want to differentiate) which IP you can then block using iptables. However if your DNS resolver (ie. [NextDNS](https://help.nextdns.io/t/h7hsgv6/redirecting-blocked-hosts-to-localhost-by-returning-0-0-0-0-instead-of-nxdomain-is-not-ideal), or [1.1.1.3](https://blog.cloudflare.com/introducing-1-1-1-1-for-families/)) returns 0.0.0.0 for blocked hostnames (instead of NXDOMAIN) then you cannot do this (unless, of course, you want to add each host manually in /etc/hosts, because /etc/hosts takes precedence - assuming you didn't change the line hosts: files dns from /etc/nsswitch.conf) -------- **OLD:** (though edited) On Linux (I tried Gentoo and Pop OS!, latest) if you have this line in /etc/hosts:

0.0.0.0 somehosthere

and you run this as root (to emulate a localhost server listening on port 443) # nc -l -p 443 -s 127.0.0.1 then you go into your browser (Firefox and Chrome/Chromium tested) and put this in address bar: https://somehosthere or 0.0.0.0:443 or https://0.0.0.0 then the terminal where you started nc(aka netcat) shows a connection attempt (some garbage text including the plaintext somehosthere if you used it in the url) or instead of the browser, you can try: curl https://somehosthere or if you want to see the plaintext request: curl http://somehosthere:443 This doesn't seem to be mitigable even when using dnsmasq as long as that 0.0.0.0 somehosthere is in /etc/hosts, but when using dnsmasq and your DNS resolver (ie. NextDNS or [Cloudflare's 1.1.1.3](https://blog.cloudflare.com/introducing-1-1-1-1-for-families/)) returns 0.0.0.0 instead of NXDOMAIN ([true](https://help.nextdns.io/t/h7hsgv6/redirecting-blocked-hosts-to-localhost-by-returning-0-0-0-0-instead-of-nxdomain-is-not-ideal) at the time of this writing) and that hostname isn't in your /etc/hosts(AND in what you told dnsmasq is the /etc/hosts to use) then there are two ways to mitigate it(either or both will work): 1. use dnsmasq arg --stop-dns-rebind

--stop-dns-rebind
              Reject (and log) addresses from upstream nameservers which are in
              the private ranges. This blocks an attack where a browser  behind
              a  firewall  is  used to probe machines on the local network. For
              IPv6, the private range covers the IPv4-mapped addresses in  pri‐
              vate  space  plus  all  link-local  (LL) and site-local (ULA) ad‐
              dresses.

2. use line bogus-nxdomain=0.0.0.0 in /etc/dnsmasq.conf which makes dnsmasq itself return NXDOMAIN for any hostname that resolved to 0.0.0.0 (except, once again, if that hostname was in /etc/hosts (bypasses dnsmasq) and what you told dnsmasq to use as /etc/hosts (if you did)) So, the second part of this question is **how to disallow accesses to 0.0.0.0 from being redirected to 127.0.0.1 ?** I want this because when using NextDNS (or [cloudflare's 1.1.1.3](https://blog.cloudflare.com/introducing-1-1-1-1-for-families/)) as DNS resolver, it returns 0.0.0.0 for blocked hostnames, instead of NXDOMAIN, thus when loading webpages, parts of them(that are located on blocked hostnames) will try to access my localhost server running on port 443 (if any) and load pages from it instead of just being blocked. Relevant browser-specific public issues being aware of this(that 0.0.0.0 maps to 127.0.0.1): Chrome/Chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=1300021 Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1672528#c17

In Linux, how do /etc/hosts and DNS work together to resolve hostnames to IP addresses? 1. if a hostname can be resolved in /etc/hosts, does DNS apply after /etc/hosts to resolve the hostname or treat the resolved IP address by /etc/hosts as a "hostname" to resolve recursively? 2. In my browser (firefox and google chrome), when I add to /etc/hosts: 127.0.0.1 google.com www.google.com typing www.google.com into the address bar of the browsers and hitting entering won't connect to the website. After I remove that line from /etc/hosts, I can connect to the website. Does it mean that /etc/hosts overrides DNS for resolving hostnames? After I re-add the line to /etc/hosts, I can still connect to the website, even after refreshing the webpage. Why doesn't /etc/hosts apply again, so that I can't connect to the website? Thanks.

I've come across an issue where a Java (1.8) application is continuing to use the DNS servers configured when the process started rather than the current configuration. This persisted for a week before the Java application was restarted. Specifically this is running on Centos 6 (yes, I know) with nscd (600s TTL for host caching). One of the 2 DNS servers was retired and a new one added at a different IP address. This was added to resolv.conf (i.e. 2 working DNS servers) and nscd restarted. However Java appears to continue using the retired DNS server / did not switch to the surviving DNS server / did not attempt to use the new DNS server. Are there rules / expectations over how the resolver should behave in such a scenario? - Should it periodically check the configuration? - Should it try another DNS server when one times out? Pointers to specifications (Posix?) would be appreciated

This is for personal use, I have a debian running on a VM. I would like to know if BIND9 is required to be able to SSH using the hostname from host machine or modifying the /etc/hosts and resolv.conf will be sufficient?