Traditionally, it has been difficult to block unwanted traffic that is initiated behind an Internet gateway. This is completely understandable considering that a traditional consumer, prosumer, and SMB gateways take an allow all, block some approach. This means that workarounds just need to find one protocol, destination or port that isn’t blocked, and bingo! Your egress channel is now unrestricted using that open hole.

What we are demonstrating here, though, is the opposite. A zero trust model works like this: block all, allow some. This idea of whitelisting is far from new. However, a practical and convenient way to do so has been the challenge. We would like to share with you how we implement a practical solution:

The DTTS (Don’t Talk To Strangers) is currently available for an early adopter group. If you’re interested, kindly contact us via support.

In the context of web resources to allow or block, the traditional approach has been to block the bad. That’s blacklisting. It is the ideology of allow everything, block some.

Whitelisting, on the other hand is the opposite ideology: block everything, allow some.

This infographic is not controversial in nature, but there are legitimate reasons why whitelisting has not gained traction. However, let’s examine a few real-life examples where the trend towards whitelisting is succeeding.

iOS AppStore
While criticism over a curated AppStore has never stopped, the end result is undeniably a safer mobile app ecosystem for the normal user.

“AppLocker contains new capabilities and extensions that allow you to create rules to allow or deny applications from running based on unique identities of files and to specify which users or groups can run those applications.”

Essentially, this is an accepted and recommended solution that whitelists executable applications in business versions of Windows, and many systems administrators literally use this approach insted of anti-virus protection, with great success!

It is only logical that DNS-based whitelisting for Internet-based resources would also be filtered using a whitelist method. It has not been widely deployed in the past due to the onboarding effort. This is where DNSthingy helps with the whitelist ecosystem including DNSthingy Whitelist Assistant Google Chrome Extension, real-time logging visibility, Whitelist Subscriptions (for sites with dependencies such as YouTube, Google, Facebook, etc.), learning mode for businesses who deploy in passive mode for 60-90 days in order to gain an organic whitelist suitable for their own enterprise.

So if you’ve wanted to give whitelisting a try, now there’s a simple and free way to try it out!

A million new websites come on the scene each month, adding to the more than one billion already up and operational!

As you may or may not be aware, many of these sites are wonderful, but sadly, many more are not healthy or moral.

We now have 10,000 safe sites available that are family-friendly, secure from those negative and immoral influences, and by its very nature, much safer against phishing, malware, third-party advertising networks, trackers, etc.

This is the culmination of years of work to provide a family-friendly online experience, for you, your loved ones and especially your children.

The source of the 10,000 domains comes from May 2015’s Alexa worldwide ranking.

A few additional notes:

We would love feedback from our subscribers

We recommend you create a new profile when trying it out for the first time, and assign that profile just to the device you want to try it out on

The list will be dynamically updated and added to, with little regard to the 10,000 number – in other words, the list will increase as needed, based on family-friendly sites that our users would assume are part of the list already

Having choice in how individual domains or websites are treated is at the core of DNSthingy. Today I would like to explore with you how the three types of customization lists work.

WHITE LIST

As the name implies, white is good. All of the websites and domains you wish to be available must be listed here. In essence, a white list is the philosophy of “Block all, allow some“. The key aspects to this type of list are:

A white list means that it is exclusive. It means that anything that isn’t explicitly listed here will be filtered.

Multiple white lists can be created and combined for easier management.

Since most websites and services use multiple domains, we’ve made it easier for you with a free Chrome extension called DNSthingy Whitelist Assistant.

In Canada, we’ve been fortunate to support and maintain Canadian Tire Stores’ white lists for many years, so this aspect of permission-based access works really well in environments that want to enable computers & devices for very specific functions and eliminate the risk of anything else whatsoever.

BLACK LIST

In a way, a black list is the opposite of a white list; it simply lists sites to be blocked. It is the “Allow all, Block some” philosophy. In a workplace environment where a certain website serves as a distraction, that site can easily be black-listed here.

RAINBOW LIST

Warning: NerdSpeak to follow here as this is likely a feature only your IT administrator would use. This customization list is for domains, sites and services that should not receive any custom filtering treatment, but rather be sent to a non-default DNS server for resolution. These are typical uses of rainbow lists:

Local domains that need to be forwarded to an Active Directory server for resolution such as mycompany.local

Split-DNS zones that resolve differently internally on a network than externally on the Internet

Create an exception for a domain that you want to be treated differently than the last-resort resolver treats it. For example, if OpenDNS blocks a domain and it’s a false positive, this is how you can treat the exception by sending that domain’s resolution request to 8.8.8.8 (Google DNS).

With any of these lists, you can create what you think may work and explore. You can come back and modify at any point.

White lists can be shared with others. This is the beginning of what we’re calling crowd-sourced white listing.

One important point to note: creating the list(s) itself does nothing at all – you still need to choose which profiles they apply to by turning them on in your Profiles dashboard.

Let me answer that in context and in contrast to a Blacklist. There are two fundamental approaches to filtering in the context of website access.

Option 1: Allow all, block some. This is effectively a Blacklist. This is an approach where bad domains are disallowed.

Option 2: Block all, allow some. This is effectively a Whitelist. In this approach, only websites and domains explicitly listed can be accessed.

Why is Whitelisting so hard?

One of the key reasons that whitelists have been difficult to adopt in the past is because of the great deal of dependencies on non-obvious domains. Let’s say you wanted to whitelist our website at www.DNSthingy.com. In the old days, you would simply concatenate the www and make a whitelist entry of DNSthingy.com so that http://DNSthingy.com as well as http://www.DNSthingy.com would work.

It’s not quite that simple anymore, especially since a website could be a combination of several sources of information that “live” on different domains, and/or different servers.

For example, let’s say your business needs to interact on eBay and you’re on a whitelist system. You would need to whitelist all of these domains (if accessing from a commonwealth country, possibly more if you’re visiting from elsewhere):

For our own subscribers (or if you’re running your own whitelist system), we are facilitating a free Google Chrome Extension called Whitelist Assistant by DNSthingy. If you’re a DNSthingy subscriber, there are additional features such as integration into your subscriber account coming shortly.