So what’s the deal
Chances are that if you’ve somehow landed here, it means that you have an idea of what DNS does for you. Chances are also there that you’re also privacy & security conscious and want to secure DNS lookups.
In any case, a short refresher below:
- 50K feet view of DNSSEC
-
-
DNS is how your machine (and other machines including your router etc) translate a domain name like www.google.com to an IP address (a.b.c.d - where a,b,c,d are integers ⇐ 255)
-
DNS was created in the early days of the Internet - security/privacy wasn’t a goal then
-
Your ISP typically hosts a DNS server and your browsing patterns are sort of leaked by the domains you lookup
-
You could use Google Dns (trusting google rather than local ISP ) - but that’s just giving Google even more data. On the other hand, instead of choosing Google, you can choose other providers that advertise that they don’t log queries and sell your data. How much you trust them to do that is up to you though. See here
-
Even though you could configure Google DNS or others, your lookups go through intermediate servers. DNS relies on caching previous lookups - so an attacker only needs to poison the cache on one of the intermediate servers.
-
DNSSEC is a set of extensions to basically add security to the underlying DNS system. Also note that DNSSEC does not address privacy AFAICT - it deals only with securing dns lookups.
- 50K feet view of PiHole
-
PiHole is a lan wide adblocker that you can run on your local intranet. You don’t actually need a raspberry pi to run it - but it’s convenient. Basically, it becomes the DNS server on your network and uses a large blacklist of ad serving domains. Now, if you visit www.somepage.com whose HTML includes an ad hosted from www.badads.com/somead.gif your browser asks to lookup www.badads.com which reaches Pi-hole server. Since that domain (www.badads.com) is present in its blocklists, it just returns an empty response and your browser does not try to follow the URL. Ergo - Ad blocked!
Setting up stuff
Keep in mind that what follows isn’t a step by step guide - Pihole documentation does that much better. What’s here is basically what you need to have in place so that you can use DNSSEC without breaking local lan machine name lookups in your intranet.
-
Router acts as the DHCP server as usual
-
PiHole for adblocking with domain lists.
-
Pihole uses dnscrypt-proxy as upstream DNS server.
-
dnscrypt-proxy
uses a list of public DNS servers to resolve lookups.-
If the name is
something.lan
, then it will forward the lookup to our router.
-
Within our network, we would prefer if we didn’t have to type othermachine.lan and othermachine does what you mean -
lookup othermachine
in our lan. How can we do this? There’s two ways - at each client, you can have a list
of DNS search domains which are dns suffixes which are automatically looked up. But doing that on each client is flaky -
so let’s do it the better way - by telling our router to pass that configuration to each client as it hands out
IP addresses. Most routers use an inbuilt version of Dnsmasq - and if you’re running something like Tomato FW or
OpenWrt, this amounts to setting domain=lan
in the dnsmasq
config.
Testing it out
Pihole page for using dnscrypt-proxy
lists a few test pages -
Wait - you can’t stop here…
So this isn’t a guide/step-by-step for the simple reason that this stuff is decently complicated. I could
try putting steps but then I would just be duplicating basic steps for setting up pihole and dnscrypt. That’s stuff
that’s better done elsewhere. All I wanted to put down here is to how not to break local lan lookups (which were broken
for me for sometime till I got around to working it out). So, if you’re new to pihole, this is where you should start.
Once you have that running to your satisfaction, you can then try dnscrypt-proxy
setup - that’s documented here