Table of Contents

testdns.py Script

Introduction

testdns.py is a Python script I wrote which uses my DNS API to inform you about potential DNS interception and misconfigurations.

This page is to provide more detail about what each test result is really telling you.

Warning Messages

"Your resolvers are:"

The script will return a list of services who are handling your DNS queries which looks something like this:

Your resolvers are:
OPENDNS - Cisco OpenDNS, LLC (AS36692)    
CLOUDFLARENET - Cloudflare, Inc. (AS13335)
BANDWIDTH-AS (AS25369)

Your system may be configured to use just one service (often your ISP) or it could be configured to use many. This test is designed to discover as many as possible in a short period of time.

If you have manually chosen your DNS resolvers and see something unexpected in this list, it might indicate a misconfiguration or interception. Further tests should give more information.

"Your resolver cached a 0 second TTL response"

Authoritative DNS servers (like my DNS API servers) can tell resolvers how long to cache responses for; this is known as the “time to live” (TTL) value.

DNS records with a 0 second TTL should not be cached but some resolvers do so anyway. This message is to inform you that your default resolver is caching 0 second TTL records.

"Your resolver modified the TTL response"

Just like the previous test, the DNS API returns a record with a 0 second TTL and expects your resolver to not cache it. This message indicates that your resolver replaced the TTL with some other value. The most likely reason to do this is to force caching on records which should not be cached.

Modifying the TTL is considered bad practice and in some situations could potentially cause connectivity issues to some websites. For example, if your resolver forces a 30 minute cache and a website with a 5 minute TTL changes their IP, you may be stuck on their old IP address which could be down for maintenance. This kind of issue is rare but you should be aware of it for if you ever get stuck with a stale IP address.

"A unique IP was expected for each resolver!"

Full message: “Queried 8.8.8.8 and got x.x.x.x. A unique IP was expected for each resolver!”

This test will perform DNS lookups to multiple public resolvers and ask the DNS API to return a random IP address. In theory, every request will have a unique response because the response is randomised. However, if you ever get a duplicate response from 2 different resolvers, it indicates something is intercepting your DNS and forcefully caching it.

Some routers have a “force DNS cache” option which will block your DNS queries to public resolvers and give you a response from the cache instead (but only if the router already has the record cached). This may potentially increase your DNS performance but could make DNS troubleshooting much harder.

It is also possible to redirect all DNS traffic to a local resolver on the network to improve cache efficiency and also to make it easier to perform DNS filtering.

"Attempted to query NS1 directly but something intercepted it"

Full message: “Attempted to query NS1 directly but something intercepted it. The DNS API saw CLOUDFLARENET - Cloudflare, Inc. (AS13335) instead of your IP.”

This test will query the first nameserver of the DNS API directly so any resolvers you use are bypassed. This message indicates that the query was intercepted and performed by a resolver server anyway.

Just like with the previous test, this could be because something on your network intercepts DNS for the purpose of caching/filtering. This is probably common on large networks at offices but is unusual on a home network unless you set it up yourself.

This test could have false positives if you use a HTTPS proxy. The DNS API is comparing your HTTPS IP with the IP it saw for your DNS traffic.

"Got an unexpected response from x .."

Full message: “Got an unexpected response from CLOUDFLARENET - Cloudflare, Inc. (AS13335) but was expecting something containing google for resolver 8.8.8.8”

This test indicates that your DNS queries are being intercepted. The name of the resolver the API saw is shown along with the IP of the resolver this script attempted to contact. If the script attempted to contact 8.8.8.8 (Google DNS) and got a response from Cloudflare (as shown in the line above), it means the DNS traffic was redirected from 8.8.8.8 to Cloudflare (most likely 1.1.1.1)

This may be because your network administrator is blocking certain resolvers but doesn't want queries to fail. It may also be because a server on your network is intercepting queries (such as a Pi-Hole installation) which has its own DNS resolver preferences.

"Got x.x.x.x when we wanted y.y.y.y"

Full message: “Got 0.0.0.0 when we wanted 192.168.1.1”

This test is designed to detect some types of DNS filtering or tampering. The script makes a request to the DNS API which is meant to return a certain IP address but a different IP address was given instead. If a local IP address is listed in the “we wanted x.x.x.x” part, it is likely your resolver is configured to block responses containing local IP addresses. This is a security feature but may be unwanted in certain situations.

If this message is triggered when a non-local IP address was expected, it may be because your DNS resolver is attempting to hijack or censor your connections.

"DNS response containing private IP x.x.x.x was blocked"

Full message: “DNS response containing private IP 192.168.1.1 was blocked, likely for security reasons.”

This message indicates that the DNS API returned an IP address within a private range (eg, it can only exist on your LAN and not the internet). Some DNS resolvers block responses containing private IPs for security reasons. This is usually a good thing.

This isn't considered a test failure but it is logged because it is sometimes helpful to know if this feature is enabled or not.

Final Output

A test result with no warnings should look something like this. The list of resolvers will be different for everyone.

Your resolvers are:
CLOUDFLARENET - Cloudflare, Inc. (AS13335)


Cache tests failed: 0
Intercept tests failed: 0
Modification tests failed: 0

Here is an example from a network where every DNS query is forcefully redirected to a Pi-Hole resolver on the network which caches results:

Your resolvers are:
OPENDNS - Cisco OpenDNS, LLC (AS36692)
CLOUDFLARENET - Cloudflare, Inc. (AS13335)


Your resolver cached a 0 second TTL response
Your resolver modified the TTL response
Cache tests failed: 2
Queried 1.1.1.1 and got 133.145.242.98. A unique IP was expected for each resolver!
Queried 8.8.8.8 and got 133.145.242.98. A unique IP was expected for each resolver!
Queried 208.67.222.222 and got 133.145.242.98. A unique IP was expected for each resolver!
Queried 159.65.48.199 and got 133.145.242.98. A unique IP was expected for each resolver!
Attempted to query NS1 directly but something intercepted it. The DNS API saw CLOUDFLARENET - Cloudflare, Inc. (AS13335) instead of your IP.
Got an unexpected response from CLOUDFLARENET - Cloudflare, Inc. (AS13335) but was expecting something containing google for resolver 8.8.8.8
Got an unexpected response from CLOUDFLARENET - Cloudflare, Inc. (AS13335) but was expecting something containing opendns for resolver 208.67.222.222
Intercept tests failed: 4
DNS response containing private IP 192.168.1.1 was blocked, likely for security reasons.
DNS response containing private IP 10.10.10.10 was blocked, likely for security reasons.
DNS response containing private IP 255.255.255.255 was blocked, likely for security reasons.
Modification tests failed: 0

This test result indicates that the TTL is being modified, DNS queries are served from the cache regardless of which resolver the PC attempts to contact, the PC is unable to query nameservers directly, and that private IP addresses are blocked.