So I saw the DNS not being a full DNS limitation in practice after all…
I checked my VPN (done over the routers, not software) with my work, did the appropriate changes. VPN works ok. DNS resolution doesn’t.
The other side of the VPN is a Windows 2016 domain network.
So the normal process would be to make a stub zone in my Windows 2016 DNS, to let my work network know about my LOCAL domain. So the public DNS (that does work in my hosting provider), cannot help at all, if I want to pass things throught the VPN and still use FQDN instead of IP.
But I cannot use a stub zone, because none of the remote (my home side) DNS can respond as a proper DNS server. Not my router, not my NethServer.
Actually my NethServer SAMBA (which is a docker with own IP) DOES respond like a proper DNS, but… is useless to me as it doesn’t know any other machine than itself and there is no user friendly way to pass DNS information from NS own basic DNS.
So I had to falsely create a normal zone in my work DNS (i.e. making it think it is authoritative for my local.myhome.net domain) and manually entered host names, so that someone over VPN contacting myserver.local.myhome.net, actually resolve it and access it through the VPN.
I wonder if instead of re-implementing a better VPN, all we need is an interface to the SAMBA provided DNS as MAIN DNS (obviously for NS systems with enabled SAMBA docker).