DNSSEC  Tutorial  champika.wijayatunga@icann.org  

Acknowledgements    

•  Rick  Lamb  – Senior  Program  Manager,  DNSSEC  @ICANN  

•  APNIC  Training  

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  

Reminder:  DNS  Resolving  

Resolver

Question:

www.example.net A

www.example.net A ?

Caching forwarder (recursive)

www.example.net A ?

“go ask net server @ X.gtld-servers.net” (+ glue)

gtld-server www.example.net A ?

“go ask ripe server @ ns.example.net” (+ glue)

example-server

www.example.net A ?

“x.y.z.1”

x.y.z.1

1" 2"

3"

4"

5"

6"

7"

Add to cache 9"

8"

10" TTL

root-server

DNS:  Data  Flow  

master Caching forwarder

Zone administrator

Zone file

Dynamic updates

1"

2"

slaves

3"

4"

5"

resolver

DNS  VulnerabiliOes  

master Caching forwarder

Zone  administrator

Zone file

Dynamic updates

1"

2"

slaves

3"

4"

5"

resolver

Server protection! Data protection!

Corrupting data" Impersonating master"

Unauthorized updates"

Cache impersonation"

Cache pollution by"Data spoofing"

lamb@

xtcn.com

 +1-­‐202-­‐709-­‐5262            VoIP  

mydomainname.com  

DNS  is  a  part  of  all  IT  ecosystems    US-­‐NSTIC  effort  

Smart  Electrical  Grid  

OECS  ID  effort  

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)  

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  

The  Internet’s  Phone  Book  -­‐  Domain  Name  System  (DNS)  

www.majorbank.se=?

Get page webserverwww @ 1.2.3.4

Username / Password Account Data

DNS Hierarchy

se com

root

majorbank.se

www.majorbank.se

DNS Resolver

www.majorbank.se = 1.2.3.4 DNS Server 1.2.3.4

Login page

ISP   Majorbank (Registrant)  

Caching  Responses  for  Efficiency  

www.majorbank.se=?

Get page webserverwww @ 1.2.3.4

Username / Password Account Data

DNS Resolver

www.majorbank.se = 1.2.3.4 DNS Server 1.2.3.4

Login page

The  Problem:    DNS  Cache  Poisoning  AWack  

www.majorbank.se=? DNS Resolver

www.majorbank.se = 1.2.3.4 DNS Server 5.6.7.8

Get page Attacker webserverwww @ 5.6.7.8

Username / Password Error

Attacker www.majorbank.se = 5.6.7.8

Login page

Password database

Argghh!  Now  all  ISP  customers  get  sent  to  aWacker.  

www.majorbank.se=? DNS Resolver

www.majorbank.se = 1.2.3.4 DNS Server 5.6.7.8

Get page Attacker webserverwww @ 5.6.7.8

Username / Password Error

Login page

Password database

Securing  The  Phone  Book  -­‐  DNS  Security  Extensions  (DNSSEC)  

www.majorbank.se=? DNS Resolver with DNSSEC

www.majorbank.se = 1.2.3.4 DNS Server with DNSSEC

1.2.3.4

Get page webserverwww @ 1.2.3.4

Username / Password Account Data

Login page

Attacker www.majorbank.se = 5.6.7.8

Attacker’s record does not validate – drop it

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 webserverwww @ 1.2.3.4

Username / Password Account Data

Login page

The  Bad:  Other  DNS  hijacks*  

*A  Brief  History  of  DNS  Hijacking  -­‐  Google  h[p://costarica43.icann.org/mee_ngs/sanjose2012/presenta_on-­‐dns-­‐hijackings-­‐marquis-­‐boire-­‐12mar12-­‐en.pdf  

•  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.  

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.  

•   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,…)  

DNSSEC  -­‐  Where  we  are  

**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  

*  COMCAST  /w  20M  and  others;  most  ISPs  in  SE  ,CZ.    AND    ~12%  of  resolvers  validate  using  DNSSEC  

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  

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  

Too  many  CAs.  Which  one  can  we  trust?  DNSSEC  to  the  rescue….  

CA  CerOficate  roots  ~1482  

Login  security  SSHFP  RFC4255  

DANE  and  other  yet  to  be  discovered  security  innovaOons,  enhancements,  and  synergies  

Content  security  Commercial  SSL  CerOficates  for  Web  and  e-­‐mail  

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  

DNSSEC  root  -­‐  1  

Domain  Names  

Securing  VoIP  

hWps://www.eff.org/observatory  hWp://royal.pingdom.com/2011/01/12/internet-­‐2010-­‐in-­‐numbers/  

•  For  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  

What  you  can  do  

DNSSEC  ImplementaOon  

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  

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)  

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+CVqQRjQvcWY256ffiw5mp0OQTQUF8vUHSHyUbbhmE56eJimqDhXb8qwlFjl40kmlzmQC5CmgugBqjgLHZbuvSfd9+Ucwkxbwx3HonAPr3+0HVqP8rSqGRqSq0VbR7LzNeaylBkumLDoriQxceV4z3d2jFv4ArnM= )

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)  

NSEC  Record  example  $ORIGIN myzone.net.!@!SOA …!

! !NS !NS.myzone.net.!

! !DNSKEY !…!! !NSEC mailbox.myzone.net. SOA NS NSEC DNSKEY RRSIG!

!

mailbox !A !192.168.10.2 !!! ! !NSEC www.myzone.net. A NSEC RRSIG!

WWW ! !A !192.168.10.3 !!

! ! !TXT !Public webserver!

! ! !NSEC myzone.net. A NSEC RRSIG TXT!

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 )

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  

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  

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    

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

TesOng  with  dig:  an  example  dig @localhost www.apnic.net +dnssec +multiline

Pushing  the  DS  record  

•  The  DS  record  must  be  published  by  the  parent  zone.  

•  Contact  the  parent  zone  to  communicate  the  KSK  to  them.  

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  with  a  hardware  security  module  (HSM)  

–  Semi-­‐automaOc    –  Good  for  dynamic  environment  

•  Using  an  external  appliance    –  ‘dnssec-­‐in-­‐a-­‐box’  –  Fully  automates  key  generaOon,  signing  and  rollover    

DNSSEC  tools  for  BIND,    NSD,  PowerDNS,  etc  

HSM,    OpenDNSSEC  

DNS  Appliance  

DNSSEC:  Internet  infrastructure  upgrade  to  help  address  today’s  needs  and  create  tomorrow’s  opportunity.  

Thank  you!