You can find a good explanation about how dns work on wikippedia.
As a simplification, you can look at it like an inverse file system. To discover the IP address for mydomain.net a computer will work in a similar way that to find a file on /net/mydomain. First it must read the root dir to find where id the net dir, in dns land it will have to ask the root servers for .net. Then it will read the net dir to search for mydomain, in dns land it will ask the.net server for mydomain.
Note that this was not a technically correct answer. Filesystems don't work that way, DNS caching and multiple DNS makes name resolving more complicated. But I feel that it is a simple model.
Back to your problem: the .net root dns are saying that the authoritative dns for your domain are dns1.stabletransit.com. and dns2.stabletransit.com.. So when a computer is triying to resolve test.mydomain.net it will ask dns1.stabletransit.com for the test.mydoin.net IP, not your server, and stabletransit doesn't know anything about test.
You have two options:
1) The sensible and easy one. Forget about running your dns server and just add test.mydomain.net to dns1.stabletransit.com. There is likely some option to do it where you bougth the domain.
2) The geek way, great for learning. Delegate your dns to your own server, learn all about dns, find some secondaries (your ISP will likely do it) and have fun. You will have to read quite a lot of documentation and experiment a little. Be sure that you are able to access your domain by IP, you will need it when (not if) something goes wrong.
I experienced similar problems, for example with adding an extra USB wifi dongle.
First I disabled dnsmasq in networkmanager as described above and I stopped dnsmasq (service dnsmasq stop)
I noticed that when resolving broke during my VPN connecting, the routing table looks slightly different (output of route command).
The name of the Gateway is DD-WRT in the case it does not work and simply 'gateway' when it does work.
The output of this did not change:
nmcli device show wlp1s0 | grep IP4.DNS
It kept showing my router IP.
A workaround to get it to work for a while is to restart systemd-resolvd:
sudo service systemd-resolved restart
Since dnsmasq is out of the equation, it is either systemd-resolvd that is the cause of the issue, or anything changing the routing table.
So this is the only difference I see:
ubuntu@ubuntu-Lenovo-Yoga-2-11:~$ route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default gateway 0.0.0.0 UG 601 0 0
which works.
And this when it does NOT work:
ubuntu@ubuntu-Lenovo-Yoga-2-11:~$ route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default DD-WRT 0.0.0.0 UG 601 0 0 wlp1s0
And the same name difference on the VPN line :
vpn-dns.name gateway 255.255.255.255 UGH 0 0 0 wlp1s0
Who knows what may influence the routing table?
It would be great if we can identify this so a bug report can be filed.
I am getting seriously sick and tired of pursuing all these bugs, but I would like to get them fixed so future users and us will be happy :).
[update]
It seems stopping systemd-resolved may fix this and not negatively impact other stuff. You can try that and let it know if it does break stuff.
I saw when running systemd-resolvd in debug when it broke:
Removing scope on link wlp1s0, protocol llmnr, family AF_INET
Removing scope on link wlp1s0, protocol llmnr, family AF_INET6
Removing scope on link *, protocol dns, family *
To disable:
sudo systemctl disable systemd-resolved.service
I updated the Ubuntu report with suggestions.
[/update]
Add: Note: the bug report :
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1624317
has a patch for 17.04 for some issues.
Please check the bug report and if possible test the patch. Thank you!
[update]
Please check the above mentioned bug report, the issue seems to be resolved for 17.10 and with a simple command DNS leakage can be disabled too.
[/update]
Best Answer
i did what @jringoot suggested in his comment:
mv /etc/resolv.conf /etc/resolv.conf_orig
ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf
which basically copies the original resolv.conf file and creates another one.
I examined it and it showed it was still using router dns.
so then I opened the file
vim /etc/resolv.conf
and edited the nameserver from the router dns to 1.1.1.1 (CloudFlare DNS)
i.e. fill it with:
nameserver 1.1.1.1
when i do a check using
nslookup google.com
it now shows it is using my specified DNS:
nslookup google.com
Server: 1.1.1.1
Address: 1.1.1.1#53
Non-authoritative answer:
Name: google.com
Address: 172.217.160.14