Who Is Answering My Queries Understanding and Characterizing

Who Is Answering My Queries: Understanding and Characterizing Interception of the DNS Resolution Path Presenters: Roy Shadmon & Han Gao Challenger: Pranav Yerabati

DNS Resolution ● ISP DNS Resolver

Public DNS Resolver ● Performance (e. g. , load balancing) ● Security (e. g. , DNSSEC support) ● DNS extension (e. g. , EDNS Client Subnet)

DNS Interception ● Who is answering my queries?

Taxonomy of DNS Resolution Paths

Who would potentially intercept our queries? ● ISP ● Censorship / firewall ● Anti-virus software / malware ● Enterprise Proxy (e. g. , Cisco Umbrella intelligent proxy)

Why can’t we rely on DNSSEC? ● Many DNS resolvers uses outdated/deprecated software ● Out of 1, 166 alternative DNS resolves that contact author’s nameservers, 205 are open to the public ○ ○ ○ Only 88 (43%) accept DNSSEC requests Those validating DNSSEC could be less Many nameservers can’t validate DNSSEC signatures

Why is DNS Interception a Problem? ● It could be used to: ○ ○ ○ collect statistics display advertisements Lead you to a malicious or incorrect page ● Ethically bad: ○ ○ Interception is difficult to detect by the client Interception is unauthorized Alternative recursive DNS servers lack proper maintenance (outdated DNS software) Some security-related functionalities are affected/broken because they don’t provide DNSSEC

Challenges faced to analyze DNSIntercept ● Acquiring clients belonging to different Autonomous Systems ● Verifying whether DNS resolution was intercepted

Verifying DNS interception ● Registered set of domains (e. g. , Our. Domain. TLD) ● Used authoritative nameservers controlled by authors ● Client sends packets directly to a list of public DNS servers ○ Queries nonce subdomains under their domain name (e. g. , UUID. Google. Our. Domain. TLD)

Approach to detecting DNSIntercept 1. Instruct client to send DNS request about one of the controlled domains to a public resolver A 2. Record its corresponding request at our authoritative nameservers, which originates from recursive resolver B 3. Compare A with B 4. Validate response received by client

Detecting interception type If A == B → Normal resolution Else If no corresponding request captured by authoritative nameserver → direct responding If single request not from resolver A → request redirection If multiple identical requests from resolvers (one of them being from A) → request replication

Design Requirements 1. Queried domain name of each request should be unique to avoid caching 2. Should be able to correlate request from client with the one captured by our authoritative nameserver in the same resolution 3. Clients should be able to send DNS packets directly to public resolvers, even when local DNS resolvers have been assigned by ISPs. 4. Requests should be able to be done over different transport protocols

Interception Model ● On-path devices are deployed to inspect/manipulate DNS packets ● Diverse DNS packets represented as such: {Src IP, Dst IP, Protocol, RR Type, Requested Domain}

Generating DNS Requests ● Need a way to address inconsistent source IPs between requests from clients and corresponding requests by recursive resolvers ● Solution: ○ Link requests through unique domain prefix that includes a distinct UUID generated for each client ● Considering RR Type and the UUID prefix, we can identify DNS packets in the same resolution

What this paper wants to figure out Q 1: How to globally measure the hidden DNS interception? Q 2: What are the characteristics of the hidden DNS interception?

Global Analysis ● Uses a SOCKS proxy network called Proxy. Rack to send customized DNS requests to any specified resolver over TCP ● Proxy. Rack has over 100 K nodes that can send DNS requests over TCP from nodes distributed globally to public resolvers

China-wide Analysis ● Built network debugger module that sends arbitrary network requests on behalf of a user to collect fine-grained DNS data ● Capable of recording packets sent on TCP & UDP ● Module can only be run manually with granted permission from user ● DNS packets are only captured of domain exclusively registered for the study to protect privacy

Overall Ethics Consideration

Data Set

Analysis 1. TCP DNS Interception Analysis (Global) a. Scope & Magnitude b. Types & Ratio 2. TCP/UDP DNS Interception Analysis (China-wide) a. What kinds of packets are more likely to be intercepted? b. Is the hijacked request faster? c. Has the response been manipulated?

TCP DNS Interception Analysis (Global) 198 ASes have intercepted traffic (of 2, 691, 7. 36%, TCP)

Interception Ratio 0. 66% 0. 53% 0. 64% EDU DNS (self-built) 0. 45% DNS traffic sent to renowned public DNS services are more likely to be intercepted.

Types of interception Direct responding is rare. Majority contains only one type of interception.

Country Distribution 158 ASes span 41 countries: 1. Russia 44 ASes (28%) 2. United States 15 ASes (9%) 3. Indonesia 8 ASes (5%) 4. Brazil and India 7 ASes each (4%)

Alternative Resolvers Actually locate in the same AS as the clients.

TCP/UDP DNS Interception Analysis (China-wide) 61 ASes have intercepted traffic (of 356, 17. 13%)

Interception Ratio: UDP vs TCP 27. 9% 12. 6% 7. 3% 0. 9% 16. 1% 2. 3% EDU DNS (self-built) 9. 8% 1. 1% DNS requests over UDP from clients are more likely to be intercepted.

Magnitude (% of total requests) – Normal resolution Request redirection Request replication Direct responding is rare. Request redirection > Request replication

DNS RR Types A-type requests are slightly preferred to be intercepted.

Performance of DNS Lookups ● RTT of requests – Which requests complete faster? ↑ Better performance Request replication vs. Normal resolution: Better. Request redirection vs. Request to local resolver: Very similar.

Performance of DNS Lookups ● RTT of requests – Which requests complete faster? ↑ Better performance Request redirection vs. Normal resolution: Uncertain.

Performance of DNS Lookups ● Arrival time of replicated requests – Which requests reach NS faster?

Performance of DNS Lookups ● Arrival time of replicated requests – Which requests reach NS faster? ↑ Replicated is faster ↓ Replicated is slower In AS 4812, ALL replicated requests arrive slower than their original counterparts

Response Manipulation ● TTL Value - 20% of the TTL values are replaced, mostly with a smaller value Preferred values for modified TTL: 1800, 3600 and 7200.

Response Manipulation ● DNS record values - A small amount of responses was tampered Classification # Response Example Client AS Gateway 54 192. 168. 32. 1 AS 4134, CN, China Telecom Monetization 10 39. 130. 151. 30 AS 9808, CN, GD Mobile Misconfiguration 26 : : 218. 207. 212. 91 AS 9808, CN, GD Mobile Others 54 fe 80: : 1 AS 4837, CN, China Unicom

Interception Motivations ● Improving DNS security ? ● Improving DNS lookup performance ? ● Reducing traffic financial settlement

Response Manipulation ● Example: traffic monetization China Mobile Group of Yunnan: advertisements of an APP.

Security Threats ● Ethics & privacy - Users may not be aware of the interception behavior ● Alternative resolvers’ security - An analysis on 205 open alternative resolvers Only 43% resolvers support DNSSEC ALL BIND versions should be deprecated before 2009

Solutions ● Encrypted DNS-over-TLS (RFC 7858) * Pic from: https: //tenta. com/blog/post/2017/12/dns-over-tls-vs-dnscrypt

Solutions ● Online checking tool r are e v l o s e hich r sing u y l l a e you r ？ W http: //whatismydnsresolver. com/

Conclusion ● Understanding - A measurement platform to systematically study DNS interception ● Findings - DNS interception exists in 259 ASes (of 3047, 8. 5%) we inspected globally - Up to 28% requests from China to Google are intercepted - Brings security concerns ● Motivations - Reducing traffic financial settlement