DNS testing is fundamental to network measurement to detect censorship as it’s a commonly used technique to implement censorship.
When reasoning about DNS interference, we shall consider the following possibilities:
- DNS hijacking (or Policy Based DNS interference), whereby a DNS resolver run by the ISP, parental control DNS service or government is configured to return specifically altered responses to specific queries. This is usually trivial to circumvent by changing resolver.
- DNS Spoofing, whereby there is equipment in the network that listens for DNS queries and sends replies back to the user faster than the legitimate DNS server. This tends to be tricker to circumvent.
- DNS Transparent Proxy, whereby all DNS requests sent by a user are routed through a DNS proxy box regardless of the destination DNS server, and the reply is served by the proxy box. This also tends to be trickier to circumvent.
The difference between DNS Spoofing and DNS Transparent Proxy is that in one case the origin server gets the client query and in the other it doesn't, in other words — if the end-to-end principle is preserved or 100%-violated. If the origin server gets the query from the client and the response from origin server is blocked so the client only gets a single injected response, then it's still spoofing. The following metadata bits are useful to classify the case as spoofing or proxy:
- presence of second DNS reply to single query
- IP TTL values of the replies got from different resolvers
- difference between probe IP addresses collected over HTTPS, DNS/TCP, DNS/UDP and STUN/UDP
- different handling of hop-by-hop EDNS(0) options
E.g. lack of the second DNS reply combined with the injected DNS response suggests1 that censorship equipment is doing an in-path attack (aka man-in-the-middle), while the presence of a second DNS reply suggests2 that an on-path attack (aka man-on-the-side) is happening.
1: "suggets in-path" (not "proves") as the second DNS reply can also disappear due to natural packet loss
2: "suggets on-path" (not "proves") as in-path equipment may do all on-path attacks as well
The following techniques may help to distinguish DNS-based censorship from a malfunctioning network or DNS service:
- more than one reply is received for a single DNS query
- the same resolver gives the same answer with DNS/TCP, DoT and DoH
- DNS Resource Record TTL “ticks” on caching Recursive Resolver
- another “non-existent” domain in same zone gives same error
- timeout can be explained by 5-tuple load balancing going bad
- delegation chain works from root (dig +trace, drill)
- domain and parent domains have SOAs and NSes matching with control measurement
- TBD :-)