DNS Deep Dive Workshop

Workshop conducted at Rootconf June 2019.

DNS is the most basic building block of the internet - A protocol for computers and devices to discover the addresses of other computers and devices across the globe. Attend this workshop to build your DevOps-fu with a thorough understanding of DNS. Walk out knowing that your DNS queries are safe from tampering or profiling by running your own DNSCrypt resolver.

Grok DNS - What makes the Domain Naming System? How does it tick? What is the plumbing like underneath?
DNS Resolution - How does your browser know what the address of google.com is? How does the query look like? How does it execute? How does the response come back? Lets talk DNS Caching
DNS Security issues - What are the ways you poison a DNS request? What happens when DNS / Cache is poisoned?
Securing your DNS - DNSSEC, DNSCrypt, DOH - We’ll delve a little bit into each of the options you have to make sure your DNS requests are secured
Setup and run your own DNS Resolver - We’ll put all that we just saw into practice - We’ll setup a DNS resolver on your local laptops to run secured DNS queries.

Transcript

1. DNS Deep Dive Workshop Rootconf | Jun 2019 Bangalore, INDIA Ashwin Murali @cruisemaniac
2. Network Details SSID: hasgeek Password: geeksrus
3. Schedule • 09:00 AM to 09:30 AM - Check-in • 09:30 AM to 11:00 AM - Session 1 • 11:00 AM to 11:30 AM - Break • 11:30 AM to 01:30 AM - Session 2
4. Introductions 2 mins • Name • Experience with DNS, DNSSEC • Cryptography experience • What do you expect to take away from this course
5. • DevOps @ Zoomcar • Self Hosted tech • Qag.me • ashwin@flatty.co • +91 9003010231 About Me
6. Session 1 • Lets Grok DNS ◦ Introduction ◦ Delegation ◦ Queries, Responses & Flags • Tools - dig, drill, host, nslookup
7. Session 2 • DNS Vulnerabilities • Secure DNS - DNSSEC, DNSCrypt, DOH • Run your own DNS Resolver
8. Session 1
9. History of the Domain Name System • Not too long ago… ◦ Computers didn’t talk to one another ◦ They were bloody expensive, very large and very very noisy • The initial version of the internet by Vint Cerf and Robert E. Kahn was tiny ◦ < 100 hosts Most basic version of the DNS - Post-its on terminals
10. • Computers became famous ◦ Post-its --> HOSTS.TXT ◦ FTP Distribution ◦ File became massive ◦ Crazy bandwidth requirements - Impractical - Too much churn • ENTER RFCs 882, 883 circa 1983 • Updated via RFCs 1034, 1035 in 1987 • Much updates!
11. DNS Protocol • Asynchronous • Very simple packet format • Mostly Stateless - UDP • Cachemaxx! ◦ DNS Response specifies caching objectives (TTL - Time To Live) ◦ Servers respond to queries with additional information
12. GROK DNS • Index of internet resources ◦ IP addresses of hosts ◦ Mail server ◦ Web server • Does not care whats put here ◦ GIS records ◦ Public Keys (DKIM) ◦ Leap Seconds ◦ Whitelisting (SPF) Limited by only your imagination! Think it, and someone’s already put it there!
13. • Data is indexed by Domain Names ◦ Domain name is a sequence of labels ◦ Labels separated by dots (“.”) and maintained as a tree • Root (“.”) at the top, Domain Names as branches & leaves • Administration is shared • Authority is delegated • No single entity is in charge
14. Internal workings of the DNS System • Servers respond to queries • Clients recursively query servers • Responses are cached at every point in the chain Recursion!!! Keep asking the same question until you get a reply or you get bored waiting!
15. Root, TLD, ccTLD • 13 root servers • “Empty label” covers the “.” zone • Top Level Domains ◦ GTLD - Generic Top Level Domain (.com, .net, .org, etc) ◦ ccTLD - Country Code Top Level Domain (.uk, .us, .in, .it, etc) ◦ New TLDs (.blog, .work, etc)
16. Delegation
17. Lets make a DNS Query
18. What just happened? • Client (PC) has details of a recursive resolver (/etc/resolv.conf) - Stub resolver ◦ nameserver 1.1.1.1 • Recursive resolvers search on behalf of clients ◦ Maintain large cache ◦ Cache is maintained based on the TTL value of the record ◦ Query from Root “.” all the way down • DNS Servers respond to queries (From cache) • Authoritative Servers reply authoritatively (They OWN the record being queried)
19. Client Stub • OS depends on client stub ◦ Eg: /etc/resolv.conf - unix • Very minimal cache • Depends on external authority to define the nameserver ip - router / network
20. Recursive Resolver • Ask authoritative servers for answer and send it back to client • Cache alongside sending response • Cache for period defined by TTL • Eg: 1.1.1.1, 8.8.8.8 • Self hosted - unbound
21. Authoritative server • Own the record being queried in its own zone file ◦ A, AAAA, MX, CNAME, SRV, etc • Will only answer if record belongs to own zone • Will point to authority if not An Authoritative Server will not query another authority for your record!
22. DNS Root Server • 13 root servers - baked into the OS / Downloaded from the internet by the resolvers • dig . ns • Most resolvers cache “.” locally - Usual refresh rate - 6-8 months
23. Caching • Everytime query is made, the response is cached • Subsequent queries for same domain are not resolved. Response provided from cache • TTL value - max period a record can be cached. • Resolver == Authoritative Server == Caching server - Can serve multiple purposes
24. Queries, Responses & Flags • Every query is made up of ◦ Qname - name of the domain ◦ Qtype - type of record - A, AAAA, MX, CNAME, NS, etc ◦ Qclass - IN, HS, CH, etc (IN most common) ◦ Flags - QR, AA, RA, RD, etc
25. Query, Responses & Flags - Demo
26. Remember!!! Question: rd Answer: qr ra aa
27. DNS RECORDS
28. • NS - NameServer • A, AAAA - ipv4, ipv6 address • CNAME - Canonical Name / Alias record • MX - Mail Exchange • PTR - Reverse Info • SRV - Service record • SOA - Start of Authority
29. Glue Records • Bind IP address to static cache so queries can always be resolved • Response is provided as Additional information • Prevent circular dependency if NS is subdomain
30. Dig, drill, host, nslookup...
31. More DNS Queries...
32. • IP Address of google.com? • Mail server for google • Who owns qag.me • Lets trace facebook.com
33. Recap & Timeout!
34. Session 2
35. DNS Vulnerabilities • Data Corruption • Unauthorised updates • Cache poisoning • Cache impersonation
36. DNSSEC • Domain Name System Security Extentions - RFC 4033 • Prevent clients from consuming manipulated / poisoned dns zone data • Data is authenticated (ad flag) but not encrypted • New record types - RRSIG, DNSKEY, DS, NSEC • Used only by zone owners on authoritative DNS servers.
37. More DNSSEC... • Chain of trust is created to validate data • Query starts with DS in parent zone ◦ DS used to validate DNSKEY record in child zone (subdomain) and so on and so forth. • Query response sets “ad” flag for dnssec validated response.
38. DOH • Domain resolution over HTTPS protocol - RFC 8484 • DOH Server needs to host HTTPS endpoint for resolver to connect • Response received via UDP in HTTPS payload • Mime type - application/dns-message • HTTP/2 can also be used to push anticipated responses
39. More DOH • Current server implementations ◦ Cloudflare ◦ Google ◦ Many more… • Current client implementations ◦ Dnscrypt-proxy ◦ Cloudflared (From cloudflare. duh!) ◦ Curl > 7.62.0 (did you know this????) ◦ Firefox ◦ Google chrome
40. DNSCrypt - The Endgame
41. • Protocol that authenticates comms between DNS Client and DNS Resolver • Prevents DNS Spoofing • Ensures response from “chosen” DNS server has not been tampered with • Last mile security
42. More DNSCrypt • Works on both TCP & UDP. Default port 443 • Does not use trusted certificate authority. • Clients must explicitly trust public key of server • Certs • Short term Keys • Key rotation
43. Dnscrypt-proxy - Lets get started!
44. Q & A + The End!