Pushing DNS to clients?

BobAGI

In what scenario is it advisable to activate these lines in the server.conf?

push "dhcp-option DNS 208.67.222.222"
push "dhcp-option DNS 208.67.220.220"

If the client has a working DNS already it seems like it should stay rather than being replaced?

But what should really be useful is to be able to push some kind of addition to the DNS, which will resolve the computers on the server side network.
As it is now I have to rely on entries in the client side hosts file when accessing server side computers and this trick does not work on units like Android phones where one cannot add entries to the hosts file (In fact I have not even found out where the hosts file is located on an Android).
Can I for instance do this:

push "dhcp-option DNS 10.0.0.7"

If I do, will that replace the current DNS wholly or add to it?

The problem here is that if I do not add the local server IP address to my client side hosts file I get totally bogus IP when I ping a host.
Like this, first ping from a server side Windows host (on it via RDP) to a server side workstation I have not added to my client side hosts file:

ping leroy-hp
Pinging leroy-hp.xxxx.com [10.0.0.31] with 32 bytes of data:
Reply from 10.0.0.31: bytes=32 time<1ms TTL=128

This resolves to the correct IP.
Then the same on my own remote PC while I have an OpenVPN tunnel hooked up to the server side LAN:

ping leroy-hp
Pinging leroy-hp.xxxx.com [206.188.193.179] with 32 bytes of data:
Reply from 206.188.193.179: bytes=32 time=122ms TTL=239

Note that the xxxx here (domain name) are the same in both responses even though I have not added a domain in my ping request.
Finally what happens when I ping a server side host (the server side DNS server in fact), which is added to my hosts file, from my client side PC:

ping main02
Pinging main02 [10.0.0.7] with 32 bytes of data:
Reply from 10.0.0.7: bytes=32 time=140ms TTL=127

I cannot wrap my head around this, it seems totally screwed up....

TinCanTech

DNS is a monster service which different OSs do differently.

For Windows you need to use --block-outside-dns, otherwise Windows simply ignores pushed DNS.
For Linux you have to use update-resolv-conf script, otherwise Linux does not install the pushed DNS.
I don't know what Android does ..

There is also "--dhcp-option DOMAIN your.domain" which sets Connection-specific DNS Suffix.
The "Domain domain" needs to be pushed after the "DNS address" ..

BobAGI

Yeah, I googled and found a maze of different approaches all more or less working....
Where do I put the --block-outside-dns? Inside the client.ovpn file or on the server in the server.conf file?
My servers are all Linux, RaspberryPi with Raspbian and now when I am building a replacement for an RPi Ubuntu Server 16.04-3 LTS on a spare mini PC.

TinCanTech

BobAGI wrote Where do I put the --block-outside-dns? Inside the client.ovpn file or on the server in the server.conf file?

By now you ought to know .. having read the openvpn docs.

BobAGI

TinCanTech wrote
BobAGI wrote Where do I put the --block-outside-dns? Inside the client.ovpn file or on the server in the server.conf file?
By now you ought to know .. having read the openvpn docs.

OK, OK, it does not say when I read the option, the description is in a section named "Windows-Specific options".
But there is an indication half a mile up the page where there is suddenly a line saying "Client mode"...

Anyway, it looks like if this is done it will BLOCK access to the client side DNS, which should be used for all hosts not on the office LAN.
I.e. the "normal" DNS should be used as a fall-back.
Is that possible?

And why am I getting totally erroneous responses for hosts on the LAN when the normal DNS is in use?
How can "leroy-hp" resolve to an address at all like 206.188.193.179 (WhoIs places this address somewhere in Florida...)
I am on a Windows 7 Pro x64 laptop btw.