- False answers through deep packet inspection or man-in-the-middle of DNS:
- Drop DNS requests for some domains,
- DNS takedown
- Inject a “not found” response for a DNS request (NX DOMAIN)
- Blocking through incorrect DNS reply
- valid + ACL’ed IPs etc.
- Configure a recursive resolver to return a “wrong” address
- Create imposter service & degrade service for clients who connect
- DNS force proxy
- DHCP race condition to inject rogue default DNS resolver
- DNS seizure
- DNS Consistency: Comparison of responses from a good reputation DNS resolver on a random high port to the dns resolver of interest,
- PTR Indications: PTR of the IP returned for local DNS and comparison of the results,
- Injection Test: Take a foreign IP that does not have a resolver listening and compare results for spoofed responses by middle boxes;
- Wait and See: Check for delayed or additional DNS replies that could have been triggered by in-path middleboxes;
- Aggregated assessment helps,
- GRC Approach: look up one domain that is not cached and tester is authoritative for to see where the request for subdomain comes from;
- Is there some way of chaining these two experiments together -- simple to do dns injection test in cases of bad domains.
- Relies on having a resolver in country AND on ISP if possible in order to control for geolocated results,
- How do you know its a client or ISP dns -- can we be confident?
OONI, DNSInjection Detects the presence of a censor that injects forged DNS replies when it detects an blacklisted domain name
- Documentation: https://trac.torproject.org/projects/tor/wiki/doc/OONI/Tests/DNSInjection
- Source: https://gitweb.torproject.org/ooni-probe.git/blob_plain/HEAD:/ooni/nettests/experimental/dns_injection.py
- Duan, Haixin, et al. "Hold-on: Protecting against on-path DNS poisoning." Securing and Trusting Internet Names (2012). http://www.icsi.berkeley.edu/pubs/networking/dnspoisoning12.pdf