Brand Rollover to Adam Networks

Posted April 12, 2019 by David Redekop to Feature

We are thrilled to have grown into Adam Networks (

We’ve enjoyed developing the DNSthingy development brand since 2014 and we’re ready for a new chapter to bring even more goodness to our subscribers and future subscribers.

Going forward, please visit our new blog at: and see you there!


Posted September 21, 2018 by David Redekop to Feature

We’re excited about version 3.2.1 of our core software because it marks a significant milestone of feature completion that our valued subscribers have most asked for.

Strong policy enforcement

The Don’t Talk To Strangers feature has been widely tested and matured for this release to truly allow security to be more convenient than ever. If you’re looking for tools to block DNS-over-HTTPS (also known as DoH or DNSoverHTTPS), Psiphon, or whatever is considered a risk in your environment that requires strong policy enforcement, look no further. Try DNSthingy for free, switch to a business plan and enjoy the best we have to offer.

Reporting dashboard

Reporting dashboard is now available on all platforms running the latest software. Please note that this requires opting into domain logging in your Dashboard -> Router settings.

More secure than ever

DNS rebinding attack protection is now also the default on all platforms.

Faster unblocking

When you live in a block-all-allow-some (whitelisting) world, you want new resources investigated and approved quickly. Not only is our inspector been optimized to get faster, all platforms except pfSense support a new feature called Proxy Subnet that allows the unblock request to be processed faster even though browsers tend to cache blocked content.

More news coming shortly

Stay tuned for even more exciting news coming shortly!

How and why we force router DNS

Posted March 1, 2018 by David Redekop to Feature

It’s amazing how DNS (the Internet’s “phone book”) can have so many different variations of how it’s used and abused. It’s a fundamental building block insomuch as the Internet is almost entirely useless without it.

On all of our platforms, DNS is forced when using the standard port and protocol over TCP and UDP port 53. Here are the firewall rules that are installed with our service:

On pfSense, these rules (among others) are inserted, but we’re showing just the DNS-forcing ones here on this screenshot:

On ASUS routers as well as ClearOS/Linux variations, the iptables rules look like this at the command-line in a typical setup (sorry there’s no GUI for these rules on AsusWRT):

This command will show and include the forcing rules:

iptables -L DNSthingy -nv -t nat --line-numbers

The result:

Chain DNSthingy (1 references)
num pkts bytes target prot opt in out source destination
2 645 44407 DNAT udp -- * * ! udp dpt:53 to:
3 2 80 DNAT tcp -- * * ! tcp dpt:53 to:

These types of rules are also referred to as DNS hijacking rules. Hijacking in a good sense, of course, because if you have a reason to distrust a device, you want to at the very least hijack its DNS usage to apply the policy of the router.

Benefits of forcing DNS

  • DNS poisoning is mitigated, especially when the attacker has a publicly-available DNS server that is being used by silently changing internal client device DNS settings (like DNSchanger does).
  • Convenience for devices with static DNS configured. Sometimes devices have statically assigned themselves a DNS server, now it doesn’t matter what public DNS resolver is statically set on a client device because the hijacking rule forces the router’s DNS to be used.
  • Endpoints require no DNS management. Since the forced DNS settings are applied, no customization is required on a per-endpoint basis.

Important note on DNS benchmark tests

Steve Gibson has an awesome freeware Domain Name Speed Benchmark utility we often recommend.

When DNS usage is forced, it makes it impossible to benchmark public DNS resolvers from “behind” one of these gateways. During benchmark tests, you want to disable the hijacking rules temporarily.

To disable these rules on AsusWRT or Linux, which will delete line number 2 and 3 based on the query above:

iptables -D DNSthingy 2
iptables -D DNSthingy 3

After ASUS reboot and/or Linux networking restart, the firewall rules will once again be auto-applied.

To disable these rules on pfSense, simply click on the checkmark to disable it, and apply the changes. After the benchmark tests are run, the rules can be enabled once again.

WARNING: Forcing DNS on port 53 alone won’t force all DNS

As a result of port 53 DNS enforcement on many edge devices, endpoint security software has begun to work around it. For example, Webroot uses port 7777. AVG and several others use port 443. Of course it’s easy to simply block destination port 7777 but when it comes to port 443 that’s not so easy as you would be blocking HTTPS (with TCP) and you’d be blocking QUIC (with UDP). This is where the zero trust model comes in.

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 ( as a resolver of last resort to provide additional protection.

Version 3.2 firmware upgrade

Posted October 31, 2017 by David Redekop to Feature

When your device auto-upgrades to version 3.2, you will enjoy the following enhancements:

1. Block page now utilizes an IP subnet (vs a single static IP on the LAN interface). This allows for faster unblock page processing, coming shortly.

2. Better NetBIOS name discovery. In cases where our service host is not the DHCP server, better name discovery is now included.

3. IP enforcement and DNS services combined into a single service. Previously there were two processes in place to facilitate load balancing across devices, but in cases where only one appliance is in use, a single process is more efficient.

4. Under, logging capability has been enhanced with many view filter options (Status, IP, Name, Answer, Rule, Rule Kind, etc).

5. Logging capability addition for traffic logging in order to easily visualize blocked/allowed packets while narrowing the list down by source, destination or blocked/allowed status

Better Browser Experience for blocked SSL sites

Posted September 7, 2017 by David Redekop to Feature

Traditionally, DNS-level filtering for SSL has been problematic because the block page SSL certificate would never match the host header requested by the browser.

For example, access would be presented with certificate. This would result in the end-user having to approve an SSL mismatch warning, illustrated to the right, which incidentally, is exactly what bad actors would do with DNS poisoning attacks. This makes it very difficult to train end-users when to ignore and when to heed warnings like that!

Our approach is different. By default, all TCP port 443 (used for TLS/SSL connections) that attempt to connect to the block page server are rejected (a TCP reset). This achieves the following results:

  • End-user device response is immediate, so the user isn’t waiting and wondering what’s going on
  • Bandwidth usage is reduced
  • Device resources are never congested due to wait times

Some DNS-based SSL blocking approaches, will offer a DNS answer of which achieves the above results as well, but then cannot present the end-user with anything helpful.

What we do want, is for the end-user to have some sort of feedback to indicate what just happened. This is where our browser extension comes in handy. To see it in action, here’s a short demonstration:

And here’s a direct link to the knowledge base article with further details and extension access.

Now you can enjoy a user-friendly SSL block page experience!

Using a Zero Trust Model to block outbound VPN, Proxy, TOR, and P2P

Posted July 28, 2017 by David Redekop to Feature Security Whitelist

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.

Making your life easier

Posted March 4, 2017 by David Redekop to Feature

Our newest firmware (3.1.4) supports our largest feature upgrade yet! Most of it you will experience in the Internet experience itself as well as the dashboard, as you learn about the new capabilities that you asked for, such as:

  • Brand new tool at which is available from any computer or device on your network
  • Automated way to check a website for dependencies so when you have a whitelisted device asking to whitelist for example, the system crawls it for dependencies and shows you which ones are safe and which ones aren’t
  • Auto-whitelisting allows for automatic approval of unblock requests provided that
    • the domain has a positive reputation
    • no known threats hosted on the domain
    • is not categorized as adult content

    (more than 90% of unblock requests will be auto-approved with this method)

  • Don’t Talk To Strangers (DTTS) new feature is included in the firmware itself; watch our blog for more details coming shortly
  • “Last seen online” option coming back soon to your dashboard; your firmware will now include the required software to offer this
  • Automatic tagging of discovered devices by Operating System coming soon; your firmware will now include the required software to offer this also
  • Business-grade platforms now include additional per-interface features; a DNS listener for each VLAN
  • Watch for new plans available soon to take advantage of these features now available in your firmware

New firmware goodies

Posted August 9, 2016 by David Redekop to Feature

We are very excited about all of these new features in our production firmware scheduled to be released at your router’s next update cycle:

  • DNSthingy now supports authoritative entries, allowing you to use a name instead of IP for internal (or external) resources.
  • Device discovery has been changed from ARP broadcasts to enrollment on “first-seen” basis from the perspective of receiving a DNS request.
  • Unknown devices including queries from foreign subnets including internal vlans not locally-connected, are now treated with your default ruleset.
  • A new utility is included to support future NVRAM migrations (on ASUS routers only).
  • The feature to allow remote support has been improved (previously it required some additional manual steps which are no longer required).
  • DNScrypt support is included in firmware, and will be introduced in the dashboard very soon.
  • Many more bug fixes and stability improvements.

It is also worth noting that ClearOS marketplace subscribers will be updated automatically as long as you’re auto-updating/upgrading your ClearOS software.  pfSense subscribers will need to visit your Packages section and confirm your update/upgrade.

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

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.