Dns

Introduction to
DNS
Naming network items

Hi
 Julien PAULI
 Programming in PHP since early 2000s
 PHP Internals hacker and trainer
 PHP 5.5/5.6 Release Manager
 Working at SensioLabs in Paris - Blackfire
 Writing PHP tech articles and books
 http://phpinternalsbook.com
 http://blog.jpauli.tech
 @julienpauli - github.com/jpauli - jpauli@php.net
 Like working on OSS such as PHP :-)

TOC
 History of Internet and networks
 The need to name things
 The need to create a synchronized decentralized system
 Domain Name Server
 A hierarchical system
 Names and zones
 Practicing DNS with BIND
 Zones creations and delegation
 Zones master and slave propagation

State Of The Art
 Each machine on a network is assigned an IP address
 IPV4 : 32 bits
 IPV6 : 128 bits
 Computers are fast at treating numbers
 Human brains are crap at treating and memorizing numbers
 But human brains are good at memorizing names (letters)
 There is a need of a global system which goal would be
association of human-memorizable mnemonics (names)
and computer assigned address numbers

Usage of a centralized file
 In 1970, ARPANET only handles hundreds of hosts
 ARPANET == Internet ancestor
 Among those, one machine were hosting a file : HOSTS.TXT ,
associating every network machine names with their addresses
 HOSTS.TXT were then copied/synchronized in each local
machine's /etc/hosts file, which is used as the local UNIX hosts db
 When HOSTS.TXT were modified, admins sent emails to each
machine to have their user download the new HOSTS.TXT and
update their own /etc/hosts

Problems showing
 ARPANET grows, more and more hosts
 Having one single HOSTS.TXT file to both update and
transfer to everyone starts to be a pain.
 That becomes unmaintainable
 ARPANET searches for a system to replace HOSTS.TXT
drawbacks
 In 1984, the DNS first RFC were written

DNS
 A distributed name database
 Name servers contain a segment
of the whole name database
 Clients, called resolvers, can
query servers
 Some caches are setup to
improve overall performances

DNS Structure
 DNS has been structured like UNIX Filesystem
 A reversed tree where root node is on top
root node
domain
subdomain

A domain name
 A domain name is the equivalent of an absolute path
 But it is read in the reverse way
 And it uses a dot as a separator and not a slash
Reading the FS
Reading the DNS

DNS decentralization
 Each subdomain may be managed by a different entity, this
is called a delegation
ICANN
NSI
BSD University
Local FS
Remote NFS

DNS overview
 This system solves the HOSTS.TXT problems
 No more duplicate entry
 Each domain name is unique
 And can be administrated by a unique entity
 Each zone can contain
 Host names
 Sub domains
 The system is
 distributed
 redundant
 delegated (no centralization)

DNS tree
 The namespace may reach 127 deepness levels
 Each tree name can be up to 63 chars
 Separator is dot " . "
 Root node has the null name ""

DNS structure
 A domain is simply a subtree of the namespace
 Each subtree node is owned by its parent
 Hence, pa.ca.us is child of ca.us and of us
us domain
pa.ca.us node
ca.us domain
Top Level Domain
Level one domain
Level two domain
Root

Zone and domain
 A zone contains records and delegation informations about
a name
 A domain contains the merge of all its zones informations

Zone delegation
 Zone delegation allows a domain administrator to delegate
any information about a zone to someone else
 Each zone can be seen as an AS

DNS ? Competitors ?
 If you connect to Internet
 DNS is a must-have
 If you got your own internet network, based on TCP/IP (network of
networks)
 DNS can be used
 If you got your own local network
 DNS is an option
 Competitors exists, like WINS or NIS
 If you need distributed management and face consistency issues, DNS
could be your solution

Resource Records (RR)
 RR are DNS data (what is stored is called a "resource record")
 Divided in classes : we'll use the TCP/IP Internet class mainly (IN)
 Classes are divided by types
 https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml
 Most commonly used types are :
 A : an IPV4 Address
 AAAA : an IPV6 address
 NS : A name server
 SOA : A Start Of Authority
 PTR : A reverse-DNS entry
 MX : A mail server entry
 TXT : Some textual information
 Location : Geo Data
 SRV : Service discovery (http, ftp, ldap ... offered by a domain)

Resource Records (RR)
 Nowadays, there exists many RR
 Postcodes can be stored in DNS ;-)
 User/pass can be stored in DNS (ldap alternative)
 DNS is a database, it is possible to add new "fields" ,
infinitely
 DNS is expansible, and is updated to follow the overall
Internet mutations through time
 Big companies may hide opportunities in DNS entries ;-)

DNS clients and servers
 Clients are called resolvers
 Servers
 May be authoritative on a zone
 May be non-authoritative on a zone
 May also be themselves clients
 Authoritative servers must be at least two per zone
 We usually call both the "master" and the "slave", but they both
are authoritative on a zone
 The "master" can update the zone infos, whereas the slaves can
only copy it from the master (or another slave) and can't edit it.

Resolving names
 A resolver is silly, and needs a server
 A server can resolve a name
 Resolving a name, is searching for an answer
 "What is the IPV4 of foo.bar ?"
 "foo.bar is at 10.5.49.6"
 Each server is only authoritative for the zone its been setup
for
 Each server only knows a small piece of names from the whole
namespace

Root servers
 Root servers know every server of the upper level
 spreaded worldwide
 critical hardware for the overall Internet life
 AnyCast routed

Resolving from root servers
 Root servers know every server of the upper level
 Every upper server
 knows the answer if no delegation is performed
 (The answer can be an error, like "no such domain")
 OR
 knows the upper server of the upper name if the zone is delegated
 So a server whether
 Knows your answer
 OR
 Knows who can know it
 ...this, recursively

DNS resolution example
 let's resolve foo.bar.baz.com

Here is the DNS
local
server
foo.bar.baz.com ??
foo.bar.baz ??
foo.bar ??
com zone server infos
baz zone server infos
foo.bar.baz.com?? Root server
com server
bar zone server infos
foo ??
foo is at 1.2.3.4
baz server
bar server
1
2
4
3
foo
bar
baz
com
.
.
.
.
1.2.3.4

Resolving a name
 A recursive server will attempt to find the answer on its
own. It follows server informations until it finds
 A non-recursive server only gives answer to its zone
information, and does not try to resolve anything by
contacting anyone else

Recursive VS Iterative queries
local
server
foo.bar.baz.com ??
foo.bar.baz ??
foo.bar ??
com zone server infos
baz zone server infos
foo.bar.baz.com?? Root server
com server
bar zone server infos
foo ??
foo is at 1.2.3.4
baz server
bar server
foo
bar
baz
com
.
.
.
.
1.2.3.4
IterativeRecursive

Resolver - server - recursion
 A resolver always issues recursive queries, it has zero
intelligence
 A server usually issues non-recursive, aka iterative queries.
 Iterative answers give a new server name
 Recursive queries involve more work on the server
DNS
Server
DNS
Server
DNS
Server
DNS
Server
Iterative
Recursive
Company A

Recursion in DNS
 If a server receives a recursive query , it must answer it fully
 If it does not have authority on the zone, it must then ask
another server. If needed, it will ask from the root server
 If a server receives a recursive query, it politely will issue
iterative queries on its side, until forwarding
DNS
Server
DNS
Server
DNS
Server
DNS
Server
Iterative
Recursive
Company A

DNS resolution
DNS
Server
DNS
Server
DNS
Server
DNS
Server
Iterative
Recursive
Company A

DNS forward
DNS
Server
DNS
Server
DNS
Server
DNS
Server
Iterative
Recursive
Company A
DNS
Server
forwarding

Let's practice it :-)
 A registrar is a company that interface with a registry
 A registry is the one company that takes care of one TLD
 Common TLD : com, net, org, fr, us, uk .. .. ...
 Registry is the big-seller
 Registrar is the detail-reseller
 Registrar takes customers domain booking, and records them to the
registry
 It records the delegation servers for the new zone, there should be
two of them

Find a registrar, and register
 ghandi, ovh , godaddy, etc...
 Buy your domain : foo.bar.
 Here, the registrar will register (haha), your nameservers
for the foo.bar. zone, against the TLD registry for .bar.
 This registration can take time, but it is usually fast
.bar zone.bar
registry
registrar Ans1
ns2
registrar B
registrar C
ns1/ns2 ns1/ns2 ns1/ns2

Domain Registration == delegation
 TLD only delegates, TLD never registers hosts
 You delegate foo into the bar. zone
 That is you declare your servers (2 minimum) to the bar. zone
 Each future resolution in bar., about foo.bar., will answer your
servers : .bar. delegates to you foo.bar. management
 Now you can register names : aka "baz.foo.bar."
 Or you can delegate full zones, like *.wow.foo.bar."
.bar zone.bar
registry
registrar Ans1
ns2
registrar B
registrar C
ns1/ns2ns1/ns2ns1/ns2

Done !
.bar zone.bar
registry
registrar Ans1
ns2
registrar B
registrar C
wow.foo.bar ?
DNS
server
.bar zone
wow.foo.bar ?
ns1.foo.bar
is here
ns1
ns2
wow.foo.bar ?
10.5.88.3
.foo.bar
zone
10.5.88.3

DNS Tools
 BIND is the defacto DNS server under Unix
 https://www.isc.org
 DIG is the defacto DNS debugger under Unix
 nslookup is old, and nowadays unmaintained, use dig
 libc is the defacto DNS resolver under Unix
 <resolv.h> and the well known gethostbyname()/getaddrinfo()
 It makes use of the /etc/resolv.conf file to find DNS servers to query
 https://www.zonemaster.net - http://dnsviz.net
 DNS brute force tools : dnsrecon / subbrute
 DNS helpers : dnstop / dnswalk

A real example
 I'm linked at home with other peers through private VPN
 jp : me
 uf : Ulysse
 Instead of learning each other network's IP addresses, we
managed to setup 2 delegations
 jp.vpn : delegated to jp, slave uf
 uf.vpn : delegated to uf , salves jp
 The TLD .vpn is publicly unused (but the contrary wouldn't
hurt much)

jp
Internet
VPN
VPN
srv.jp.vpn
JP

JP example
 I need a recursive server
 Because I want to use it as my DNS server, for my home network
 I need to have it safe from the Internet
 I need to be authoritative on jp.vpn. , this is my zone
 I thus need to declare a zone file in BIND
 I need to sync, as a slave, zones from uf.vpn.
 I will then be able to access my peers machines by resolving their
names localy
 I also need to allow transfer of my jp.vpn. zone to my peer,
so that he will be able to query my hosts localy and serve as
replicates

Put some BIND config
options {
directory "/var/cache/bind";
version "Guess";
recursion yes;
allow-transfer { none; };
dnssec-validation auto;
allow-query { "private"; };
notify yes;
auth-nxdomain no; # conform to RFC1035
listen-on { any; };
};
zone "jp.vpn" {
type master;
allow-transfer { "private"; };
file "/etc/bind/zones/db.vpn";
forwarders {};
};
zone "." {
type hint;
file "/etc/bind/db.root";
};

db.jp.vpn configuration
$TTL 604800
$ORIGIN jp.vpn.
@ IN SOA srv admin.srv (
3 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS srv
srv IN A 192.168.0.1
gaming IN A 192.168.0.4
nas IN A 192.168.0.2
mkt IN A 192.168.0.254
obs IN CNAME srv
stat IN CNAME srv
nd IN CNAME srv

BIND documentation ?
 Every information about BIND and the DNS is here :
http://www.zytrax.com/books/dns/

Zone configuration detailed
 $TTL gives the default TTL of any entry that does not
overwrite it (common use-case)
 $ORIGIN is the delegated zone. Every '@' refers to it , every
name not ended by a point "." will refer to $ORIGIN
 A fully qualified name must end with a point
 This is a pretty common mistake done in bind configuration
$TTL 604800
$ORIGIN jp.vpn.

 owner-name ttl class rr name-server email
$TTL 604800
$ORIGIN jp.vpn.

 "jp.vpn. with TTL 604800 of class INternet has an SOA (Start
Of Authority) delegated by srv.jp.ovpn. and managed by
admin@srv.jp.vpn."
 In email address of zone contact, '@' is replaced by a dot
 That's the way of doing things !
 A SOA resource record is mandatory ! You declare yourself as
being authoritative on a dedicated zone
$TTL 604800
$ORIGIN jp.vpn.

 It's serial number is 3 (used for slave sync)
 slaves should try to refresh the zone every 604800s
 If slaves fail to contact master, they should retry after 86400s
 The zone expires after 2419200s , slaves should stop
responding after this time if they did not refresh from master
 If a negative answer is given its cache is 604800s
$TTL 604800
$ORIGIN jp.vpn.
@ IN SOA srv admin.srv (3 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL

 @ replaces the $ORIGIN
 jp.vpn. is managed by the srv.jp.vpn. name server
 srv.jp.vpn. is at 192.168.0.1
 obs.jp.vpn. is an alias of srv.jp.vpn. and will have IP 192.168.0.
... ...
@ IN NS srv
srv IN A 192.168.0.1
obs IN CNAME srv

Slave zones
zone "uf.vpn" {
type slave;
masters { 10.1.2.1; };
forwarders {};
};

Let's dig it
dig foo.jp.vpn @192.168.0.1
; <<>> DiG 9.10.3-P4-Ubuntu <<>> foo.jp.vpn @192.168.0.1
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 64753
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;foo.jp.vpn. IN A
;; AUTHORITY SECTION:
jp.vpn. 604800 IN SOA srv.jp.vpn. admin.srv.jp.vpn. 3
604800 86400 2419200 604800
;; Query time: 11 msec
;; SERVER: 192.168.0.1#53(192.168.0.1)
;; WHEN: Thu Oct 05 16:38:12 CEST 2017
;; MSG SIZE rcvd: 86

DIG flags and answer details
 qr : always here, means "answer"
 aa : authoritative answer
 rd : recursivity demanded
 ra : recursive answer
 status : NXDOMAIN == "no such domain" == "foo.jp.vpn
doesn't exist"
;; Got answer:

Authoritative ?
;; Got answer:
dig dl.free.fr @192.168.0.1
; <<>> DiG 9.10.3-P4-Ubuntu <<>> dl.free.fr @192.168.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32392
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 2, ADDITIONAL: 3

Recursive ?
 By asking an iterative query on a non-authority server, this
one will NOT recursively resolve.
 It will answer what it can : the next NS found
dig dl.free.fr @192.168.0.1 +norecurse
; <<>> DiG 9.10.3-P4-Ubuntu <<>> dl.free.fr @192.168.0.1 +norecurse
;; Got answer:
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 3
free.fr. 85526 IN NS freens2-g20.free.fr.

Recursive ?
 Now recursive : we got our answer
;; Got answer:
;; ANSWER SECTION:
dl.free.fr. 85763 IN A 212.27.63.45
dl.free.fr. 85763 IN A 212.27.63.32

Let's ask for a trace
 Let's trace all the resolution process
dig dl.free.fr @192.168.0.1 +trace
. 261197 IN NS g.root-servers.net.
. 261197 IN NS e.root-servers.net.
;; Received 525 bytes from 192.168.0.1#53(192.168.0.1) in 40 ms
fr. 172800 IN NS e.ext.nic.fr.
fr. 172800 IN NS d.nic.fr.
;; Received 730 bytes from 192.112.36.4#53(g.root-servers.net) in 36 ms
;; Received 614 bytes from 192.5.4.2#53(d.ext.nic.fr) in 51 ms
dl.free.fr. 86400 IN A 212.27.63.35
dl.free.fr. 86400 IN A 212.27.63.32

DNS caches
 Each zone answer is cached.
 The first DNS query for dl.free.fr will go to the root
 Root gives .fr server address
 The server then now memorize .fr server address and will
reuse it for any further .fr resolution
 Thus, the root server will NOT be queried again for any .fr
further query
 etc .... , recursively

DNS resolution caching
 As a tree, the DNS resolution mechanism can cache the
closest branch information and reuse it
 Example : you ask for baz.foo.bar.com
 If you asked before for hello.wow.bar.com
 Your DNS server will start resolution from the bar.com NS zone
 If you asked before for wow.foo.bar.com
 Your DNS server will start resolution from foo.bar.com NS zone
 If you asked before for hello.com
 Your DNS server will start resolution from com NS zone

Dumping / flushing cache
 Generating and dumping the cache
 Flushing cache
> rndc dumpdb -cache
> cat /var/cache/bind/named_dump.db
> rndc flush && rndc reload

Multiple records and perfs
 Often, DNS is used as a basic Round Robin load balancer
;; Got answer:
;; ANSWER SECTION:
dl.free.fr. 85763 IN A 212.27.63.45
dl.free.fr. 85763 IN A 212.27.63.32

Multiple records and perfs
 For iterative resolution, measures are performed by the
server to ask the best responsive server among the full list
dig dl.free.fr @192.168.0.1 +trace
. 513067 IN NS i.root-servers.net.
. 513067 IN NS m.root-servers.net.
. 513067 IN NS h.root-servers.net.
. 513067 IN NS a.root-servers.net.
. 513067 IN NS b.root-servers.net.
. 513067 IN NS f.root-servers.net.
. 513067 IN NS c.root-servers.net.
. 513067 IN NS d.root-servers.net.
. 513067 IN NS g.root-servers.net.
. 513067 IN NS j.root-servers.net.
. 513067 IN NS l.root-servers.net.
. 513067 IN NS k.root-servers.net.

Then ?
 DNS is not very hard as soon as you understand its structure,
and why it's been designed
 Take however care about security
 DNS has not been designed when security issues were in minds
 Thus, vanilla DNS is pretty unsecure
 No validation of hosts, of answers, no limits, no encryption, etc...
 DNSSEC tries to answer some problems (also DNS over TLS)
 Some other tools as well (BIND RPZ)
 Don't jump into DNS without clearly knowing security risks
 Do not open a recursive server to the world, it will be used as
an attack vector in worldwide DNS attacks

Then ?
 Try to start by setting up your own recursive server
 Read bind doc ! http://www.zytrax.com/books/dns/
 Trust it more than any server you used to use before
 Your ISP server can lie, and can record any query you pass
 Privacy of your information ?
 Using your own recursive server is like keeping your day-to-day
surf for yourself
 Say bye bye to 8.8.8.8, 1.1.1.1 or 9.9.9.9 : DIY
 Internet is decentralized, don't centralize it if you can prevent that

And after ?
 After you can experiment managing your own zone and
delegations
 You buy a domain, and you fully manage it
 Instead of letting it done by your registrar

Ha , and to sum things up
 https://www.youtube.com/watch?v=oN7ripK5uGM

Dns

More Related Content

What's hot

Similar to Dns

More from julien pauli

Recently uploaded

Dns