$30 off During Our Annual Pro Sale. View Details »

DNS Deep Dive Workshop

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.

Ashwin Murali

June 23, 2019
Tweet

More Decks by Ashwin Murali

Other Decks in Technology

Transcript

  1. DNS Deep Dive Workshop
    Rootconf | Jun 2019
    Bangalore, INDIA
    Ashwin Murali
    @cruisemaniac

    View Slide

  2. Network Details
    SSID: hasgeek
    Password: geeksrus

    View Slide

  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

    View Slide

  4. Introductions
    2 mins
    ● Name
    ● Experience with DNS, DNSSEC
    ● Cryptography experience
    ● What do you expect to take away from this course

    View Slide

  5. ● DevOps @ Zoomcar
    ● Self Hosted tech
    ● Qag.me
    ● ashwin@flatty.co
    ● +91 9003010231
    About Me

    View Slide

  6. Session 1
    ● Lets Grok DNS
    ○ Introduction
    ○ Delegation
    ○ Queries, Responses & Flags
    ● Tools - dig, drill, host, nslookup

    View Slide

  7. Session 2
    ● DNS Vulnerabilities
    ● Secure DNS - DNSSEC, DNSCrypt, DOH
    ● Run your own DNS Resolver

    View Slide

  8. Session 1

    View Slide

  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

    View Slide

  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!

    View Slide

  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

    View Slide

  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!

    View Slide

  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

    View Slide

  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!

    View Slide

  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)

    View Slide

  16. Delegation

    View Slide

  17. Lets make a DNS Query

    View Slide

  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)

    View Slide

  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

    View Slide

  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

    View Slide

  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!

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  25. Query, Responses & Flags - Demo

    View Slide

  26. Remember!!!
    Question:
    rd
    Answer:
    qr
    ra
    aa

    View Slide

  27. DNS RECORDS

    View Slide

  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

    View Slide

  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

    View Slide

  30. Dig, drill, host, nslookup...

    View Slide

  31. More DNS Queries...

    View Slide

  32. ● IP Address of google.com?
    ● Mail server for google
    ● Who owns qag.me
    ● Lets trace facebook.com

    View Slide

  33. Recap & Timeout!

    View Slide

  34. Session 2

    View Slide

  35. DNS Vulnerabilities
    ● Data Corruption
    ● Unauthorised updates
    ● Cache poisoning
    ● Cache impersonation

    View Slide

  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.

    View Slide

  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.

    View Slide

  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

    View Slide

  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

    View Slide

  40. DNSCrypt - The Endgame

    View Slide

  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

    View Slide

  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

    View Slide

  43. Dnscrypt-proxy - Lets get started!

    View Slide

  44. Q & A + The End!

    View Slide