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.
DNS Deep Dive Workshop
Rootconf | Jun 2019
● 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
● Experience with DNS, DNSSEC
● Cryptography experience
● What do you expect to take away from this course
● DevOps @ Zoomcar
● Self Hosted tech
● +91 9003010231
● Lets Grok DNS
○ Queries, Responses & Flags
● Tools - dig, drill, host, nslookup
● DNS Vulnerabilities
● Secure DNS - DNSSEC, DNSCrypt, DOH
● Run your own DNS Resolver
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
● 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!
● Very simple packet format
● Mostly Stateless - UDP
○ DNS Response speciﬁes caching objectives (TTL - Time To Live)
○ Servers respond to queries with additional information
● 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!
● 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
Internal workings of the DNS System
● Servers respond to queries
● Clients recursively query servers
● Responses are cached at every point in the chain
Keep asking the same question until you get a reply or you get bored waiting!
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)
Lets make a DNS Query
What just happened?
● Client (PC) has details of a recursive resolver (/etc/resolv.conf) - Stub resolver
○ nameserver 18.104.22.168
● 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
● OS depends on client stub
○ Eg: /etc/resolv.conf - unix
● Very minimal cache
● Depends on external authority to deﬁne the nameserver ip - router / network
● Ask authoritative servers for answer and send it back to client
● Cache alongside sending response
● Cache for period deﬁned by TTL
● Eg: 22.214.171.124, 126.96.36.199
● Self hosted - unbound
● Own the record being queried in its own zone ﬁle
○ 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!
DNS Root Server
● 13 root servers - baked into the OS / Downloaded from the internet by the
● dig . ns
● Most resolvers cache “.” locally - Usual refresh rate - 6-8 months
● Everytime query is made, the response is cached
● Subsequent queries for same domain are not resolved. Response provided
● TTL value - max period a record can be cached.
● Resolver == Authoritative Server == Caching server - Can serve multiple
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
Query, Responses & Flags - Demo
● 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
● 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
Dig, drill, host, nslookup...
More DNS Queries...
● IP Address of google.com?
● Mail server for google
● Who owns qag.me
● Lets trace facebook.com
Recap & Timeout!
● Data Corruption
● Unauthorised updates
● Cache poisoning
● Cache impersonation
● Domain Name System Security Extentions - RFC 4033
● Prevent clients from consuming manipulated / poisoned dns zone data
● Data is authenticated (ad ﬂag) but not encrypted
● New record types - RRSIG, DNSKEY, DS, NSEC
● Used only by zone owners on authoritative DNS servers.
● 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” ﬂag for dnssec validated response.
● 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
● Current server implementations
○ Many more…
● Current client implementations
○ Cloudﬂared (From cloudﬂare. duh!)
○ Curl > 7.62.0 (did you know this????)
○ Google chrome
DNSCrypt - The Endgame
● Protocol that authenticates comms between DNS Client and DNS Resolver
● Prevents DNS Spooﬁng
● Ensures response from “chosen” DNS server has not been tampered with
● Last mile security
● Works on both TCP & UDP. Default port 443
● Does not use trusted certiﬁcate authority.
● Clients must explicitly trust public key of server
● Short term Keys
● Key rotation
Dnscrypt-proxy - Lets get started!
Q & A + The End!