v10.1 - Configuring GTM's DNS Security Extensions
Security extensions were added to the DNS protocol as a means of countering malicious attacks such as cache poisoning, domain hijacking, and man-in-the-middle attacks. The extensions are described in detail in RFC 4033 (Introduction and Requirements), RFC 4034 (Resource Records), and RFC 4035 (Protocol Modifications). Understanding what DNSSEC is and why it's important is well covered elsewhere -- whitepapers, research, etc at http://www.dnssec.net and there's a nice implementation tutorial at http://www.dyndns.com/support/kb/implementing_dnssec.html -- so we'll focus here on the DNSSEC implementation details as it pertains to GTM.
Preparatory Steps
Before we get to the configuration, there's a couple prerequisites to consider:
- In Non-FIPS deployments, the BIG-IP must be provisioned for GTM and licensed for GTM/DNSSEC.
- In FIPS deployments, the BIG-IP must be provisioned for LTM/GTM and licensed for LTM/GTM/DNSSEC.
- Must have a Data Center, Server, and Listener configured before creating a DNSSEC zone
You'll find that you can configure DNSSEC regardless of the licensed status, just note that the configuration will be ignored until the license is active. This seemed odd, but after talking to the product manager, the reasoning makes great sense.
"With the release of 10.0.0 we split configuration and licensing such that a customer can configure items or see items that are not licensed. Mainly this was done to support easier trial and eval licensing options. So with 10.x we no longer use configuration as the licensing enforcement point."
Finally, in creating your keys, you'll need to determine the bit width (1024/2048/4096), the type (zsk/ksk), fips (enable/disable), TTL, Rollover Period, Expiration Period, Signature Validity Period, and the Signature Publication Period. Note that NIST recommends a 30 day expiration on zone signing keys and a one year expiration on key signing keys. This is great for production, but lousy for quick tests where you want to see key generation. This table shows the recommended production expiration period and the calculated rollover period, which subtracts the TTL and an extra fifty seconds for buffer time. The table also shows the times we'll use in our test configuration.
DNSSEC Configuration in the GUI
The first step in configuring the DNSSEC zone is to create your key pair. You need at least one each of a zone signing key and a key signing key to sign a zone. To get started, navigate to Global Traffic -> DNNSEC Key List and click the circled plus sign (or just click DNSSEC Key List and hit the create button in the right pane.) For our trial configuration, we'll create both the ZSK and the KSK similarly:
Note that once the keys are created, they cannot be changed (though you'll be able to alter the configuration.) For keys created without a rollover/expiration period, you can manually force a rollover by going into key generation tab for that key and specifying a rollover/expiration time:
Once these keys are created, we can sign the zone:
DNSSEC Configuration in TMSH
The steps are really brief on the command line. First, launch the tmsh shell and three commands later it's complete.
- create gtm dnssec-key ztesting.com { key-type zsk ttl 100 rollover-period 03:20 expiration-period 05:50 signature-valid-period 01:00 signature-pub-period 40 }
- create gtm dnssec-key ktesting.com { key-type ksk ttl 100 rollover-period 03:20 expiration-period 05:50 signature-valid-period 01:00 signature-pub-period 40 }
- create gtm dnssec-zone testing.com keys add { ktesting.com ztesting.com }
Seriously, that's it! Unlike the GUI where you can add the keys with all values in seconds, in tmsh, you need to use the dd::hh:mm::ss notation for your time (no leading 00's). I'm looking into why the "show gtm dnssec-key" doesn't return any data, but alternately you can use "list gtm dnssec-key" instead as show below.
root@golgotha(Active)(tmos)# list gtm dnssec-key
gtm dnssec-key ktesting.com {
expiration-period 5:50
generation {
41 {
expiration 2009-11-19:11:37:49
public-text MIGJAoGBAMPaob9WVTWrfIsaEzRo/DYy5mcYK2LIfOqFuSsS9+TszLrRHHRcq2dStUItqc3KotyfgaWdom7FMd3pwMJmZNYSZNmekkwTjrk7RbmgTdg4IMXg3VpAm2O6tJqLfqGNM/xcqddYv/IOMu6OXzNGD6Fwc3TwNROayWsrDwa7S+rhAgMBAAE=
rollover 2009-11-19:11:35:19
}
42 {
expiration 2009-11-19:11:41:10
public-text MIGJAoGBALUBvxNuF15ffrL+3o0GQUaZT+A8Kq3zyqvIi2Pgvo5kNiP/dDe53gwmg2CJ9qnacT2UurRWx5L/gORWZ9Nen8fjugiJldHIOl9zX8Xxq7TtvPpqYjgBeD+O1uz6s8vAGeNd8Xk16N87Ctm+2xXLERTI2ft4gGUNi/IaAoKDe3XxAgMBAAE=
rollover 2009-11-19:11:38:40
}
}
key-type ksk
rollover-period 3:20
signature-pub-period 40
signature-valid-period 1:0
ttl 100
}
gtm dnssec-key ztesting.com {
expiration-period 5:50
generation {
47 {
expiration 2009-11-19:11:38:48
public-text MIGJAoGBAKRSP6K6NoNNwZd2LccHHls7znWb1hPyWSmBfFiDmiwf7qovRjFgr9O/d+PC6/LNhLyeqR4xBUVhq+ohk0AXuvKZKOhfigFDUZAdmPp2sCUFqT6oWXax1K5WVbllRJgryGYITQ95phyR/wJj/DQMIaOIMOZSjOfEq8ofenhRaO43AgMBAAE=
rollover 2009-11-19:11:36:18
}
48 {
expiration 2009-11-19:11:42:09
public-text MIGJAoGBANFVVkO58bXb9NwLMi2TCUxcWwVAOEL0tyKi2QDydi2t7PByfrf5Z2bvSoIkRPfYHg7Qy3oXCKGSP0ecxNHzzLeANMkGu2s3+6wvqlgYdzh+QHSXIHmNDrPZ8kcdHdwuVSOrC3xbWby6IPXWVFO+c+ev4db4VEkpUu4MRw23+javAgMBAAE=
rollover 2009-11-19:11:39:39
}
}
rollover-period 3:20
signature-pub-period 40
signature-valid-period 1:0
ttl 100
}
Here we validate the zone configuration with the "show gtm dnssec-zone" command:
root@golgotha(Active)(tmos)# sho gtm dnssec-zone
Gtm::DNSSEC Zone: testing.com
------------------------------------------------------
Status
Availability : available
State : enabled
Reason : contains at least one KSK and ZSK
DNSSEC On the Wire
Looking at the wireshark decode on the GTM response to my dig request with +dnssec set, we see that the response was authenticated by the server, and that the client received three resource records. The A record, and two RRSIG records (one shown).
Digging DNSSEC
Finally, looking at the dnssec response to my dig request, you can see that my first query received two signatures, as one is about to expire, and a follow-up query where only one signature is returned. Notice the ad flag in the response, which indicates the data has been authenticated.
vadmin@vadmin:/var/tmp$ dig @10.10.20.5 www.test.com +dnssec +multiline
; <<>> DiG 9.6.1-P1 <<>> @10.10.20.5 www.test.com +dnssec +multiline ; (1 server found) ;; global options: +cmd ;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38697 ;; flags: qr aa rd ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION:
;www.test.com. IN A;; ANSWER SECTION:
www.test.com. 30 IN A 10.10.20.50
www.test.com. 30 IN RRSIG A 7 3 30 20091119131554 (
20091119131454 4592 test.com.
KuEmDJ4ZGw2KVEXCwth77hl7No1w20s1rba1JrIAnWTM
Fa561zo6dyBE3aAW6H9GsKMIcOFm8RftwqNaelntmyIO
mLRz9Aw90LJjoa71AFuCcBKdhNC3R2Nz8rh+QdpkXABM
y+Fo0skuH6RtsgNqN7oOLLUJV2fnOd0yqyPla40= )
www.test.com. 30 IN RRSIG A 7 3 30 20091119131554 (
20091119131454 60830 test.com.
xXtZCNsBVsHeI1A7NFVCPUto+v0cyahAR8eEWRDWQgnk
fnI0M0vOKaKMkNLF2ZqnpAsdP6IrnBNl76VN82pxtcwc
vAkxFH6wtHMOOM0+xTR4IUleUfCtzUpdRZZYLfVylbmW
AE8YyVDiUWiqt9B1tt2PzFMBUEDfaA9f6jKly+I= );; Query time: 4 msec
;; SERVER: 10.10.20.5#53(10.10.20.5)
;; WHEN: Sun Nov 15 01:32:10 2009
;; MSG SIZE rcvd: 429vadmin@vadmin:/var/tmp$ dig @10.10.20.5 www.test.com +dnssec +multiline
; <<>> DiG 9.6.1-P1 <<>> @10.10.20.5 www.test.com +dnssec +multiline ; (1 server found) ;; global options: +cmd ;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6175 ;; flags: qr aa rd ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION:
;www.test.com. IN A;; ANSWER SECTION:
www.test.com. 30 IN A 10.10.20.50
www.test.com. 30 IN RRSIG A 7 3 30 20091119131554 (
20091119131454 60830 test.com.
xXtZCNsBVsHeI1A7NFVCPUto+v0cyahAR8eEWRDWQgnk
fnI0M0vOKaKMkNLF2ZqnpAsdP6IrnBNl76VN82pxtcwc
vAkxFH6wtHMOOM0+xTR4IUleUfCtzUpdRZZYLfVylbmW
AE8YyVDiUWiqt9B1tt2PzFMBUEDfaA9f6jKly+I= );; Query time: 3 msec
;; SERVER: 10.10.20.5#53(10.10.20.5)
;; WHEN: Sun Nov 15 01:32:21 2009
;; MSG SIZE rcvd: 249
Conclusion
DNSSEC, while fairly complicated architecturally, is easily configured on the GTM, whether completed in the GUI or in tmsh. Hopefully this tutorial has been helpful in demystifying the process.
