Suspicious DNS responses

The Domain Name System translates a domain name to an IP address allowing for easy navigation to information presented by systems attached to the internet. Such translations can be incorrect, either as a consequence of misconfiguration, or of intentional intervention be that legal, extralegal or illegal.

The following graphs give an overview of our current ongoing monitoring efforts of such invalid DNS entries.

Read a brief description how we perform such monitoring. Or download the full paper. DNShonest implementation paper

Click and drag here to zoom

Goals and methodology

Goals

Determine if a DNS server is giving 'dishonest' reponses about the domains we query for.
Determine which Autonomous Systems contain DNS servers giving 'dishonest' query responses
Determine the owner of Autonomous Systems containing 'dishonest' query responses

Caveats

Despite the inherent suggestion of completeness that a visualization brings, this iteration does NOT show all 'dishonest' servers in a probed country, nor does it show all domains a probed server 'lies' about.
This iteration tests a small set of domain servers, taken from Joss´ original sample set.
This iteration tests a small set of domains, also taken from Joss´ original sample set.
Lying is a big claim, and in this case it explicitly means that a reply given by a domain name server is not the reply it should give. We have tried to avoid false positives as much as possible, first identifying suspicious replies, after which additional probes aid in determining if something is a lie or not.
This description is not complete. Soon.

Assumptions

A query reply from a DNS server in a given country queried remotely, can be compared to a local query to a 'known good' DNS server´s query reply
Such a reply should allow a mapping of DNS based blocking/censorship by using remote probes only.

Methodology

Probe a remote DNS server for a domain name
Probe a local DNS server for the same domain name
Collect a set of 'suspect' replies
Analyze these replies for known 'bad' answers such as a 127.0.0.1 or 'localhost' reply
Run additional HTTP requests against the remaining suspect list to further reduce false positives