Integrating F5 GTM with Infoblox and DNSSEC - Part 4
Integrating F5 GTM with Infoblox and DNSSEC - Part 4

Integrating F5 GTM with Infoblox and DNSSEC - Part 4

In part 3 of this series of articles, I detailed how Infoblox could be set up to delegate a secure zone to an F5 GTM. In this final part I will cover how we can check that everything is working by using DNSSEC validation.

Now that the Infoblox and GTM environments are fully configured, it should be possible to use DNSSEC validation to check that the "scp.gslb.company.com" FQDN is being signed correctly with DNSSEC by the GTM. We can also fail one of the SCP servers and see how GTM handles the DNS changes required to redirect users to the other SCP server.

To start with, it is not enough to send queries directly to the GTM or Infoblox devices to check things are working because in the real world these devices will probably not be performing validation and certainly should not have recursion enabled. In order to simulate a real world environment I used a Linux machine running Fedora Core 13 that comes with BIND 9.7 and configured it as a recursive caching-only DNS server. I enabled DNSSEC with the following statements inside the options statement within named.conf:

        dnssec-enable yes;
dnssec-validation yes;

I also modified the root hints file (usually called db.cache or named.ca) and removed the Internet root server hints and added a hint for the fake root server running on one of my Infoblox appliances:

.                       518400  IN      NS      A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET. 3600000 IN A 192.168.10.221

The root zone KSK also needs to be added to the configuration. This can be obtained by using dig to query the DNSKEY records on the fake root server:

$ dig @192.168.10.221 . dnskey
; <<>> DiG 9.7.1-P2-RedHat-9.7.1-2.P2.fc13 <<>> @192.168.10.221 . dnskey
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;. IN DNSKEY
;; ANSWER SECTION:
. 1296000 IN DNSKEY 257 3 7 AwEAAc2690E2L366xU0pfaycB5rtXEJZV1AOduPMVH4wM6fUpyTxbkZY QmyC2tObicHDvl9Z7nJSyzYWIG6zVtBU++8G4W4x9ZTZRKwuQJYYfBJX vCvDzCDlgfnf0ErAXmswhdbZVet1kwZXjr54REUui1Vm308A/Cda23Z5 2h1oKvOcvyGAVvS5LMzbPkn+walMysHKY3UUJuoTkqJ3RhrOEkjSkVXH r9aGIGH6SkjQKY8sY70NZOV3ivpQ9cPTMKYVmHzHkQKwqVdWpCrykxPO c3+qPV/Br9hyr1ba+R/0qGLZtH0CtyN/R9/RuX3vK7knU9leZ4NY1q9c p+47aRssq4E=
. 1296000 IN DNSKEY 256 3 7 AwEAAdQoPl7zytdrN0W0GsxnAONRo/cJeBY1kOU5wcV48sGNUcd3dU/2 u1TXcJPzPTyAEl+XxtuERQi2AMyIrFNjQoTJDAo21n/G6RUP7x3RiiRu sG+n78955sy+0YtF6YybXsEFEPAvc2iYcsq4F2112iLZ0LFBuN8EzZ+U XJbVRxTh
;; Query time: 3 msec
;; SERVER: 192.168.10.221#53(192.168.10.221)
;; WHEN: Thu Nov 25 12:30:18 2010
;; MSG SIZE rcvd: 439

The DNSKEY with a type code of 257 is the one that needs to be copied into the managed-keys statement and added to named.conf:

managed-keys {
"." initial-key 257 3 7 "AwEAAc2690E2L366xU0pfaycB5rtXEJZV1AOduPMVH4wM6fUpyTxbkZY QmyC2tObicHDvl9Z7nJSyzYWIG6zVtBU++8G4W4x9ZTZRKwuQJYYfBJX v
CvDzCDlgfnf0ErAXmswhdbZVet1kwZXjr54REUui1Vm308A/Cda23Z5 2h1oKvOcvyGAVvS5LMzbPkn+walMysHKY3UUJuoTkqJ3RhrOEkjSkVXH r9aGIGH6SkjQKY8sY70NZOV3ivpQ9c
PTMKYVmHzHkQKwqVdWpCrykxPO c3+qPV/Br9hyr1ba+R/0qGLZtH0CtyN/R9/RuX3vK7knU9leZ4NY1q9c p+47aRssq4E=";
};

If the DNS server has already been set up to perform DNSSEC validation via the Internet root servers, then there may already be a root zone KSK configured. This means it may not only be necessary to remove the existing root zone KSK key from the managed-keys statement, but it may also be necessary to remove the "managed-keys.bind" and "managed-keys.bind.jnl" zone files (if they exist). BIND should be stopped and these two files deleted as they could contain a cached copy of the real root zone KSK from the Internet.

Now that the DNSSEC configuration is complete on the validating DNS server, we should be able to start BIND and send it some queries for "scp.company.com" by using "dig" with the "+dnssec" option.

Using the Fedora Core system, I can use the loopback address (127.0.0.1) to communicate with the local validating DNS server as follows:

[root@FC-BIND-1 paul]# dig @127.0.0.1 scp.company.com. +dnssec
; <<>> DiG 9.7.1-P2-RedHat-9.7.1-2.P2.fc13 <<>> @127.0.0.1 scp.company.com. +dnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;scp.company.com. IN A
;; ANSWER SECTION:
scp.company.com. 28800 IN CNAME scp.gslb.company.com.
scp.company.com. 28800 IN RRSIG CNAME 7 3 28800 20101128163552 20101124153552 52613 company.com. LFUkeKPe5Ut2Emyim1TtCYJdLwM0i/IcCNqfbXW04bgiejNBeWYAJrjm /O6oHMj8wcfr01ddTdPjPsm1hbBDRjpAUD6L9zp9SVCJjkEHfm2dB1hN 6LvFXJlu4UUauN4KGa8+SgvRxCzpMElOdUIo6doyU47CIJDT0U1Azmly UF4=
scp.gslb.company.com. 30 IN A 192.168.10.231
scp.gslb.company.com. 30 IN RRSIG A 7 4 30 20101201161157 20101124161157 57737 gslb.company.com. qxjPPsiZwm63jwDDhKGl1j2calSshDLmUe8KeaBCRh8E48NIa9HX3lqg BVDUfFTZ9x079ta8uggN/X2jN7H2FAaWQc+AxZuwSAocUvbAnBxBPJfH k07FxrcGtuXipUY4dnwwb7h+xKpcreuF+SzoWGXzLlViBMLAl6xblaLQ GnE=
;; Query time: 143 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Nov 24 16:35:46 2010
;; MSG SIZE rcvd: 430

Straight away we can see that it has worked. The flags field contains the "ad" bit, which means Authenticated Data and the answer section contains both the CNAME and the A record for one of the SCP servers that the GTM returned. Both CNAME and A records are authenticated by their associated RRSIG records.

If I stop the SSH service running on 192.168.10.231, next time I query for scp.company.com the GTM should detect that SSH is down and return the IP address of the other SCP server:

[root@FC-BIND-1 paul]# service sshd stop
Stopping sshd: [ OK ]
[root@FC-BIND-1 paul]# dig @127.0.0.1 scp.company.com. +dnssec
; <<>> DiG 9.7.1-P2-RedHat-9.7.1-2.P2.fc13 <<>> @127.0.0.1 scp.company.com. +dnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;scp.company.com. IN A
;; ANSWER SECTION:
scp.company.com. 28764 IN CNAME scp.gslb.company.com.
scp.company.com. 28764 IN RRSIG CNAME 7 3 28800 20101128163552 20101124153552 52613 company.com. LFUkeKPe5Ut2Emyim1TtCYJdLwM0i/IcCNqfbXW04bgiejNBeWYAJrjm /O6oHMj8wcfr01ddTdPjPsm1hbBDRjpAUD6L9zp9SVCJjkEHfm2dB1hN 6LvFXJlu4UUauN4KGa8+SgvRxCzpMElOdUIo6doyU47CIJDT0U1Azmly UF4=
scp.gslb.company.com. 30 IN A 192.168.10.237
scp.gslb.company.com. 30 IN RRSIG A 7 4 30 20101201161517 20101124161517 57737 gslb.company.com. cq+oK0d5O+RIt2gHZMnZPQwFmIfUNyXyULHIfgECAwuruIIsHZCsixsd UKpm7NmcbC+iKjFMf4DrLo/Bhc+y6/cEES8KIrWmJ3tN4I7j2EzuT6Oh 8QLp9mwnY6kD26t7FyuWxtRtXCbQL9SSTu2BZV3fJf/SbN80m+h6NLg4 4DQ=
;; Query time: 3 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Nov 24 16:36:22 2010
;; MSG SIZE rcvd: 430

Again we can see that the "ad" bit is set, so the response was authenticated, but looking at the answer we can see that the GTM has detected that SSH is down on the first SCP server and it is now returning the IP address of the second SCP server. Note also that the RRSIG attached to the scp.gslb.company.com A record is different. In a static zone, the RRSIG would not change, but because the GTM is dynamically adjusting the DNS response it has to generate a new signature.

There are going to be a few delays during this switchover process that may need tuning. For instance, the GTM is responding with a TTL of 30 seconds, so records will be cached on recursive DNS servers for this length time regardless of the actual state of the service (I'm sure the TTL could be reduced, I tried in zonerunner but it didn't seem to make any difference in my environment). It will also take a certain amount of time between polling cycles before the GTM detects a change in state. So if testing in a lab environment it is normal to see inconsistencies while awaiting healthchecks to complete and cached entries to expire. This is demonstrated below, when the original SSH service is restarted it takes a certain amount of time for the GTM to detect it, so the secondary IP address is returned which then gets cached on the recursive DNS server, so it is not until the cached entry expires that we see the DNS response change back to the primary SCP server:

[root@FC-BIND-1 paul]# service sshd start
Starting sshd: [ OK ]
[root@FC-BIND-1 paul]# dig @127.0.0.1 scp.company.com. +dnssec
; <<>> DiG 9.7.1-P2-RedHat-9.7.1-2.P2.fc13 <<>> @127.0.0.1 scp.company.com. +dnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;scp.company.com. IN A
;; ANSWER SECTION:
scp.company.com. 28722 IN CNAME scp.gslb.company.com.
scp.company.com. 28722 IN RRSIG CNAME 7 3 28800 20101128163552 20101124153552 52613 company.com. LFUkeKPe5Ut2Emyim1TtCYJdLwM0i/IcCNqfbXW04bgiejNBeWYAJrjm /O6oHMj8wcfr01ddTdPjPsm1hbBDRjpAUD6L9zp9SVCJjkEHfm2dB1hN 6LvFXJlu4UUauN4KGa8+SgvRxCzpMElOdUIo6doyU47CIJDT0U1Azmly UF4=
scp.gslb.company.com. 30 IN A 192.168.10.237
scp.gslb.company.com. 30 IN RRSIG A 7 4 30 20101201153845 20101124153845 57737 gslb.company.com. nooVlSgNmDNVTc85xyZXDy6GgdEraFzcunq22KLyGgFMQJu47gul5qWW bIR6M+dMAi/J7PiMIYWXse1Jd51YzOh/2Xoc8J02xy/ev1VMRUg3Ga3A s/sfG1EVgGebmBhxmPeska0RcKkwCeOaZS804FfRtjzNIjsixm+nTLnw PBU=
;; Query time: 3 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Nov 24 16:37:04 2010
;; MSG SIZE rcvd: 430
[root@FC-BIND-1 paul]# dig @127.0.0.1 scp.company.com. +dnssec
; <<>> DiG 9.7.1-P2-RedHat-9.7.1-2.P2.fc13 <<>> @127.0.0.1 scp.company.com. +dnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;scp.company.com. IN A
;; ANSWER SECTION:
scp.company.com. 28713 IN CNAME scp.gslb.company.com.
scp.company.com. 28713 IN RRSIG CNAME 7 3 28800 20101128163552 20101124153552 52613 company.com. LFUkeKPe5Ut2Emyim1TtCYJdLwM0i/IcCNqfbXW04bgiejNBeWYAJrjm /O6oHMj8wcfr01ddTdPjPsm1hbBDRjpAUD6L9zp9SVCJjkEHfm2dB1hN 6LvFXJlu4UUauN4KGa8+SgvRxCzpMElOdUIo6doyU47CIJDT0U1Azmly UF4=
scp.gslb.company.com. 21 IN A 192.168.10.237
scp.gslb.company.com. 21 IN RRSIG A 7 4 30 20101201153845 20101124153845 57737 gslb.company.com. nooVlSgNmDNVTc85xyZXDy6GgdEraFzcunq22KLyGgFMQJu47gul5qWW bIR6M+dMAi/J7PiMIYWXse1Jd51YzOh/2Xoc8J02xy/ev1VMRUg3Ga3A s/sfG1EVgGebmBhxmPeska0RcKkwCeOaZS804FfRtjzNIjsixm+nTLnw PBU=
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Nov 24 16:37:13 2010
;; MSG SIZE rcvd: 430
[root@FC-BIND-1 paul]# dig @127.0.0.1 scp.company.com. +dnssec
; <<>> DiG 9.7.1-P2-RedHat-9.7.1-2.P2.fc13 <<>> @127.0.0.1 scp.company.com. +dnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;scp.company.com. IN A
;; ANSWER SECTION:
scp.company.com. 28703 IN CNAME scp.gslb.company.com.
scp.company.com. 28703 IN RRSIG CNAME 7 3 28800 20101128163552 20101124153552 52613 company.com. LFUkeKPe5Ut2Emyim1TtCYJdLwM0i/IcCNqfbXW04bgiejNBeWYAJrjm /O6oHMj8wcfr01ddTdPjPsm1hbBDRjpAUD6L9zp9SVCJjkEHfm2dB1hN 6LvFXJlu4UUauN4KGa8+SgvRxCzpMElOdUIo6doyU47CIJDT0U1Azmly UF4=
scp.gslb.company.com. 11 IN A 192.168.10.237
scp.gslb.company.com. 11 IN RRSIG A 7 4 30 20101201153845 20101124153845 57737 gslb.company.com. nooVlSgNmDNVTc85xyZXDy6GgdEraFzcunq22KLyGgFMQJu47gul5qWW bIR6M+dMAi/J7PiMIYWXse1Jd51YzOh/2Xoc8J02xy/ev1VMRUg3Ga3A s/sfG1EVgGebmBhxmPeska0RcKkwCeOaZS804FfRtjzNIjsixm+nTLnw PBU=
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Nov 24 16:37:23 2010
;; MSG SIZE rcvd: 430
[root@FC-BIND-1 paul]# dig @127.0.0.1 scp.company.com. +dnssec
; <<>> DiG 9.7.1-P2-RedHat-9.7.1-2.P2.fc13 <<>> @127.0.0.1 scp.company.com. +dnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;scp.company.com. IN A
;; ANSWER SECTION:
scp.company.com. 28690 IN CNAME scp.gslb.company.com.
scp.company.com. 28690 IN RRSIG CNAME 7 3 28800 20101128163552 20101124153552 52613 company.com. LFUkeKPe5Ut2Emyim1TtCYJdLwM0i/IcCNqfbXW04bgiejNBeWYAJrjm /O6oHMj8wcfr01ddTdPjPsm1hbBDRjpAUD6L9zp9SVCJjkEHfm2dB1hN 6LvFXJlu4UUauN4KGa8+SgvRxCzpMElOdUIo6doyU47CIJDT0U1Azmly UF4=
scp.gslb.company.com. 30 IN A 192.168.10.231
scp.gslb.company.com. 30 IN RRSIG A 7 4 30 20101201161157 20101124161157 57737 gslb.company.com. qxjPPsiZwm63jwDDhKGl1j2calSshDLmUe8KeaBCRh8E48NIa9HX3lqg BVDUfFTZ9x079ta8uggN/X2jN7H2FAaWQc+AxZuwSAocUvbAnBxBPJfH k07FxrcGtuXipUY4dnwwb7h+xKpcreuF+SzoWGXzLlViBMLAl6xblaLQ GnE=
;; Query time: 6 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Nov 24 16:37:36 2010
;; MSG SIZE rcvd: 430

Now that the sub-domain has been delegated and DNSSEC operation has been verified, additional services can be defined on the GTM simply by defining more Wide IPs and creating associated CNAMEs in the parent zone through the Infoblox GUI.

Today, the practical uses for this configuration may be fairly limited as DNSSEC deployment is suffering from a classic chicken and egg syndome, but when domains such as com and co.uk are signed next year (2011) we may see DNSSEC start to take off, and that's when the value of this combined F5/Infoblox approach can really be appreciated.

Paul Roberts is Technical Services Manager at tuscany networks and can be contacted via email at paul.roberts@tuscanynetworks.com

        LinkedIn
        Tweet
Share