I long ago created my own shell scripts that permanently connect to my own NAS on my private local area network (LAN) via SSH.
Create a simple example of a new script:
#!/bin/env bash
while sleep 5; do
ssh NAS-local ### It is domain name, I do not use IP address as a hard code. Let DNS resolve IP address first.
### My own router knows where is this NAS-local. I do not need ISP.
done
I do not use any option like ssh -6 <domain-name> for IPv6. I do NOT want the connection with my NAS on a public network (WAN and MAN, for example: ISP is on the WAN).
LAN is okay for me because my own private router knows where my NAS host is located. I do not need this public ISP to resolve my NAS domain to an IPv6 address.
My devices, router and ISP support native IPv6.
This script will be executed automatically when reboot.
A issue:
The nice Portmaster firewall sometimes notifies me after rebooting my computer, but ssh want to connect to my public ISP on the WAN once by rebooting because of IPv6. (I see a clear detail, the public IPv6 address belongs to my ISP)
I know SSH is not a problem with IPv4. For example, I force ssh to use the option: ssh -4 <domain-name> → No issue. It always connects to my private LAN.
I know now after my investigation. systemd-resolve caused this.
It is related to the tip I had followed a long time ago:
My solution:
Delete the symlink /etc/resolv.conf for systemd-resolved.
Disable systemd-resolved.service.
I restore my old resolv.conf from my backup. However, it could be generated by networkmanager as the dependency required by KDE.
The SSH IPv6 connection to my private NAS always remains in my private LAN after DNS resolving on my private router after each reboot, that is my expectation.
Edit:
That looks like systemd-resolve --status shows that ISP’s DNS with IPv6 support is used as the current default DNS server after reboot.
Edit2:
Another solution is also possible if you want to continue using systemd-resolved
Hmm - IPv6 is often more trouble than it is worth.
But I doubt the reason to your trouble is the resolver app used.
How did you reach the conclusion that using systemd-resolved is the root cause?
This is because you are using an unqualified hostname which does not resolve inside your LAN - likely because the primary DNS is not inside your LAN as you discovered.
Years ago I investigated why I had all that trouble resolving local computer names - and I ended up setting up ISC-bind and ISC-dhcp service on a raspberry pi using a subnet of a public domain I own.
I had severe headaches learning the bind syntax but when I finally got it working - what a relief - and it is easy to mantain.
This setup makes resolving local names a piece of cake.
The default order of multiple DNS servers is not good in systemd-resolved. For example, I have 3 different DNS servers in LAN and WAN:
DNS server in my private router for IPv4 on the LAN.
DNS server in my private router for IPv6 on the LAN.
DNS server in the paid ISP router for IPv6 on the WAN, not IPv4.
(AFAIK, IPv6 does not need NAT, this is why the ISP can know where many many devices are on the LAN and WAN)
(Everyone needs an ISP. If without ISP, then you can no longer use Internet except LAN).
systemd-resolved automatically selects 3rd DNS as the default DNS server. I have never manually configured DNS from systemd-resolved.
When I switched systemd-resolved to networkmanager, networkmanager generated these 3 same DNS servers in /etc/resolv.conf, but in a different order not the same as systemd-resolved:
The second DNS server (in my router) is first default and the third DNS server (in my paid ISP) is last in the order of networkmanager.
