Quad9 support

Posted November 22, 2017 by David Redekop to DNS Feature

DNSthingy’s core value is on-premise filtering with fastest possible performance (i.e. it isn’t a cloud DNS service), allowing you to apply different policies to different device groups. You’re never locked into a one-size-fits-all scenario. An IoT network should not have the same permission as a desktop or mobile device, for example.

However, once a domain is approved for upstream resolution, DNSthingy will send it to the upstream DNS resolver of your choice. This is made very easy with a customized drop-down list like this:

So, in addition to all the DNSthingy services, you can use quad9.net (9.9.9.9) as a resolver of last resort to provide additional protection.

How we are different from OpenDNS

Posted July 11, 2017 by David Redekop to DNS

For those familiar with the great service from our OpenDNS friends, a common question we get is “How are you different from OpenDNS?”

Well, we don’t compete with them. Assuming you also like them, our service complements theirs! In fact, quite a number of our subscribers are OpenDNS subscribers as we integrate quite well as you’ll see if you try it out, including a native built-in OpenDNS Updater so you don’t need to run your dynamic IP updater on any other device.

There are many other differences though, here’s a partial list that most often applies:

  • Deterministic answers – apply different DNS policies to different devices. For example:
    • IoT devices for example, need a very limited whitelist
    • Guest iOS devices may just want obviously-bad content blocked
    • CFO money transfer devices need a very limited whitelist only to the bank in use
  • Whitelisting is our specialty
    • Start with nothing, add what you need
    • Cloud-based web crawler searches and identifies dependencies and threat intelligence to allow only what is safe
  • Domain-joined devices do not need to use Active Directory’s DNS servers:
    • Our rainbow (or re-direct) lists feature AD domain redirection to AD so that all non-AD queries are never sent to AD DNS.
    • Benefit #1 is that your Active Directory DNS servers can now experience a high-level of protection by having strict egress control
    • Benefit #2 is that your devices can experience different treatment from others (appropriate policy based on use case)
  • A live log for complete visibility of DNS queries (and their answers) that occur on your network
  • Tight integration with firewall rules disallows the easiest of DNS filtering circumvention:
    • This also hijacks the hijackers – if you have malware that changes your DNS servers to 8.8.8.8, for example, DNSthingy hijacks the DNS queries and answers them by the policy/rule set applied to the device
    • If you use the “No Internet” rule, it’s more than just a DNS firewall. All traffic is blocked while maintaining internal visibility. Perfect for a NAS or devices that should never have egress access at all (a simple way to stop exfiltration).
  • Importantly, we do not offer public resolver services at all. DNSthingy has a focus in the on-premise space where layer 2 (mac address) can be followed for IP address changes, etc. This is how we are completely different and yet integrates with OpenDNS (and other cloud public resolvers, for that matter). We also appreciate the security that DNSSEC and DNScrypt bring to Internet security, so those are included and dashboard switches for you to enable are coming shortly.

Thanks for reading, we have much more coming to our blog in the next few days!

New SafeSearch option includes Bing

Posted June 27, 2016 by David Redekop to DNS Feature

SafeSearch filters the display of explicit search results in images, videos, and text.

We’re glad to be able to offer an expanded version of our Forced SafeSearch feature. Forced SafeSearch uses the network-level enforcement method offered by Bing and Google. Here’s how the feature looks on the dashboard with a simple ON/OFF button:

Force SafeSearch option on DNSthingy.com/dashboard

This setting is now on by default for new subscribers and new Blacklist rulesets. This was much requested as iOS’s Siri uses Bing exclusively.

Why we believe Forced SafeSearch is better

It is important to note that this feature is not locking SafeSearch as utilized in the past for school/home environments. Locking and other proxy methods previously in use, could easily bypass SafeSearch by using https (SSL) instead of http. Locking SafeSearch into the browser is easily bypassed with a new private/incognito window.

The combination of network-level forced SafeSearch and alternate DNS attempts being blocked (also a default with DNSthingy in router mode) makes circumvention much more difficult.

Authoritative DNS made easy

Posted February 15, 2016 by David Redekop to DNS Feature

How often do you end up having to remember IP addresses to access internal resources such as a NAS or any of your IoT devices? Consider using names instead of IP addresses:

Before After
By IP address By memorable name
Example: http://192.168.1.10 Example http://MyNAS.local
Hard to remember Easy to remember
Might change with a factory reset Never needs to change
Incompatible with future network schemes Never needs to change
Will need to change with IPv6 Never needs to change

A better practice is to simply choose an easy-to-remember name and use your DNSthingy to create an authoritative list and enable it on your rulesets. Now you’ll never have to remember the IP address by simply following these steps, for example, if you had a NAS at 192.168.1.10 you wish to access by various names:

  1. From DNSthingy.com/dashboard, login and create a new authoritative list like this:
    Create an authoritative list
  2. Fill in the IP address and the full list of names you want to work, similar to this:
    Edit the list names
  3. Finally, enable the list in your rulesets so it looks like this:
    Authoritative list enabled

That’s it! You’re all set! Now you can always access your NAS via http://mynas.local or http://nas.local or http://yournas.local or http://newnas.local.

Important: this feature requires version 2.7.0 which will be automatically upgraded for all subscribers and non-subscribers alike.

Ad-free iOS apps

Posted December 17, 2015 by David Redekop to Blacklist Case Study DNS

iOS apps, especially with little children, are often completely unusable unless the ads and trackers are all blocked. Many parents are used to putting an app in airplane mode before letting kids play. Unfortunately that disqualifies all apps that require connectivity.

DNSthingy ad-blocking disabled: DNSthingy ad-blocking enabled:
with-iAd without-iAd

While Apple has their own iAd ecosystem, many mobile apps use alternate ad providers (mopub is a popular one), which are already blocked in our default blacklists.

But to have a truly beautiful iOS app experience and cover all the bases, follow these steps for the ruleset applied to your iOS devices:

  1. block-ads

    The blacklist above does not include hosts that prevent services from working.

  2. Now you want to create a separate list (Dashboard -> Manage Rules -> My Lists -> Create a List -> blacklist) called iAds and include these hosts:

    iadsdk.apple.com
    iad.apple.com

  3. Finally, go to your Ruleset and turn it on like this:

    block-iAds

Note: blocking Apple iAds will prevent iTunes radio (does anyone still listen to that?) from working as well as the occasional tracked ad. For most subscribers, this is a small price to pay for a superior iOS app experience.

Enjoy!

Avoid private DNS record leakage

Posted November 12, 2015 by David Redekop to DNS Feature

The nature of mobile devices that roam from site to site, often means that private DNS records unintentionally leak out to the public Internet. For example:

DNS record OK to be public visible DNS record that should remain secret
MailServer.YourCompany.com YourSecretServer.YourCompany.local
As long as your devices stay on your business network, network information leakage isn’t a concern. However, let’s say a mobile device is setup at the office with an application that references YourSecretServer.YourCompany.local and then it is taken home by a team member.

As soon as the app is launched at home, the home router is asked:

Hi, where is YourSecretServer.YourCompany.local?

And, of course, it sends that request upstream to your Internet Service Provider. Even though it cannot answer it, the DNS request (the question above) has been sent across the Internet in clear-text and therefore subject to surveillance of the most trivial kind.

To avoid this type of DNS leakage, DNSthingy firmware never allows DNS queries to be sent to the Internet unless they are part of the Mozilla Public Suffix list found at:

publicsuffix.org

In any and all foreign premises where DNSthingy answers DNS queries, when the query for YourSecretServer.YourCompany.local is asked, DNSthingy simply answers with NXDOMAIN, meaning it does not exist.

That’s how we prevent DNS record leakage in all of our current firmware versions.

Force Google SafeSearch with a button

Posted May 20, 2015 by David Redekop to DNS Feature

We love it that Google has made the SafeSearch option enforceable at the network level. For their details see:

https://support.google.com/websearch/answer/186669?hl=en

In addition to enabling this feature with a simple profile management button, all DNS queries are also policy-enforced, which means that any device attempting to use alternate DNS servers continues to get policy-enforced answers.

Below is our introductory video:

OpenDNS Updater now supported

Posted June 27, 2014 by David Redekop to DNS

As a DNSthingy subscriber, you can now consolidate DynDNS and OpenDNS updater onto your on-premise DNSthingy device by utilizing this feature on your dashboard:

DNSthingy-OpenDNS-Updater-fullscreen-800

This is what the OpenDNS area looks like in more detail:

DNSthingy-OpenDNS-Updater-detail

Enjoy your “updater” consolidation on your dynamic public IP networks!

This should simplify the updates from various devices and services we all use. We should note that the update is called from our controller, not from any software on your device. We use the first public IP that the device finds on its outbound traffic to update OpenDNS.

How to avoid DNS-based profiling

Posted June 3, 2014 by David Redekop to DNS

Image courtesy freedigitalphotos.netPlease forgive the NerdSpeak in this article in advance. Nevertheless, I encourage you to read on, get informed and learn about the Domain Name System (DNS). It is as critical to the Internet as your arteries are in your human body.

DNS as a fundamental building block of the Internet leaves numerous “breadcrumbs” behind as you use Internet services. This has largely been off anyone’s radar. For one thing, Google has earned a tremendous degree of trust in their brand, so when they launched a fast open resolver about five years ago, the world adopted it very quickly.

However, their public DNS resolver is completely void of any privacy policy. This leaves them open to sharing this data with 3-letter government agencies without violating any terms of service. To be clear, nobody is accusing them of doing this, including us. They have rightfully earned their trust, but we should all be aware of what the possibilities are.

Let’s take a step back. DNS is basically finding out where www.something.com lives. Since computers can only understand numbers, but we as humans like to use letters and words, it has been likened to the world’s largest dynamically-updated “phone book of the Internet”. It is almost magical that this is even possible!

Typically, your upstream DNS provider is one of these:

  1. Your ISP-provided DNS server(s). This happens by virtue of setting up your ISP-provided router, or using a router with default settings.
  2. Google DNS. (8.8.8.8 and 8.8.4.4) If your tech-inclined self or nerdy friend set this up for you, this is a very common choice. Google uses anycast to get as close to you as they can.
  3. OpenDNS – either FamilyShield, OpenDNS or Umbrella. (208.67.22x.xxx) This is one of our favourite ways to filter because of the great groundwork laid by the cool people at OpenDNS. OpenDNS also uses anycast to be virtually everywhere.

These are not the only options, but the most common ones. In a scenario where you’re using a DNS-based geo-unblock service of some kind, your upstream provider is your subscription DNS proxy.

In each of these cases, 100% of your queries are sent to the DNS provider. This allows them to profile you and know if you are an evernote user, a gmail user, if you browse or buy your travel from expedia, etc. You may not care, but you should at least be aware.

In each of the above cases, you should understand the business motives behind them to better assess where you feel more comfortable given your situation.

Google’s biggest reason for ever providing an open resolver (8.8.8.8 and 8.8.4.4) is that it gave them instantaneous and almost-free access to extensive profiling on a per-IP basis they didn’t have before. For example, if you use Google DNS and you’re an active eBay user and never even use Google for search, they have a tremendous profile on you on the amount of times ebay.com is visited and even the amount of times you access paypal.

Now that we’ve covered how these “breadcrumbs” leave a trail, let’s discuss how you can avoid such profiling, if that is a concern to you.

It is with full disclosure that one of these options is using our DNSthingy services. What else do you expect from a company blog, right? Anyhow, here are our transparent reasons:

  1. We have a published privacy policy.
  2. We provide as many on-premise DNS resolutions as possible on a cached basis. This means fewer queries that leave “breadcrumbs”.
  3. We never centrally log DNS queries, except in cases where you temporarily opt-in for support purposes.
  4. We distribute DNS queries based on your needs and DNSthingy preferences.
  5. You choose your resolver of last resort. This is the DNS server that is used if none of the filtering applies to a given query.

There is an alternate method to avoid DNS-based profiling by a single upstream resolver. That is to use a Recursive Resolver yourself that does not use a Forwarder. Bind can achieve this on just about any platform, or the DNS Server that is built into any Windows Server operating system. It is worth mentioning, though, that a man-in-the-middle between you and the Internet could still profile you but it would not be done on a mass basis like an upstream resolver would.

As with any privacy and confidentiality issues, awareness is always the first step to better safety online.