Resolver: LAN, VPN and WAN name resolution
![Creative The name of the picture](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgO9GURib1T8z7lCwjOGLQaGtrueEthgQ8LO42ZX8cOfTqDK4jvDDpKkLFwf2J49kYCMNW7d4ABih_XCb_2UXdq5fPJDkoyg7-8g_YfRUot-XnaXkNYycsNp7lA5_TW9td0FFpLQ2APzKcZ/s1600/1.jpg)
![Creative The name of the picture](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhYQ0N5W1qAOxLP7t7iOM6O6AzbZnkXUy16s7P_CWfOb5UbTQY_aDsc727chyphenhyphen5W4IppVNernMMQeaUFTB_rFzAd95_CDt-tnwN-nBx6JyUp2duGjPaL5-VgNO41AVsA_vu30EJcipdDG409/s400/Clash+Royale+CLAN+TAG%2523URR8PPP.png)
up vote
1
down vote
favorite
I have read the man pages on resolv.conf and resolvconf and resolvconf.conf but don't understand everything and feel I'm a tad lost on how I might (ahem) resolve this problem:
Scenario:
I have a LAN with a router that acts as DHCP and nameserver. The nameserver resolves all devices on this LAN either with no TLD or the .lan TLD. For example I can resolve with nslookup, ping, and any other tool names like "nas" and "nas.lan" that reach my NAS server (network accessible storage server). Any other names it forwards the request on to my ISP's DNSs.
My resolv.conf therefore looks like this:
# Generated by resolvconf
domain lan
nameserver 192.168.0.1
I get fine resolution of all LAN and WAN names.
I now connect to a Cisco VPN at work and resolvconf updates the resolv.conf to:
# Generated by resolvconf
domain myworkplace.com
search myworkplace.com lan
nameserver 192.168.1.10
nameserver 192.168.1.11
nameserver 192.168.0.1
And now I cannot reach "nas" or "nas.lan" on my LAN anymore but I can reach "nas" and "nas.myworkplace.com" on the VPN. WAN names are now resolved by the VPN assigned namesever 192.168.1.10, and the NAS I reach this way is on the VPN not on my LAN (a different server).
Aside: I don't actually have any such name clash, but I provide it in the apocryphal example here because a solution clearly needs to cater for it.
Now what I would like to achieve is something like this:
"nas.lan" resolves to my LAN NAS
"nas.myworkplace.com" resolves to the VPN NAS
"nas" resolves to one or the other based on config (hints of resolv.conf's ndots setting here but not sure).
My questions:
- Is this even doable with resolvconf?
- If not, is there some other way to do it (example using dnsmaq instead of libc as a resolver on my box?).
I appreciate any pointers here as I'm finding the man pages to be less than easy to digest and decrypt with a specific need like this in mind. I have searched on-line for a good while now and oddly enough only found others asking the same question (without answer) in other fora!
This isn't a problem unique to me, or my discovery clearly. Anyone on a LAN with devices they wants to see there, connecting to another LAN over a VPN seems likely to run into precisely this issue of being able to resolve only names on the VPN not the LAN while connected, needing to close the VPN to resolve LAN names again.
dns vpn lan resolv.conf resolvconf
add a comment |Â
up vote
1
down vote
favorite
I have read the man pages on resolv.conf and resolvconf and resolvconf.conf but don't understand everything and feel I'm a tad lost on how I might (ahem) resolve this problem:
Scenario:
I have a LAN with a router that acts as DHCP and nameserver. The nameserver resolves all devices on this LAN either with no TLD or the .lan TLD. For example I can resolve with nslookup, ping, and any other tool names like "nas" and "nas.lan" that reach my NAS server (network accessible storage server). Any other names it forwards the request on to my ISP's DNSs.
My resolv.conf therefore looks like this:
# Generated by resolvconf
domain lan
nameserver 192.168.0.1
I get fine resolution of all LAN and WAN names.
I now connect to a Cisco VPN at work and resolvconf updates the resolv.conf to:
# Generated by resolvconf
domain myworkplace.com
search myworkplace.com lan
nameserver 192.168.1.10
nameserver 192.168.1.11
nameserver 192.168.0.1
And now I cannot reach "nas" or "nas.lan" on my LAN anymore but I can reach "nas" and "nas.myworkplace.com" on the VPN. WAN names are now resolved by the VPN assigned namesever 192.168.1.10, and the NAS I reach this way is on the VPN not on my LAN (a different server).
Aside: I don't actually have any such name clash, but I provide it in the apocryphal example here because a solution clearly needs to cater for it.
Now what I would like to achieve is something like this:
"nas.lan" resolves to my LAN NAS
"nas.myworkplace.com" resolves to the VPN NAS
"nas" resolves to one or the other based on config (hints of resolv.conf's ndots setting here but not sure).
My questions:
- Is this even doable with resolvconf?
- If not, is there some other way to do it (example using dnsmaq instead of libc as a resolver on my box?).
I appreciate any pointers here as I'm finding the man pages to be less than easy to digest and decrypt with a specific need like this in mind. I have searched on-line for a good while now and oddly enough only found others asking the same question (without answer) in other fora!
This isn't a problem unique to me, or my discovery clearly. Anyone on a LAN with devices they wants to see there, connecting to another LAN over a VPN seems likely to run into precisely this issue of being able to resolve only names on the VPN not the LAN while connected, needing to close the VPN to resolve LAN names again.
dns vpn lan resolv.conf resolvconf
add a comment |Â
up vote
1
down vote
favorite
up vote
1
down vote
favorite
I have read the man pages on resolv.conf and resolvconf and resolvconf.conf but don't understand everything and feel I'm a tad lost on how I might (ahem) resolve this problem:
Scenario:
I have a LAN with a router that acts as DHCP and nameserver. The nameserver resolves all devices on this LAN either with no TLD or the .lan TLD. For example I can resolve with nslookup, ping, and any other tool names like "nas" and "nas.lan" that reach my NAS server (network accessible storage server). Any other names it forwards the request on to my ISP's DNSs.
My resolv.conf therefore looks like this:
# Generated by resolvconf
domain lan
nameserver 192.168.0.1
I get fine resolution of all LAN and WAN names.
I now connect to a Cisco VPN at work and resolvconf updates the resolv.conf to:
# Generated by resolvconf
domain myworkplace.com
search myworkplace.com lan
nameserver 192.168.1.10
nameserver 192.168.1.11
nameserver 192.168.0.1
And now I cannot reach "nas" or "nas.lan" on my LAN anymore but I can reach "nas" and "nas.myworkplace.com" on the VPN. WAN names are now resolved by the VPN assigned namesever 192.168.1.10, and the NAS I reach this way is on the VPN not on my LAN (a different server).
Aside: I don't actually have any such name clash, but I provide it in the apocryphal example here because a solution clearly needs to cater for it.
Now what I would like to achieve is something like this:
"nas.lan" resolves to my LAN NAS
"nas.myworkplace.com" resolves to the VPN NAS
"nas" resolves to one or the other based on config (hints of resolv.conf's ndots setting here but not sure).
My questions:
- Is this even doable with resolvconf?
- If not, is there some other way to do it (example using dnsmaq instead of libc as a resolver on my box?).
I appreciate any pointers here as I'm finding the man pages to be less than easy to digest and decrypt with a specific need like this in mind. I have searched on-line for a good while now and oddly enough only found others asking the same question (without answer) in other fora!
This isn't a problem unique to me, or my discovery clearly. Anyone on a LAN with devices they wants to see there, connecting to another LAN over a VPN seems likely to run into precisely this issue of being able to resolve only names on the VPN not the LAN while connected, needing to close the VPN to resolve LAN names again.
dns vpn lan resolv.conf resolvconf
I have read the man pages on resolv.conf and resolvconf and resolvconf.conf but don't understand everything and feel I'm a tad lost on how I might (ahem) resolve this problem:
Scenario:
I have a LAN with a router that acts as DHCP and nameserver. The nameserver resolves all devices on this LAN either with no TLD or the .lan TLD. For example I can resolve with nslookup, ping, and any other tool names like "nas" and "nas.lan" that reach my NAS server (network accessible storage server). Any other names it forwards the request on to my ISP's DNSs.
My resolv.conf therefore looks like this:
# Generated by resolvconf
domain lan
nameserver 192.168.0.1
I get fine resolution of all LAN and WAN names.
I now connect to a Cisco VPN at work and resolvconf updates the resolv.conf to:
# Generated by resolvconf
domain myworkplace.com
search myworkplace.com lan
nameserver 192.168.1.10
nameserver 192.168.1.11
nameserver 192.168.0.1
And now I cannot reach "nas" or "nas.lan" on my LAN anymore but I can reach "nas" and "nas.myworkplace.com" on the VPN. WAN names are now resolved by the VPN assigned namesever 192.168.1.10, and the NAS I reach this way is on the VPN not on my LAN (a different server).
Aside: I don't actually have any such name clash, but I provide it in the apocryphal example here because a solution clearly needs to cater for it.
Now what I would like to achieve is something like this:
"nas.lan" resolves to my LAN NAS
"nas.myworkplace.com" resolves to the VPN NAS
"nas" resolves to one or the other based on config (hints of resolv.conf's ndots setting here but not sure).
My questions:
- Is this even doable with resolvconf?
- If not, is there some other way to do it (example using dnsmaq instead of libc as a resolver on my box?).
I appreciate any pointers here as I'm finding the man pages to be less than easy to digest and decrypt with a specific need like this in mind. I have searched on-line for a good while now and oddly enough only found others asking the same question (without answer) in other fora!
This isn't a problem unique to me, or my discovery clearly. Anyone on a LAN with devices they wants to see there, connecting to another LAN over a VPN seems likely to run into precisely this issue of being able to resolve only names on the VPN not the LAN while connected, needing to close the VPN to resolve LAN names again.
dns vpn lan resolv.conf resolvconf
asked Apr 25 at 11:28
![](https://i.stack.imgur.com/fFIBX.jpg?s=32&g=1)
![](https://i.stack.imgur.com/fFIBX.jpg?s=32&g=1)
Validator
82
82
add a comment |Â
add a comment |Â
2 Answers
2
active
oldest
votes
up vote
2
down vote
accepted
I guess the reason why you can't use your LAN DNS when using the VPN is that the resolver only makes two attempts by default:
From resolv.conf manual:
attempts:n
sets the number of times the resolver will send a query to its name servers before giving up and returning an error to the calling application. The default is RES_DFLRETRY (currently 2, see ). The value for this option is silently capped to 5.
So its is trying the two DNS Servers provided by your companys VPN first and than returns an error. You could set attempts to 3 so your LAN DNS is also taken into consideration.
The downside to this is, that it slows down your DNS requests by waiting for the last server to finally answer. And you are sending all your DNS request to your company - thats an impact on performance and your privacy as well.
I would recommend to use dnsmasq.
You could add upstream DNS server by domain in a dnsmasq conf with an specified domain like this:
server=/lan/192.168.0.1
And by default dnsmasq polls upstream servers from the /etc/resolv.conf.
From the Notes section of the dnsmasq Manpage:
... By default, dnsmasq reads /etc/resolv.conf to discover the IP addresses of the upstream nameservers it should use, since the information is typically stored there. Unless --no-poll is used, dnsmasq checks the modification time of /etc/resolv.conf (or equivalent if --resolv-file is used) and re-reads it if it changes. This allows the DNS servers to be set dynamically by PPP or DHCP since both protocols provide the information. ...
So if your VPN Client change the resolv.conf you are able to use both if you could keep your dnsmasq on top of the resolv.conf.
But i guess this is not how the VPN is editing you resolv.conf so i would try to disable the DNS capabilities of the VPN and add the DNS Servers of your company manually to your dnsmasq config:
server=/myworkplace.com/192.168.1.10
server=/myworkplace.com/192.168.1.11
server=192.168.0.1
In this case all your queries for the internet and lan going to 192.168.0.1 and all queries for myworkplace.com are going to your companys DNS.
Turns out that "attempts:n" doesn't solve the problem. To clarify I can, in resolv.conf put my LAN nameserver at top followed by the two VPN namesevers (and attempts: 3), and LAN names resolve, WAN names resolve, but VPN names do not. That is my nameserver responds in the negative and the libc resolver does not try the next nameserver. Which is a shame as that slight behavioural change in the libc resolver would see this issue easy to solve. The dnsmasq solution I suspect increasingly is the only one available (though yet to test) and I appreciate the tip!
â Validator
Apr 26 at 12:45
add a comment |Â
up vote
0
down vote
git clone https://github.com/timebandit1969/resolvchange.git
https://www.purebasic.com/download.php and download linux demo version of PureBasic x64, don't worry I don't think the limitations will stop you from compiling it, I checked it out. Compile (Make Executable) resolvchange.pb
chmod +x resolvchange
start vpn if running one and immediately run resolvchange with the following:
./resolvchange
That was a program that fixes the issue with network-manager or dnsmasq etc messing up the dns in resolv.conf, completely I am free from the problem with resolvchange
â Joe Pisco
Apr 29 at 9:05
add a comment |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
2
down vote
accepted
I guess the reason why you can't use your LAN DNS when using the VPN is that the resolver only makes two attempts by default:
From resolv.conf manual:
attempts:n
sets the number of times the resolver will send a query to its name servers before giving up and returning an error to the calling application. The default is RES_DFLRETRY (currently 2, see ). The value for this option is silently capped to 5.
So its is trying the two DNS Servers provided by your companys VPN first and than returns an error. You could set attempts to 3 so your LAN DNS is also taken into consideration.
The downside to this is, that it slows down your DNS requests by waiting for the last server to finally answer. And you are sending all your DNS request to your company - thats an impact on performance and your privacy as well.
I would recommend to use dnsmasq.
You could add upstream DNS server by domain in a dnsmasq conf with an specified domain like this:
server=/lan/192.168.0.1
And by default dnsmasq polls upstream servers from the /etc/resolv.conf.
From the Notes section of the dnsmasq Manpage:
... By default, dnsmasq reads /etc/resolv.conf to discover the IP addresses of the upstream nameservers it should use, since the information is typically stored there. Unless --no-poll is used, dnsmasq checks the modification time of /etc/resolv.conf (or equivalent if --resolv-file is used) and re-reads it if it changes. This allows the DNS servers to be set dynamically by PPP or DHCP since both protocols provide the information. ...
So if your VPN Client change the resolv.conf you are able to use both if you could keep your dnsmasq on top of the resolv.conf.
But i guess this is not how the VPN is editing you resolv.conf so i would try to disable the DNS capabilities of the VPN and add the DNS Servers of your company manually to your dnsmasq config:
server=/myworkplace.com/192.168.1.10
server=/myworkplace.com/192.168.1.11
server=192.168.0.1
In this case all your queries for the internet and lan going to 192.168.0.1 and all queries for myworkplace.com are going to your companys DNS.
Turns out that "attempts:n" doesn't solve the problem. To clarify I can, in resolv.conf put my LAN nameserver at top followed by the two VPN namesevers (and attempts: 3), and LAN names resolve, WAN names resolve, but VPN names do not. That is my nameserver responds in the negative and the libc resolver does not try the next nameserver. Which is a shame as that slight behavioural change in the libc resolver would see this issue easy to solve. The dnsmasq solution I suspect increasingly is the only one available (though yet to test) and I appreciate the tip!
â Validator
Apr 26 at 12:45
add a comment |Â
up vote
2
down vote
accepted
I guess the reason why you can't use your LAN DNS when using the VPN is that the resolver only makes two attempts by default:
From resolv.conf manual:
attempts:n
sets the number of times the resolver will send a query to its name servers before giving up and returning an error to the calling application. The default is RES_DFLRETRY (currently 2, see ). The value for this option is silently capped to 5.
So its is trying the two DNS Servers provided by your companys VPN first and than returns an error. You could set attempts to 3 so your LAN DNS is also taken into consideration.
The downside to this is, that it slows down your DNS requests by waiting for the last server to finally answer. And you are sending all your DNS request to your company - thats an impact on performance and your privacy as well.
I would recommend to use dnsmasq.
You could add upstream DNS server by domain in a dnsmasq conf with an specified domain like this:
server=/lan/192.168.0.1
And by default dnsmasq polls upstream servers from the /etc/resolv.conf.
From the Notes section of the dnsmasq Manpage:
... By default, dnsmasq reads /etc/resolv.conf to discover the IP addresses of the upstream nameservers it should use, since the information is typically stored there. Unless --no-poll is used, dnsmasq checks the modification time of /etc/resolv.conf (or equivalent if --resolv-file is used) and re-reads it if it changes. This allows the DNS servers to be set dynamically by PPP or DHCP since both protocols provide the information. ...
So if your VPN Client change the resolv.conf you are able to use both if you could keep your dnsmasq on top of the resolv.conf.
But i guess this is not how the VPN is editing you resolv.conf so i would try to disable the DNS capabilities of the VPN and add the DNS Servers of your company manually to your dnsmasq config:
server=/myworkplace.com/192.168.1.10
server=/myworkplace.com/192.168.1.11
server=192.168.0.1
In this case all your queries for the internet and lan going to 192.168.0.1 and all queries for myworkplace.com are going to your companys DNS.
Turns out that "attempts:n" doesn't solve the problem. To clarify I can, in resolv.conf put my LAN nameserver at top followed by the two VPN namesevers (and attempts: 3), and LAN names resolve, WAN names resolve, but VPN names do not. That is my nameserver responds in the negative and the libc resolver does not try the next nameserver. Which is a shame as that slight behavioural change in the libc resolver would see this issue easy to solve. The dnsmasq solution I suspect increasingly is the only one available (though yet to test) and I appreciate the tip!
â Validator
Apr 26 at 12:45
add a comment |Â
up vote
2
down vote
accepted
up vote
2
down vote
accepted
I guess the reason why you can't use your LAN DNS when using the VPN is that the resolver only makes two attempts by default:
From resolv.conf manual:
attempts:n
sets the number of times the resolver will send a query to its name servers before giving up and returning an error to the calling application. The default is RES_DFLRETRY (currently 2, see ). The value for this option is silently capped to 5.
So its is trying the two DNS Servers provided by your companys VPN first and than returns an error. You could set attempts to 3 so your LAN DNS is also taken into consideration.
The downside to this is, that it slows down your DNS requests by waiting for the last server to finally answer. And you are sending all your DNS request to your company - thats an impact on performance and your privacy as well.
I would recommend to use dnsmasq.
You could add upstream DNS server by domain in a dnsmasq conf with an specified domain like this:
server=/lan/192.168.0.1
And by default dnsmasq polls upstream servers from the /etc/resolv.conf.
From the Notes section of the dnsmasq Manpage:
... By default, dnsmasq reads /etc/resolv.conf to discover the IP addresses of the upstream nameservers it should use, since the information is typically stored there. Unless --no-poll is used, dnsmasq checks the modification time of /etc/resolv.conf (or equivalent if --resolv-file is used) and re-reads it if it changes. This allows the DNS servers to be set dynamically by PPP or DHCP since both protocols provide the information. ...
So if your VPN Client change the resolv.conf you are able to use both if you could keep your dnsmasq on top of the resolv.conf.
But i guess this is not how the VPN is editing you resolv.conf so i would try to disable the DNS capabilities of the VPN and add the DNS Servers of your company manually to your dnsmasq config:
server=/myworkplace.com/192.168.1.10
server=/myworkplace.com/192.168.1.11
server=192.168.0.1
In this case all your queries for the internet and lan going to 192.168.0.1 and all queries for myworkplace.com are going to your companys DNS.
I guess the reason why you can't use your LAN DNS when using the VPN is that the resolver only makes two attempts by default:
From resolv.conf manual:
attempts:n
sets the number of times the resolver will send a query to its name servers before giving up and returning an error to the calling application. The default is RES_DFLRETRY (currently 2, see ). The value for this option is silently capped to 5.
So its is trying the two DNS Servers provided by your companys VPN first and than returns an error. You could set attempts to 3 so your LAN DNS is also taken into consideration.
The downside to this is, that it slows down your DNS requests by waiting for the last server to finally answer. And you are sending all your DNS request to your company - thats an impact on performance and your privacy as well.
I would recommend to use dnsmasq.
You could add upstream DNS server by domain in a dnsmasq conf with an specified domain like this:
server=/lan/192.168.0.1
And by default dnsmasq polls upstream servers from the /etc/resolv.conf.
From the Notes section of the dnsmasq Manpage:
... By default, dnsmasq reads /etc/resolv.conf to discover the IP addresses of the upstream nameservers it should use, since the information is typically stored there. Unless --no-poll is used, dnsmasq checks the modification time of /etc/resolv.conf (or equivalent if --resolv-file is used) and re-reads it if it changes. This allows the DNS servers to be set dynamically by PPP or DHCP since both protocols provide the information. ...
So if your VPN Client change the resolv.conf you are able to use both if you could keep your dnsmasq on top of the resolv.conf.
But i guess this is not how the VPN is editing you resolv.conf so i would try to disable the DNS capabilities of the VPN and add the DNS Servers of your company manually to your dnsmasq config:
server=/myworkplace.com/192.168.1.10
server=/myworkplace.com/192.168.1.11
server=192.168.0.1
In this case all your queries for the internet and lan going to 192.168.0.1 and all queries for myworkplace.com are going to your companys DNS.
edited Apr 25 at 12:52
answered Apr 25 at 12:02
![](https://lh5.googleusercontent.com/---vXIVnCW30/AAAAAAAAAAI/AAAAAAAAAJ8/LcS4Ff7iIY4/photo.jpg?sz=32)
![](https://lh5.googleusercontent.com/---vXIVnCW30/AAAAAAAAAAI/AAAAAAAAAJ8/LcS4Ff7iIY4/photo.jpg?sz=32)
FSchndr
364
364
Turns out that "attempts:n" doesn't solve the problem. To clarify I can, in resolv.conf put my LAN nameserver at top followed by the two VPN namesevers (and attempts: 3), and LAN names resolve, WAN names resolve, but VPN names do not. That is my nameserver responds in the negative and the libc resolver does not try the next nameserver. Which is a shame as that slight behavioural change in the libc resolver would see this issue easy to solve. The dnsmasq solution I suspect increasingly is the only one available (though yet to test) and I appreciate the tip!
â Validator
Apr 26 at 12:45
add a comment |Â
Turns out that "attempts:n" doesn't solve the problem. To clarify I can, in resolv.conf put my LAN nameserver at top followed by the two VPN namesevers (and attempts: 3), and LAN names resolve, WAN names resolve, but VPN names do not. That is my nameserver responds in the negative and the libc resolver does not try the next nameserver. Which is a shame as that slight behavioural change in the libc resolver would see this issue easy to solve. The dnsmasq solution I suspect increasingly is the only one available (though yet to test) and I appreciate the tip!
â Validator
Apr 26 at 12:45
Turns out that "attempts:n" doesn't solve the problem. To clarify I can, in resolv.conf put my LAN nameserver at top followed by the two VPN namesevers (and attempts: 3), and LAN names resolve, WAN names resolve, but VPN names do not. That is my nameserver responds in the negative and the libc resolver does not try the next nameserver. Which is a shame as that slight behavioural change in the libc resolver would see this issue easy to solve. The dnsmasq solution I suspect increasingly is the only one available (though yet to test) and I appreciate the tip!
â Validator
Apr 26 at 12:45
Turns out that "attempts:n" doesn't solve the problem. To clarify I can, in resolv.conf put my LAN nameserver at top followed by the two VPN namesevers (and attempts: 3), and LAN names resolve, WAN names resolve, but VPN names do not. That is my nameserver responds in the negative and the libc resolver does not try the next nameserver. Which is a shame as that slight behavioural change in the libc resolver would see this issue easy to solve. The dnsmasq solution I suspect increasingly is the only one available (though yet to test) and I appreciate the tip!
â Validator
Apr 26 at 12:45
add a comment |Â
up vote
0
down vote
git clone https://github.com/timebandit1969/resolvchange.git
https://www.purebasic.com/download.php and download linux demo version of PureBasic x64, don't worry I don't think the limitations will stop you from compiling it, I checked it out. Compile (Make Executable) resolvchange.pb
chmod +x resolvchange
start vpn if running one and immediately run resolvchange with the following:
./resolvchange
That was a program that fixes the issue with network-manager or dnsmasq etc messing up the dns in resolv.conf, completely I am free from the problem with resolvchange
â Joe Pisco
Apr 29 at 9:05
add a comment |Â
up vote
0
down vote
git clone https://github.com/timebandit1969/resolvchange.git
https://www.purebasic.com/download.php and download linux demo version of PureBasic x64, don't worry I don't think the limitations will stop you from compiling it, I checked it out. Compile (Make Executable) resolvchange.pb
chmod +x resolvchange
start vpn if running one and immediately run resolvchange with the following:
./resolvchange
That was a program that fixes the issue with network-manager or dnsmasq etc messing up the dns in resolv.conf, completely I am free from the problem with resolvchange
â Joe Pisco
Apr 29 at 9:05
add a comment |Â
up vote
0
down vote
up vote
0
down vote
git clone https://github.com/timebandit1969/resolvchange.git
https://www.purebasic.com/download.php and download linux demo version of PureBasic x64, don't worry I don't think the limitations will stop you from compiling it, I checked it out. Compile (Make Executable) resolvchange.pb
chmod +x resolvchange
start vpn if running one and immediately run resolvchange with the following:
./resolvchange
git clone https://github.com/timebandit1969/resolvchange.git
https://www.purebasic.com/download.php and download linux demo version of PureBasic x64, don't worry I don't think the limitations will stop you from compiling it, I checked it out. Compile (Make Executable) resolvchange.pb
chmod +x resolvchange
start vpn if running one and immediately run resolvchange with the following:
./resolvchange
answered Apr 28 at 8:40
![](https://lh3.googleusercontent.com/-XdUIqdMkCWA/AAAAAAAAAAI/AAAAAAAAAAA/4252rscbv5M/photo.jpg?sz=32)
![](https://lh3.googleusercontent.com/-XdUIqdMkCWA/AAAAAAAAAAI/AAAAAAAAAAA/4252rscbv5M/photo.jpg?sz=32)
Joe Pisco
11
11
That was a program that fixes the issue with network-manager or dnsmasq etc messing up the dns in resolv.conf, completely I am free from the problem with resolvchange
â Joe Pisco
Apr 29 at 9:05
add a comment |Â
That was a program that fixes the issue with network-manager or dnsmasq etc messing up the dns in resolv.conf, completely I am free from the problem with resolvchange
â Joe Pisco
Apr 29 at 9:05
That was a program that fixes the issue with network-manager or dnsmasq etc messing up the dns in resolv.conf, completely I am free from the problem with resolvchange
â Joe Pisco
Apr 29 at 9:05
That was a program that fixes the issue with network-manager or dnsmasq etc messing up the dns in resolv.conf, completely I am free from the problem with resolvchange
â Joe Pisco
Apr 29 at 9:05
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1028066%2fresolver-lan-vpn-and-wan-name-resolution%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password