DNS, How it works
Or, why does my Route53 not work?
Created by Laurence J MacGuire a.k.a Liu Jian Ming
ThoughtWorks Xi’An, 2015/06/02
What does it do?
Translates names into IPs (and then some)
> "Where is baidu.com?"
< "8.8.8.8"
Why? Because I numbers don’t make for good marketing. (Unless you’re Chinese, 163.com, 10010.com, 10086.com, etc)
How it worked before
$> cat /etc/hosts
baidu.com 8.8.8.8
google.com 4.4.4.4
Still in use (local overrides), but the internet got too big.
Challenges:
- Had to keep the file up-to-date
- Had to re-distribute this file to every device on the internet.
Gigabytes? Terabytes? Petabytes?
Needed a (de)centralised system
Centralised access: because everyone needs the same information.
Decentralised updates: because everyone can update their own information.
Enter the Hierarchy
www.iro.umontreal.ca
^ ^ ^ ^
Read from right to left.
CA => Canada
UMONTREAL => University (of) Montreal
IRO => Informatics (and) Research Operations
something.com [enter]
What happens now?
No, really, what happens?
So. Distributed and Hierarchical.
Two kinds of DNS servers
- Authoritative (Have answers)
- Resolvers/Forwarders (or “recursive”) (get answers)
More than just Name => IP
A (and AAAA) => Name to IP
CNAME => Name to another Name
MX => Mail servers
PTR => IP to Name
SRV => Service discovery
TXT => Whatever text
NS => Name servers (ooooh. I smell magic!)
And others
ALIAS is NOT standard. It’s Route53 specific.
Take step back
How did recursion work?
- How does ROOT know where .CA is?
- How does .CA know where UMONTREAL.CA is?
- IRO.UMONTREAL.CA?
Wait for it!
Those NS records!
Zone: umontreal.ca
iro.umontreal.ca NS => 3.4.5.6
This is called “delegation”.
A Whole Chain
[ROOT]
|
v
.CA (192.228.28.9, 199.19.4.1, ...)
|
v
UMONTREAL.CA (132.204.8.141, 132.204.8.131, ...)
|
v
IRO.UMONTREAL.CA (132.204.24.66, 132.204.24.69, ...)
In action
user@host:~$ dig +trace www.iro.umontreal.ca
; <<>> DiG 9.9.5-9ubuntu0.5-Ubuntu <<>> +trace www.iro.umontreal.ca
;; global options: +cmd
. 3161 IN NS c.root-servers.net.
/* AND 12 OTHERS */
;; Received 447 bytes from 127.0.1.1#53(127.0.1.1) in 2511 ms
ca. 172800 IN NS j.ca-servers.ca.
/* AND 3 OTHERS */
;; Received 513 bytes from 192.5.5.241#53(f.root-servers.net) in 3222 ms
umontreal.ca. 86400 IN NS dnsp1.dit.umontreal.ca.
/* AND 3 OTHERS */
;; Received 684 bytes from 192.228.30.9#53(e.ca-servers.ca) in 3673 ms
iro.umontreal.ca. 28800 IN NS dnsp2.dit.umontreal.ca.
/* AND 3 OTHERS */
;; Received 199 bytes from 206.167.244.111#53(ns2.risq.qc.ca) in 2833 ms
www.iro.umontreal.ca. 3600 IN CNAME himalia.iro.umontreal.ca.
himalia.iro.umontreal.ca. 3600 IN A 132.204.24.179
;; Received 161 bytes from 132.204.8.131#53(dnsp1.dit.umontreal.ca) in 304 ms
Root servers, or Chicken vs the Egg
But how do I know which Root server to use?
They’re just hard-coded.
Route53 Doesn’t Work!?
$> aws route53 create-hosted-zone \
--name my-new-department-name.example-company-name.com ...
$> # aws add-record \
# some-application.my-new-department-name.example-company-name.com 4.5.6.7
$> dig some-application.my-new-department-name.example-company-name.com
> NXDOMAIN => NAME NOT FOUND
But Why?!?
Because it lacks the proper delegation! That’s why.
It needs to be linked from the root servers.
Accredited Registrar?
GoDaddy? Namecheap?
Or. What happens when you buy a domain?
Can you guess?
.COM / Verisign
Verisign is responsible for running the .COM TLD servers.
Questions?
The end
There’s more if you want
Debugging DNS
$> dig (+trace) $TYPE $NAME @$SERVER
/* OUTPUT */
;; ANSWER SECTION:
$NAME $CACHE-TIME IN $VALUE
Debugging DNS
https://www.whatsmydns.net/
‘MX’ type records
Specify which servers handle mail for a DNS name.
$> leprechaun@cnmlappy:~$ dig mx thoughtworks.com
/* TRUNCATED */
;; QUESTION SECTION:
;thoughtworks.com. IN MX
;; ANSWER SECTION:
thoughtworks.com. 3600 IN MX 10 mother.thoughtworks.com.
thoughtworks.com. 3600 IN MX 5 chidmzlnmta01.thoughtworks.com.
thoughtworks.com. 3600 IN MX 20 wormhole.thoughtworks.com.
‘TXT’ type records
Just store text in DNS.
Typical use: ‘SPF’ records.
$> leprechaun@cnmlappy:~$ dig TXT thoughtworks.com
/* TRUNCATED */
;; QUESTION SECTION:
;thoughtworks.com. IN TXT
;; ANSWER SECTION:
thoughtworks.com. 3600 IN TXT "v=spf1 a mx include:cmail1.com ?all"
‘SRV’ type records
Service discovery
leprechaun@cnmlappy:~$ dig _xmpp-server._tcp.jabber.org SRV
/* TRUNCATED */
;; QUESTION SECTION:
;_xmpp-server._tcp.jabber.org. IN SRV
;; ANSWER SECTION:
_xmpp-server._tcp.jabber.org. 900 IN SRV 30 30 5269 hermes2.jabber.org.
_xmpp-server._tcp.jabber.org. 900 IN SRV 31 30 5269 hermes2v6.jabber.org.
‘ALIAS’ type records
These actually don’t exist. It’s a Route53 invention.
It’s like a ‘CNAME’, but performed by Route53 internally.
DNS is (was?) inherently insecure
The DNS protocol is ~30 years old. Security was NOT a priority then.
It uses (mostly) plain-text UDP.
Biggest problem: DNS Poisonning.
DNS Poisoning Example
What if you poisoned China Unicom’s DNS resolver? 1000000+ people affected.
What can we do about it?
Enter DNSSEC.
Can someone explain asymmetric encryption
(or public/private key encryption)
DNSSEC Example
We can trust DNSSEC as long as we trust the top-level (DNS system itself)
Who runs the Root servers?
ICANN (Internet Corporation for Assigned Names and Numbers) supervises them.
But they are run by private corporations (Verisign) and government institutions (US Military research)