Temporary activate other nameserver

On a ipv6 only server I want to temporary activate another nameserver who offers DNS64/NAT64 to bridge connections to ipv4 addresses.

I only need this connection to backup a SVN repository from svn.code.sf.net for which unfortunately no aaaa record exists (why?!!)

I solved the issue by changing the content of /etc/resolv.conf from within the shellscript that does the backup job. After the download it changes the nameserver entries back to the normal configuration.

It runs now with a “sleep 10” after the change which succeeded in all my tests. But I would prefer to signal the new values to the responsible daemon.

Will that be the NetworkManager.service? Or what is the best method for my demand?

OS: Rocky Linux release 9.3 (Blue Onyx)

Thanks for your advice!

Found this Doc with instruction on changing dns configuration via nmcli
which seem to be the correct way (other than changing the file /etc/resolv.conf directly)
Will give it a try tomorrow…

Yes, that is usually the way; NetworkManager manages the /etc/resolv.conf
NetworkManager can be configured to not touch the /etc/resolv.conf, but then one needs some other way to manage it.

Note though that the /etc/nsswitch.conf has probably files dns for hosts. That is, the name resolution reads first /etc/hosts and after that uses the resolver (if necessary). The /etc/hosts has by default only the localhost ( and ::1). You could have that one “AAAA” in there, if only this host needs that one (static) address.

I thought about that before implementing the change of /etc/resolv.conf, but I suppose the NAT64 service which I use as bridge to IPv4 creates the fake IPv6 address on demand. So it will only be there for the while where I call the connection via the DNS64 service.

It worked :slight_smile:

Here the recipe for activating the “Public NAT64 service” (https://www.nat64.net/) on my Rocky Linux 9 server in the Hetzner Cloud (cax11)

nmcli con mod 'System eth0' ipv6.dns '2a00:1098:2c::1,2a01:4f8:c2c:123f::1,2a00:1098:2b::1'
nmcli con down 'System eth0' && nmcli con up 'System eth0'

and back to normal configuration:

nmcli con mod 'System eth0' ipv6.dns '2a01:4ff:ff00::add:1,2a01:4ff:ff00::add:2'
nmcli con down 'System eth0' && nmcli con up 'System eth0'

1 Like

Instead of modifying the existing connection, how about creating a second connection, and then switch between them?

man nmcli

heading “connection management commands”

1 Like

Thanks for the hint! Yes, that looks like the ideal method for my case :smiley: I will work on it and post the improved recipe when ready and tested.

Done and works like a charm! Thanks again for pointing me to this improved method! :hugs:

Create a new connection with settings from Hetzners default

# nmcli con clone 'System eth0' nat64
System eth0 (5fb06bd0-0bb0-7ffb-45f1-d6edd65f3e03) cloned as nat64 (4ca97012-e022-4572-bac6-14e6c318dc72).

Modify new connection to use DNS64/NAT64 from “Public NAT64 service” (https://www.nat64.net/)
# nmcli con mod nat64 ipv6.dns '2a00:1098:2c::1,2a01:4f8:c2c:123f::1,2a00:1098:2b::1' connection.autoconnect no

Switch to new connection

# nmcli -p con up nat64 ifname eth0
Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/7)

Switch back to default

# nmcli -p con up 'System eth0' ifname eth0
Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/8)

Now you have two connections for that one interface. If you did clone all settings, then both have connection.autoconnect: yes. Which one do you expect to take over when the system boots?

Perhaps this “temporary” connection should not try to activate on boot? connection.autoconnect: no
Alternatively, tune the connection.autoconnect-priority of them to make the regular “win”.

1 Like

Thanks for your review and warning! I now fixed it on the machine and in the solutions post.

It was great to see the command lines used in the test.