You are not logged in.
when home:
have laptop accept DNS nameserver assigned from dhcp and not use anything else.
when away:
reject dhcp assigned DNS nameservers and use only 8.8.8.8
should I just add to /etc/resolv.conf.head
nameserver 192.168.1.1
nameserver 8.8.8.8my concern is that at home, 8.8.8.8 may be used if it resolves faster than unbound on my router
and when away, i may connect to a wifi router whose IP is 192.168.1.1.
Last edited by hamhock (2017-05-20 05:26:17)
Offline
seems to work - at least on home network. 8.8.8.8 is never used for uncached FQDN's. seems the order within resolv.conf.head is important.
would still like to know how to avoid a situation where a public wifi's router has the same IP as my home router without manually editing any resolv files or changing my home router's IP.
Last edited by hamhock (2017-05-16 21:54:08)
Offline
It isn't foolproof, but I used to get around it by using a subnet for my home network that was much less likely to be found in the wild. For example 10.164.53.0/24.
I used this method when I had to use a lot of VPN's for work, and would often find myself conflicting with 192.168.*.* networks.
Last edited by Slithery (2017-05-16 22:02:02)
Offline
thanks for the subnet idea - i may implement in the future. i guess for now, i'll just comment out my home ip when away from home.
Offline
puzzling observation. when i use dig
dig nba.comthe SERVER used is always the same nameserver in first position in resolv.conf
when i use drill
drill nba.comthe SERVER used is always different - appears to be randomly chosen from the nameservers listed in resolv.conf.
makes me wonder what nameserver(s) are actually used when browsing the internet - is there a way to find out?
Last edited by hamhock (2017-05-17 05:14:25)
Offline
Don't edit resolve.conf or use a static head - update /etc/resolveconf.conf, notably the "name_server_blacklist" key. Ensure this update happens before your network managing tool runs resolveconf.
Otherwise you'll already run into the conflict you mentioned in your first post (use a local DNS server abroad)
It'd be simpler (you could use a static setup) if you were using different interfaces for the connections.
To figure what server is used, you'll have to wirshark or netstat remote port 53 (clients might simply have internal settings or hardcoded failsafes) - and actually that's not entirely sufficient because DNS servers on other ports, eg. 5353.
Offline
Maybe this solution described by tedu is a solution for you:
http://www.tedunangst.com/flak/post/tur … conf-trick
The idea is that your router responds to any DNS request by redirecting any requests that try to pass the router to itself. This way you could set a public IP address in your laptop's resolv.conf which would be used if your not in your home network. With iptables or nftables this also needs just a single line in your routers ruleset.
Offline
Don't edit resolve.conf or use a static head - update /etc/resolveconf.conf, notably the "name_server_blacklist" key. Ensure this update happens before your network managing tool runs resolveconf.
Otherwise you'll already run into the conflict you mentioned in your first post (use a local DNS server abroad)
i always edit the dhcp server or resolv.conf.head or resolv.conf.tail
To figure what server is used, you'll have to wirshark or netstat remote port 53 (clients might simply have internal settings or hardcoded failsafes) - and actually that's not entirely sufficient because DNS servers on other ports, eg. 5353.
i used wireshark and it confirms the the results for the dig and host commands, i.e., the DNS server used is the first one listed in resolv.conf. so that is good news. I was afraid DNS resolving would work the way the drill results were indicating, i.e., the DNS server selected to resolve the domain would be randomly selected from resolv.conf. makes me wonder if Drill is designed to work that way.
Last edited by hamhock (2017-05-17 16:00:23)
Offline
Maybe this solution described by tedu is a solution for you:
http://www.tedunangst.com/flak/post/tur … conf-trickThe idea is that your router responds to any DNS request by redirecting any requests that try to pass the router to itself. This way you could set a public IP address in your laptop's resolv.conf which would be used if your not in your home network. With iptables or nftables this also needs just a single line in your routers ruleset.
i may implement. i am already doing that for ports 80 and 443 (pfblockerng) as well as port 123.
Offline
i always edit the dhcp server or resolv.conf.head or resolv.conf.tail
or use a static head
...
.head and .tail are just framed to resolve.conf and the result is used in order until a DNS server responds.
With a leading 192.168.1.1, 192.168.1.1 will be used whenever there's a responding DNS server on that IP - whether at home or in a hotel.
Since I understood you'd like to avoid that, you must not use a static resolv.conf.* setup, but alter it with the connection and also ensure to blacklist anything but 8.8.8.8 abroad. In case the server is blocked, you then won't go with a hostile DNS server unnoticed.
Offline
you must not use a static resolv.conf.* setup, but alter it with the connection
not sure what you mean by alter resolv.conf "with the connection."
I use netctl, do you mean I should add a DNS directive in my netctl profile for home - like this:
DNS=('192.168.1.1')Offline
No, afaics this will only append a server.
You can use ExecUpPost to sed away unwanted DNS servers from resolv.conf, but notice that this will get undone whenever resolveconf is run again (what however should* not happen until the profile is changed)
You'd then have two profiles, one for home and one for abroad.
As long as there're several entries in /etc/resolve.conf you cannot be sure to not use the "wrong" one, eg. you need to get rid of the local server when you're out of home.
*no guarantees, https://www.youtube.com/watch?v=5RyYrs5tu60
Offline
Why not just run Unbound on the local PC, and then benefit from Unbound performing proper DNS lookups itself, and local DNS caching?
Offline
What brebs said plus make sure you use DNSSEC.
R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K
Offline
Why not just run Unbound on the local PC, and then benefit from Unbound performing proper DNS lookups itself, and local DNS caching?
when at home, would the performance suffer much due to higher non-cached replies since I would no longer benefit from the "shared" cache of unbound on the router?
when away, i wonder what the percentage of non-cached queries would be and the difference in latency compared to google's cached response.
I may implement if there is little downside and hassle of running unbound on the laptop.
BTW, it is a chromebook running arch with a 16GB SSD - would running unbound noticeably increase the overhead (cpu use and storage, and cache)?
Offline
Try it and see, I expect you'll be very pleased.
It has amazed me for many years, that people see how important DNS is (i.e. apps break when it fails), but people resist coming to the fairly obvious conclusion that running a *local* DNS recursive resolver is the best option for speed & reliability.
Offline
Try it and see, I expect you'll be very pleased.
you are correct. i installed it and is working very well - i do not notice any increase in DNS lookup time.
what is considered best practice for resolv.conf on a laptop? after unbound install i edited my resolv.conf.head file to only have 127.0.0.1. my router adds it's IP in second position
here's my resolv.conf now:
nameserver 127.0.0.1
nameserver 192.168.1.1Offline
Offline
personally, I remove/configure software so that /etc/resolv.conf only gets changed *manually*.
ok, i edited /etc/resolvconf.conf and uncommented 127.0.0.1
when i run resovconf -u, the only nameserver in resolv.conf is 127.0.0.1
I hope that is the proper way to ensure that 127.0.0.1 will always be the only nameserver.
Offline
Personally, with a local DNS resolver (Unbound or even BIND), I've never been tempted to add a 2nd DNS server as backup.
I find that if I don't use GoogleDNS as a backup (it uses DNSSEC), I sometimes stumble across domains that don't resolve.
Offline