What Really Happens On Your Network? Part Eight

Just last week, we had a post of things people have discovered happening on their networks.  But there is no shortage of these types of posts, so here is another collection of them or you can read previous iterations of these type of posts.

Read on to find out more to find out what people discovered happening on their networks, thanks to Pi-hole. Continue reading “What Really Happens On Your Network? Part Eight”

What Really Happens On Your Network? Part Seven

We’re back with the latest iteration of users discovering things on their network via Pi-hole.  This post is a compilation of things users have discovered over the past year.  Some were bad, some were interesting, and some were enlightening.  This isn’t the first time we’ve written a post like this, but we will try to go into more detail about what people have discovered and group together similar discoveries.  Below you’ll find previous renditions of this type of post.

Read on to find out more to find out what people discovered happening on their networks, thanks to Pi-hole.

Continue reading “What Really Happens On Your Network? Part Seven”

Mitigate A New CERT Vulnerability (#598349) With An Entry In /etc/hosts

There is a new CERT vulnerability that can leave you vulnerable to a Man-in-the-Middle attack.  You can mitigate this vulnerability today by adding these two lines to your /etc/hosts file:

0.0.0.0 wpad wpad.example.com 
:: wpad wpad.example.com

example.com is a stand in for your local domain.  So replace example.com with whatever your local domain is.

The essence of this vulnerability is that an attacker can add a device to the network named wpad and get a DHCP lease, thus inserting the name wpad.example.com in the local DNS pointing to the attacker’s machine.  The presence of that A record allows control of the proxy settings of any browser in the network.

You can learn more about the technology behind this attack at Google’s Project Zero page–it’s an older article, but gives some insight into the inner workings of the attack.

The next release of dnsmasq includes an option (dhcp-ignore-names) that can be used to mitigate the attack at the source, but we haven’t heard how Simon will act on this new vulnerability.

Since FTLDNS is just our fork of dnsmasq, we can easily merge in any upstream changes from him, but we wanted to let you know of the /etc/hosts fix that you can immediately implement.

Pi-hole v4.0 Released With FTLDNS, Improved Blocking Modes, Regex, Docker, and More

We’re very pleased to release Pi-hole v4.0 today, which includes fixes, tweaks, and lots of new stuff, including FTLDNS (special thanks to our beta testers!)  In a sentence, FTLDNS is dnsmasq with Pi-hole’s special sauce baked in.

FTLDNS does everything dnsmasq does because it is dnsmasq–just our fork of it.  So all of your existing config files will still work with it.  We intentionally modified the original dnsmasq source code as little as possible so that we can easily integrate any upstream changes as they are released.

Read on to find out everything included in this release or read the technical details in the changelogs.

Continue reading “Pi-hole v4.0 Released With FTLDNS, Improved Blocking Modes, Regex, Docker, and More”

FTLDNS and Unbound Combined For Your Own All-Around DNS Solution

How Pi-hole Works

Pi-hole acts as a forwarding DNS server, which means if it doesn’t know where a domain is, it has to forward your query to another server that does.  When you install Pi-hole, it knows where the ad-serving domains are (because you tell it), so it doesn’t forward those requests.  But it doesn’t know where legitimate sites are. Thus these requests are forwarded to an upstream, recursive server.

These servers also don’t know where the real Website exists unless they have been asked to find it before.  The only DNS servers that truly know where a domain is is an authoritative DNS server.  For now, we don’t need to know what an authoritative DNS server is, just that it’s the single source of truth for a domain’s real IP address.

So when you have a Pi-hole in use on your network, the flow of traffic goes like this:

  1. Your client asks the Pi-hole Who is pi-hole.net?
  2. Your Pi-hole will check its cache and reply if the answer is already known.
  3. Your Pi-hole will check the blocking lists and reply if the domain is blocked.
  4. Since neither 2. nor 3. is true in our example, the Pi-hole forwards the request to the configured external upstream DNS server(s).
  5. Upon receiving the answer, your Pi-hole will reply to your client and tell it the answer of its request.
  6. Lastly, your Pi-hole will save the answer in its cache to be able to respond faster if any of your clients queries the same domain again.

The Concern With Upstream Servers

The concern with the existing method lies in step 4.  In today’s world, these upstream servers are known as Google, OpenDNS, and CloudFlare, amongst others.  They advertise themselves as free private DNS servers, but how do you know for certain they are keeping their promise that your information is truly private?

Furthermore, from the point of an attacker, the DNS servers of larger providers are very worthwhile targets, as they only need to poison one DNS server, but millions of users might be affected.  For example, instead of your bank’s actual IP address, you could be sent to a phishing site hosted on some island.  This scenario has already happened and it isn’t unlikely to happen again…

So What Is The Difference Between A Recursive DNS Server and An Authoritative DNS server?

The first distinction we have to be aware of is whether a DNS server is authoritative or not.  If I’m the authoritative server for, e.g., pi-hole.net, then I know which IP is the correct answer for a query.  Recursive name servers, in contrast, resolve any query they receive by consulting the servers authoritative for this query by traversing the domain.  Example: We want to resolve pi-hole.net. On behalf of the client, the recursive DNS server will traverse the path of the domain across the Internet to deliver the answer to the question.

What Is The Solution?

Operating your own local, recursive DNS server.  Think of it as running your own Google or CloudFlare DNS service.  It can run on the same device you are already using Pi-hole for and there are no additional hardware requirements.

This changes the six step procedure mentioned previously to this 12 step process:

How Pi-hole Works With FTLDNS and Unbound

  1. Your client asks the Pi-hole Who is pi-hole.net?
  2. Your Pi-hole will check its cache and reply if the answer is already known.
  3. Your Pi-hole will check the blocking lists and reply if the domain is blocked.
  4. Since neither 2. nor 3. is true in our example, the Pi-hole delegates the request to the (local) recursive DNS resolver.
  5. Your recursive server will send a query to the DNS root servers: “Who is handling .net?”
  6. The root server answers with a referral to the TLD servers for .net.
  7. Your recursive server will send a query to one of the TLD DNS servers for .net: “Who is handling pi-hole.net?”
  8. The TLD server answers with a referral to the authoritative name servers for pi-hole.net.
  9. Your recursive server will send a query to the authoritative name servers: “What is the IP of pi-hole.net?”
  10. The authorative server will answer with the IP address of the domain pi-hole.net.
  11. Your recursive server will send the reply to your Pi-hole which will, in turn, reply to your client and tell it the answer of its request.
  12. Lastly, your Pi-hole will save the answer in its cache to be able to respond faster if any of your clients queries the same domain again.

Step 4 is where the major change happens.  The steps that follow are what the upstream servers would normally handle (along with any data tracking they may or may not be doing).

Recursion is more involved than just asking some upstream server. This has benefits and drawbacks:

Benefit

Privacy – as you’re directly contacting the responsive servers, no server can fully log the exact paths you’re taking, as e.g. the Google DNS servers will only be asked if you want to visit a Google website, but not if you visit the website of your favourite newspaper, etc.

Drawback

Traversing the entire path may be slow, especially the first time you visit a website.  While the bigger DNS providers always have answers for commonly used domains in their cache, you will have to transverse the path if you visit a page for the first time time.  A first request to a formerly unknown TLD may take up to one second (or even more if you’re also using DNSSEC).  Subsequent requests to domains under the same TLD usually complete in < 0.1s. Fortunately, your Pi-hole does efficient caching to minimize the number of queries that will actually have to be performed.

Setting It Up

This blog post won’t go into detail about how to set it up, for that, we have an article you can follow (at this time you’ll need to be participating in our beta test of FTLDNS).

But once complete, you’ll be able to do something like this instead of setting Google as your upstream DNS provider.

Interested in this?

FTLDNS is currently in beta, so we hope you’ll check it out and also help support our endeavors with our one-time fundraising goal of $100,000.

FTLDNS is out of beta and part of Pi-hole v4.0.

 

Limited Edition Pi-hole Coins Are Now For Sale

Patrons got first dibs, but there are still plenty of coins available.

These coins are high quality, colored, and textured.  Check out the product page for more information.  Enjoy!

Proceeds from the sales will be used to further develop Pi-hole.

Get Early Access To Our Coins By Signing Up For Patreon

We launched our Patreon page a few days ago.  Patrons of Pi-hole get several benefits: in addition to the rewards already granted by becoming a patron, you’ll also get a flair on our user forums, and early access to things such as first access to our collector’s coins.

Patreon charges you on the first of the month, so if you sign up today, you’ll be just in time.  We’re offering our patrons first dibs on the Pi-hole collector coins we have been teasing.  So if you want one, make sure you sign up for Patreon today.

Finally, here’s what the custom flair on our user forums looks like:

 

Coins, Patreon Feedback Round 2, Plus Our Fundraiser

Separate from Patreon: Collectable Coins Will Be For Sale

These are 2 inch metal coins with color and texture.  Only 300 have been made (seven of which have gone to the developers) and each one has a sequential number printed on it.

If these are a success, we will be designing and selling more coins, but this will be the only limited edition run with sequential numbering, so if you’re a collector or just a die hard fan, you’ll need to act fast.  We’ll do another blog post announcing when they are available for purchase.

Patreon Reward Levels

$15/month Mug-of-the-month Club

We are also running a mug-of-the-month tier for those willing to donate $15 a month.  Each month, we’ll ship out a mug with a new Pi-hole inspired design on it.  Here are just a few we’ve already had commissioned.

and more like these…

$10/month Sticker-of-the-month Club

Get a sheet of 24 stickers each month.

$1-5/month Thank You!

We can’t offer much at this price point, but we do appreciate your help.  You’ll get a special “Patron” flair on our user forums and/or Reddit.  You’ll also get access to our patron-only posts on Patreon.

Our Fundraiser

We’re attempting to raise $100,000 in an effort to develop Pi-hole even more. Patreon is an extended effort to offer you tangible rewards for supporting us.

One-time funding goal for developing full time, faster updates, faster bug fixes, quicker support response times, more features, more platforms natively supported…

$22,465 of $100,000 raised
$
Select Payment Method
Personal Info

Donation Total: $25.00 One Time

{amount} donation plus {fee_amount} to help cover fees.

If you’d like to support the development of Pi-hole, use the form above to send us a donation (monthly or a one-time).

You can also help us out by becoming a patron or purchasing items/services through our affiliate links below.

  • Bitcoin 33v5DGMGwYiDDJsKExksY1jhZbhGqF1SVe
  • Bitcoin Cash  qquhjgl9l5yfghu2kmw7q495m4xdgfc4q59zntpjmh
  • Ethereum 0x5Cd7f79D8D542847B2A313297037d3CAc1FeFBB4

We are all volunteers on the project and work on it in our free time.  Your donations will help support our infrastructure and keep us motivated to improve the product.

No registration is needed.