DNSSEC Signing Experiences. Michael Sinatra, UC Berkeley Internet2 Member Meeting 3 November 2010

Transcription

1 DNSSEC Signing Experiences Michael Sinatra, UC Berkeley Internet2 Member Meeting 3 November

2 Why deploy DNSSEC? DNS has traditionally been an asecure protocol. More applications rely on security--from the DNS perspective, integrity becomes important. Then there s the Kaminsky vulnerability. Turns out it s much easier to poison DNS caches than we previously thought. More applications can use the DNS if integrity is guaranteed. Michael Sinatra 2

3 Okay, but why deploy DNSSEC at a university? Universities aren t banks, but they still have a lot of data people want. Think of 50,000 SSNs. (Did I say 50,000? More like 1,000,000.) There s a lot of money that goes through the hands of UC. But we re also a research institution: We should be willing to do what it takes to be early adopters of new technologies. We should also go out and share our experiences when possible. Michael Sinatra 3

4 Key-signing/management tools Appliances: Infoblox, Secure64, etc. OpenDNSSEC: Very full-featured, useful for large installations-- possibly even TLDs. Supports HSMs. dnssec-tools.org: Simple, lightweight signing tools. Initially only supported Fedora (later RHEL too). Tools not very portable away from Linux. zkt: Also lightweight and fairly simple, bundled with BIND and in FreeBSD ports collection. (Had to do some very minor C code modifications to get it to do exactly what I wanted.) Michael Sinatra 4

5 Existing DNS Management Most DNS is managed through home-grown web application. Written in Perl. Runs on FreeBSD systems. Stores data in PostgreSQL (8.4, for you scoring at home). Backend scripts generate zonefiles (BIND format) from PostgreSQL and push them out to the DNS master servers. ==> Opportunity to insert signing process here Michael Sinatra 5

6 Existing DNS Management Generated zonefiles placed in single directory (oops). Not always great for key management. Kberkeley.edu key Kberkeley.edu private Kberkeley.edu key Kberkeley.edu private If you have all of your subzones keys in one directory, you don t want to end up accidentally doing something like: dnssec-signzone [ ] *berkeley.edu*.private Most tools want each zone and associated keys in a single, separate directory per zone. Michael Sinatra 6

7 Existing DNS Management DNS subdomains are created when you put another dot in a DNS name: foo.berkeley.edu mail.foo.berkeley.edu workstation1.foo.berkeley.edu Subdomains can be represented in DNS as separate zones ( zone cut ) or as embedded labels in existing ( parent ) zone. Michael Sinatra 7

8 Zone cut foo.berkeley.edu www mail workstation1 IN SOA [ ] IN NS [ ] IN A [ ] IN AAAA [ ] IN A [ ] IN AAAA [ ] IN A [ ] IN AAAA [ ] Michael Sinatra 8

9 Embed in parent zone berkeley.edu [ ] mail.foo workstation1.foo IN SOA [ ] IN NS [ ] IN A [ ] IN AAAA [ ] IN A [ ] IN AAAA [ ] IN A [ ] IN AAAA [ ] Michael Sinatra 9

10 Existing DNS Management Our application supports both types and both types are used, with separate files being created regardless, and placed in the parent using $INCLUDE (oops-oops!). And for various other reasons, it s really hard to convert embedded subdomains into zone cuts. Can t just walk through directory and sign every file I see. Michael Sinatra 10

11 Other gotchas Serial numbers are tricky! Must be incremented for zone to be transferred to slave DNS servers. Tools sometimes have different ways of dealing with this. Existing regime has a particular way of dealing with this (and yours is probably different). Because zones must be periodically re-signed, even if the data is unchanged, your signed zones may get out-of sync with what your management app thinks! This is especially true with bump in the wire (signing appliance) and bump in the stack approaches (like this one). Michael Sinatra 11

12 Other gotchas Example: Many tools support unixtime, but many existing DNS management processes use date-time format. unixtime: date-time: Uh-oh! The unixtime is convenient, but it s less than the current date-time. Michael Sinatra 12

13 Signing regime Script parses generated named.conf file and creates (if necessary) directory for zone(s). Uses BIND s named-compilezone to create monolithic zonefile in format that zkt likes and get rid of all of those icky $INCLUDEs! zkt then signs the zones and increments the serial number in the unsigned (compiled) zone. Date-time serial numbers stay (pretty much in sync). Michael Sinatra 13

14 Other other gotchas Key rollovers are tricky, but many tools can automate them (and they re getting better). Algorithm upgrades are crazy hard! Sign your zones with most robust algorithm currently supported. Not all clients may support it, but that s not necessarily a bad thing. Michael Sinatra 14

15 Algorithm Rollovers From: draft-ietf-dnsop-rfc4641bis-03#section Initial 2 New RRSIGS 3 New DNSKEY SOA0 SOA1 SOA2 RRSIG_ZSK_1(SOA0) RRSIG_ZSK_1(SOA1) RRSIG_ZSK_1(SOA2) RRSIG_ZSK_2(SOA1) RRSIG_ZSK_2(SOA2) DNSKEY_KSK_1 DNSKEY_KSK_1 DNSKEY_KSK_1 DNSKEY_ZSK_1 DNSKEY_ZSK_1 DNSKEY_ZSK_1 RRSIG_KSK_1(DNSKEY) RRSIG_KSK_1(DNSKEY) DNSKEY_KSK_2 RRSIG_KSK_2(DNSKEY) DNSKEY_ZKS_2 RRSIG_KSK_1(DNSKEY) RRSIG_KSK_2(DNSKEY) Remove DNSKEY 5 Remove RRSIGS SOA3 SOA4 RRSIG_ZSK_1(SOA3) RRSIG_ZSK_2(SOA4) RRSIG_ZSK_2(SOA3) DNSKEY_KSK_2 DNSKEY_KSK_2 DNSKEY_ZSK_2 DNSKEY_ZSK_2 RRSIG_KSK_1(DNSKEY) RRSIG_KSK_2(DNSKEY) RRSIG_KSK_2(DNSKEY) Michael Sinatra 15

16 Conclusions There are lots of tricks and pitfalls, but DNSSEC is both necessary and important for us in higher ed. It s only a piece of the security puzzle, but an important piece. As always, a big question in implementation will be, how much to change our process for existing tools or appliances or how much to modify tools (or write our own) to maintain our existing process? Michael Sinatra 16

17 Memory utilization for Authoritative server Michael Sinatra 17

18 CPU utilization for Caching server Michael Sinatra 18

19 Thank you. See also: Michael Sinatra 19