Vous êtes sur la page 1sur 12

Points of consideration when adopting DNSSEC

APRICOT2014 @ Petaling Jaya, Malaysia ISOC NetOps Workshop 1 Wednesday, 26 Feb 2014 9:00-10:30 Miki Takata - NTT Communications Corporation Innovative Architecture Center - DNSOPS.JP executive board member

Why DNSSEC?
!! DNS protocol is vulnerable to cache poisoning ! Cache poisoning
"! Possible techniques for cyber crimes "! ex. phishing, Advanced persistent threat

!! DNSSEC provides patches to DNS ! Effective against cache poisoning


"! To protect DNS data

General points
!! Simple is Best !! Avoid black boxes !! Prepare for troubles ! What kind of troubles can be expected? ! What actions can be taken? !! Have better understanding of DNSSEC protocols and/or tools

Authoritative DNS Server (1)


!! System design for preventing the validation error ! hidden master / (validation proxy) / public slave ! ex. NLnet Labs: Credns
"! http://www.nlnetlabs.nl/projects/credns/

Authoritative DNS Server (2)


!! qmail problem ! (This is *NOT* a DNSSEC problem) ! On remote delivery, qmail queries "ANY" type
"! Answers may include "TXT", "RRSIG", etc.. "! May lead to large packet more than 512 bytes

! qmail can't handle DNS answer packet larger than 512 bytes
"! deferral: CNAME_lookup_failed_temporarily._(#4.4.3)

! To resolve: apply the patch to qmail


"! https://www.ckdhr.com/ckd/qmail-103.patch

!! caution: Some people are using qmail without knowing it ! ex. Linux Controller, mail hosting, etc..

Authoritative DNS Server (3)


!! If you provides slave service, get ready for DNSSEC !! Typical slave service ! Master is controlled by the customer ! Slave is provided ISP, hosting, etc.. (You) !! One day, customer will sign his/her zone on master ! axfr signed zone to slave ! slave server will adopt DNSSEC unintentionally!

Authoritative DNS Server (4) source IP: n.n.n.n

spoof source IP: n.n.n.n

Victim n.n.n.n

large.example. ANY

Reect + Amplication

RRL: Response Authoritative Rate Limit DNS Server 7

Cache DNS Server (1)


!! bogus domains are common these days ! by operational mistake / software failure ! by attack !! How to react to bogus domains ! define your policy before adopting DNSSEC
"! stop validating bogus domains ? "! leave it as bogus ?

! which level of domain ?


"! ROOT or TLD ? "! individual domain ?

!! should watch critical / high profile domains ! detect failures quickly !! should follow @ComcastDNS # ! bogus domain report by Comcast
8

Cache DNS Server (2)


!! On customer support ! Additional troubleshooting procedures may be needed
"! When the customer says: "! "I can't browse http://example.com/"

! Currently, operators ask questions such as:


"! "What operating system and browser do you use ?" "! "Which IP address assigned to your PC ?" "! "Please, ping to 192.0.2.80", etc..

! Add one more question


"! "Which DNS server do you use ?"

! Operators should check


"! Is customer using our DNS ? "! Is the zone bogus on our DNS ?

Tools to check
!! Check zone conditions from other sites !! dig example.com @DNS +dnssec ! Check for "ad" flag !! useful check tool sites: ! DNSViz (A DNS visualization tool)
"! Sandia National Laboratories "! http://dnsviz.net/

! DNSSEC Analyzer VeriSign Labs


"! http://dnssec-debugger.verisignlabs.com/

10

Using result of validation


!! DNSSEC awareness is hard to see !! So let's differentiate your services by DNSSEC !! DNSSEC/TLSA Validator ! https://www.dnssec-validator.cz/

!! "DNSSEC Ready Logo" by DNSSEC Japan ! Self check principle (no approval) ! http://dnssec.jp/?page_id=595
11

Conclusion
!! Many considerations in adopting DNSSEC !! For steady operation ! Be prepared for future incidents / troubles ! Needless to say, DNS operation, of course # !! Relationship with Customer Support !! Use existing tools / web services

12