3. DNS
Basics
• DNS
converts
names
(www.icann.org)
to
numbers
(192.0.32.7)
• ..to
idenOfy
services
such
as
www
and
e-‐mail
• ..that
idenOfy
and
link
customers
to
business
and
visa
versa
4. Reminder:
DNS
Resolving
Question:
www.example.net A
1" 2"
www.example.net A ?
Resolver
www.example.net A ?
Caching
forwarder
(recursive)
“go ask net server @ X.gtld-servers.net”
(+ glue)
gtld-server
www.example.net A ?
“go ask ripe server @ ns.example.net”
(+ glue)
www.example.net A ?
example-server
“x.y.z.1”
x.y.z.1
3"
4"
5"
6"
7"
9"
8"
Add to cache
10" TTL
root-server
5. DNS:
Data
Flow
master Caching forwarder
Zone administrator
Zone file
Dynamic
updates
1"
2"
3"
slaves
4"
5"
resolver
6. DNS
VulnerabiliOes
Corrupting data" Impersonating master"
Cache impersonation"
master Caching forwarder
Zone
administrator
Zone file
Dynamic
updates
1"
2"
3"
slaves
4"
5"
resolver
Unauthorized updates"
Cache pollution by"
Data spoofing"
Server protection! Data protection!
8. Where
DNSSEC
fits
in
• ..but
CPU
and
bandwidth
advances
make
legacy
DNS
vulnerable
to
MITM
aWacks
• DNS
Security
Extensions
(DNSSEC)
introduces
digital
signatures
into
DNS
to
cryptographically
protect
contents
• With
DNSSEC
fully
deployed
a
business
can
be
sure
a
customer
gets
un-‐modified
data
(and
visa
versa)
9. The
Bad:
DNSChanger
-‐
‘Biggest
Cybercriminal
Takedown
in
History’
–
4M
machines,
100
countries,
$14M
Nov
2011
h[p://krebsonsecurity.com/2011/11/malware-‐click-‐fraud-‐kingpins-‐arrested-‐in-‐estonia/
End-‐2-‐end
DNSSEC
valida_on
would
have
avoided
the
problems
10. The
Internet’s
Phone
Book
-‐
Domain
Name
System
(DNS)
www.majorbank.se=?
Get page
webserver
www @
1.2.3.4
Username / Password
Account Data
DNS Hierarchy
DNS
Resolver
root
se com
majorbank.se
www.majorbank.se
www.majorbank.se = 1.2.3.4
DNS
1.2.3.4 Server
Login page
ISP
Majorbank (Registrant)
11. Caching
Responses
for
Efficiency
www.majorbank.se=?
Get page
webserver
www @
1.2.3.4
Username / Password
Account Data
DNS
Resolver
www.majorbank.se = 1.2.3.4
DNS
1.2.3.4 Server
Login page
12. The
Problem:
DNS
Cache
Poisoning
AWack
www.majorbank.se=? DNS
Resolver
www.majorbank.se = 1.2.3.4
DNS
5.6.7.8 Server
Get page Attacker
webserver
www @
5.6.7.8
Username / Password
Error
Attacker
www.majorbank.se = 5.6.7.8
Login page
Password database
13. Argghh!
Now
all
ISP
customers
get
sent
to
aWacker.
www.majorbank.se=? DNS
Resolver
www.majorbank.se = 1.2.3.4
DNS
5.6.7.8 Server
Get page Attacker
webserver
www @
5.6.7.8
Login page
Username / Password
Error
Password database
14. Securing
The
Phone
Book
-‐
DNS
Security
Extensions
(DNSSEC)
www.majorbank.se=? DNS
Resolver
with
DNSSEC
Attacker’s record does not
validate – drop it
www.majorbank.se = 1.2.3.4
DNS
Server with
DNSSEC
1.2.3.4
Get page
webserver
www @
1.2.3.4
Login page
Username / Password
Account Data
Attacker
www.majorbank.se = 5.6.7.8
15. Resolver
only
caches
validated
records
www.majorbank.se=? DNS
Resolver
with
DNSSEC
www.majorbank.se = 1.2.3.4
DNS
Server with
DNSSEC
1.2.3.4
Get page
webserver
www @
1.2.3.4
Login page
Username / Password
Account Data
16. The
Bad:
Other
DNS
hijacks*
• 25
Dec
2010
-‐
Russian
e-‐Payment
Giant
ChronoPay
Hacked
• 18
Dec
2009
–
Twi[er
–
“Iranian
cyber
army”
• 13
Aug
2010
-‐
Chinese
gmail
phishing
a[ack
• 25
Dec
2010
Tunisia
DNS
Hijack
• 2009-‐2012
google.*
– April
28
2009
Google
Puerto
Rico
sites
redirected
in
DNS
a[ack
– May
9
2009
Morocco
temporarily
seize
Google
domain
name
• 9
Sep
2011
-‐
Diginotar
cer_ficate
compromise
for
Iranian
users
• SSL
/
TLS
doesn't
tell
you
if
you've
been
sent
to
the
correct
site,
it
only
tells
you
if
the
DNS
matches
the
name
in
the
cer_ficate.
Unfortunately,
majority
of
Web
site
cer_ficates
rely
on
DNS
to
validate
iden_ty.
• DNS
is
relied
on
for
unexpected
things
though
insecure.
*A
Brief
History
of
DNS
Hijacking
-‐
Google
h[p://costarica43.icann.org/mee_ngs/sanjose2012/presenta_on-‐dns-‐hijackings-‐marquis-‐boire-‐12mar12-‐en.pdf
17. The
Business
Case
for
DNSSEC
• Cyber
security
is
becoming
a
greater
concern
to
enterprises,
government,
and
end
users.
DNSSEC
is
a
key
tool
and
differenOator.
• DNSSEC
is
the
biggest
security
upgrade
to
Internet
infrastructure
in
over
20
years.
It
is
a
pla`orm
for
new
security
applicaOons
(for
those
that
see
the
opportunity).
• DNSSEC
infrastructure
deployment
has
been
brisk
but
requires
experOse.
Gecng
ahead
of
the
curve
is
a
compeOOve
advantage.
18. •
DNSSEC
-‐
Where
we
are
Deployed
on
462/654
TLDs
(29
July
2014
70%
.com
.hr
.es
.in
.af
.ee
.lb
.bg
.tm
.cz
.nl
.uk
.de
.jp
.cn
.ru
.р
ф
.my
مليسيا
.asia
.tw
台灣,
.kr
한국 .net,
.org,
.post,
+gtlds)
• Root
signed**
and
audited
• Required
in
new
gTLDs.
Basic
support
by
ICANN
registrars
• Growing
ISP
support*.
• 3rd
party
signing
soluOons***
• Growing
S/W
H/W
support:
NLNetLabs,
ISC,
Microsop,
PowerDNS,
Secure64…?
openssl,
pos`ix,
XMPP,
mozilla:
early
DANE
support
• IETF
standard
on
DNSSEC
SSL
cerOficates
(RFC6698)
• Growing
support
from
major
players…(Apple
iPhone/iPad,
Google
8.8.8.8,…)
*
COMCAST
/w
20M
and
others;
most
ISPs
in
SE
,CZ.
AND
~12%
of
resolvers
validate
using
DNSSEC
**Int’l
bo[om-‐up
trust
model
/w
21
TCRs
from:
TT,
BF,
RU,
CN,
US,
SE,
NL,
UG,
BR,
Benin,
PT,
NP,
Mauri_us,
CZ,
CA,
JP,
UK,
NZ…
***
Par_al
list
of
registrars:
h[ps://www.icann.org/en/news/in-‐focus/dnssec/deployment
19. But…
• But
deployed
on
~1-‐2%
(3.5M)
of
2nd
level
domains.
Many
have
plans.
Few
have
taken
the
step
(e.g.,
yandex.com,
paypal.com*,
comcast.com).
• DNSChanger
and
other
aWacks
highlight
today’s
need.
(e.g
end-‐2-‐end
DNSSEC
validaOon
would
have
avoided
the
problems)
• InnovaOve
security
soluOons
(e.g.,
DANE)
highlight
tomorrow’s
value.
*
h[p://fedv6-‐deployment.antd.nist.gov/cgi-‐bin/generate-‐com
h[p://www.thesecurityprac_ce.com/
the_security_prac_ce/2011/12/all-‐paypal-‐domains-‐are-‐now-‐using-‐dnssec.html
h[p://www.nacion.com/2012-‐03-‐15/Tecnologia/Si_os-‐web-‐de-‐bancos-‐_cos-‐podran-‐ser-‐mas-‐seguros.aspx
20. DNSSEC:
So
what’s
the
problem?
• Not
enough
IT
departments
know
about
it
or
are
too
busy
pucng
out
other
security
fires.
• When
they
do
look
into
it
they
hear
old
stories
of
lack
of
turnkey
soluOons.
•
Registrars*/DNS
providers
see
no
demand
leading
to
“chicken-‐and-‐egg”
problems.
*but
required
by
new
ICANN
registrar
agreement
21. Too
many
CAs.
Which
one
can
we
trust?
DNSSEC
to
the
rescue….
CA
CerOficate
roots
~1482
DNSSEC
root
-‐
1
Login
security
SSHFP
RFC4255
Content
security
Commercial
SSL
CerOficates
for
Web
and
e-‐mail
DANE
and
other
yet
to
be
discovered
security
innovaOons,
enhancements,
and
synergies
Content
security
“Free
SSL”
cerOficates
for
Web
and
e-‐mail
and
“trust
agility”
Network
security
IPSECKEY
RFC4025
Cross-‐
organizaOonal
and
trans-‐naOonal
idenOty
and
authenOcaOon
E-‐mail
security
DKIM
RFC4871
Securing
VoIP
Domain
Names
hWps://www.eff.org/observatory
hWp://royal.pingdom.com/2011/01/12/internet-‐2010-‐in-‐numbers/
22. • For
What
you
can
do
Companies:
– Sign
your
corporate
domain
names
– Just
turn
on
validaOon
on
corporate
DNS
resolvers
• For
Users:
– Ask
ISP
to
turn
on
validaOon
on
their
DNS
resolvers
• For
All:
– Take
advantage
of
organizaOons
offering
DNSSEC
educaOon
and
training
24. DNSSEC
Resource
Records
• 3
Public
key
crypto
related
RRs
– RRSIG
=
Signature
over
RRset
made
using
private
key
– DNSKEY
=
Public
key,
needed
for
verifying
a
RRSIG
– DS
=
DelegaOon
Signer;
‘Pointer’
for
building
chains
of
authenOcaOon
• One
RR
for
internal
consistency
– NSEC
=
Next
Secure;
indicates
which
name
is
the
next
one
in
the
zone
and
which
typecodes
are
available
for
the
current
name
• authenOcated
non-‐existence
of
data
RFC
4034
25. DNSKEY
• Contains
the
zone’s
public
key
• Uses
public
key
cryptography
to
sign
and
authenOcate
DNS
resource
record
sets
(RRsets).
• Example:
myzone.net. IN DNSKEY 256 3 5
( AwEAAagrVFd9xyFMQRjO4DlkL0dgUCtogviS+FG9Z6Au3h1ERe4EIi3L
X49Ce1OFahdR2wPZyVeDvH6X4qlLnMQJsd7oFi4S9Ng+hLkgpm/n+otE
kKiXGZzZn4vW0okuC0hHG2XU5zJhkct73FZzbmBvGxpF4svo5PPWZqVb
H48T5Y/9 ) ; key id = 3510
Public
key
(base64)
26. RRSIG
• The
private
part
of
the
key-‐pair
is
used
to
sign
the
resource
record
set
(RRset)
per
zone
• The
digital
signature
per
RRset
is
saved
in
an
RRSIG
record
myzone.net. 86400 NS ns.myzone.net.
86400 NS ns.yourzone.net.
86400 RRSIG NS 5 2 86400 (
20121202010528 20121102010528 3510
myzone.net.
Y2J2+CVqQRjQvcWY256ffiw5mp0OQTQUF8vUHSHyUbbhmE56eJimqDh
Xb8qwlFjl40kmlzmQC5CmgugBqjgLHZbuvSfd9+Ucwkxbwx3HonAPr3
+0HVqP8rSqGRqSq0VbR7LzNeaylBkumLDoriQxceV4z3d2jFv4ArnM=
)
27. Types
of
Keys
• Zone
Signing
Key
(ZSK)
– Sign
the
RRsets
within
the
zone
– Public
key
of
ZSK
is
defined
by
a
DNSKEY
RR
• Key
Signing
Key
(KSK)
– Signed
the
keys
which
includes
ZSK
and
KSK
and
may
also
be
used
outside
the
zone
• Using
a
single
key
or
both
keys
is
an
operaOonal
choice
(RFC
allows
both
methods)
29. DelegaOon
Signer
(DS)
• Establishes
the
chain
of
trust
from
parent
to
child
zones
• Found
in
the
parent’s
zone
file
• In
this
example,
myzone.net
has
been
delegated
from
.net.
This
is
how
it
looks
like
in
.net
zone
file
myzone.net. IN NS ns1.myzone.net.
NS ns2.myzone.net.
IN DS 19996 5 1 (
CF96B018A496CD1A68EE7
C80A37EDFC6ABBF8175 )
IN DS 19996 5 2 (
6927A531B0D89A7A4F13E11031
4C722EC156FF926D2052C7D8D70C50
14598CE9 )
30. DelegaOon
Signer
(DS)
• DelegaOon
Signer
(DS)
RR
indicates
that:
– delegated
zone
is
digitally
signed
– indicated
key
is
used
for
the
delegated
zone
• Parent
is
authoraOve
for
the
DS
of
the
childs
zone
– Not
for
the
NS
record
delegaOng
the
childs
zone!
– DS
should
not
be
in
the
childs
zone
31. DNSSEC
ValidaOon
• Recursive
servers
that
are
dnssec-‐enabled
can
validate
signed
zones
• The
AD
bit
in
the
message
flag
shows
if
validated
• Other
opOons
if
you
don’t
have
a
validaOng
resolver
– Use
a
validator
add-‐on
for
your
web
browser
• ex:
hWps://www.dnssec-‐validator.cz/
– Online
web
tools
• hWp://dnsviz.net/
• hWp://dnssec-‐debugger.verisignlabs.com/
– Use
an
open
DNSSEC-‐validaOng
resolver
• Some
open
validaOng
resolvers
– DNS-‐OARC’s
ODVR
(link)
• 149.20.64.20
(BIND9),
149.20.64.21
(Unbound)
– Google
Public
DNS
• 8.8.8.8
or
8.8.4.4
32. DNSSEC
-‐
Secng
up
a
Secure
Zone
• Enable
DNSSEC
in
the
configuraOon
file
(named.conf)
dnssec-enable yes;
dnssec-validation yes;
• Create
key
pairs
(KSK
and
ZSK)
dnssec-keygen -a rsasha1 -b 1024 -n zone
myzone.net
• Publish
your
public
key
• Signing
the
zone
• Update
the
config
file
– Modify
the
zone
statement,
replace
with
the
signed
zone
file
• Test
with
dig
33. Signing
the
Zone
• Sign the zone using the secret keys:
dnssec-signzone –o <zonename> -N INCREMENT
-f <output-file> -k <KSKfile> <zonefile>
<ZSKfile>
dnssec-signzone –o myzone.net
db.myzone.net Kmyzone.net.+005+33633
• Once
you
sign
the
zone
a
file
with
a
.signed
extension
will
be
created
– db.myzone.net.signed
34. TesOng
with
dig:
an
example
dig @localhost www.apnic.net +dnssec +multiline
35. Pushing
the
DS
record
• The
DS
record
must
be
published
by
the
parent
zone.
• Contact
the
parent
zone
to
communicate
the
KSK
to
them.
36. Ways
to
Deploy
DNSSEC
• As
part
of
the
DNS
sopware
used
– Manual
key
management
– Can
be
quite
complex
– For
staOc
environment
– Some
means
of
automaOon
using
• opOon
commands
and
scripts
• Use
DNSSEC
tools
for
BIND,
NSD,
PowerDNS,
etc
with
a
hardware
security
module
(HSM)
– Semi-‐automaOc
– Good
for
dynamic
environment
• Using
an
external
appliance
– ‘dnssec-‐in-‐a-‐box’
– Fully
HSM,
OpenDNSSEC
DNS
Appliance
automates
key
generaOon,
signing
and
rollover