Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

Network Details SSID: hasgeek Password: geeksrus

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

Session 1

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

● 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!

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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!

Slide 13

Slide 13 text

● 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

Slide 14

Slide 14 text

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!

Slide 15

Slide 15 text

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)

Slide 16

Slide 16 text

Delegation

Slide 17

Slide 17 text

Lets make a DNS Query

Slide 18

Slide 18 text

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)

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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!

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

Query, Responses & Flags - Demo

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

DNS RECORDS

Slide 28

Slide 28 text

● 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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

Dig, drill, host, nslookup...

Slide 31

Slide 31 text

More DNS Queries...

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

Recap & Timeout!

Slide 34

Slide 34 text

Session 2

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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.

Slide 37

Slide 37 text

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.

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

DNSCrypt - The Endgame

Slide 41

Slide 41 text

● 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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

Dnscrypt-proxy - Lets get started!

Slide 44

Slide 44 text

Q & A + The End!