DNS/DNSSEC

 Workshop  
Jakarta,  Indonesia  
19-­‐20  December  2014  
 
Hosted  by  PANDI  
 
Presenters
•  Champika  Wijayatunga  
–  Security  Engagement  Manager  (APAC)  –  ICANN  
     [email protected]  
 
 
 
 
Acknowledgements
•  Dave  Piscitello,  ICANN  
•  Rick  Lamb,  ICANN  
•  Mauricio  Vergara,  ICANN  
•  Bill  Manning  
•  APNIC,  NSRC,  ISOC  
Agenda
•  Day  1  
–  DNS  Concepts  
–  BIND  configuraOons  
–  Recursive  Servers  
–  AuthoritaOve  Name  Servers  
–  Zone  delegaOons  

•  Day  2  
–  DNS  Security  
–  DNSSEC  
–  Key  management  
–  TroubleshooOng  
Brief  Overview  of    
the  DNS
 
 

5  
 The World’s Network – the Domain Name System

+ Internet Protocol numbers are unique addresses

that allow computers to find one another
+ The Domain Name System matches IP numbers
with a name
+ DNS is the underpinning of unified Internet
+ DNS keeps Internet secure, stable and
interoperable
+ ICANN was formed in 1998 to coordinate DNS

6
 Functions that ICANN Coordinates

+ Domain Name System (DNS)

+ Internet Protocol (IP) Address Allocation
+ Protocol-Parameter Registry
+ Root Server Systems
+ Generic Top-Level Domain Names (gTLD) system
management
+ Country-code Top-Level Domain Name (ccTLD)
DNS
+ Time Zone Database Management

7
What is the Domain Name System?
A  distributed  database  primarily  used  to  obtain  the  
 
IP  address,  a  number,  e.g.,    
192.168.23.1  or  fe80::226:bbff:fe11:5b32  
 
that  is  associated  with  a  
 
user-­‐friendly  name  (www.example.com)  
 
Why  do  we  need  a  DNS?  
 It’s  hard  to  remember  lots  of  four  decimal  numbers  
and  it’s  impossibly  hard  to  remember  hexadecimal  ones  
 

8  
What is a domain?
•  A  domain  is  a  node  in  the  Internet  name  space  
–  A  domain  includes  all  its  descendants  
•  Domains  have  names  
–  Top-­‐level  domain  (TLD)  names  are  generic  or  country-­‐specific  
–  TLD  registries  administer  domains  in  the  top-­‐level    
–  TLD  registries  delegate  labels  beneath  their  top  level  delegaOon  
.
org gov com ... AF ... ZW
icann ncfta irs ftc google msn co
www ssac google
Names in generic Top Level Domains Names in country-code TLDs

9  
Root Servers
 L-Root
+ Geographical diversity via Anycast
+ Around 160 dedicated servers
+ Presence on every continent
+ On normal basis 15 ~ 25 kqps
+ That is app 2 billion DNS queries a day

11
 L-Root presence

12
 L-Root stats

13
 What is the New gTLD Program?

largest-ever expansion global restructuring

of the domain name system

Internationalized Domain
Names and non Latin-based innovation
characters

Managed by ICANN =
security and
multistakeholder input
stability

14
 What are the benefits?

• Enhance competition, innovation and choice

Choice in the Domain Name space
• Increase competition among current
Registries, Registrars
• Allow new companies to enter the market
Innovation
• Greater diversity in regions participating
• Enhanced security

Competition

15
 1930total
number of applications received

911 675
North America Europe

24
South America 17 303
Africa
Asia Pacific

16
Domain name registration 101
How to register a domain:
•  Choose a string e.g., example!
•  Visit a registrar to check string
availability in a TLD
•  Pay a fee to register the name
•  Submit registration information
•  Registrar and registries manage:
–  “string” + TLD
(managed in registry DB)
–  Contacts, DNS
(managed in Whois)
–  DNS, status
(managed in Whois DBs)
–  Payment information

17  
 OperaOonal  elements  of  the  DNS  
•  AuthoritaOve  Name  Servers  host  zone  data  
–  The  set  of  “DNS  data”  that  the  registrant  publishes  
•  Recursive  Name  Resolvers  (“resolvers”)  
–  Systems  that  find  answers  to  queries  for  DNS  data  
•  Caching  resolvers  
–  Recursive  resolvers  that  not  only  find  answers  but  also  
store  answers  locally  for  “TTL”  period  of  Ome    
•  Client  or  “stub”  resolvers  
–  Soeware  in  applicaOons,  mobile  apps  or  operaOng  
systems  that  query  the  DNS  and  process  responses  

18
DNS:  Internet’s  directory  assistance  
•  Client  “stub”  resolvers     What  is  the  IPv6  
ask  quesOons   address  for  
www.icann.org?  
–  Soeware  in  applicaOons,  
mobile  apps  or  operaOng  
systems  that  issue  DNS  
queries  and  process  
responses  

•  Recursive  name  resolvers  

find  answers  to  queries  
I’ll  find  that  
for  DNS  data   answer  for  you  
dns1.icann.org

19
Domain  name  “directory  assistance”  
How  does  a  resolver  find  the  IP  address  of  ICANN.ORG?  
•  Resolvers  find  answers  by  asking  quesOons  iteraJvely  
m.root-servers.net
Here’s  a  list  of  ORG  
TLD  name  servers.      
Ask  root  name  servers  for    
Ask  one  of  these.
IPv6  address  of  ICANN.ORG  

a0.org.afilias-nst.info
Here’s  a  list  of  
ICANN  name  
Ask  a0.org.afilias-­‐nst.info   servers.      
 for  IPv6  address  of   Ask  one  of  these.
dns1.icann.org ICANN.ORG  
The  IPv6  adddress  
of  www.icann.org  
Ask  ns.icann.org  for     2001:500:88:200::7
for  IPv6  address  of  
ICANN.ORG     ns.icann.org

20
 DNS Resource Records (RR)
•  Unit of data in the Domain Name System
•  Define attributes for a domain name
Label! !TTL !Class! Type !Data!
www ! !3600 ! IN ! A! 192.168.0.1!

•  Most common types of RR

o  A
o  AAAA
o  NS
o  SOA
o  MX
o  CNAME
 DNS Resource Record Sets
•  MulOple  RR  with  same  LABEL  and  TYPE  are  
grouped  into  Resource  Record  Sets  (RRsets)  
www ! !A !192.168.0.1!
www ! !A !192.168.10.10!
!
} RRset

mail ! !MX!5 server1.zone.!

mail ! !MX!5 server1.zone.! } RRset

}
!
server2 !A !10.20.30.40!
RRset
!
server1 !AAAA !2001:123:456::1!
server2 !AAAA !2001:123:456::2!
!!
} RRset
What is a DNS zone data?
•  DNS  zone  data  are  hosted  at  
an  authoritaJve  name  server  
•  Each  “cut”  has  zone  data  
(root,  TLD,  delegaOons)      
•  DNS  zones  contain  resource  
records  that  describe  
•  name  servers,  
•   IP  addresses,    
•  Hosts,    
•  Services    
•  Cryptographic     Only  US  ASCII-­‐7  leQers,  digits,  and  hyphens  
keys  &  signatures…   can  be  used  as  zone  data.  
 
 In  a  zone,  IDNs  strings  begin  with  XN-­‐-­‐  

23  
Common  DNS  Resource  Records  
Time to live (TTL)
•  How long RRs are accurate
Start of Authority (SOA) RR
•  Source: zone created here
•  Administrator’s email
•  Revision number of zone file
Name Server (NS)
•  IN (Internet)
•  Name of authoritative server
Mail Server (MX)
•  IN (Internet)
•  Name of mail server
Sender Policy Framework (TXT)
•  Authorized mail senders

24
Common  DNS  Resource  Records  
Name server address record
•  NS1 (name server name)
•  IN (Internet)
•  A (IPv4) * AAAA is IPv6
•  IPv4 address (192.168.0.1)
Web server address record
•  www (world wide web)
•  IN (Internet)
•  A (IPv4) * AAAA is IPv6
IPv4 address (192.168.0.2)
File server address record
•  FTP (file transfer protocol)
•  IN (Internet)
•  CNAME means “same address
spaces and numbers as www”

25
 Where  can  I  get  root  zone  data?  
•  IANA  Root  Zone  Management  
–  hmp://www.iana.org/domains/root/files  

Unrestricted access
(no account required)
26
 What is caching? What  is  the  IPv6  
•  IteraOve  resolvers  may  cache   address  for  
DNS  records  they  receive   icann.org  
from  other  name  servers  as   My Mac
they  process  client  queries  
–  Speeds  up  resoluOon  
–  Saves  bandwidth  
I’ll  cache  this  
–  Responses  are  non-­‐authorita,ve  
response  
•  Are  cached  records  valid  
forever?   My local resolver

–  No.  The  Ome  to  live  (TTL)  field  in  

DNS  records  bounds  how  long  
an  iteraOve  resolver  can  cache  
that  parOcular  record   ICANN’s name
icann.org  
server (authoritative)
AAAA  2001:500:88:200::7  

27
Places where DNS data lives

Changes do not propagate

instantly
Slave
Might take up to ‘refresh’
to get data from master

Not going to net if TTL>0

Upload of zone
data is local policy
Cache server

Master

Slave server
Registry DB
RegistraOon  Data  Directory  Services  
 
Whois
Databases containing records of registrations

•  Domain  Whois   •  Address  Whois  

–  Sponsoring  Registrar   –  Regional  Internet  Registry  
–  Domain  Name  Servers   –  IPv4/v6  address  allocaOon  
–  Domain  Status   –  ASN  allocaOon  
–  CreaOon/Expiry  dates   –  CreaOon/Expiry  dates  
–  Point  of  Contact   –  Point  of  Contact  
–  DNSSEC  data  
29
Questions?

30
DNS  Security  
 
Symmetric vs. Asymmetric Key
Symmetric     Asymmetric  
generally  fast     Can  be  1000  Omes  slower  
Same  key  for  both  encrypOon  and   Uses  two  different  keys  (public  and  
decrypOon   private)  
  DecrypOon  key  cannot  be  calculated  from  
the  encrypOon  key  
Key  lengths:  512  to  4096  bits  
Used  in  low-­‐volume    
 
Hash Functions
•  produces  a  condensed  representaOon  of  a  message  (hashing)  
•  The  fixed-­‐length  output  is  called  the  hash  or  message  digest  
•  A  hash  funcOon  takes  an  input  message  of  arbitrary  length  and  
outputs  fixed-­‐length  code.  The  fixed-­‐length  output  is  called  the  
hash,  or  the  message  digest,  of  the  original  input  message.    
•  A  form  of  signature  that  uniquely  represents  the  data  
•  Uses:    
–  Verifying  file  integrity  -­‐  if  the  hash  changes,  it  means  the  data  is  either  
compromised  or  altered  in  transit.  
–  Digitally  signing  documents  
–  Hashing  passwords    
Hash Functions
•  Message  Digest  (MD)  Algorithm    
–  Outputs  a  128-­‐bit  fingerprint  of  an  arbitrary-­‐length  input  
–  MD4  is  obsolete,  MD5  is  widely-­‐used  
•  Secure  Hash  Algorithm  (SHA)  
–  SHA-­‐1  produces  a  160-­‐bit  message  digest  similar  to  MD5  
–  Widely-­‐used  on  security  applicaOons  (TLS,  SSL,  PGP,  SSH,  S/MIME,  
IPsec)  
–  SHA-­‐256,  SHA-­‐384,  SHA-­‐512  are  also  commonly  used,  which  can  
produce  hash  values  that  are  256,  384,  and  512-­‐bits  respecOvely  
•  RIPEMD  
–  Derived  from  MD4,  but  performs    
–  RIPEMD-­‐160  is  the  most  popular  version    
DNS Security - Background
•  The  original  DNS  protocol  wasn’t  designed  with  security  in  mind  
–  It  has  very  few  built-­‐in  security  mechanism  
•  As  the  Internet  grew  wilder  &  wollier,  IETF  realized  this  would  be  a  
problem  
–  For  example  DNS  spoofing  was  to  easy  
•  DNSSEC  and  TSIG  were  develop  to  help  address  this  problem  
•  Some  security  problems:  
–  Using  reverse  DNS  to  impersonate  hosts  
–  Soeware  bugs  (buffer  overflows,  bad  pointer  handling)  
–  Bad  crypto  (predictable  sequences,  forgeable  signatures)  
–  Cache  poisoning  (purng  inappropriate  data  into  the  
cache)  

https://wiki.tools.isoc.org/DNSSEC_History_Project
 DNS Cache Poisoning

3
1
www.example.com 192.168.1.99
I want to access
www.example.com QID=64569
QID=64570 (pretending to be
the authoritative
QID=64571 match!
zone)
2
QID=64571
Client DNS Caching Root/GTLD
Server

QID=64571
3
www.example.com 192.168.1.1

Webserver
(192.168.1.1) ns.example.com
DNS Amplification
•  A  type  of  reflecOon  amack  combined  with  
amplificaOon  
–  Source  of  amack  is  reflected  off  another  machine  
–  Traffic  received  is  bigger  (amplified)  than  the  
traffic  sent  by  the  amacker  
•  UDP  packet’s  source  address  is  spoofed  
DNS Amplification
Root/GTLD
Queries  for  
www.example.com  

DNS Recursive server

ns.example.com
www.example.com 192.168.1.1

Compromised
Machines
(spoofed IP)

Victim Machine

Attacker
Securing the Nameserver
•  Run  the  most  recent  version  of  the  DNS  soeware  
–  Apply  the  latest  patches  
•  Hide  version  
•  Restrict  queries  
–  Allow-query { acl_match_list; };
•  Prevent  unauthorized  zone  transfers  
–  Allow-transfer { acl_match_list; };
•  Run  BIND  with  the  least  privilege  (use  chroot)  
•  Randomize  source  ports  
–  don’t  use  query-source  opOon  
•  Secure  the  box  
•  Use  TSIG  and  DNSSEC  
TransacOon  Signature  
(TSIG)  
DNS Protocol Vulnerability
•  DNS  data  can  be  spoofed  and  corrupted  between  master  
server  and  resolver  or  forwarder  
•  The  DNS  protocol  does  not  allow  you  to  check  the  validity  of  
DNS  data  
–  Exploited  by  bugs  in  resolver  implementaOon  (predictable  transacOon  
ID)  
–  Polluted  caching  forwarders  can  cause  harm  for  quite  some  Ome  (TTL)  
–  Corrupted  DNS  data  might  end  up  in  caches  and  stay  there  for  a  long  
Ome  
•  How  does  a  slave  (secondary)  know  it  is  talking  to  the  proper  
master  (primary)?  
DNS: Data Flow
Zone administrator
1"
4"
Zone file master Caching forwarder

2"
3" 5"

Dynamic
updates
slaves
resolver
 DNS Vulnerabilities
Corrupting data" Impersonating master"
Cache impersonation"
Zone administrator
1"
4"
Zone file master Caching forwarder

2"
3" 5"

Dynamic
updates
slaves
resolver
Cache pollution by"
Data spoofing"
Unauthorized updates"

Server protection! Data protection!

TSIG Protected Vulnerabilities
Impersonating master"
Zone administrator

Zone file master Caching forwarder

Dynamic
updates
slaves
resolver

Unauthorized updates"
What is TSIG?
•  A  mechanism  for  protecOng  a  message  from  a  primary  to  
secondary  and  vice  versa  
•  A  keyed-­‐hash  is  applied  (like  a  digital  signature)  so  recipient  
can  verify  the  message  
–  DNS  quesOon  or  answer  
–  &  the  Omestamp  
•  Based  on  a  shared  secret  -­‐  both  sender  and  receiver  are  
configured  with  it  
–  TSIG/TKEY  uses  DH,  HMAC-­‐MD5,  HMAC-­‐SHA1,  
HMAC-­‐SHA224,  HMAC-­‐SHA512  among  others  
What is TSIG - Transaction
Signature?
•  TSIG  (RFC  2845)  
–  authorizing  dynamic  updates  &  zone  transfers  
–  authenOcaOon  of  caching  forwarders  
•  Used  in  server  configuraOon,  not  in  zone  file  
TSIG example
verification"

AXFR" AXFR"

Sig ...! Sig ...!

Query: AXFR"

Slave" Master"
KEY:
 KEY:

%sgs!f23fv! %sgs!f23fv!

Response: Zone"
SOA " SOA "
…" …"
SOA" SOA"

Sig ...! Sig ...!

verification"
TSIG steps
1.  Generate  secret  

2.  Communicate  secret  

3.  Configure  servers  

4.  Test  
TSIG - Names and Secrets
•  TSIG  name  
–  A  name  is  given  to  the  key,  the  name  is  what  is  
transmimed  in  the  message  (so  receiver  knows  
what  key  the  sender  used)  

•  TSIG  secret  value  

–  A  value  determined  during  key  generaOon  
–  Usually  seen  in  Base64  encoding  
TSIG – Generating a Secret
•  dnssec-­‐keygen  
–  Simple  tool  to  generate  keys  
–  Used  here  to  generate  TSIG  keys  

> dnssec-keygen -a <algorithm> -b

<bits> -n host <name of the key>!
TSIG – Generating a Secret
•  Example!
> dnssec-keygen –a HMAC-MD5 –b 128 –n HOST ns1-
ns2.pcx.net

This will generate the key

> Kns1-ns2.pcx.net.+157+15921

>ls
Kns1-ns2.pcx.net.+157+15921.key
Kns1-ns2.pcx.net.+157+15921.private
TSIG – Generating a Secret
•  TSIG  should  never  be  put  in  zone  files  
–  might  be  confusing  because  it  looks  like  RR:  

ns1-ns2.pcx.net. IN KEY 128 3 157 nEfRX9…bbPn7lyQtE=!

TSIG – Configuring Servers
•  Configuring  the  key  
–  in  named.conf  file,  same  syntax  as  for  rndc  
–  key { algorithm ...; secret ...;}  
•  Making  use  of  the  key  
–  in  named.conf  file  
–  server x { key ...; }!
–  where  'x'  is  an  IP  number  of  the  other  server  
Configuration Example – named.conf
Primary server 10.33.40.46! Secondary server 10.33.50.35

! !
key ns1-ns2.pcx. net {! key ns1-ns2.pcx.net {!
!algorithm hmac-md5;! !algorithm hmac-md5;!
!secret "APlaceToBe";! !secret "APlaceToBe";!
};! };!
server 10.33.50.35 {! server 10.33.40.46 {!
!keys {ns1-ns2.pcx.net;};! keys {ns1-ns2.pcx.net;};!
};! };!
zone "my.zone.test." {! zone "my.zone.test." {!
!type master;! !type slave;!
!file “db.myzone”;! !file “myzone.backup”;!
!allow-transfer {! !masters {10.33.40.46;};!
!key ns1-ns2.pcx.net ;};! };!
};!

You can save this in a file and refer to it in the named.conf

using ‘include’ statement:
include “/var/named/master/tsig-key-ns1-ns2”;
TSIG Testing : dig
•  You  can  use  dig  to  check  TSIG  configuraOon  
–  dig @<server> <zone> AXFR -k <TSIG keyfile>!

$ dig @127.0.0.1 example.net AXFR \!

-k Kns1-ns2.pcx.net.+157+15921.key!

•  Wrong  key  will  give  “Transfer  failed”  and  on  

the  server  the  security-­‐category  will  log  this.  
TSIG Testing - TIME!
•  TSIG  is  Ome  sensiOve  -­‐  to  stop  replays  
–  Message  protecOon  expires  in  5  minutes  
–  Make  sure  Ome  is  synchronized  
–  For  tesOng,  set  the  Ome  
–  In  operaOons,  (secure)  NTP  is  needed  
TSIG steps
1.  Generate  secret  
–  dnssec-keygen -a <algorithm> -b <bits> -n
host <name of the key>  
2.  Communicate  secret  
–  scp <keyfile> <user>@<remote-server>:<path>  
3.  Configure  servers  
–  key { algorithm ...; secret ...;}  
–  server x { key ...; }  
4.  Test  
–  dig @<server> <zone> AXFR -k <TSIG
keyfile>!
Questions
DNSSEC  
Vulnerabilities Protected by DNSSEC
Cache impersonation"
Zone administrator

Zone file master Caching forwarder

Dynamic
updates
slaves
resolver

Cache pollution by"

Data spoofing"
DNSSEC
•  Protects  the  integrity  of  data  in  the  DNS  by  establishing  
a  chain  of  trust  
•  Uses  public  key  cryptography  –  each  link  in  the  chain  
has  a  public/private  key  pair  
•  A  form  of  digitally  signing  the  data  to  amest  its  validity  
•  Standard  is  defined  in  RFC4033,  RFC4034,  and  RFC4035  
•  Guarantees  
–  AuthenOcity  
–  Integrity   RFC  
–  Non-­‐existence  of  a  domain   4033  
RFC  
4034  
RFC  
4035  
DNSSEC Resource Records RFC  
4034  
•  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  
DNSSEC RRs
•  Data  authenOcity  and  integrity  by  signing  the  
Resource  Records  Sets  with  private  key  

•  Public  DNSKEY  is  used  to  verify  the  RRSIG  

•  Children  sign  their  zones  with  their  private  key  

–  AuthenOcity  of  that  key  established  by  signature/
checksum  by  the  parent  (DS)  
•  Ideal  case:  one  public  DNSKEY  distributed  
RR’s and RRsets
•  Resource  Record:  
Name    TTL      class      type    rdata    
www.example.net.    7200      IN  A    192.168.1.1  

•  RRset:  RRs  with  same  name,  class  and  type:  

www.example.net.  7200  IN    A  192.168.1.1  
           A  10.0.0.3  
           A  172.10.1.1  

•  RRsets  are  signed,  not  the  individual  RRs  

DNSKEY
•  Contains  the  zone’s  public  key  
•  Uses  public  key  cryptography  to  sign  and  
authenOcate  DNS  resource  record  sets  
(RRsets).  
•  Example:   16-bit field flag
Protocol octet
DNSKEY algorithm number
irrashai.net. IN DNSKEY 256 3 5
( AwEAAagrVFd9xyFMQRjO4DlkL0dgUCtogviS
+FG9Z6Au3h1ERe4EIi3L
X49Ce1OFahdR2wPZyVeDvH6X4qlLnMQJsd7oFi4S9Ng+hLkgpm/n+otE
kKiXGZzZn4vW0okuC0hHG2XU5zJhkct73FZzbmBvGxpF4svo5PPWZqVb
H48T5Y/9 ) ; key id = 3510
Public key (base64)
NSEC Record example
$ORIGIN example.net.!
@ !SOA …!
!!NS!NS.example.net.!
!!DNSKEY !…!
!!NSEC mailbox.example.net. SOA NS NSEC DNSKEY !RRSIG!

!
mailbox !A !192.168.10.2 !!
!! ! !NSEC www.example.net. A NSEC RRSIG!
WWW ! !A !192.168.10.3 !!
!! ! !TXT !Public webserver!
!! ! !NSEC example.net. A NSEC RRSIG TXT!
Delegation Signer (DS)
•  Establishes  the  chain  of  trust  from  parent  to  child  zones  
•  Found  in  the  parent’s  zone  file  
•  In  this  example,  irrashai.net  has  been  delegated  from  .net.  
This  is  how  it  looks  like  in  .net  zone  file    
 
  Key ID
irrashai.net. IN NS ns1.irrashai.net.
NS ns2.irrashai.net. DNSKEY algorithm (RSASHA1)
IN DS 19996 5 1 (
CF96B018A496CD1A68EE7 Digest type: 1 = SHA1
C80A37EDFC6ABBF8175 ) 2 = SHA256
IN DS 19996 5 2 (
6927A531B0D89A7A4F13E11031
4C722EC156FF926D2052C7D8D70C50
14598CE9 )
Delegation 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  
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  
•  Trusted  anchor  in  a  security  aware  server    
•  Part  of  the  chain  of  trust  by  a  parent  name  server  
•  Using  a  single  key  or  both  keys  is  an  operaOonal  
choice  (RFC  allows  both  methods)  
Creation of keys
•  Zones  are  digitally  signed  using  the  private  key  
•  Can  use  RSA-­‐SHA-­‐1,  DSA-­‐SHA-­‐1  and  RSA-­‐MD5  
digital  signatures  
•  The  public  key  corresponding  to  the  private  
key  used  to  sign  the  zone  is  published  using  a  
DNSKEY  RR  
Chain of Trust
•  DNSSEC  is  based  on  trust  
•  Root  is  on  top  of  the  chain  of  trust.  
–  Root  servers  were  signed  on  July  15,  2010.  
ImplemenOng  DNSSEC  
Setting up a 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
champika.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    
Updating the DNS Configuration
•  Enable  DNSSEC  in  the  configuraOon  file  (named.conf)  
options {
directory “….”
dnssec-enable yes;
dnssec-validation yes;
};
 
•  Other  opOons  that  can  be  added  later  
–  auto-dnssec { off | allow | maintain} ;
–  These  opOons  are  used  to  automate  the  signing  and  key  
rollover  
 
Creating key pairs
•  To  create  ZSK  

dnssec-keygen -a rsasha1 -b 1024 -n zone

<myzone>

•  To  create  KSK  

dnssec-keygen -a rsasha1 -b 1400 -f KSK -n

zone champika.net
Generating Key Pair
•  Generate  ZSK  and  KSK  

dnssec-keygen -a rsasha1 -b 1024 -n zone <myzone>  

 
Default  values  are  RSASHA1  for  algorithm,  1024  bits  for  ZSK  and  2048  bits  
for  KSK  

The command above can be simplified as:

dnssec-keygen –f KSK <myzone>

This generates four files.

Note: There  has  to  be  at  least  one  public/private  key  pair  for  each  DNSSEC  
zone  
Publishing your public key
•  Using  $INCLUDE  you  can  call  the  public  key  
(DNSKEY  RR)  inside  the  zone  file  
 
$INCLUDE /path/Kchampika.net.+005+33633.key ;
ZSK
$INCLUDE /path/Kchampika.net.+005+00478.key ;
KSK

•  You  can  also  manually  enter  the  DNSKEY  RR  in  

the  zone  file  
Signing the Zone
•  Sign the zone using the secret keys:

dnssec-signzone –o <zonename> -k <KSKfile>

<zonefile> <ZSKfile>

dnssec-signzone –o champika.net –k
Kchampika.net.+005+40000 db.champika.net
Kchampika.net.+005+33633

•  Once  you  sign  the  zone  a  file  with  a  .signed  extension  

will  be  created  
–  db.champika.net.signed
Signing the Zone
•  Note  that  only  authoritaOve  records  are  
signed    
–  NS  records  for  the  zone  itself  are  signed  
–  NS  records  for  delegaOons  are  not  signed  
–  DS  RRs  are  signed!  
–  Glue  is  not  signed  
•  Difference  in  the  file  size  
–  db.champika.net  vs.  db.champika.net.signed  
Smart Signing
•  Searches  the  key  repository  for  any  keys  that  
will  match  the  zone  being  signed    
options {
keys-directory { “path/to/keys”; };

•  Then  the  command  for  smart  signing  is    

dnssec-signzone –S db.myzone.net
Publishing the Zone
•  Reconfigure  to  load  the  signed  zone.  Edit  
named.conf  and  point  to  the  signed  zone.  
 
zone “<myzone>” {
type master;
# file “db.myzone.net”;
file “db.myzone.net.signed”;
};
Pushing the DS record
•  The  DS  record  must  now  be  published  by  the  
parent  zone.  
•  Contact  the  parent  zone  to  communicate  the  
KSK  to  them.  
Testing the server
•  Ask  a  dnssec  enabled  quesOon  from  the  server  
and  see  whether  the  answer  contains  dnssec-­‐
enabled  data  
–  Basically  the  answers  are  signed  

dig @localhost www.champika.net

+dnssec +multiline
Testing with dig: an example
Tools to use in DNSSEC

•  Authoritative Servers that support DNSSEC

o  NSD (by NLNetLabs)
o  Knot (by CZ NIC Labs)

o  BIND (by ISC)

o  Vantio (by Nominum)

o  Y:A:D::I::F:A (by EURid)

o  MS DNS Server (by Microsoft)

o  TinyDNSSEC (based on tinydns by D.J. Bernstein)