Ubuntu 15.10 and dns=dnsmasq is commented out in /etc/NetworkManager/NetworkManager.conf Before I connect to a VPN /etc/resolv.conf contains nameserver 2xx.xx.xx.xx <-- ISP DNS 1 nameserver 2xx.xx.xx.xx <-- ISP DNS 2 after a VPN connection /etc/resolv.conf contains nameserver 1xx.xx.xx.xx <-- VPN DNS 1 nameserver 1xx.xx.xx.xx <-- VPN DNS 2 nameserver 2xx.xx.xx.xx <-- ISP DNS 1 The regular wired connection and the VPN have DNS servers set in network manager with automatic (only addresses). The ISP server shouldn't be there at all. What else can I change? (removing dns=dnsmasq was one change to stop split DNS).

I am on Linux Mint 20 with Cinnamon 4.6.7. I would like a non admin user reg to be able to make /etc/resolv.conf mutable without using sudo. So I made this script at /home/reg/make-resolv-conf-mutable.sh: #!/bin/bash sudo chattr -i /etc/resolv.conf I made it executable and am trying to remove sudo password requirement with sudo visudo, but it still requires the password even after I have added these lines at bottom of /etc/sudoers and new file /etc/sudoers.d/resolv-conf-rules reg ALL=NOPASSWD: /home/reg/make-resolv-conf-mutable.sh reg ALL=(ALL:ALL) NOPASSWD: /home/reg/make-resolv-conf-mutable.sh I ran sudo visudo -c and all the files said "parsed OK" including /etc/sudoers and /etc/sudoers.d/resolv-conf-rules.

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

I recently switched from the **Cisco AnyConnect Secure Mobility Client** to **OpenConnect** to solve a long-standing issue where my Docker containers could not access internal sites over my corporate VPN. This switch resolved that issue (as reported in several similar cases online), but it introduced a new problem: Now, every time I connect to the VPN using OpenConnect, **/etc/resolv.conf is not properly updated** with the internal DNS servers as the Cisco client used to do automatically. I’ve been working around this by manually updating resolv.conf after each connection, and even wrote a small script to speed that up — but this doesn't feel like a solid or sustainable solution. --- ### My setup: - OS: Ubuntu 24.04.02 - Packages:

network-manager-openconnect         1.2.10-3build2
  network-manager-openconnect-gnome   1.2.10-3build2
  openconnect                         9.12-1build5

- I use the **GNOME UI** for connection because my VPN requires **SSO login via a web view**. --- ### Questions: 1. How can I make OpenConnect automatically update resolv.conf when the VPN connects? 2. Is there a NetworkManager hook or OpenConnect config that I’m missing? 3. Are there known limitations when using OpenConnect via the GNOME UI regarding DNS updates? --- Any advice, workaround, or best practice would be greatly appreciated.

I have an LXC container created and started as follows:

sudo lxc-create -t debian -n mylxc -- --release bullseye
sudo lxc-start -n mylxc
sudo lxc-attach -n mylxc

On the LXC host I have a DHCP server running which provides IPv4 and IPv6 IP addresses and announces IPv4 and IPv6 DNS servers. The LXC correctly gets both an IPv4 and an IPv6 address. It adds only the IPv4 DNS server to /etc/resolv.conf, though. How can I get my LXC container to properly receive the IPv6 DNS server via DHCP?

My Mastodon instance is not showing previews of images from remote servers. I have tried to run RAILS_ENV=production /home/mastodon/live/bin/tootctl media refresh --days 0.2 And get a lot of errors of the form > Error processing 114092630496524137: failed to connect: No address for media.mstdn.social on https://media.mstdn.social/media_attachments/files/114/092/629/337/741/863/original/9539833c10d5b81d.mp4 I have narrowed the problem down to resolve, I think. When I call nslookup media.mstdn.social I get: > ;; Got SERVFAIL reply from 127.0.0.53, trying next server I had problems earlier with wget, curl and similar, so I added Hetzner's dns-servers. That solved the problems, but not for mastodon. So I guess I need to get 127.0.0.53 to work? resolvectl status > Global > Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported > resolv.conf mode: static > > Link 2 (eth0) > Current Scopes: none > Protocols: -DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported Any idea what to do?

My config : Raspberry - Raspbian - Debian 11 Bullseye - CM4 Package resolvconf My

/etc/network/interfaces

auto eth0
iface eth0 inet static
address 192.168.100.125/24
gateway 192.168.100.100
dns-search test.local
dns-nameservers 192.168.100.101 192.168.100.102
iface eth0 inet6 static
address 2001:0db8:3c4d:0015:0000:d234::3eee:0000
gateway 2001:0db8:3c4d:0015:0000:d234::3eee:0100
dns-nameservers 2001:0db8:3c4d:0015:0000:d234::3eee:0101 2001:0db8:3c4d:0015:0000:d234::3eee:0102

I modify

/etc/network/interfaces

with shell script using sed command, I restart my network with

sudo systemctl restart networking

**My first problem**: When I put dhcp to static, my dns configuration isn't updated on resolvconf, so I have the new static dns and the last dhcp dns. Same thing when I put new ipv6 DNS and when I delete it I keep the last ipv6 DNS configuration after rebooting the network. I do not know if I can refresh resolvconf file to keep only dns configuration by

/etc/network/interfaces

. **My second problem**: When i set my ipv6 static all works fine, i can change them, but when i want passed with dhcpv6 or autoconfiguration i cannot restart my network, i have this error.

sudo systemctl status networking.service
● networking.service - Raise network interfaces
     Loaded: loaded (/lib/systemd/system/networking.service; enabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Wed 2021-11-24 09:14:57 CET; 6min ago
       Docs: man:interfaces(5)
    Process: 856 ExecStart=/sbin/ifup -a --read-environment (code=exited, status=1/FAILURE)
   Main PID: 856 (code=exited, status=1/FAILURE)
        CPU: 151ms

nov. 24 09:14:57 debian dhclient: than a configuration issue please read the section on submitting
nov. 24 09:14:57 debian dhclient: bugs on either our web page at www.isc.org or in the README file
nov. 24 09:14:57 debian dhclient: before submitting a bug.  These pages explain the proper
nov. 24 09:14:57 debian dhclient: process and the information we find helpful for debugging.
nov. 24 09:14:57 debian dhclient:
nov. 24 09:14:57 debian dhclient: exiting.
nov. 24 09:14:57 debian ifup: ifup: failed to bring up eth0
nov. 24 09:14:57 debian systemd: networking.service: Main process exited, code=exited, status=1/FAILURE
nov. 24 09:14:57 debian systemd: networking.service: Failed with result 'exit-code'.
nov. 24 09:14:57 debian systemd: Failed to start Raise network interfaces.

I looked for advice for this problem but everything I could find about a configuration file at the address

/etc/network/interfaces.d/setup

that I don’t have. So I don’t know where this problem can come from. Have you ever encountered any of these problems? If you have any leads I am a taker. I can’t give you additional configuration because I don’t have the raspberry on the weekend.

I the old days, resolv.conf was static and you edited it yourself. Later on, the DHCP client would rewrite it, using some static entries and what it got from the DHCP lease. These days, some distributions - like mine (Linux Mint 18.1) have a /etc/resolv.conf.d mechanism with several subdirectories of scripts, and, well, I can't make heads and tails of it. What's the right way, then, to... - indicate that I want to use or not-use the DNS server(s) obtained in the DHCP lease? - add fixed entries to resolv.conf, always or as a fallback when there's no DHCP-lease-obtained nameserver? - make decisions about relative order in the file? I don't mind writing some scripts of my own if I have to, I just don't want to "work against" the existing mechanism or do duplicate work.

I'm using Debian jessie and I don't have network-manager or resolvconf installed and I'm using DHCP. **DHCP with static DNS** First of all I tried editing: /etc/network/interfaces And adding this: dns-nameservers 8.8.8.8 So now interfaces file looks like this: allow-hotplug eth0 iface eth0 inet dhcp dns-nameservers 8.8.8.8 To have DHCP and static DNS at the same time, but after restarting networking.service nothing will change. when using DHCP: ps aux | grep dhcp dhclient -v -pf /run/dhclient.eth0.pid -lf /var/lib/dhcp/dhclient.eth0.leases eth0 **Manually editing** If I manually edit /etc/resolv.conf and put nameserver 8.8.8.8 there, after restarting networking.service, system DNS server changes to 8.8.8.8, but after doing a ifup: sudo ifup eth0 Again /etc/resolv.conf automatically changes to 192.168.1.1. **NetworkManager** Then I decide to use network-manager, I installed network-manager and after setting DNS server IP in default connection and reconnecting it, it works but after rebooting the system, network-manager creates a new connection with default DNS server (192.168.1.1) and automatically connects to this one. I also checked *automatically connect to this network when it is available* in correct connection, but after reboot network-manager again connects to the other one. **Reseting after 10 Hour** I somehow managed to fix this issue by changing the new connection configs, now it does not create a new connection in every boot and connects to correct connection however now after something around 10 Hours DNS server automatically changes to 192.168.1.1 and I should reconnect the connection or restart NetworkManager.service to get DNS back into 8.8.8.8. So it's not network-manager which overrides /etc/resolv.cof **Static config** After facing all these I decide to go with static configuration. First I uninstalled network-manager then I added static configuration to: /etc/network/interfaces something like this: iface eth0 inet static address 192.168.1.10 gateway 192.168.1.1 netmask 255.255.255.0 dns-nameservers 8.8.8.8 After restarting networking.service these setting will not apply to system and interface has no IP so network is unreachable too. **Turning router DHCP off** Now that I turned my router's DHCP off, static config works fine, but I need DHCP to be on for other devices. **Permission** I can edit /etc/resolv.conf and change it's permission so nobody can edit it... But I'm looking for a reason. I want to know why these are not working, which program overrides /etc/resolv.conf and what is the right way to set DNS server. Is there anything that I'm missing here?

I have been configuring NixOS as a dev machine lately (and so far I really love it). I was planning of using a nginx image as reverse proxy to route all *.dev requests to running docker images. This works for requests to localhost already, as I can reach apps of started conainers when they're connected to the same network. Now for resolving *.dev requests I added a dnsmasq configuration to my nixos config: services.dnsmasq = { enable = true; resolveLocalQueries = true; servers = [ ''/.dev/127.0.0.1'' ''8.8.8.8'' ''8.8.4.4'' ]; }; When rebuilding, I get the output starting the following units: dnsmasq.service, but when I try to reach my .dev URI's, I still only get DNS_PROBE_FINISHED_NXDOMAIN. What could be the issue here?

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.

In Linux /etc/resolv.conf get often overwritten when we setup the DNS, because of the multitude of programs managing the DNS servers. How to properly setup the DNS ?

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'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.

### The issue Changing the DNS option in resolv.conf from the VM's gateway to 8.8.8.8 will result in no DNS resolution. resolvectl query google.com succeeds if I set DNS to my gateway. ### The set-up - /etc/resolv.conf is linked to stub-resolv.conf - systemd-networkd is configured as follows:

[Match]
  Name=enp0s3
  
  [Network]
  Address=192.168.0.222/24
  Gateway=192.168.0.1
  DNS=8.8.8.8

- /etc/systemd/resolv.conf has not been modified ### Additional troubleshooting - I tried linking /etc/resolv.conf to /run/systemd/resolve/resolv.conf instead and only listing 8.8.8.8 as nameserver there. But systemd-resolved overwrites /run/systemd/resolve/resolv.conf

One of my Fedora systems will often fail to do DNS resolution. Both ping host.ext and nslookup host.ext fail. When I edit /etc/resolv.conf to use nameserver 1.1.1.1 instead of nameserver 127.0.0.53, nslookup works, but ping still fails. Why is the runtime library not using the nameserver listed in /etc/resolv.conf? /etc/nsswitch.conf contains # Generated by authselect # Do not modify this file manually, use authselect instead. Any user changes will be overwritten. # You can stop authselect from managing your configuration by calling 'authselect opt-out'. # See authselect(8) for more details. # In order of likelihood of use to accelerate lookup. passwd: files sss systemd shadow: files group: files sss systemd hosts: files myhostname resolve [!UNAVAIL=return] dns services: files sss netgroup: files sss automount: files sss aliases: files ethers: files gshadow: files networks: files dns protocols: files publickey: files rpc: files How do I fix that? How do I persuade the local named to forward its requests to an external name server? Linux has acquired all these little "helpful" modules, but it seems to me they just obfuscate situations such as these.

I'm using Debian 11 (Bullseye). I'd like to use a different DNS server. I found the file /etc/resolv.conf. It looks like this (by default):

nameserver 192.168.1.1
nameserver 1.1.1.1
nameserver 8.8.8.8

Fair enough default. Use the local router/gateways DNS, then Cloudflare, followed by Google's DNS. There is a second file, too, though - /etc/network/interfaces. For me, where is what it looks like by default (I'm using DHCP)

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug enp4s0f0
iface enp4s0f0 inet dhcp

In that file, I can set my preferred DNS there by saying this, if I wanted to use, say, [quad9](https://www.quad9.net/) for my DNS.

dns-nameservers 9.9.9.9

So, if I'd like to change my DNS server, which file do I need to edit? Just one? Both?

I have 2 computer set up with Ubuntu 22.04.3 installed. They both have the same docker version (25.0.3, build 4debf41). However if I check the resolv.conf file in any container I create, the first one is copying the host resolv.conf whereas the other one has a file containing only the following line :

$ docker run -it --rm busybox
/ # cat /etc/resolv.conf
nameserver 10.0.2.3
/ #

The expected one looks like :

$ docker run -it --rm busybox
/ # 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 169.x.x.x
search c.my-org-domain.internal routeraabbcc.com lan
/ #

It is nearly the same as my host machine. I'm struggling to find the reason for this, because I need my container to re-use the host resolv.conf file which contains my organization dns.

I'm trying to modify NetworkManager's default DNS settings so that whenever I add a new connection it uses 127.0.0.1 instead of the default DNS for that connection. I still would like to be able to modify the DNS for each individual connections afterwards however. I set up [DNSCrypt](https://www.dnscrypt.org/) recently, and it worked great on most networks. However, some networks that I use require that I use their DNS server instead of DNSCrypt, meaning that I cannot simply set the default nameserver on resolv.conf to 127.0.0.1. I found that NetworkManager/nmcli still did a good job of using DNSCrypt when I changed some of the networks to use 127.0.0.1. However, it would be very nice if each new connection had this config by default: /etc/NetworkManager/system-connections/connection.conf looks like this:

-ini
[ipv4]
dns=127.0.0.1;
ignore-auto-dns=true
method=auto

In my research I found this in the NetworkConfig.conf manpage:

-none
Specify default values for connections. […]

Example:

    [connection]
    ipv6.ip6-privacy=0

However, there are only a few supported properties, and trying this did not work:

-ini
[connection]
ipv4.method=auto
ipv4.dns=127.0.0.1;
ipv4.ignore-auto-dns=true

I was wondering if there were any know workarounds to this issue, either using NetworkManager or something different.

Debian 12.4 with networking managed by systemd networking.service, dual stack IPv4 and IPv6. I am aware of the many questions asking how to _stop_ the system from updating resolv.conf, and this is not a duplicate. TL;DR ----- At bootup, ifup appears to be overwriting resolv.conf (which I want) but doing it "incorrectly" (I think). The result is that resolv.conf ends up looking like this (prefix obfuscated): nameserver 26xx:xxxx:xxxx:xxxx:201:2eff:fe70:3bfe What is missing here is the nameserver entry for IPv4, and the search entry for my LAN domain. Details ------- To troubleshoot, I did the following: * Deleted all current leases in /var/lib/dhcp * Started packet capture on the firewall for DHCP and DHCP6 ports * Rebooted the Debian system * Examined the resulting capture file with Wireshark The findings are: * The IPv4 DHCP transaction requests, and the server returns, all the necessary information, including the hostname, domain name and DNS server IP. * The IPv6 DHCP transaction requests the same data, but the response includes only the DNS server address; hostname and domain name are not present in the DHCP6 response. What I suspect is happening is that ifup is correctly setting up resolv.conf with the IPv4 data, then completely overwriting it with the IPv6 response instead of combining them. ***THE QUESTION***: What is supposed to happen with DHCP options and resolv.conf in a dual-stack system? Another way of asking that is "Who's at fault here, ifup or pfSense?" Note ---- Packages network-manager and resolvconf are not installed, and systemd-networkd is disabled. The network is being managed by systemd's networking.service unit. I didn't intentionally set things up this way, it's what I got by default at installation.