SlideShare a Scribd company logo

dns-sec-4-slides

•
•
kj teoh
kj teoh

This document provides an overview of how DNS lookups generally work, with a focus on DNS security (DNSSEC). It explains the standard DNS lookup process, where a user's request is recursively resolved through root servers, TLD servers, and name servers until an IP address is returned. It then discusses DNSSEC in more detail, explaining the new record types it introduces like DNSKEY, RRSIG, DS, and NSEC to authenticate records and prove non-existence. The document emphasizes that while DNSSEC aims to validate records are authentic, recursive resolvers still may not perform validation, limiting its effectiveness. It also provides steps to configure a zone with DNSSEC.

Related slideshows

DNS Attacks
DNS AttacksDNS Attacks
DNS Attacks
 
DNS High-Availability Tools - Open-Source Load Balancing Solutions
DNS High-Availability Tools - Open-Source Load Balancing SolutionsDNS High-Availability Tools - Open-Source Load Balancing Solutions
DNS High-Availability Tools - Open-Source Load Balancing Solutions
 
Encrypted DNS - DNS over TLS / DNS over HTTPS
Encrypted DNS - DNS over TLS / DNS over HTTPSEncrypted DNS - DNS over TLS / DNS over HTTPS
Encrypted DNS - DNS over TLS / DNS over HTTPS
 
1 of 4
Download to read offline
DNS Lookups - How DNS Generally Works – NOT DNS SEC DNS is probably one of the most poorly understood protocols and its probably because it has many “faces”. The following example is an overview of how its all held together by Internet cloth. You send a “name”, you expect an IPv4 or IPv6 in return. www google.com.my a-m.root.servers .com.root.servers .com.my.root.servers ns.google.com.my root.hints file a.root.server xxx b.root.server yyy .. m.root.server.zzz ISP Recursive DNS Server 1 2 3 4 User will query ISP DNS who in turn refers to root.hints in local system 1. a-m.root servers queried for .com.my they will return with a list of .com.root servers 2. query goes to .com.root servers and a list is returned for .com.my.root 3. query goes to .com.my.root servers and a specific list is returned for ns.google.com.my 4. query goes to ns.google.com.my and a “A” record is returned (or AAAA) Onces this happens / completes, your ISP will cache the records for a specific period and does not have to repeat the entire process again and again. For some real samples, do “dig isc.org +trace” UDP/53 IPv4/IPv6 149.20.64.69 Zone Record www A 149.20.64.69 mail A xxx.yyy ftp A yyy.zzz May transport on IPv6 anycast / unicast Glue Records May transport on IPv4 but query for AAAA record or vice-versa
DNS Lookups - How DNS Generally Works – DNS Sec - Recursion DNS Sec in this context is taken to mean … if the recursion is “secure” and if the results being returned by my ISPs DNS server is authentic and/or correct. In otherwords, some due diligence employed by my provider to help ensure that the returned records are “real”. DNS Sec does not encrypt traffic. kjteoh@uruk:~$ dig isc.org +dnssec ; <<>> DiG 9.10.3 <<>> isc.org +dnssec ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30990 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;isc.org. IN A ;; ANSWER SECTION: isc.org. 1 IN A 149.20.64.69 isc.org. 1 IN RRSIG A 5 2 60 20151126190706 This is an example where validation / authentication has taken placed and it is marked with the “ad” which has been circled. EDNS enabled. Traditional UDP DNS was restricted to 512 bytes and this has since been extended with EDNS. Participating DNS servers will negotiated and settle on a “size”. Note: DNS can do TCP too The “problem” here is... not all zones are DNS signed/enabled. So it is not digs function to NOT display records which are not DNS Sec enabled. Records will display albeit w/o the “ad” marker. So ISPs should commit to a few extra CPU cycles and enable DNS Sec validation. This does not however appear to be happening. Users are then left none the wiser. On the one part, DNS Sec zone appear to be valid. All steps and procedures have been employed to make it good. But if the ISPs recursive element does not commit CPU cycles to DNS Sec, then all value associated is lost. See sample immediately on the lower left where all semblance of DNS Sec exist minus the validation... absurdity or ignorance? kjteoh@latitude:~$ dig isc.org +dnssec ; <<>> DiG 9.10.3 <<>> isc.org +dnssec ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 545 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;isc.org. IN A ;; ANSWER SECTION: isc.org. 49 IN A 149.20.64.69 isc.org. 49 IN RRSIG A 5 2 60 20151126190706 This is where the problems begin to start. ISC.ORG is DNS Sec ready and the query being performed requires the +dnssec option. The flags returned however DO NOT indicate that its been validated. All other indications return indicate that it is DNS Sec validated, but in truth, not. Note: RRSIG. kjteoh@uruk:~$ delv isc.org ; fully validated isc.org. 60 IN A 149.20.64.69 isc.org. 60 IN RRSIG A 5 2 60 201 kjteoh@uruk:~$ delv -i isc.org ; answer not validated isc.org. 60 IN A 149.20.64.69 Preferred behavior – No RRSIG Missing “ad”
DNS Lookups - How DNS Generally Works – DNS Sec – Record Types I think there is some confusion about DNS Sec record types. DNS Sec does introduce a few new records but too, no human intervention is really needed for its creation... unlike say, an MX record or a A record which had to be written by hand to a “zone” file. The general procedure of creating a DNS Sec zone/record is to firstly set it up in the traditional fashion, and create all the required MX, A & CNAME records. Only after you're satisfied with this do you then proceed with a ZSK & KSK. After that, you would create a DS Key and have this installed at your Parent DNS Server. This will be used as a Secure Entry Point (SEP). In truth, it is the SEP that becomes the single most important factor in ensuring that your DNS Sec set up or zones work accordingly. Without which, your zone (DNS Sec enabled) is worthless. DNSKEY Used: Sign the zone (ZSK Zone Signing Key – shorter bits) Sign the Key that signed the zone (KSK – longer bits) RRSIG – Resource Record Signature Used: Signature typically for: IN NS ns1.xxx.com / IN A www.xxx.com DS – Delegation Signer Used: Records given to your PARENT to confirm your identity xxx.com DLV – DNSSEC Look-aside Validation Similar to DS above. The parent may not be DNSSEC ready … use DLV If I buy a domain from godaddy.com I will have to do the following: i. Use a DNS server to sign the zone (DNSKEY process ZSK/KSK) ii. RRSIG record will be created automatically iii. Generate a DS record which looks like MD5/SHA(2) key iv. Go to godaddy.com fill in the blanks... v. Eg. My ns1.xxx is IP Address, ns2.xxx is IP Address vi. Eg. My DS hash is “677b80bcf6712c04669bc97b7” .com.my.root.servers ns.google.com.my www DS Record/Hash is installed … for zone/domain record xxx.com This is the SEP. The response must have come from here ONLY. When the ISPs recursion DNS can properly identify that the SEP is indeed valid, the validation of the zone is complete. This can only be achieved where few conditions are met. One, ISP DNS is DNS Sec enabled. Two, the zone is duly ZSK/KSK'ed. Last, a DS Key is obtained and properly installed on the Parent DNS Server (which too must be DNS Sec enabled). Otherwise, use DLV – BUT is becoming depreciated as more and more root servers are becoming DNS Sec aware.
DNS Lookups - How DNS Generally Works – DNS Sec – NSEC DNS Servers have traditionally returned NXDOMAIN when no record is found. With DNS Sec however, a new NSEC record is returned in place of NXDOMAIN. What DNS Sec does here is attempt to prove that the queries-for record is non-existing by returning the NEXT available record in its “dovetail”. kjteoh@my-anoc0:~$ dig gone.isc.org ; <<>> DiG 9.4-ESV-R4 <<>> gone.isc.org ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 9945 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 NSEC – Next Secure – returns NSEC __name__.isc.org NSEC3 – Next Secure (v3) – returns NSEC3 __hash__record__isc.org kjteoh@uruk:~$ dig GONE.isc.org +dnssec ; <<>> DiG 9.10.3 <<>> GONE.isc.org +dnssec ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 47298 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1 isc.org. 3293 IN NSEC _adsp._domainkey.isc.org. A NS SOA MX TXT …. NOTE: isc.org NS server proving to you that next record is adsp...isc.org Traditional Response Note: NSEC will return text records and NSEC3 will returned hashed records which will in turn totally prevent domain “walking”. We should remember that these records do not required explicit configuration by hand. The process of creating the ZSK / KSK will “encapsulate” the regular ZONE record and create the additional records required. In otherwords, while you would need to write out an A record, you DO NOT need to do the same for an NSEC or DS KEY or RRSIG entry. Steps Required to create DNS Sec Zone 1. ready to host zone raj.com.my - regular zone file created 2. dnssec-keygen -a RSASHA256 -b 1024 raj.com.my (this will create pub/pri key ZSK) 3. dnssec-keygen -a RSASHA256 -b 2048 -f KSK raj.com.my (this will create pub/pri key KSK – NOTE) 4. config named.conf to include path to keys. Continue → zone "raj.com.my" IN { type master; file "bind/keys/raj.com.my.db"; key-directory "bind/keys/raj.com.my"; inline-signing yes; auto-dnssec maintain; }; 5. reload Bind and run dig @locahost raj.com.my +dnssec You should get RRSIG values 7. dnssec-dsfromkey -a SHA1 your-PUB-KSK-KEY raj.com.my. IN DS 1495 8 1 78E72B-Shortened

More Related Content

dns-sec-4-slides

  • 1. DNS Lookups - How DNS Generally Works – NOT DNS SEC DNS is probably one of the most poorly understood protocols and its probably because it has many “faces”. The following example is an overview of how its all held together by Internet cloth. You send a “name”, you expect an IPv4 or IPv6 in return. www google.com.my a-m.root.servers .com.root.servers .com.my.root.servers ns.google.com.my root.hints file a.root.server xxx b.root.server yyy .. m.root.server.zzz ISP Recursive DNS Server 1 2 3 4 User will query ISP DNS who in turn refers to root.hints in local system 1. a-m.root servers queried for .com.my they will return with a list of .com.root servers 2. query goes to .com.root servers and a list is returned for .com.my.root 3. query goes to .com.my.root servers and a specific list is returned for ns.google.com.my 4. query goes to ns.google.com.my and a “A” record is returned (or AAAA) Onces this happens / completes, your ISP will cache the records for a specific period and does not have to repeat the entire process again and again. For some real samples, do “dig isc.org +trace” UDP/53 IPv4/IPv6 149.20.64.69 Zone Record www A 149.20.64.69 mail A xxx.yyy ftp A yyy.zzz May transport on IPv6 anycast / unicast Glue Records May transport on IPv4 but query for AAAA record or vice-versa
  • 2. DNS Lookups - How DNS Generally Works – DNS Sec - Recursion DNS Sec in this context is taken to mean … if the recursion is “secure” and if the results being returned by my ISPs DNS server is authentic and/or correct. In otherwords, some due diligence employed by my provider to help ensure that the returned records are “real”. DNS Sec does not encrypt traffic. kjteoh@uruk:~$ dig isc.org +dnssec ; <<>> DiG 9.10.3 <<>> isc.org +dnssec ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30990 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;isc.org. IN A ;; ANSWER SECTION: isc.org. 1 IN A 149.20.64.69 isc.org. 1 IN RRSIG A 5 2 60 20151126190706 This is an example where validation / authentication has taken placed and it is marked with the “ad” which has been circled. EDNS enabled. Traditional UDP DNS was restricted to 512 bytes and this has since been extended with EDNS. Participating DNS servers will negotiated and settle on a “size”. Note: DNS can do TCP too The “problem” here is... not all zones are DNS signed/enabled. So it is not digs function to NOT display records which are not DNS Sec enabled. Records will display albeit w/o the “ad” marker. So ISPs should commit to a few extra CPU cycles and enable DNS Sec validation. This does not however appear to be happening. Users are then left none the wiser. On the one part, DNS Sec zone appear to be valid. All steps and procedures have been employed to make it good. But if the ISPs recursive element does not commit CPU cycles to DNS Sec, then all value associated is lost. See sample immediately on the lower left where all semblance of DNS Sec exist minus the validation... absurdity or ignorance? kjteoh@latitude:~$ dig isc.org +dnssec ; <<>> DiG 9.10.3 <<>> isc.org +dnssec ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 545 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;isc.org. IN A ;; ANSWER SECTION: isc.org. 49 IN A 149.20.64.69 isc.org. 49 IN RRSIG A 5 2 60 20151126190706 This is where the problems begin to start. ISC.ORG is DNS Sec ready and the query being performed requires the +dnssec option. The flags returned however DO NOT indicate that its been validated. All other indications return indicate that it is DNS Sec validated, but in truth, not. Note: RRSIG. kjteoh@uruk:~$ delv isc.org ; fully validated isc.org. 60 IN A 149.20.64.69 isc.org. 60 IN RRSIG A 5 2 60 201 kjteoh@uruk:~$ delv -i isc.org ; answer not validated isc.org. 60 IN A 149.20.64.69 Preferred behavior – No RRSIG Missing “ad”
  • 3. DNS Lookups - How DNS Generally Works – DNS Sec – Record Types I think there is some confusion about DNS Sec record types. DNS Sec does introduce a few new records but too, no human intervention is really needed for its creation... unlike say, an MX record or a A record which had to be written by hand to a “zone” file. The general procedure of creating a DNS Sec zone/record is to firstly set it up in the traditional fashion, and create all the required MX, A & CNAME records. Only after you're satisfied with this do you then proceed with a ZSK & KSK. After that, you would create a DS Key and have this installed at your Parent DNS Server. This will be used as a Secure Entry Point (SEP). In truth, it is the SEP that becomes the single most important factor in ensuring that your DNS Sec set up or zones work accordingly. Without which, your zone (DNS Sec enabled) is worthless. DNSKEY Used: Sign the zone (ZSK Zone Signing Key – shorter bits) Sign the Key that signed the zone (KSK – longer bits) RRSIG – Resource Record Signature Used: Signature typically for: IN NS ns1.xxx.com / IN A www.xxx.com DS – Delegation Signer Used: Records given to your PARENT to confirm your identity xxx.com DLV – DNSSEC Look-aside Validation Similar to DS above. The parent may not be DNSSEC ready … use DLV If I buy a domain from godaddy.com I will have to do the following: i. Use a DNS server to sign the zone (DNSKEY process ZSK/KSK) ii. RRSIG record will be created automatically iii. Generate a DS record which looks like MD5/SHA(2) key iv. Go to godaddy.com fill in the blanks... v. Eg. My ns1.xxx is IP Address, ns2.xxx is IP Address vi. Eg. My DS hash is “677b80bcf6712c04669bc97b7” .com.my.root.servers ns.google.com.my www DS Record/Hash is installed … for zone/domain record xxx.com This is the SEP. The response must have come from here ONLY. When the ISPs recursion DNS can properly identify that the SEP is indeed valid, the validation of the zone is complete. This can only be achieved where few conditions are met. One, ISP DNS is DNS Sec enabled. Two, the zone is duly ZSK/KSK'ed. Last, a DS Key is obtained and properly installed on the Parent DNS Server (which too must be DNS Sec enabled). Otherwise, use DLV – BUT is becoming depreciated as more and more root servers are becoming DNS Sec aware.
  • 4. DNS Lookups - How DNS Generally Works – DNS Sec – NSEC DNS Servers have traditionally returned NXDOMAIN when no record is found. With DNS Sec however, a new NSEC record is returned in place of NXDOMAIN. What DNS Sec does here is attempt to prove that the queries-for record is non-existing by returning the NEXT available record in its “dovetail”. kjteoh@my-anoc0:~$ dig gone.isc.org ; <<>> DiG 9.4-ESV-R4 <<>> gone.isc.org ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 9945 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 NSEC – Next Secure – returns NSEC __name__.isc.org NSEC3 – Next Secure (v3) – returns NSEC3 __hash__record__isc.org kjteoh@uruk:~$ dig GONE.isc.org +dnssec ; <<>> DiG 9.10.3 <<>> GONE.isc.org +dnssec ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 47298 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1 isc.org. 3293 IN NSEC _adsp._domainkey.isc.org. A NS SOA MX TXT …. NOTE: isc.org NS server proving to you that next record is adsp...isc.org Traditional Response Note: NSEC will return text records and NSEC3 will returned hashed records which will in turn totally prevent domain “walking”. We should remember that these records do not required explicit configuration by hand. The process of creating the ZSK / KSK will “encapsulate” the regular ZONE record and create the additional records required. In otherwords, while you would need to write out an A record, you DO NOT need to do the same for an NSEC or DS KEY or RRSIG entry. Steps Required to create DNS Sec Zone 1. ready to host zone raj.com.my - regular zone file created 2. dnssec-keygen -a RSASHA256 -b 1024 raj.com.my (this will create pub/pri key ZSK) 3. dnssec-keygen -a RSASHA256 -b 2048 -f KSK raj.com.my (this will create pub/pri key KSK – NOTE) 4. config named.conf to include path to keys. Continue → zone "raj.com.my" IN { type master; file "bind/keys/raj.com.my.db"; key-directory "bind/keys/raj.com.my"; inline-signing yes; auto-dnssec maintain; }; 5. reload Bind and run dig @locahost raj.com.my +dnssec You should get RRSIG values 7. dnssec-dsfromkey -a SHA1 your-PUB-KSK-KEY raj.com.my. IN DS 1495 8 1 78E72B-Shortened