I have a strange problem when I connect to a company VPN with forticlient application. First, I did not know what was wrong. After spending some time, I figured out that DNS is not working as it should have. Unfortunately, I have no idea, who's fault is that. It may be FortiClient, systemd-resolved, or something else. I am using Ubuntu 22.04, which is not an official version yet, but I have doubts it will get any better until official release in a week or two. This is output from resolvectl before VPN is established: username@hostname:~$ resolvectl Global Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported resolv.conf mode: stub Link 2 (enp2s0) Current Scopes: none Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported Link 3 (wlp1s0) Current Scopes: DNS Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported Current DNS Server: 192.168.1.1 DNS Servers: 192.168.1.1 2a00:ee0:d::13 2a00:ee0:e::13 DNS Domain: -- After VPN is established resolvectl reports additional link called vpn: username@hostname:~$ resolvectl Global Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported resolv.conf mode: stub Link 2 (enp2s0) Current Scopes: none Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported Link 3 (wlp1s0) Current Scopes: DNS Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported Current DNS Server: 172.20.1.21 DNS Servers: 172.20.1.16 172.20.1.21 2a00:ee0:d::13 2a00:ee0:e::13 DNS Domain: company.com Link 5 (vpn) Current Scopes: none Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported As you can see additional DNS servers are added to Link 3, which should help me resolve internal names when connected to VPN. Strange thing is that when I write username@hostname:~$ resolvectl query name.company.com name.company.com: resolve call failed: 'name.company.com' not found I do not get anything. If I try with nslookup like this username@hostname:~$ nslookup > server 172.20.1.16 Default server: 172.20.1.16 Address: 171.20.1.16#53 > name.company.com Server: 172.20.1.16 Address: 172.20.1.16#53 Name: name.company.com Address: 172.20.38.251 I get the correct answer. Since this was strange I traced network traffic to see what does nslookup differently than resolvectl query. It turned out that nslookup uses a VPN assigned address for the source IP when asking DNS for a name. On the other hand, resolvectl query uses all other addresses for source IP except the one assigned by VPN. Because of that I guess DNS server does not have the route to send back an answer correctly to my computer, or DNS queries may even not reach the newly added DNS servers. Because of that none of the programs I need can resolve the names correctly. The result is that I cannot connect anywhere within a VPN with a domain name. Does anybody have an idea how to make resolvectl realize there is newly assigned VPN address, and it should use it as the source IP. Should FortiClient do some additional configutation on establishing a connection? Probably not. I tried to restart systemd-resolved after VPN is established, but it does not help. Should I restart some other service? Which one? ---------- Update: I have checked how DNS is setup in network settings, and they are correct. Without VPN the network interface wlp1s0 shows: username@hostname:~$ nmcli device show wlp1s0 | grep DNS IP4.DNS: 192.168.1.1 IP6.DNS: 2a00:ee0:d::13 IP6.DNS: 2a00:ee0:e::13 After VPN is connected: username@hostname:~$ nmcli device show wlp1s0 | grep DNS IP4.DNS: 172.20.1.16 IP4.DNS: 172.20.1.21 username@hostname:~$ nmcli device show vpn | grep DNS IP4.DNS: 172.20.1.16 IP4.DNS: 172.20.1.21

My Ubuntu client is still using an OLD DNS in systemd-resolve. When I run systemd-resolve --status I find old and new DNS. The new DNS has been set using DHCP scope options on my network. I've successfully updated all my RHEL systems, but this is not the case for Debian/Ubuntu systemd: From systemd-resolve --status:

DNSSEC setting: no
    DNSSEC supported: no
         DNS Servers: 192.168.10.44 ( OLD )
                      192.168.10.69 ( NEW )

**resolved.conf**

cat /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
#Cache=yes
#DNSStubListener=yes

**resolv.conf**

# This file is managed by man:systemd-resolved(8). Do not edit.
#
# 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 "systemd-resolve --status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs must 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
search example.com

**/etc/systemd/network/** is empty. I've countless times tried to restart systemd-resolved and systemd-networkd, since I read somewhere in Github systemd repo that systemd-networkd is responsible for updating stuff with DHCP which systemd-resolve will use. **EDIT:** **/run/systemd/resolve/stub-resolv.conf**

# This file is managed by man:systemd-resolved(8). Do not edit.
#
# 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 "systemd-resolve --status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs must 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
search example.com

**EDIT2:** As part of recent comments **/etc/netplan/50-cloud-init.yml**

# This file is generated from information provided by
# the datasource.  Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
    version: 2
    ethernets:
        ens3:
            dhcp4: true
            match:
                macaddress: XX:XX:XX:XX:XX
            set-name: ens3

My understanding is that if I am using third party DNS (Google, etc.) or DNS provided by my ISP (Comcast, etc.), I do not need the LLMNR feature on.  I am attempting to disable it, but setting LLMNR=no in /etc/systemd/resolved.conf and restarting the box does not seem to work. I am on Ubuntu 17.10.  How can I go about achieving this goal?

systemctl status systemd-resolved.service returns systemd-resolved.service - Network Name Resolution Loaded: loaded (/lib/systemd/system/systemd-resolved.service; enabled; vendor preset: enabled) Active: active (running) since Wed 2023-02-01 19:47:24 CET; 15min 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: 65445 (systemd-resolve) Status: "Processing requests..." Tasks: 1 (limit: 36023) Memory: 1.6M CPU: 3.572s CGroup: /system.slice/systemd-resolved.service └─65445 /lib/systemd/systemd-resolved Feb 01 19:47:20 srvides00 systemd: Starting Network Name Resolution... Feb 01 19:47:24 srvides00 systemd-resolved: Positive Trust Anchors: Feb 01 19:47:24 srvides00 systemd-resolved: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d Feb 01 19:47:24 srvides00 systemd-resolved: Negative trust anchors: home.arpa 10.in-addr.arpa 16.172.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.> Feb 01 19:47:24 srvides00 systemd-resolved: Failed to open configuration file **'/etc/systemd/resolved.conf': Permission denied** Feb 01 19:47:24 srvides00 systemd-resolved: Failed to parse configuration file: Permission denied Feb 01 19:47:24 srvides00 systemd-resolved: **Failed to stat /etc/resolv.conf: Permission denied** Feb 01 19:47:24 srvides00 systemd: Started Network Name Resolution. Please find below the permission details -rwxr-xr-x 1 root root 1406 Apr 7 2022 /etc/systemd/resolved.conf lrwxrwxrwx 1 root root 39 Jan 20 2021 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf What could be wrong, we are on Ubuntu 22.04.1 Getting "Temporary failure in name resolution" while ping any entries in the /etc/hosts

I have a program that will run a set of commands against new server installs and I need to change an entry in a file for each install. We need to change the default DNS from 127.0.0.X (which it defaults to as it installs without an internet connection) to 8.8.8.8 I was using the following command: sudo awk '{sub(/#DNS=/,"DNS=8.8.8.8")}' /etc/systemd/resolved.conf however this doesn't appear to be working under gawk/new OS version. sudo gawk '{gensub(/#DNS=/,"DNS=8.8.8.8")}' /etc/systemd/resolved.conf What am I doing wrong? Is there a better way to change the default DNS entry? Current Server OS: Ubuntu 24.04.2-live-server Previous Server OS: Ubuntu 20.04.6-live-server **EDIT:** Sample line input file: ~~~ #DNS= #FallbackDNS= #Domains ~~~ The command should find the first line above and replace it with DNS=8.8.8.8 however it is not. Desired output: ~~~ DNS=8.8.8.8 #FallbackDNS= #Domains ~~~ When I run the awk command the file still reads: ~~~ #DNS= #FallbackDNS= #Domains ~~~ Additionally, it should only find and replace an exact match of #DNS= What command and syntax will replace #DNS= with DNS=8.8.8.8?

Ubuntu 18 I've done a ton of research and am close to pulling this picture together but can't quite understand: How can I configure systemd-resolved for mdns? My goal specifically: - to bring up a server on a 10.0.0.0/16 network - for the new server to give itself some arbitrary name like foo1 - to be able to connect to that server from another machine on the same network using the name foo1 Can anyone tell me please how to make this happen specifically using systemd-resolved? thanks So far I have configured resolved.conf at follows on ubuntu@ip-10-0-0-229:/etc$ --> CHROME -> cat /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=yes MulticastDNS=yes #DNSSEC=no #Cache=yes #DNSStubListener=yes ubuntu@ip-10-0-0-229:/etc$ --> CHROME ->

I am having some troubles in making systemd-resolved to properly work. My configuration is "minimal": the main configuration file /etc/systemd/resolved.conf is basically empty (everything is commented out) and I've a very simple drop-in file in /etc/systemd/resolved.conf.d/99-default.conf configuring a couple of (global) name servers. The configuration is synthesized by the following output:

root@host:~# systemd-analyze cat-config systemd/resolved.conf
# /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. Local configuration
# should be created by either modifying this file (or a copy of it placed in
# /etc/ if the original file is shipped in /usr/), or by creating "drop-ins" in
# the /etc/systemd/resolved.conf.d/ directory. The latter is generally
# recommended. Defaults can be restored by simply deleting the main
# configuration file and all drop-ins located in /etc/.
#
# Use 'systemd-analyze cat-config systemd/resolved.conf' to display the full config.
#
# See resolved.conf(5) for details.

[Resolve]
# Some examples of DNS servers which may be used for DNS= and FallbackDNS=:
# Cloudflare: 1.1.1.1#cloudflare-dns.com 1.0.0.1#cloudflare-dns.com 2606:4700:4700::1111#cloudflare-dns.com 2606:4700:4700::1001#cloudflare-dns.com
# Google:     8.8.8.8#dns.google 8.8.4.4#dns.google 2001:4860:4860::8888#dns.google 2001:4860:4860::8844#dns.google
# Quad9:      9.9.9.9#dns.quad9.net 149.112.112.112#dns.quad9.net 2620:fe::fe#dns.quad9.net 2620:fe::9#dns.quad9.net
#DNS=
#FallbackDNS=1.1.1.1#cloudflare-dns.com 8.8.8.8#dns.google 1.0.0.1#cloudflare-dns.com 8.8.4.4#dns.google 2606:4700:4700::1111#cloudflare-dns.com 2001:4860:4860::8888#dns.google 2606:47>
#Domains=
#DNSSEC=no
#DNSOverTLS=no
#MulticastDNS=no
#LLMNR=no
#Cache=yes
#CacheFromLocalhost=no
#DNSStubListener=yes
#DNSStubListenerExtra=
#ReadEtcHosts=yes
#ResolveUnicastSingleLabel=no
#StaleRetentionSec=0

# /etc/systemd/resolved.conf.d/99-default.conf
[Resolve]
DNS=192.168.2.105 192.168.2.106

The problem is that the drop-in file seems to be completely ignored at runtime... I mean if a trigger a command for summarizing the systemd-resolved status then the output is the following:

root@host:~# systemd-resolve --status
Global
           Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
    resolv.conf mode: uplink
Fallback DNS Servers: 1.1.1.1#cloudflare-dns.com 8.8.8.8#dns.google 1.0.0.1#cloudflare-dns.com 8.8.4.4#dns.google 2606:4700:4700::1111#cloudflare-dns.com 2001:4860:4860::8888#dns.google
                      2606:4700:4700::1001#cloudflare-dns.com 2001:4860:4860::8844#dns.google

Link 2 (wired1)
    Current Scopes: none
         Protocols: -DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 3 (wired0)
    Current Scopes: none
         Protocols: -DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

I was expecting to find the DNS servers specified in drop-in file (192.168.2.105 and 192.168.2.106) in Global section of the output... but they are not there... What am I mistaking? Is there something I am completely missing out? (that's very likely, since I am a systemd-resolved beginner)

I will be running a Pi-hole server in a docker container, so I have freed up port 53 by settingDNSStubListener=no in /etc/systemd/resolved.conf and restarting systemd-resolved. This has freed up port 53, but now DNS doesn't work. I get ;; connection timed out; no servers could be reached Looking at Network Settings from the desktop, I see 1.1.1.1 and 8.8.8.8 as the DNS servers assigned by DHCP as currently configured, but how do I get my system to use these? **UPDATE1:** /etc/resolv.conf has this: nameserver 127.0.0.53 options edns0 trust-ad search domain.local

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

For some reason I can't manage to set domains for resolvectl. Either I don't understand what it does at all or something is weird for me. Once I set a domain e.g. sudo resolvectl domain enp2s0 example.com, any query to example.com or any of its subdomains result in timeouts and NXDOMAIN for searched queries. Why am I experiencing that? Also doesn't this feature actually work simply just like search in resolv.conf file but namespaced by network interface? i.e. If I query subdomain which is acutally nothing but subdomain.example.com and it has answers on that interface DNS servers I should resolve it successfully, am I right?

I have the following system: root@debian:~# dpkg -l systemd-resolved Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-================-============-============-================================= ii systemd-resolved 257.4-3 amd64 systemd DNS resolver root@debian:~# cat /etc/issue Debian GNU/Linux trixie/sid \n \l root@debian:~# ls -l /etc/resolv.conf lrwxrwxrwx 1 root root 39 Mar 26 20:21 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf root@debian:~# cat /run/systemd/resolve/stub-resolv.conf # 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 . Then I installed Zebedee tunneling and it's work fine.
And when I set my firefox on localhost:81 , I access to sites are filtered. root@debian:~# telnet localhost 81 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. Now, I want to use DNS over localhost:81.
How can I do it? **UPDATE:** My resolvectl is: root@debian:~# resolvectl status Global Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported resolv.conf mode: stub DNS Servers: 8.8.8.8 Link 2 (enp0s31f6) Current Scopes: LLMNR/IPv4 mDNS/IPv4 Protocols: -DefaultRoute +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported Default Route: no Link 3 (wlp58s0) Current Scopes: none Protocols: -DefaultRoute +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported Default Route: no Link 5 (docker0) Current Scopes: none Protocols: -DefaultRoute +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported Default Route: no

How do I configure an Ubuntu 20.04 system so it overrides the default DNS? It seems that by default there is a global and per-link DNS setting. I tried a couple of things that did not work: - Edit /etc/systemd/resolved.conf with the DNS Servers - Created /etc/systemd/network/enp0s3.conf with the DNS servers configured - Removed all DNS related parameters from the DHCP request by editing /etc/dhcp/dhclient.conf All these changes (and the combinations) result in the DNS servers being prepended to the list of global DNS servers. Most 'solutions' are to either install resolvconf or replace the /etc/resolv.conf symbolic link with a file and set the DNS servers there. Both of these seem like a workaround. I would like to use the existing tooling (systemd-resolved) to override the DNS Servers. As suggested by @xenoid in the comments: Setting the DNS for the interface through the GUI resulted in a file /etc/NetworkManager/system-connections/enp0s3.nmconnection that contains the correct DNS servers, the output of resolvectl status includes the correct DNS servers, this however is not what I had in mind. I am looking for a solution that does the configuration using systemd-resolved, which is possible from what I can find, but it is unclear how. Since this requires a GUI installation.

While trying to fix a DNS issue with NetworkManager's ModemManager on Ubuntu, I came across this difference in the output of systemd-resolve --status when connected. (ping ip works, manually editing /etc/resolv.conf fixes the problem, and setting FallbackDNS also fixes the problem, but all with side-effects. **Working installation - PPP modem** (Ubuntu 17.10) Link 3 (wwp0s20u6) Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6 LLMNR setting: yes MulticastDNS setting: no DNSSEC setting: no DNSSEC supported: no DNS Servers: 198.142.0.51 211.29.132.12 **Broken installation - PPP modem** (Same hardware - Lubuntu 17.04) Link 2 (wwp0s20u6) Current Scopes: LLMNR/IPv4 LLMNR/IPv6 LLMNR setting: yes MulticastDNS setting: no DNSSEC setting: no DNSSEC supported: no These are both versions of Ubuntu and identical hardware. The configs of the network connections in /etc/NetworkManager/system-connections are also identical. On links with DHCP like ethernet and Wifi adapters, the DNS scope is added to the link and DNS works correctly on both machines. e.g. **Broken installation - WiFi adapter working** Link 3 (wlan0) Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6 LLMNR setting: yes MulticastDNS setting: no DNSSEC setting: no DNSSEC supported: no DNS Servers: 192.168.0.1 So, I speculate that it's not a problem with systemd-resolved itself, but with something that tells systemd-resolved it should be looking for DNS. ***What are systemd link "Scopes"?*** ***Why would one machine assign the "DNS" scope and the other not?***

I'm using Fedora 36 as my everyday desktop machine and I try to do something that I though was fairly simple but I can't find another person on the net providing a proper configuration for this. Basically, everything is in the title: I want to find the proper systemd-resolved configuration to use my local Bind server as a DNS (nothing complex so far), *but also* fallback on any DHCP-provided DNS. What I tried so far is to force NetworkManager to provide my local Bind instance in the DHCP-provided DNS in the first place with the following configuration:

# /etc/dhcp/dhclient.conf
prepend domain-name-servers 127.0.0.1;
require subnet-mask, domain-name-servers;

# /etc/NetworkManager/conf.d/dhcp-client.conf
[main]
dhcp=dhclient

But that doesn't work. systemd-resolved still queries DHCP-provided DNS prior to my local Bind server. I found a systemd-resolved configuration that queries my local Bind server:

# /etc/systemd/resolved.conf
DNS=127.0.0.1 ::1
Domains=~.

But I'm unsure that it falls back to DHCP-provided DNS.

Today, on my Ubuntu 22.04.5 computer, I discovered two unknown nameservers in /etc/resolv.conf (symlink to /run/systemd/resolve/resolv.conf):

nameserver fe80::e0eb:40ff:fe79:e364%36     # Does not belong
nameserver 172.20.10.1                      # Does not belong
nameserver 192.168.1.1                      # Correct nameserver
search .

As a result, all local hostnames on my intranet (e.g., *myhost*) were failing to resolve. Rerunning sudo systemd restart systemd-resolved.service did not change anything. I finally tracked down the problem to my iPhone 8 which was connected by a USB cable to the computer. The iPhone was running a Personal Hotspot, and **systemd** was treating it as my primary nameserver, overriding 192.168.1.1. How can I prevent this problem from happening in the future when my iPhone is connected to the computer? Is there some way to tell **systemd** to ignore the iPhone's hotspot? Thank you very much.

I want to use basic tool available without installing anything to solve an IP into it's FQDN. I know the domain in which I can solve this IP. The command line or the tool should be available on any minimal debian or rhel based system which exclude : - /usr/bin/host - /usr/bin/nslookup - /usr/bin/dig I'm trying with getent but to no end for now. My resolvctl config looks like this: nameserver 127.0.0.53 search dom2.lan dom1.lan What I want is to get the FQDN of IP 10.1.1.1 in dom3.lan (not in resolvconf) without any package installed but the one on a Ubuntu server minimal image for example. getent hosts 10.1.1.1 does not return anything. host 10.1.1.1 dom3.lan return the hostname I want. So how can I achieve this without installing bind9-tools just with standard systemctl or basic linux package available in any linux distro that is less than 3 years old. Edit 1 : The solution I'm looking for need to be available to any user. I consider that python3 is available. Edit 2: I may be confused or dumb or may mis-explain what I mean. If I do the following nslookup request here's the result: Without domain appened: nslookup srv1 ;; Got SERVFAIL reply from 127.0.0.53 Server: 127.0.0.53 Address: 127.0.0.53#53 ** server can't find srv1: SERVFAIL With domain happen nslookup srv1.dom3.lan Server: 127.0.0.53 Address: 127.0.0.53#53 Non-authoritative answer: Name: srv1.dom3.lan Address: 10.1.1.1 Now I know my local DNS can solve dom3.lan. BUT I don't want to add it in my default search in /etc/resolf.conf because it's not my choice and the choice make sense in our context. BUT I'd like to be able to do reverse lookup like nslookup 10.1.1.1 and using a different search than the one set in /etc/resolv.conf. AND at the moment I realize that I don't even manage to do such a request from dig or host or nslookup while if I edit my /etc/resolv.conf without changing any other DNS settings it works. So my question is : is there a way to set a search for a reverse DNS lookup with any tool and if possible not an installed one. nslookup set q=A set domain=dom3.lan 10.1.1.1 no result with dig dig @127.0.0.53 +norecurse +domain=dom3.lan. -x 10.1.1.1 No result either. I'm not even sure this question makes sense but there's definitely strange stuff happening on my system. If changing my /etc/resolv.conf search works I feel like a tool like dig or nslookup should work as well.

For configuring custom DNS servers in a brand new Kubuntu 19.10 laptop it wasn't enough with adding to /etc/systemd/resolved.conf: >DNS=77.88.8.7 77.88.8.3 #Yandex's DNS with no porn even on Google Images I also had to change the symlink of /etc/resolv.conf

$ ls -l /etc/resolv.conf 
lrwxrwxrwx 1 root root 37 oct 26 01:48 /etc/resolv.conf -> /run/systemd/resolve/stub-resolv.conf
$ sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf

/run/systemd/resolve/stub-resolv.conf only has the ISP's given DNSs, while the custom DNSs are only in /run/systemd/resolve/resolv.conf. When looking at:

man systemd-resolved.service

it says that the recommended file is /run/systemd/resolve/stub-resolv.conf, but I don't get their differences (that _understandable and simple_ explanation should be the accepted answer). If so, how could I set the system to use the globally configured DNSs using that file and not the other? >**Note**: On laptop, with plenty of WiFi connections, it's not viable to configure a per-connection DNS, like suggested in many sites that says how to achieve this I just described Additional info for curious:

/run/systemd/resolve/$ diff stub-resolv.conf resolv.conf 
3,8c3,4
 # This is a dynamic resolv.conf file for connecting local clients directly to
> # all known uplink DNS servers. This file lists all configured search domains.
17,18c13,17
 nameserver 77.88.8.7
> nameserver 77.88.8.3
> nameserver 200.49.130.40
> # Too many DNS servers configured, the following entries may be ignored.
> nameserver 200.42.4.207

I have read about systemd-resolved.service https://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html and learnt four modes of handling /etc/resolv.conf. 1. /run/systemd/resolve/stub-resolv.conf 2. /usr/lib/systemd/resolv.conf 3. /run/systemd/resolve/resolv.conf 4. /etc/resolv.conf may be managed by other package I have read it for several times, but still feel confused about how to determine which mode of /etc/resolv.conf I should choose as a normal user. For example, I try to add some custom dns servers, so, > 1. Add DNS=8.8.8.8 8.8.4.4 in /etc/systemd/resolved.conf and check /run/systemd/resolve/resolv.conf, 8.8.8.8 and 8.8.4.4 exist in it. > 2. If symlinking /run/systemd/resolve/resolv.conf to /etc/resolv.conf, 8.8.8.8 and 8.8.4.4 are gone in > /run/systemd/resolve/resolv.conf. Update 1: test@instance-1:~$ cat /run/systemd/resolve/resolv.conf ... # See man:systemd-resolved.service(8) for details about the supported modes of # operation for /etc/resolv.conf. nameserver 8.8.8.8 nameserver 8.8.4.4 test@instance-1:/etc$ sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf test@instance-1:/etc$ ls -alh /etc/resolv.conf lrwxrwxrwx 1 root root 32 Mar 18 07:22 /etc/resolv.conf -> /run/systemd/resolve/resolv.conf test@instance-1:/etc$ sudo reboot test@instance-1:~$ cat /etc/resolv.conf domain c.prime-poetry-197705.internal search c.prime-poetry-197705.internal. google.internal. nameserver 169.254.169.254 test@instance-1:~$ cat /run/systemd/resolve/resolv.conf domain c.prime-poetry-197705.internal search c.prime-poetry-197705.internal. google.internal. nameserver 169.254.169.254 test@instance-1:~$ ls -alh /etc/resolv.conf lrwxrwxrwx 1 root root 32 Mar 18 07:22 /etc/resolv.conf -> /run/systemd/resolve/resolv.conf Update 2: symlinking from /etc/resolv.conf test@instance-1:~$ sudo ln -sf /etc/resolv.conf /run/systemd/resolve/resolv.conf test@instance-1:~$ ls -alh /run/systemd/resolve/resolv.conf lrwxrwxrwx 1 root root 16 Mar 18 07:51 /run/systemd/resolve/resolv.conf -> /etc/resolv.conf test@instance-1:~$ sudo reboot test@instance-1:~$ ls -alh /run/systemd/resolve/resolv.conf -rw-r--r-- 1 systemd-resolve systemd-resolve 603 Mar 18 07:52 /run/systemd/resolve/resolv.conf

I'm currently working on a project that has required some DNS troubleshooting. However I am fairly new to the wonderful world of networking and I'm at a bit of a loss as to where to begin. My specific problem probably belongs on the Raspberry Pi Stack Exchange, so I'll avoid crossposting. Just looking for information here. Looking for information, I was lead to the resolv.conf(5) file, resolvconf(8), systemd-resolve(1), and the beast that avahi appears to be. My Raspberry Pi with Raspbian Buster appears to have avahi-daemon running. My Ubuntu 18.04.4 LTS has systemd-resolved AND avahi-daemon. Does resolvconf(8) (man page only on Ubuntu) coordinate the two? When is /etc/resolv.conf used/ignored? *On Ubuntu:*

$ cat /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.53
search telus

*On Raspbian:*

$ cat /etc/resolv.conf

# Generated by resolvconf
nameserver 192.168.0.1
nameserver 8.8.8.8
nameserver fd51:42f8:caae:d92e::1

Which utilities are responsible for this? I don't really understand enough jargon to sift through the man pages and differentiate all these, and I'd love an explanation of how their roles are related.

I have machines that run in all kinds of environments which aren't under my control and I need to configure them to work in all of those. My current issue is, that some environments have a .local domain which is resolved using unicast dns (which is against the standard) while others might use the mdns. With /etc/nsswitch.conf you were able to set hosts: files mdns_minimal dns which would try mdns first and then fall back to regular unicast dns if it couldn't resolve the name using mdns. With systemd-resolved, it seems that you can enable or disable multicast dns using the MulticastDNS setting, but I wonder if there is a way to achieve the same "fallback system". It seems that currently, systemd-resolved tries multicast dns for .local names and fail if it can't resolve them by default.