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!

Encrypted SNI death blow to transparent filtering

Posted October 3, 2018 by David Redekop to DNS Security

Encrypted SNI, announced by Cloudflare this past week, is a positive move towards privacy and security. It makes sure that along the path from your browser, all the way to the host you’re contacting, even the hostname such as isn’t visible.

However, the side effect of this natural progression of encryption, is that gateways which depend on SNI for Internet Filtering cannot do so any longer when Encrypted SNI is deployed. Transparent filtering, as it is called, is in use by Squid and many other SSL filtering gateways.

On the other hand, the good news is that DNS-based filtering remains as powerful as ever. In fact, DNS-based filtering has a significant advantage over proxy-based technology for these reasons:

  • Lower RAM and storage resources required on gateway such as pfSense (only a DNS query response vs packet inspection, caching of page contents, etc)
  • Faster end-user experience (for the time it takes for a DNS query the end-user knows if destination is blocked or allowed)
  • Better compatibility – no more worries about end-user applications’ proxy incompatibilities
  • Better IoT security control and connectivity

It is clear that DNS-based filtering is here to stay. Watch for news on how DNS over TLS and DNS over HTTPS have a future on-premise to provide the best of security and privacy, while also facilitating system administrators’ responsibility to provide security at the gateway.


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!

DNS rebind protection

Posted July 26, 2018 by David Redekop to DNS Security

The green circle is what you’re looking for on your local DNS server on your LAN. Then, and only then, according to GRC DNS benchmark freeware, do you pass the test of private IPs being stripped from public DNS queries. As of DNSthingy build 1916 and above, this behaviour is now the default.

This is important because it’s a security strategy to mitigate DNS rebinding attacks that are making the rounds to get into private IPv4 networks which are often presumed to be protected from the public internet.

Steve Gibson on Security Now Episode #673 (show notes PDF) had great coverage on the DNS rebinding attack, after already having covered it in episode #260.

A setting is available in pfSense that is used to enable this setting in the pfSense UI (2.3+) under System -> Advanced:

As long as that box is unchecked as shown in the screenshot, it will trigger build 1916 and onwards to block RFC1918 private addresses (, 172.16/12, 192.168/16) + 169.254/16 subnets as well as IPv6 link-local and the applicable area of NAT64 space. Note that this is also the behaviour with pfSense default DNS resolver (unbound).

On other platforms (ClearOS, ASUS) this behaviour is default as well, starting with Build 1916 and onwards.

To check your build, log into your dashboard -> Router -> rest your mouse over your “Running” version to display your build number as shown here.

The qualifying build is available on pfSense Rapid Release Channel as of 27 July 2018 and will be deployed automatically on other platforms. Keep enjoying your peace of mind!

DNS over TLS or HTTPS – the rest of the story

Posted April 3, 2018 by David Redekop to DNS DTTS

Secure DNS isn’t everything it first appears… especially when you consider the impact on different roles.


DoH (DNS over HTTPS) and/or DNS over TLS rapidly gained attention of the infosec community with CloudFlare’s announcement of offering on their worldwide anycast network. While the 35-year-old DNS protocol admittedly remains the weakest building block of the Internet in terms of security and privacy, not everything is at it seems.


In order to objectively assess this recent announcement of CloudFlare’s, it’s important to assess the impact on audiences of all types not just what the headlines would have you believe. There are at least four identifiable audience types to whom the impact is quite significant and different from one another, and each have solid rationales for their perspectives.

  1. The consumer

    There’s no doubt that the Internet consumer over the years has been abused in terms of tracking and targeted advertising as we need to look no further than the facebook debacle we are experiencing in Q1-Q2 of 2018. Even when someone visits, the DNS or the Internet “directory” has been mostly delivered in plain-text, meaning that anyone along the way, including your Internet gateway, your ISP and anyone else in the path of the data transit had visibility into what each subscriber’s habits were. So, the idea of secure DNS means that each individual DNS query, or directory lookup, is no longer visible to those parties, thereby providing additional privacy as well as security. The privacy part is more obvious since the actual question of “where is” is completely obscured from the Internet Service Provider and everyone else from your device to the service you’re asking. The security aspect happens to be a nice side benefit since the obscurity of the question and answer disallows any man-in-the-middle altering of the answer as well as profiling of your habits. All in all, secured DNS is a huge win for the consumer, most especially in a nation-state that is oppressive. That is, as long as the oppressive state isn’t blocking that service of which you’re asking. This is just a small prediction: certain nation states will be blocking if they haven’t already by 2 April 2018.

  2. The Systems Administrator (sysadmin)

    The role of the often underappreciated sysadmin is to be the silent hero, unworthy of any outward accolades. The reward of a “job well done” is found in the lack of problems experienced by users and stakeholders alike. Sysadmins have handled the gradual, but predictable, rollout to the secured web (http to https), the “going dark” problem in stride, because it was good for the Internet community by achieving greater privacy and security. Partially this was because DNS remained a channel of control for the sysadmin. If a device tried to access a destination known to be in control of a malicious actor, it could be blocked at the DNS level because (a) it was visible and (b) it was known to be bad. When you remove the visibility to the sysadmin who is responsible to make sure nothing malicious happens over the edge of a network, this is a problem.

  3. The Provider

    Any organization in the position of gaining end user or sysadmin trust to have their DNS queries sent to them for answers, has a whole lot of responsibility. This kind of burden doesn’t come without cost, and therefore, benefit. Any organization that offers recursive, encrypted DNS services, and fast delivery at that, needs to be analyzed in terms of motives. In the case of CloudFlare, it is obvious that their existing subscribers benefit the most, as it is even expressed in their own blog post:

    “…every new user of makes Cloudflare’s Authoritative DNS service a bit better. And, vice versa, every new user of Cloudflare’s Authoritative DNS service makes a bit better.”

    Of course, every company can do what they want, but an objective assessment should always consider the provider’s true motive. In this case, the customers as well as the customers of Cloudflare’s customers stand to win when they use

  4. The Nation State

    The reality of oppressive regimes isn’t lost, either. The “going dark” problem, up until now, at least still revealed clear-text DNS queries, for the most part, except for OpenDNS’s DNScurve adoption, implemented as DNScrypt. Clear-text DNS allowed DNS-based filtering and analytics to play a significant role with great nation state firewalls to allow or block certain connections and services.

    With secured DNS now being part of the “going dark” protocols, it simply complicates the cat-and-mouse game, in which anyone is welcome to participate. When secured DNS is standardized and can be hosted anywhere, from a directory perspective, it just made it that much more difficult for nation states to filter source/destination pairs to be blocked.

    To be sure, vendors to Nation State firewalls will quickly up their game to compensate for lack of DNS visibility by offering increased threat intelligence fine-tuned to destinations including granular per-IP SANs to make up for the lack of DNS visibility.

How does DNSSEC fit into all of this?

Aside from the fact that DNSSEC is often misunderstood as private or secure (as in encrypted), it gives no privacy advantages whatsoever over non-DNSSEC DNS. This well-intentioned protocol has been a 20-year challenge and still isn’t being widely adopted. When properly implemented, DNSSEC gives authenticity, making DNS man-in-the-middle attacks impossible.

Our Conclusion

Everyone agrees on the importance that the edge of a network plays in terms of network reliability and security. In the industry, we often make an analogy to physical border officials who have the unenviable job of allowing or refusing entry to visitors. In the same way that officials need to have at least a reasonable risk assessment of entering individuals, the same applies to the edge of a computer network. While detailed traffic between endpoint and secured server should remain private and encrypted, the determination of which devices are communicating where, that should remain in control of the edge.

To do so, means the edge must have DNS visibility. This is not only sensible, but it is possible, and everybody wins. Here’s how:

Endpoint ↔ [Secured DNS channel] ↔ Edge ↔ Secured DNS channel ↔ Public Resolver

To give end users the privacy while allowing sysadmins to have the tools to protect the managed network, all outgoing connections must be whitelisted with DTTS (Don’t Talk To Strangers), an implementation of short-lived “allow” rules based on the TTL (Time To Live) of successful DNS answers. “Strangers” are destination IPs that were not first resolved via DNS. For example, will not resolve to an IP address, therefore, no “allow” rule is created to its authoritative destination. On the other hand, is permitted, so an “allow” rule is temporarily created for the asker, but only for the period of the TTL. Likewise, any internet traffic attempted without an allowed DNS query is simply not allowed. This approach gives the end-user the complete confidentiality of a banking transaction, while the sysadmin knows only that Internet-Exit-Point-A is conducting business with Bank-B, not aware of any further details. The Nation State is aware of the same since source-destination IP pairs always remain visible in transit. Everybody is happy.

Who doesn’t like a happy ending?

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.

Attack of the Internet of ‘Thingys’ episode

Posted January 26, 2018 by David Redekop to Press

David Schropfer invited us to his show this week…

Sobering report from the World Economic forum. And, by ‘sobering,’ it means: if you don’t already have a drinking problem, this could cause one!
We talk about the IoT Christmas, and new things to watch out for:

Great interview with David Redekop of DNSthingy: Internet of things, Botnets and more… Wrap up by answering a few guest questions

If you’re interested in how threats occur in the modern days we talk about a variety of bad actor approaches and how they can be addressed or mitigated including an important role by Quad9.

Here’s the link directly to the episode:

Blocking third party ads – a security feature

Posted January 23, 2018 by David Redekop to Security

In hindsight, we have verifiable information that blocking of third party ad networks is a necessary security precaution:

These ads and misleading displays are blocked with our default Rule Set which blocks third party ad networks including ones mentioned by Arstechnica.

Keep safe!

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.