Welcome!
DNS / DNSSEC tutorial
Champika Wijayatunga, APNIC
In conjunction with SANOG 7 Acknowledgements
• Bill Manning • Ed Lewis • Joe Abley • Olaf M. Kolkman
㻨㻳㻑㻱㻨㻷 NeuStar Introduction to DNS Purpose of naming
• Addresses are used to locate objects
• Names are easier to remember than numbers
• You would like to get to the address or other objects using a name
• DNS provides a mapping from names to resources of several types Names and addresses in general
• An address is how you get to an endpoint – Typically, hierarchical (for scaling): • 950 Milton Street, Brisbane City, QLD 4064 • 204.152.187.11, +617-3858-3188
• A “name” is how an endpoint is referenced – Typically, no structurally significant hierarchy • “David”, “Tokyo”, “apnic.net” Naming History
• 1970’s ARPANET – Host.txt maintained by the SRI-NIC – pulled from a single machine – Problems • traffic and load • Name collisions • Consistency
• DNS created in 1983 by Paul Mockapetris (RFCs 1034 and 1035), modified, updated, and enhanced by a myriad of subsequent RFCs DNS
• A lookup mechanism for translating objects into other objects • A globally distributed, loosely coherent, scalable, reliable, dynamic database • Comprised of three components
A “name space”
Servers making that name space available
Resolvers (clients) which query the servers about the name space DNS Features: Global Distribution
• Data is maintained locally, but retrievable globally – No single computer has all DNS data
• DNS lookups can be performed by any device
• Remote DNS data is locally cachable to improve performance DNS Features: Scalability
• No limit to the size of the database – One server has over 20,000,000 names • Not a particularly good idea
• No limit to the number of queries – 24,000 queries per second handled easily
• Queries distributed among masters, slaves, and caches DNS Features: Reliability
• Data is replicated – Data from master is copied to multiple slaves
• Clients can query – Master server – Any of the copies at slave servers
• Clients will typically query local caches DNS Features: Dynamicity
• Database can be updated dynamically – Add/delete/modify of any record
• Modification of the master database triggers replication – Only master can be dynamically updated • Creates a single point of failure Concept: DNS Names
• How names appear in the DNS – Fully Qualified Domain Name (FQDN) • WWW.APNIC.NET. – labels separated by dots
• DNS provides a mapping from FQDNs to resources of several types
• Names are used as a key when fetching data in the DNS Concept: DNS Names contd.
• Domain names can be mapped to a tree • New branches at the ‘dots’ dots Root DNS
net org com ccTLDs
apnic iana
www whoiswhois ftp Concept: Resource Records
• The DNS maps names into data using Resource Records.
Resource Record
www.apnic.net. … A 10.10.10.2
Address Resource
• More detail later Concept: Domains
• Domains are “namespaces”
• Everything below .com is in the com domain
• Everything below apnic.net is in the apnic.net domain and in the net domain
Concept: Domains • com domain
co
ne ed • • apnic.net • t u m google domain
apnic sun tislab • is
• • i moons
training ww • ft ww w w net p ns ns domain 2 1 Delegation
• Administrators can create subdomains to group hosts – According to geography, organizational affiliation or any other criterion
• An administrator of a domain can delegate responsibility for managing a subdomain to someone else – But this isn’t required
• The parent domain retains links to the delegated subdomain – The parent domain “remembers” who it delegated the subdomain to Concept: Zones and Delegations
• Zones are “administrative spaces”
• Zone administrators are responsible for portion of a domain’s name space
• Authority is delegated from a parent and to a child Concept: Zones and Delegations
net net zone •
domain com net edu • •
apnic.net apnic sun tislabs • isi
• zone • moon
training www • training.apnic.net ftp www zone ns2 ns1 Concept: Name Servers
• Name servers answer ‘DNS’ questions
• Several types of name servers – Authoritative servers • master (primary) • slave (secondary) – (Caching) recursive servers • also caching forwarders – Mixture of functionality Concept: Name Servers contd.
• Authoritative name server – Give authoritative answers for one or more zones – The master server normally loads the data from a zone file – A slave server normally replicates the data from the master via a zone transfer Concept: Name Servers contd.
• Authoritative name server
slave
master slave Concept: Name Servers contd.
• Recursive server – Do the actual lookups; ask questions to the DNS on behalf of the clients
– Answers are obtained from authoritative servers but the answers forwarded to the clients are marked as not authoritative
– Answers are stored for future reference in the cache Concept: Resolvers
• Resolvers ask the questions to the DNS system on behalf of the application
• Normally implemented in a system library (e.g, libc) gethostbyname(char *name); gethostbyaddr(char *addr, int len, type); Concept: Resolving process & Cache
㻴㼘㼈㼖㼗㼌㼒㼑㻝 㼕㼒㼒㼗㻐㼖㼈㼕㼙㼈㼕 㼚 㼚 㼚 㻑㼄㼓㼑㼌㼆㻑㼑㼈㼗㻃㻤 㼚㼚㼚㻑 㼄㼓㼑㼌㼆㻑 㼑㼈㼗 㻃㻤㻃㻢
㼚㼚㼚㻑 㼄㼓㼑㼌㼆㻑 㼑㼈㼗 㻃㻤㻃㻢 㻤㼖㼎㻃㼑㼈㼗 㻃㼖㼈㼕 㼙㼈㼕 㻃㻣 㻃㻻㻑 㼊㼗 㼏㼇㻐㼖㼈㼕 㼙㼈㼕 㼖㻑 㼑㼈㼗 㻃㻋㻎 㻃㼊㼏㼘㼈㻌 㻵㼈㼖㼒㼏㼙㼈㼕 㻦㼄㼆㼋㼌㼑㼊 㻔 㻜 㻕 㻑 㻔 㻙 㻛 㻑 㻘 㻑 㻔 㻓 㼉㼒㼕㼚 㼄㼕㼇㼈㼕 㼚㼚㼚㻑 㼄㼓㼑㼌㼆㻑 㼑㼈㼗 㻃㻤㻃㻢 㻋 㼕㼈㼆㼘㼕㼖㼌㼙㼈㻌 㼊 㼗㼏㼇㻐㼖㼈㼕㼙㼈㼕 㻤㼖㼎㻃㼄㼓㼑㼌㼆㻃㼖㼈㼕 㼙㼈㼕 㻃㻣 㻃㼑㼖㻑 㼄㼓㼑㼌㼆㻑 㼑㼈㼗 㻃㻋㻎 㻃㼊㼏㼘㼈㻌
㻤㼇㼇㻃㼗 㼒㻃㼆㼄㼆㼋㼈 㼚㼚㼚㻑 㼄㼓㼑㼌㼆㻑 㼑㼈㼗 㻃㻤㻃㻢 㻔 㻜 㻕 㻑 㻔 㻙 㻛 㻑 㻘 㻑 㻔 㻓
㼄㼓㼑㼌㼆㻐㼖㼈㼕㼙㼈㼕 Concept: Resource Records
• Resource records consist of it’s name, it’s TTL, it’s class, it’s type and it’s RDATA • TTL is a timing parameter • IN class is widest used • There are multiple types of RR records • Everything behind the type identifier is called rdata www.apnic.net. 3600 IN A 10.10.10.2
ttl Label type rdata class Example: RRs in a zone file
apnic.net. 7200 IN SOA ns.apnic.net. admin.apnic.net. ( 2001061501 ; Serial 43200 ; Refresh 12 hours 14400 ; Retry 4 hours 345600 ; Expire 4 days 7200 ; Negative cache 2 hours )
apnic.net. 7200 IN NS ns.apnic.net. apnic.net. 7200 IN NS ns.ripe.net.
whois.apnic.net. 3600 IN A 193.0.1.162
host25.apnic.net. 2600 IN A 193.0.3.25 Label ttl class type rdata Resource Record: SOA and NS
• The SOA and NS records are used to provide information about the zone itself
• The NS indicates where information about a given zone can be found apnic.net. 7200 IN NS ns.apnic.net. apnic.net. 7200 IN NS ns.ripe.net.
• The SOA record provides information about the start of authority, i.e. the top of the zone, also called the APEX Resource Record: SOA
Contact address Master server
net. 3600 IN SOA A.GTLD-SERVERS.net. nstld.verisign-grs.com. ( 2002021301 ; serial 30M ; refresh 15M ; retry 1W ; expiry Version number 1D ) ; neg.answ.ttl
Timing parameter Concept: TTL and other Timers
• TTL is a timer used in caches – An indication for how long the data may be reused – Data that is expected to be ‘stable’ can have high TTLs
• SOA timers are used for maintaining consistency between primary and secondary servers 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
Cache server
Upload of zone data is local policy Master
Registry DB Slave server To remember...
• Multiple authoritative servers to distribute load and risk: – Put your name servers apart from each other
• Caches to reduce load to authoritative servers and reduce response times
• SOA timers and TTL need to be tuned to needs of zone. Stable data: higher numbers What have we learned so far
• We learned about the architectures of – resolvers, – caching forwarders, – authoritative servers, – timing parameters
• We continue writing a zone file Writing a zone file
• Zone file is written by the zone administrator
• Zone file is read by the master server and it’s content is replicated to slave servers
• What is in the zone file will end up in the database
• Because of timing issues it might take some time before the data is actually visible at the client side First attempt
• The ‘header’ of the zone file – Start with a SOA record – Include authoritative name servers and, if needed, glue – Add other information
• Add other RRs
• Delegate to other zones The SOA record Comments apnic.net. 3600 IN SOA ns.apnic.net. ( admin\.email.apnic.net. 2002021301 ; serial 1h ; refresh 30M ; retry 1W ; expiry 3600 ) ; neg. answ. ttl
• [email protected] admin\.email.apnic.net • Serial number: 32bit circular arithmetic – People often use date format – To be increased after editing • The timers above qualify as reasonable Authoritative NS records and related A records apnic.net. 3600 IN NS NS1.apnic.net. apnic.net. 3600 IN NS NS2.apnic.net. NS1.apnic.net. 3600 IN A 203.0.0.4 NS2.apnic.net. 3600 IN A 193.0.0.202
• NS record for all the authoritative servers – They need to carry the zone at the moment you publish • A records only for “in-zone” name servers – Delegating NS records might have glue associated Other ‘APEX’ data
secret-wg.org. 3600 IN MX 50 mailhost.secret-wg.org. secret-wg.org. 3600 IN MX 150 mailhost2.secret-wg.org. secret-wg.org. 3600 IN LOC ( 52 21 23.0 N 04 57 05.5 E 0m 100m 100m 100m ) secret-wg.org. 3600 IN TXT “Demonstration and test zone”
Examples: TXT records A records • MX records for KEY records for dnssec mail (see next slide) • Location records MX record
• SMTP (simple mail transfer protocol) uses MX records to find the destination mail server
• If a mail is sent to [email protected] the sending mail agent looks up ‘apnic.net MX’
• MX record contains mail relays with priority – The lower the number the higher the priority
• Don’t add MX records without having a mail relay configured Other data in the zone
localhost.apnic.net. 3600 IN A 127.0.0.1 NS1.apnic.net. 4500 IN A 203.0.0.4 www.apnic.net. 3600 IN CNAME wasabi.apnic.net. apnic.net. 3600 IN MX 50 mail.apnic.net.
• Add all the other data to your zone file
• Some notes on notation – Note the fully qualified domain name including trailing dot – Note TTL and CLASS Zone file format short cuts nice formatting apnic.net. 3600 IN SOA NS1.apnic.net. admin\.email.apnic.net. ( 2002021301 ; serial 1h ; refresh 30M ; retry 1W ; expiry 3600 ) ; neg. answ. Ttl apnic.net. 3600 IN NS NS1.apnic.net. apnic.net. 3600 IN NS NS2.apnic.net. apnic.net. 3600 IN MX 50 mail.apnic.net. apnic.net. 3600 IN MX 150 mailhost2.apnic.net. apnic.net. 3600 IN TXT “Demonstration and test zone” NS1.apnic.net. 4500 IN A 203.0.0.4 NS2.apnic.net. 3600 IN A 193.0.0.202 localhost.apnic.net. 3600 IN A 127.0.0.1 NS1.apnic.net. 3600 IN A 193.0.0.4 www.apnic.net. 3600 IN CNAME IN.apnic.net. Zone file short cuts: repeating last name apnic.net. 3600 IN SOA NS1.apnic.net. admin\.email.apnic.net. ( 2002021301 ; serial 1h ; refresh 30M ; retry 1W ; expiry 3600 ) ; neg. answ. Ttl 3600 IN NS NS1.apnic.net. 3600 IN NS NS2.apnic.net. 3600 IN MX 50 mail.apnic.net. 3600 IN MX 150 mailhost2.apnic.net. 3600 IN TXT “Demonstration and test zone” NS1.apnic.net. 3600 IN A 203.0.0.4 NS2.apnic.net. 3600 IN A 193.0.0.202 localhost.apnic.net. 4500 IN A 127.0.0.1 NS1.apnic.net. 3600 IN A 203.0.0.4 www.apnic.net. 3600 IN CNAME IN.apnic.net. Zone file short cuts: default TTL
$TTL 3600 ; Default TTL directive apnic.net. IN SOA NS1.apnic.net. admin\.email.apnic.net. ( 2002021301 ; serial 1h ; refresh 30M ; retry 1W ; expiry 3600 ) ; neg. answ. Ttl IN NS NS1.apnic.net. IN NS NS2.apnic.net. IN MX 50 mail.apnic.net. IN MX 150 mailhost2.apnic.net. IN TXT “Demonstration and test zone” NS1.apnic.net. IN A 203.0.0.4 NS2.apnic.net. IN A 193.0.0.202 localhost.apnic.net. 4500 IN A 127.0.0.1 NS1.apnic.net. IN A 203.0.0.4 www.apnic.net. IN CNAME NS1.apnic.net. Zone file short cuts: ORIGIN
$TTL 3600 ; Default TTL directive $ORIGIN apnic.net. @ IN SOA NS1 admin\.email.apnic.net. ( 2002021301 ; serial 1h ; refresh 30M ; retry 1W ; expiry 3600 ) ; neg. answ. Ttl IN NS NS1 IN NS NS2 IN MX 50 mailhost IN MX 150 mailhost2
IN TXT “Demonstration and test zone” NS1 IN A 203.0.0.4 NS2 IN A 193.0.0.202 localhost 4500 IN A 127.0.0.1 NS1 IN A 203.0.0.4 www IN CNAME NS1 Zone file short cuts: Eliminate IN
$TTL 3600 ; Default TTL directive $ORIGIN apnic.net. @ SOA NS1 admin\.email.sanog.org. ( 2002021301 ; serial 1h ; refresh 30M ; retry 1W ; expiry 3600 ) ; neg. answ. Ttl NS NS1 NS NS2 MX 50 mailhost MX 150 mailhost2
TXT “Demonstration and test zone” NS1 A 203.0.0.4 NS2 A 193.0.0.202 localhost 4500 A 127.0.0.1 NS1 A 203.0.0.4 www CNAME NS1 Delegating a zone (becoming a parent)
• Delegate authority for a sub domain to another party (splitting of
training.apnic.net from apnic.net) •
co ne ed • •
t u • m google
apnic.net apnic sun tislab
• is
zone i moons •
trai• ning ww • training.apnic.net ww w ft zone p ns ns w 2 1 Concept: Glue
• Delegation is done by adding NS records: training.apnic.net. NS ns1.training.apnic.net. training.apnic.net. NS ns2.training.apnic.net. training.apnic.net. NS ns1.apnic.net. training.apnic.net. NS ns2.apnic.net.
• How to get to ns1 and ns2… We need the addresses
• Add glue records to so that resolvers can reach ns1 and ns2 ns1.training.apnic.net. A 10.0.0.1 ns2.training.apnic.net. A 10.0.0.2 Concept: Glue contd.
• Glue is ‘non-authoritative’ data • Don’t include glue for servers that are not in sub zones
training.apnic.net. NS ns1.training.apnic.net. Training.apnic.net. NS ns2.training.apnic.net.
training.apnic.net. NS ns2.apnic.net. training.apnic.net. NS ns1.apnic.net. ns1.training.apnic.net. A 10.0.0.1 Ns2.training.apnic.net. A 10.0.0.2
Only this record needs glue Delegating training.apnic.net. from apnic.net. training.apnic.net apnic.net • Setup minimum • Add NS records and two servers glue • Create zone file with NS records • Make sure there is no • Add all other data from the training.apnic.net training.apnic.net. data zone in the zone file Questions ? BIND Installation Overview
• Retrieving BIND • Building and Installing BIND • Mailing Lists Retrieving BIND
• HTTP, FTP – Internet Systems Consortium • http://www.isc.org • Other packages – OpenSSL • Will be needed for DNSSEC BIND
• Version 8 – In use, available, obsolete – Don't start to use it – Migrate to Version 9 – (Okay, BIND 8 is faster than BIND 9) • Version 9 – Current version (9.3.1 as of March 2005) • Release • Release Candidate (Betas) • Snapshots (Alphas) – Never Use Snapshots on production servers Getting BIND 9
• HTTP – http://www.isc.org/products/BIND/ – http://www.isc.org/products/BIND/bind9.html • BIND 9.3.1 today • FTP – ftp.isc.org - anonymous – Change Directory to /isc/bind9 • cd 9.3.1 – ftp://ftp.isc.org/isc/bind9/9.3.1/bind-9.3.1.tar.gz Overview
• Retrieving BIND Building and Installing BIND • Mailing Lists Unpacking BIND9
• tar -xvfz bind-9.3.1.tar.gz – Uncompresses and creates directory – bind-9.3.1 • What's in there? – A lot of stuff (dig, libraries etc) – ./configure (script) – ./doc/arm/Bv9ARM.html • Administrator's Reference Manual • Good source!!! Building BIND9
• must be in the BIND 9.3.1 directory >./configure (options) – Determine the appropriate includes and compiler settings > make – Build and compile > make install – sudo (if not root) – Install BIND What happens
• Executables – /usr/local/sbin • dnssec-keygen, dnssec-makekeyset, dnssec-signkey, dnssec-signzone • lwresd, named-checkconf, named-checkzone • rndc, rndc-confgen • named – /usr/local/bin • dig • host, isc-config.sh, nslookup • nsupdate • And libraries included Testing
• Make sure right version is now installed > named –v > BIND 9.3.1 Overview
• Retrieving BIND • Building, Installing BIND Mailing Lists BIND 9 Mailing Lists
• Joining mail lists – http://www.isc.org/services/public/lists/bin d-lists.html – bind9-users, bind-announce – (bind-users is for bind8) • Archives – http://www.isc.org/ml-archives/ Questions? Recursive Server Overview
• Recursive Service • Root server list • localhost • 0.0.127.in-addr.arpa • named.conf Recursive Server
• Used to lookup data by applications • Needs to know how to reach top of DNS • Also should stop some queries – localhost, 127.0.0.1 • Files – named.conf – root.hints – localhost zone – 0.0.127.in-addr.arpa zone • We'll do named.conf last Root server list
• List of the 13 root server records • Where to get it – ftp rs.internic.net • anonymous login • cd domain • get one of these files (they are [nearly] the same) – db.cache – named.root – named.cache What it looks like
; This file holds the information on root name servers needed to ; initialize cache of Internet domain name servers ; (e.g. reference this file in the "cache .
• Nothing • You will refer to it in named.conf using a zone statement • In real networks, don't change it – But for learning, we will change it localhost
• Loopback name in operating systems • Means 127.0.0.1 • Queries for this shouldn't use recursion • So we will configure a file to define the localhost. zone – Note the "." localhost file
$TTL 86400 @ IN SOA localhost. root.localhost. ( 1 ; serial 1800 ; refresh 900 ; retry 69120 ; expire 1080 ; negative cache ttl ) NS localhost. A 127.0.0.1 Reverse for localhost
• Since we want "localhost -> 127.0.0.1" we want to have "127.0.0.1 -> localhost"
• We need a zone called 0.0.127.in- addr.arpa. 0.0.127.in-addr.arpa file
$TTL 86400 @ IN SOA localhost. root.localhost. ( 1 ; serial 1800 ;refresh 900 ;retry 69120 ;expire 1080 ;negative cache ttl ) NS localhost. 1 PTR localhost. Assembling the files
• Here's my directory: [/var/named/recursive] % ls 0.0.127.in-addr.arpa localhost named.root
• The directory name and file names will be in named.conf
• Now I create a named.conf file in the same directory named.conf
options { directory "/var/named/recursive"; recursion yes; // by default recursion is on }; zone "." { type hint; file "named.root"; }; zone "localhost." { type master; file "localhost"; }; zone "0.0.127.in-addr.arpa." { type master; file "0.0.127.in-addr.arpa"; }; Running the server
• From the directory % named -g -c named.conf Testing the server
• Just to show it is alive % dig @127.0.0.1 www.arin.net ; <<>> DiG 9.2.2rc1 <<>> @127.0.0.1 www.arin.net ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16580 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 10, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.arin.net. IN A ;; ANSWER SECTION: www.arin.net. 10800 IN A 192.149.252.17 www.arin.net. 10800 IN A 192.149.252.16 ;; AUTHORITY SECTION: arin.net. 10800 IN NS arrowroot.arin.net. (and so on) ;; Query time: 3066 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed Feb 19 11:07:05 2003 ;; MSG SIZE rcvd: 251 Congratulations - Your First Server!
• It's just the beginning... Questions ? Reverse DNS Overview
• Principles • Creating reverse zones • Setting up nameservers • Reverse delegation procedures What is ‘Reverse DNS’?
• ‘Forward DNS’ maps names to numbers – svc00.apnic.net -> 202.12.28.131
• ‘Reverse DNS’ maps numbers to names – 202.12.28.131 -> svc00.apnic.net Reverse DNS - why bother?
• Service denial • That only allow access when fully reverse delegated eg. anonymous ftp • Diagnostics • Assisting in trace routes etc • SPAM identifications • Registration responsibilities In-addr.arpa
• Hierarchy of IP addresses – Uses ‘in-addr.arpa’ domain • INverse ADDRess
• IP addresses: – Less specific to More specific • 210.56.14.1 • Domain names: – More specific to Less specific • delhi.vsnl.net.in
– Reversed in in-addr.arpa hierarchy • 14.56.210.in-addr.arpa Principles – DNS tree - Mapping numbers to names - ‘reverse DNS’
Root DNS net edu com arpa au apnic in-addr whoiswhois RIR 202202 203 210 211..
ISP 6464 22.64.202 .in-addr.arpa Customer 2222 Creating reverse zones
• Same as creating a forward zone file – SOA and initial NS records are the same as normal zone – Main difference • need to create additional PTR records
• Can use BIND or other DNS software to create and manage reverse zones – Details can be different Creating reverse zones - contd
• Files involved – Zone files • Forward zone file – e.g. db.domain.net • Reverse zone file – e.g. db.192.168.254 – Config files •
253.253.192.in-addr.arpa. Pointer (PTR) records
• Create pointer (PTR) records for each IP address
131.28.12.202.in-addr.arpa. IN PTR svc00.apnic.net.
or
131 IN PTR svc00.apnic.net. A reverse zone example
$ORIGIN 1.168.192.in-addr.arpa. @ 3600 IN SOA test.company.org. ( sys\.admin.company.org. 2002021301 ; serial 1h ; refresh 30M ; retry 1W ; expiry 3600 ) ; neg. answ. ttl
NS ns.company.org.Note trailing NS ns2.company.org.dots
1 PTR gw.company.org. router.company.org.
2 PTR ns.company.org. ;auto generate: 65 PTR host65.company.org $GENERATE 65-127 $ PTR host$.company.org. Setting up the primary nameserver
• Add an entry specifying the primary server to the named.conf file
zone "
• Add an entry specifying the primary server to the named.conf file
zone "
• /24 Delegations • Address blocks should be assigned/allocated • At least two name servers • /16 Delegations • Same as /24 delegations • APNIC delegates entire zone to member • Recommend APNIC secondary zone
• < /24 Delegations RFC • Read “classless in-addr.arpa delegation” 2317 APNIC & ISPs responsibilities
• APNIC – Manage reverse delegations of address block distributed by APNIC (61/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8) – Process organisations requests for reverse delegations of network allocations • Organisations – Be familiar with APNIC procedures – Ensure that addresses are reverse-mapped – Maintain nameservers for allocations • Minimise pollution of DNS Subdomains of in-addr.arpa domain
• Example: an organisation given a /16 – 192.168.0.0/16 (one zone file and further delegations to downstreams) – 168.192.in-addr.arpa zone file should have:
0.168.192.in-addr.arpa. NS ns1.organisation0.com. 0.168.192.in-addr.arpa. NS ns2.organisation0.com. 1.168.192.in-addr.arpa. NS ns1.organisation1.com. 1.168.192.in-addr.arpa. NS ns2.organisation1.com. 2.168.192.in-addr.arpa. NS ns1.organisation2.com. 2.168.192.in-addr.arpa. NS ns2.organisation2.com. : : Subdomains of in-addr.arpa domain
• Example: an organisation given a /20 – 192.168.0.0/20 (a lot of zone files!) – have to do it per /24) – Zone files
0.168.192.in-addr.arpa. 1.168.192.in-addr.arpa. 2.168.192.in-addr.arpa. : : 15.168.192.in-addr.arpa. Subdomains of in-addr.arpa domain
• Example: case of a /24 subnetted with the mask 255.255.255.192 – In-addr zone – 254.253.192.in-addr.arpa – Subnets • 192.253.254.0/26 • 192.253.254.64/26 • 192.253.254.128/26 • 192.253.254.192/26 – If different organisations has to manage the reverse-mapping for each subnet • Solution to follow… Classless in-addr for 192.253.254/24
• CNAME records for each of the domain names in the zone – Pointing to domain names in the new subdomains
$ORIGIN 254.253.192.in-addr.arpa.
0-63 NS ns1.organisation1.com. 0-63 NS ns2.organisation1.com.
1 CNAME 1.0-63 2 CNAME 2.0-63
64-127 NS ns1.organisation2.com. 64-127 NS ns2.organisation2.com.
65 CNAME 65.64-127 66 CNAME 66.64-127 Classless in-addr for 192.253.254/24
• Using $GENERATE (db.192.253.254 file)
$ORIGIN 254.253.192.in-addr.arpa.
0-63 NS ns1.organisation1.com. 0-63 NS ns2.organisation1.com.
$GENERATE 1-63$ CNAME $.0-63
64-127 NS ns1.organisation2.com. 64-127 NS ns2.organisation2.com.
$GENERATE 65-127$ CNAME $.64-127 Classless in-addr for 192.253.254.0/26
• Now, the zone data file for 0-63.254.253.192.in- addr.arpa can contain just PTR records for IP addresses 192.253.254.1 through 192.253.154.63
$ORIGIN 0-63.254.253.192.in-addr.arpa. $TTL 1d @ SOA ns1.organisation1.com. Root.ns1.organisation1.com. ( 1 ; Serial 3h ; Refresh 1h ; Retry 1w ; Expire 1h ) ; Negative caching TTL NS ns1.organisation1.com. NS ns2.organisation1.com.
1 PTR org1-name1.organisation1.com. 2 PTR org1-name2.organisation1.com. 3 PTR org1-name3.organisation1.com. Reverse delegation procedures
• Upon allocation, member is asked if they want /24 place holder domain objects with member maintainer – Gives member direct control
• Standard APNIC database object, – can be updated through myAPNIC, Online form or via email.
• Nameserver/domain set up verified before being submitted to the database.
• Protection by maintainer object – (current auths: CRYPT-PW, PGP).
• Zone file updated 2-hourly Reverse delegation procedures
• Use MyAPNIC to create ‘domain’ objects – Highly recommended
• Or use the web form • http://www.apnic.net/db/domain.html
• On-line form interface – Real time feedback – Gives errors, warnings in zone configuration • serial number of zone consistent across nameservers • nameservers listed in zone consistent Evaluation procedures
• Parser checks for – ‘whois’ database • IP address range is assigned or allocated • Must be in APNIC database – Maintainer object • Mandatory field of domain object – Nic-handles • zone-c, tech-c, admin-c Online errors (also via email) Request submission error
Update failed
Authorisation failed Successful update
Update ok! Creation of domain objects
• Two options – Ask APNIC hostmasters to create the dummy domain objects at the time when the IP allocation is made – Do it yourself
• Domain objects protected by maintainers – hierarchical protection using “mnt-lower” – APNIC protects all the /8’s by MAINT-AP-DNS Creation of domain objects
• When APNIC creates a dummy domain object – APNIC hostmasters will include members maintainer object in the respective domain objects – Include dummy information in the nameservers attribute – Once the domain objects are maintained by members maintainer ID, they can perform any modification to the object Creation of domain objects
• If you opt to create the domain objects yourself – Either you can use MyAPNIC – Or use web/email templates
• Using web/email templates will result in initial errors – As the /8 is hierarchically maintained by MAINT-AP-DNS – Contact
• APNIC highly recommend you to use MyAPNIC when creating domain objects – MyAPNIC parser will check the maintainer of ‘inetnum’ object – If the password matches no errors will be returned
• Can use MyAPNIC to create multiple domain objects at once – ex: If you are allocated a /19, you can provide the full IP range and 32 domain objects can be created in one go Whois domain object Reverse Zone domain: 28.12.202.in-addr.arpa descr: in-addr.arpa zone for 28.12.202.in-addr.arpa admin-c: DNS3-AP Contacts tech-c: DNS3-AP zone-c: DNS3-AP nserver: ns.telstra.net nserver: rs.arin.net nserver: ns.myapnic.net Name nserver: svc00.apnic.net Servers nserver: ns.apnic.net mnt-by: MAINT-APNIC-AP mnt-lower: MAINT-DNS-AP changed: [email protected] 19990810 Maintainers source: APNIC (protection) Removing lame delegations
• Objective – To repair or remove persistently lame DNS delegations • DNS delegations are lame if: – Some or all of the registered DNS nameservers are unreachable or badly configured • APNIC commenced formal implementation of the lame DNS reverse delegation procedures – On 30 September 2004 IPv6 Reverse delegations IPv6 representation in the DNS
• Forward lookup support: Multiple RR records for name to number – AAAA (Similar to A RR for IPv4 ) – A6 without chaining (prefix length set to 0 )
• Reverse lookup support: – Reverse nibble format for zone ip6.int – Reverse nibble format for zone ip6.arpa IPv6 forward and reverse mappings
• Existing A record will not accommodate IPv6’s 128 bit addresses • BIND expects an A record’s record- specific data to be a 32-bit address (in dotted-octet format) • An address record – AAAA (RFC 1886) • A reverse-mapping domain – Ip6.int (now replaced by ip6.arpa) The reverse DNS tree – with IPv6
Root DNS
net edu com arpa int apnic in-addr IP6 whoiswhois RIR 202202 203 210
ISP 6464 IPv6 Addresses Customer 2222 Root DNS b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.ip6.arpa.
arpa int
IP6
H164 ISP /32 H8 Downstream ISP /40 H10 Customer H12 /48
Devices /128 H32 IPv6 forward lookups
• Multiple addresses possible for any given name – Ex: in a multi-homed situation • Can assign A records and AAAA records to a given name/domain • Can also assign separate domains for IPv6 and IPv4 Sample forward lookup file
;; domain.edu $TTL 86400 @ IN SOA ns1.domain.edu. root.domain.edu. ( 2002093000 ; serial - YYYYMMDDXX 21600 ; refresh - 6 hours 1200 ; retry - 20 minutes 3600000 ; expire - long time 86400) ; minimum TTL - 24 hours ;; Nameservers IN NS ns1.domain.edu. IN NS ns2.domain.edu.
;; Hosts with just A records host1 IN A 1.0.0.1
;; Hosts with both A and AAAA records host2 IN A 1.0.0.2 IN AAAA 2001:468:100::2 IPv6 reverse lookups
• IETF decided to restandardize IPv6 PTR RRs – They will be found in the IP6.ARPA namespace rather than under the IP6.INT namespace
• The ip6.int domains has been deprecated, but some hosts still use them – Supported for backwards compatiblity
• Now using ip6.arpa for reverse IPv6 reverse lookups - PTR records
• Similar to the in-addr.arpa
b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.ip6.arpa. IN PTR test.ip6.example.com.
• Example: reverse name lookup for a host with address 3ffe:8050:201:1860:42::1 $ORIGIN 0.6.8.1.1.0.2.0.0.5.0.8.e.f.f.3.ip6.arpa.
1.0.0.0.0.0.0.0.0.0.0.0.2.4.0.0 14400 IN PTR host.example.com. Sample reverse lookup file
;; 0.0.0.0.0.0.1.0.8.6.4.0.1.0.0.2.rev ;; These are reverses for 2001:468:100::/64) ;; File can be used for both ip6.arpa and ip6.int. $TTL 86400 @ IN SOA ns1.domain.edu. root.domain.edu. ( 2002093000 ; serial - YYYYMMDDXX 21600 ; refresh - 6 hours 1200 ; retry - 20 minutes 3600000 ; expire - long time 86400) ; minimum TTL - 24 hours ;; Nameservers IN NS ns1.domain.edu. IN NS ns2.domain.edu. 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR host1.ip6.domain.edu 2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR host2.domain.edu ;; ;; Can delegate to other nameservers in the usual way ;; Questions ? RNDC & TSIG What is RNDC?
• Remote Name Daemon Controller • Command-line control of named daemon • Usually on same host, can be across hosts – Locally or remotely Configuring RNDC
• "rndc-confgen" generates lines to be added to two files – rndc.conf – named.conf Generating the lines: > rndc-confgen
key “rndc-key” { algorith hmac-md5; secret “rXxroiejf8937Bjf_+-532ktj/==“; }; Options { default-key “rndc-key”; default-server 127.0.0.1; default-port 953; #End of rndc.conf
# User with the followign in named.conf, adjusting the # allow list as needed # key “rndc-key” { # algorithm hmac-md5; # secret “rXxroiejf8937Bjf_+-532ktj/==“; # }; # controls { # inet 127.0.0.1 port 953 # allow { 127.0.0.1; } keys { “rndc-key” }; # }; Using an rndc.conf file
• /etc/rndc.conf specifies defaults for rndc • E.g., key "rndc-key" { algorithm hmac-md5; secret "dY7/uIiR0fKGvi5z50+Q=="; };
options { default-key "rndc-key"; default-server 127.0.0.1; default-port 953; }; Enabling RNDC in the server – named.conf • key definition key rndc-key { secret "dY7/uIiR0fKGvi5z50+Q=="; algorithm hmac-md5; }; – Warning: example secret looks good but is invalid (don't copy it!) • controls statement controls { inet 127.0.0.1 port 953 // for remote host, use allow { 127.0.0.1; } // actual IP keys { "rndc-key"; }; }; What can be done with RNDC
> rndc stop - kills server > rndc status - prints some information > rndc stats - generates stat file (named.stats) > rndc reload - refresh zone(s), with variations > rndc trace - increases debug level > rndc flush - removes cached data • other commands in the ARM TSIG What is TSIG - Transaction Signature?
• A mechanism for protecting a message from a primary to secondary and vice versa
• A keyed-hash is applied (like a digital signature) so recipient can verify message – DNS question or answer – & the timestamp
• Based on a shared secret - both sender and receiver are configured with it What is TSIG - Transaction Signature?
• TSIG (RFC 2845) – authorizing dynamic updates & zone transfers – authentication of caching forwarders
• Used in server configuration, not in zone file Names and Secrets
• TSIG name – A name is given to the key, the name is what is transmitted in the message (so receiver knows what key the sender used)
• TSIG secret value – A value determined during key generation – Usually seen in Base64 encoding Using TSIG to protect AXFR
• Deriving a secret > dnssec-keygen -a
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 Using TSIG to protect AXFR
• 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 ;}; allow-transfer { }; 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”; TIME!!!
• TSIG is time sensitive - to stop replays – Message protection expires in 5 minutes – Make sure time is synchronized – For testing, set the time – In operations, (secure) NTP is needed Questions ? Secured Dynamic Updates Caution
• Portions of this slide set present features that do not appear in BIND until BIND 9.3 – Snapshot code is available for this
• BIND 9.2 can perform most of the dynamic update features Outline
• Dynamic Update Basics • Setting Up A Dynamic Zone • Tools • Securing It • Authorization Configuration • Playing with Update Commands • Interactions with DHCP Getting Data Into DNS
Zone File Primary NS $origin z. @ soa ns ro ns ns1. ns a 1.1.1.1 Dynamic Update
AXFR Network Database
Secondary NS Advantages of Dynamic Updates
• Change DNS data quickly • Make changes from anywhere • No need to reload whole zone • Data becomes more current Uses of Dynamic Update
• Adding a new delegation to a large zone – Cut down on reload times
• Conference attendees – Laptops can use same name, new IP Risks of Dynamic Update
• Authoritative servers listen to the network for data • Authorization checks needed before accepting a request • Server risks being tied up with updates • Dynamic zones are hard to edit via "the old ways" Other Considerations
• Once a zone goes dynamic, it is hard to edit • Mixing dynamic data and critical static data is a bad idea, even neglecting security concerns • This isn't meant to scare you from dynamic update, but to alert you "Secure" Dynamic Update
• Secure refers to the safety of the update requests – Only the right clients will be able to get data into the zone
• Limitations on the term "secure" – Won't stop anyone issuing bad requests – Doesn't address DNSSEC, adding digital signatures to the zone Tools
• In order to do any of this, we need tools (software)
• All are part of a BIND 9 distribution – named - the server, concentrating on conf file – dig - a query/response tool – nsupdate - issues dynamic update messages – rndc - remote name server daemon control – dnssec-keygen - makes the keys needed A static zone zone "myzone.example." { type master; file "myzone.example."; allow-transfer { any; }; }; Adding a dynamic zone zone "myzone.example." { type master; file "myzone.example."; allow-transfer { any; }; }; zone "dynamic.myzone.example." { type master; file "dynamic.myzone.example."; allow-transfer { any; }; allow-update { any; }; }; //note: on-line slide is different dynamic.myzone.example
> cat db.dynamic.myzone.example
$ORIGIN dynamic.myzone.example. $TTL 1d ; 1 day @ IN SOA ns1 root ( 1 ; serial 30m ; refresh (30 minutes) 15m ;retry (15 minutes) 19h ;expire (19h12m) 18min ;minimum (18min) ) NS ns1.myzone.example Journal Files
• Once a dynamic zone begins running – A journal file (
• Basic debugging aid • dig @server domain.name type • Used to verify that change has been made • Used to verify that SOA number increments dig examples
> dig @127.0.0.1 version.bind chaos txt > dig @127.0.0.1 myzone.example. soa +multiline > dig @127.0.0.1 dynamic.myzone.example. soa nsupdate
• Generates updates based upon user input • Used to make requested updates nsupdate example
% nsupdate > server 127.0.0.1 > zone dynamic.myzone.example. > update add alu.dynamic.myzone.example. 600 A 192.168.160.1 > update add dynamic.myzone.example. 600 MX 10 alu > send > quit
• Just to check our work... % dig @127.0.0.1 alu.dynamic.myzone.example. A % dig @127.0.0.1 dynamic.myzone.example. MX rndc
• "Remote" management of server, usually across 127.0.0.1 • Used to stop, reload server • Used to freeze and unfreeze dynamic zone { available in BIND 9.3 } rndc examples
% rndc -c rndc.conf status % rndc -c rndc.conf reload % rndc -c rndc.conf freeze dynamic.myzone.example % rndc -c rndc.conf unfreeze dynamic.myzone.example % rndc -c rndc.conf stop
NOTE: "freeze" and "unfreeze" are introduced in BIND 9.3 dnssec-keygen
• Simple tool to generate keys • Used here to generate TSIG keys dnssec-keygen tsig example
% dnssec-keygen -a HMAC-MD5 -b 128 -n host sample.tsig.key Ksample.tsig.key.+157+02308
% ls Ksample* Ksample.tsig.key.+157+02308.key Ksample.tsig.key.+157+02308.private "Secured" Dynamic Update
• Limited to the security of the requests • Dynamic Updates to a DNSSEC zone is a work in progress • Two steps – Identify and authenticate the updater – Determine if updater is authorized Steps
• Create a separate zone for dynamic updates – (Done) • Configure keys • Configure policy TSIG keys
• Issue: Naming the key – Name is arbitrary, but must be consistent between the named.conf and client – There is an advantage to making it the same as a domain in the zone
• To test the keys, turn on key-based authorization of AXFR - just for testing Making TSIG keys
• dnssec-keygen -a HMAC-MD5 -b 128 -n host \ slave1.dynamic.myzone.example. • dnssec-keygen -a HMAC-MD5 -b 128 -n host \ slave2.dynamic.myzone.example.
• ls: Kslave1.dynamic.myzone.example.+157+42488.key Kslave1.dynamic.myzone.example.+157+42488.private
Kslave2.dynamic.myzone.example.+157+57806.key Kslave2.dynamic.myzone.example.+157+57806.private Adding TSIG to named.conf
key “slave1.dynamic.myzone.example." { algorithm HMAC-MD5; secret "sd7qi6tiw+N5fK3mGNDNJU9TwIju+1ye7r2shgfkxIg="; }; key “slave2.dynamic.myzone.example." { algorithm HMAC-MD5; secret "KXMoZHZIIxVsxKp4aUp6YTy3EswUN9CeDEpneJDOgVM="; }; Configuring TSIG AXFR
• Just so we can see that the keys work zone "dynamic.myzone.example." { type master; file "dynamic.myzone.example."; allow-transfer { key slave1.dynamic.myzone.example.; key slave2.dynamic.myzone.example.; }; allow-update { 127.0.0.1; }; }; Testing with dig
• Fails: % dig @127.0.0.1 dynamic.myzone.example. axfr
• Succeeds: % dig @127.0.0.1 dynamic.myzone.example. axfr -y slave1.dynamic.myzone.example.:KXMoZHZIIxVsxKp4aUp 6YTy3EswUN9CeDEpneJDOgVM=
• This shows that the TSIG key is properly configured in named.conf Key based dynamic updates (TSIG)
zone "dynamic.myzone.example." { type master; file "dynamic.myzone.example."; allow-transfer { key slave1.dynamic.myzone.example.; key slave2.dynamic.myzone.example.; }; allow-update { key user1.dynamic.myzone.example.; key user2.dynamic.myzone.example.; }; }; "Keying" nsupdate
• The next three slides show different ways to add key information to nsupdate – first hides key from "ps -aux" by entering it interactively – second hides it by referencing the file it is in – last puts the secret on the command line Keyed nsupdate #1
% nsupdate > zone dynamic.myzone.example. > server 127.0.0.1 > key user1.dynamic.myzone.example. sd7qi6tiw+N5fK3mGNDNJU9TwIju+1ye7r2shgfkxIg= > update add puri.dynamic.myzone.example. 600 A 192.168.50.1 > send
% dig @127.0.0.1 puri.dynamic.myzone.example A Keyed nsupdate #2
% nsupdate -k Kuser1.dynamic.myzone.example.+157+57806. > zone dynamic.myzone.example. > server 127.0.0.1 > update add alu.dynamic.myzone.example. 900 A 192.168.50.2 > Send
% dig @127.0.0.1 alu.dynamic.myzone.example A Keyed nsupdate #3
% nsupdate -y Kuser1.dynamic.myzone.example.:sd7qi6tiw+N5fK3mGND NJU9TwIju+1ye7r2shgfkxIg= > zone dynamic.myzone.example. > server 127.0.0.1 > update add palak.dynamic.myzone.example. A 90 192.168.50.2 > send
% dig @127.0.0.1 palak.dynamic.myzone.example. A Questions? DNSSEC 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 Why DNSSEC?
• DNS is not secure – Applications depend on DNS • Known vulnerabilities
• DNSSEC protects against data spoofing and corruption Overview
• Introduction • DNSSEC mechanisms – To authenticate servers (TSIG ) – To establish authenticity and integrity of data • Quick overview • New RRs • Using public key cryptography to sign a single zone • Delegating signing authority ; building chains of trust • Key exchange and rollovers • Conclusions DNS: known concepts
• Known DNS concepts: – Delegation, Referral, Zone, RRs, label, RDATA, authoritative server, caching forwarder, resolvers, SOA parameters, etc
– Don’t know? Do ask!
• Operational knowledge with BIND – BIND 8 or 9 named.conf, writing zone files – All examples based on IPv4 Reminder: DNS Resolving Question: www.apnic.net A
www.apnic.net A ? root-server 1 2
www.apnic.net A ? 3“go ask net server @ X.gtld-servers.net” (+ glue) Resolver Caching 192.168.5.10 forwarder 4www.apnic.net A ? 8 (recursive) gtld-server 5 “go ask ripe server @ ns.apnic.net” (+ glue) 9 Add to cache 6 www.apnic.net A ?
10 TTL 7 “192.168.5.10” apnic-server 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 Vulnerabilities protected by DNSKEY / RRSIG / NSEC Cache impersonation Zone administrator
Zone file master Caching forwarder
Dynamic updates slaves resolver
Cache pollution by Data spoofing Difference Between TSIG and DNSSEC
• TSIG secures transaction – Making sure DNS messages come from the right place and aren't modified in transit • DNSSEC secures (signs) zone data – Making sure resource records are those signed by the administrator of the zone • Only endpoints that share a key can use TSIG to verify DNS messages • Any endpoints that support DNSSEC can use it to verify signed zone data DNS Security Extensions
• Described in RFC 2535, allow a zone administrator to digitally sign zone data
• Updates for RFC 2535 – Delegation Signer Resource Record – Legacy Resolver Compatibility for Delegation Signer – DNSKEY RR Secure Entry Point Flag – DNS Security Introduction and Requirements – Protocol Modifications for the DNS Security Extensions – Resource Records for the DNS Security Extensions
• See http://www.dnssec.net/ for DNSSEC related RFCs and Drafts DNS Security Extensions
• TSIG uses a keyed cryptographic hash algorithm, which requires that both endpoints share a key • DNSSEC uses public key cryptography, which doesn't require shared keys • End-to-end integrity check between producer (DNS Admin) and consumer (Resolver, Application) Public Key Cryptography Illustrated
plaintext encrypt ciphertext
K1
ciphertext decrypt plaintext
K2 The Key Pair: Public and Private • In practice – One key of the pair is kept private – The other key is made public, by uploading it to a key server, publishing it via a directory, or having a certification authority sign it in to a certificate Public Key Cryptography
• The magic behind public key cryptography is the key pair • A key pair is generated from a mathematical formula such that data encrypted with one key can only be decrypted by the other • In other words, if – E() is the encryption function – D() is the decryption function – p is plaintext data – c is ciphertext (encrypted) data
• And the key pair is k1 and k2
c = Ek (p), p = Dk Application of Public and Private Keys
• To send private data, encrypt the data in the recipient's public key – Only the recipient, with the corresponding private key, can decrypt it • To sign data, encrypt the data in your private key – If the data decrypts with the corresponding public key, retrieved from a directory or key server, it came from you The DNSKEY Record
• In DNSSEC, each zone has a key pair • The private key – Is stored somewhere secure – Is used to sign zone data • The public key – Is stored in the zone data, as a DNSKEY record – Is used to verify zone data • DNSKEY was known before as the KEY RR The DNSKEY Record (cont.)
• Example: example.com. 86400 IN DNSKEY 256 3 5 ( AQPSKmynfzW4kyBv015MU G2DeIQ3Cbl+BBZH4b/0PY1kxkmvHjcZc8no kfzj31GajIQKY+5CptLr3buXA10hWqTkF7H6 RfoRqXQeogmMHfpftf6zMv1LyBUgia7za6ZEzOJB OztyvhjL742iU/TpPSEDhm2SNKLijfUppn1U aNvv4w== ) • The RDATA fields are: – Flags (256, indicating that this key can be used for authentication and confidentiality, and that it's a zone key) – Protocol (3, indicating that this is a DNSSEC key) – Algorithm (5, indicating that this key is used with the RSA/SHA1 public key algorithm) – The key itself, in base 64 The RRSIG Record
• A zone's private key is used to sign the data in the zone • The signatures are added to the zone in the form of RRSIG records – Example: foo.example SOA ns1.foo.example hostmaster.foo.example. ( 2005072200 ; serial 3600 ; refresh (1 hour) 900 ; retry (15 minutes) 2592000 ; expire (4 weeks 2 days) 3600 ; minimum (1 hour) ) RRSIG SOA 1 2 86400 20050820205058 ( 20050720205058 25993 foo.example. D+JEeIZvzzTc//m/Tq0uwccbfjCHd7siiIYJ fpqy45XU5mMRumkvMH7NyShjjtg+Qijr2uvh J/VpgiVVS38TEg== ) The RRSIG Record (cont.)
• The RDATA fields are: – The type covered (SOA, indicating that this RRSIG record signs the domain name's SOA record) – The protocol (1, indicating that this RRSIG record was produced using RSA) – The number of labels in the domain name signed (2) – The original TTL on the record (86400) – The RRSIG record's expiration (20050820205058, indicating that this RRSIG record expires on August 20, 2005, just before 9 pm GMT) The RRSIG Record (cont.)
• The RDATA fields are: – The RRSIG record's inception (20050720205058, indicating that this RRSIG record was added on July 20, 2005, just before 9 pm GMT) – The key ID (25993), used to identify the key to use to verify the RRSIG record – The signer's domain name (foo.example), used to look up the key to use to verify the RRSIG record – The signature itself, in base 64 The NSEC Record
• RRSIG records are fine for authenticating records
• But how about negative responses, like NXDOMAIN or NODATA? – These don't contain records to sign
• To authenticate those, DNSSEC adds a new record type, NSEC (the RR formerly known as NXT) The NSEC Record
• The NSEC record for a given domain name tells you – Which record types exist for that domain name – Which gaps ("empty space") exists between domain names in a zone – The next domain name in the zone Sorting Zones
• The idea of a "next secure" record suggests that, in DNSSEC, zones have an order • To sort the domain names in a zone into the proper order – Write all owner names as fully qualified – Shift all owner names to lowercase – Sort lexicographically from highest-level (rightmost) label in owner name to lowest-level (leftmost) label – Non-existent labels come before X, so foo.example precedes • X.foo.example Sorting a Zone
• So…this zone foo.example. 86400 IN SOA ns1 hostmaster ( 2001112000 1h 15m 30d 1h )
86400 IN NS ns1 86400 IN MX 10 mail 3600 IN A 192.168.0.1 www 86400 IN CNAME @ ns1 86400 IN A 192.168.0.3 ns2 86400 IN A 10.0.0.1 sub 86400 IN NS ns1.sub sub 86400 IN NS ns2.sub ns1.sub 3600 IN A 172.16.0.1 ns2.sub 3600 IN A 172.16.0.2 mail 86400 IN A 192.168.0.2 Sorting a Zone (cont.)
• Would sort to this foo.example. 86400 IN SOA ns1.foo.example. ( hostmaster.foo.example. 2001112000 1h 15m 30d 1h ) foo.example. 86400 IN NS ns1.foo.example. foo.example. 86400 IN MX 10 foo.example. 3600 IN A 192.168.0.1 mail.foo.example. 86400 IN A 192.168.0.2 ns1.foo.example. 86400 IN A 192.168.0.3 ns2.foo.example. 86400 IN A 10.0.0.1 sub.foo.example. 86400 IN NS ns1.sub.foo.example. sub.foo.example. 86400 IN NS ns2.sub.foo.example. www.foo.example. 86400 IN CNAME foo.example. ns1.sub.foo.example. 3600 IN A 172.16.0.1 ns2.sub.foo.example. 3600 IN A 172.16.0.2 A Sorted Zone with NSEC Records foo.example. 86400 IN SOA ns1.foo.example. hostmaster.foo.example. ( 2001112000 ; serial 3600 ; refresh (1 hour) 900 ; retry (15 minutes) 2592000 ; expire (4 weeks 2 days) 3600 ; minimum (1 hour) ) 86400 NS ns1.foo.example. 86400 NS ns2.foo.example. 3600 A 192.168.0.1 86400 MX 10 mail.foo.example. 86400 NSEC mail.foo.example. A NS SOA MX NSEC mail.foo.example.86400 IN A 192.168.0.2 86400 NSEC ns1.foo.example. A NSEC ns1.foo.example. 86400 IN A 192.168.0.3 86400 NSEC ns2.foo.example. A NSEC ns2.foo.example. 86400 IN A 10.0.0.1 86400 NSEC sub.foo.example. A NSEC ns1.sub.foo.example. 3600 IN A 172.16.0.1 ns2.sub.foo.example. 3600 IN A 172.16.0.2 sub.foo.example. 86400 IN NS ns1.sub.foo.example. 86400 IN NS ns2.sub.foo.example. 86400 KEY 49408 3 3 86400 NSEC www.foo.example. NS KEY NSEC www.foo.example. 86400 IN CNAME foo.example 86400 NSEC foo.example. CNAME NSEC The Chain of Trust
• What prevents a hacker from breaking in to the primary master name server and changing the zone data, including the zone's DNSKEY record? – The DNSKEY record is signed by the zone's private key – This DNSKEY can be securely identified with the according DS RR from the parents' zone – The DS RR in the parent zone is signed by the parent zone's private key. (This builds the "chain of trust”) • Security aware resolver have a public key (or a hash of a public key) of a trusted-"root" ("." or DS RR) • DS RR can be used to start an "Island of security" down from ". The Chain of Trust
• This established a chain of trust from any signed zone to the root – The zone's DNSKEY record is self-signed by its private zone- signing key – The zone's DS record (in the parent zone) is signed by the parent-zones' private key – The parent zone's DS record is used to identify the zone's public key, and so on – The root zone's DNSKEY record is widely known Or – The start of a chain of trust can be verified by a locally configured public key (or hash of a Public Key) The Chain of Trust (cont.)
• Example:
$TTL 3600 ; 1 hour foo.example IN DNSKEY 256 3 1 ( AQPJovN2i//gtI17J28mIHvwy0QZaoA60IUIE98Hy6NT sJLHD8kVAbydZTVlej5FJpjpnK5Im+hRnnGVq3GIZYmH ) ; key id = 25993
RRSIG DNSKEY 1 2 3600 20011220212022 ( 20011120212022 54056 example. PE84yB2wUU4Ai49b3+8p01esZWIs2nue8bKxf+Kn3tW7 wCrvaRDsGCvKePWwP8V3A5tkez3wtQif7uIigvlq+w== ) The Chain of Trust Illustrated (Detail view) The Chain of Trust Illustrated (Detail view) Implementation of the Chain of Trust
• If the chain of trust is broken • However, administrators of individual name servers can work around this by adding trusted-keys statements to their name server's named.conf files • Example: trusted-keys { "foo.example." 256 3 1 "AQPJovN2i//gtI17J28mIHvwy0QZaoA60IUIE98Hy6NTsJLHD8 VAbydZTVlej5FJpjpnK5Im+hRnnGVq3GIZYmH"; }; The DS (Delegation Signer) Record
• The DS RR is used in the DNSKEY authentication process – Answer to the Question: is the zone's public key (DNSKEY) valid? • The DS Key is stored in the parent zone of the DNSKEY's zone • DS RR simplifies DNS zone management and zone signing The DS (Delegation Signer) Record
• Example – DNSKEY in (child-)zone sub.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz fwJr1AYtsmx3TGkJaNXVbfi/ 2pHm822aJ5iI9BMzNXxeYCmZ DRD99WYwYqUSdjMmmAphXdvx egXd/M5+X7OrzKBaMbCVdFLU Uh6DhweJBjEVv5f2wwjM9Xzc nOf+EPbtG9DMBmADjFDc2w/r ljwvFw== ) ; key id = 60485 – DS in Parent-zone sub.example.com. 86400 IN DS 60485 5 1 ( 2BB183AF5F22588 179A53B0A 98631FAD1A292118 ) The DS (Delegation Signer) Record • The RDATA fields are: – Key Tag field (to help identify the key in the child zone) – Algorithm field (of the key in the child zone) – Digest Type field (Algorithm of the Digest/Hash value) – The Digest/Hash of the Key in the child zone, in base64 Steps to Signing a Zone 1. Generate a key pair for the zone Options { dnssec-enable yes; }; 2. Add the DNSKEY record to the zone 3. Sign the zone 4. (Optional) Look how much bigger it got 5. Update the zone statement 6. Send the dsset to your parent zone's administrator scp dsset* [email protected]:/var/named/gtld-sg/dsset 7. Wait for DS RR in parent zone 8. Test 1. Generate a Key Pair for the Zone
• Example: # dnssec-keygen -a RSA -b 512 -n ZONE foo.example. Kfoo.example.+001+25993 // 4 files will be generated * Keyset, dsset, Public & Private Keys
# more Kfoo.example.+001+25993.key foo.example. IN KEY 256 3 1 AQPJovN2i//gtI17J28mIHvwy0QZaoA60IUIE98Hy6NTsJLHD8kVAbyd ZTVlej5FJpjpnK5Im+hRnnGVq3GIZYmH
# more Kfoo.example.+001+25993.private Private-key-format: v1.2 Algorithm: 1 (RSA) Modulus: yaLzdov/4LSNeydvJiB78MtEGWqAOtCFCBPfB8ujU7CSxw/J FQG8nWU1ZXo+RSaY6JvZ5xlatxiGWJhw== PublicExponent: Aw== PrivateExponent: hmyiTwf/6yMI/MT0xBWn9dzYEPGq0eBYsA0/WofCN8ndlEJZnhdBNqdbJ53K51qN odHoWw== Prime1: 5OjA15uBHdv1wDcQIrOWRviHM6OkqTwOa 4X/rawxdvPFX8xsSKzD5S9sUZ9T8NlojVVY+YdnV5XU= Exponent1: +RlOzvUx4s= Prime2: rime1: 5OjA15uBHdv1wDcQIrOWRviHM6OkqTwOa +RlOzvUx4s= Prime2: Prime1: 5OjA15uBHdv1wDcQIrOWRviHM6OkqTwOa+RlOzvUx4s= Prime2: Prime1:5OjA15uBHdv1wDcQIrOWRviHM6Okqrime1: 2. Add the DNSKEY Record to the Zone • Example:
# more db.foo.example $TTL 1d foo.example. 86400 IN SOA ns1 hostmaster ( 2001112000 1h 15m 30d 1h) 86400 IN NS ns1 86400 IN NS ns2 86400 IN MX 10 mail 3600 IN A 192.168.0.1 www 86400 IN CNAME @ ns1 86400 IN A192.168.0.3 ns2 86400 IN A 10.0.0.1 sub 86400 IN NS ns1.sub sub 86400 IN NS ns2.sub ns1.sub 3600 IN A 172.16.0.1 ns2.sub 3600 IN A 172.16.0.2 mail 86400 IN A 192.168.0.2
$INCLUDE Kfoo.example.+001+25993.key 3. Sign the Zone
• Example:
# dnssec-signzone -o foo.example db.foo.example db.foo.example.signed
# more db.foo.example.signed ; File written on Tue Nov 20 16:55:15 2001 ; dnssec_signzone version 9.1.3 foo.example. 86400 IN SOA ns1.foo.example. hostmaster.foo.example. 2001112000 ; serial 3600 ; refresh (1 hour) 900 ;retry (15 minutes) 2592000 ; expire (4 weeks 2 days) 3600 ; minimum (1 hour) ) 86400 RRSIG SOA 1 2 86400 20011220235515 ( 20011120235515 25993 foo.example. QiBBXkDhaR1XR+bJo1W+2XhehvA8go45WRublbD3Ghas38tHeaiT1LfN3 7ZIgnHZtlYobLrE/y1cikXuo58pnA== ) 4. Look How Much Bigger It Got
• Example:
# wc db.foo.example*
15 78 587 db.foo.example 112 399 4246 db.foo.example.signed 127 477 4833 total 5. Update the Zone Statement
• Example: # cat /etc/named.conf zone "foo.example" { type master; file "db.foo.example.signed"; }; # rndc reload foo.example 6. Send the dsset to Your Parent Zone's Administrator
• # mail hostmaster@example Subject: Please sign the foo.example dsset
Dude,
Would you please sign the foo.example dsset for me and put the DS RR in your zone.
You rock,
dsset-foo.example. 8. Wait for DS RR in parent zone
• Example:
foo.example. 86400 IN DS 25993 3 1 ( 2BB183AF5F22588 179A53B0A98631FAD1A292118 ) 9. Test • Example: dig soa foo.example +dnssec ;; QUESTION SECTION: ;foo.example. IN SOA
;; ANSWER SECTION: foo.example. 86400 IN SOA ns1.foo.example. hostmaster.foo.example. 2001112000 3600 900 2592000 3600 foo.example. 86400 IN RRSIG SOA 1 2 86400 20011221203100 20011121203100 25993 foo.example. jaxaqjnl9uuFx4NxbW7ftUJvENzlXez0NRSuaHpw/awrw3k8uV2aZXaD tNz/OWlpvu5p+lDn3/2AI83ppNLbfw== ;; AUTHORITY SECTION: foo.example. 86400 IN NS ns2.foo.example foo.example. 86400 IN NS ns1.foo.example. foo.example. 86400 IN RRSIG NS 1 2 86400 20011221203100 20011121203100 25993 foo.example DOIahoJejw99MVSKhJDLaIeARJ8NRQ9QXQxMzV8Nq5cr79moWPPvIV+Q pdF/jK3KhvTBQ4cnmjq0axL/c1V2cA== ;; Query time: 3 msec ;; SERVER: 192.168.0.1#53(192.168.0.1 Resigning a Zone
• Just run dnssec-signzone on it again • Example:
# dnssec-signzone -o foo.example db.foo.example.signed \ Kfoo.example.+001+25993
# mv db.foo.example.signed.signed db.foo.example.signed # reload foo.example Questions? Summary
• DNS Concepts • BIND • Recursive Server • Configuring Domains • Reverse DNS • IPv6 Reverse • ACLs • Views • RNDC • TSIG • Secured Dynamic Updates • DNSSEC Thank you! :)