Introduction

Among the many features released with GTM version 11, DNS Express has to be near the top of the list for many DNS administrators. DNS Express is a high performance in-memory authoritative DNS server. GTM has always been able to serve DNS records from its local BIND instance, but this left it subject to many of the same performance limitations as other BIND servers. In addition to its ability to far outperform most any DNS server (125k queries per second per core), DNS Express also has a number of security features to mitigate DDoS attacks as well. This makes DNS Express enabled virtual servers far more resilient to denial of service attacks.

Configuring DNS Express As An Authoritative Secondary

This section expects that you have new Linux server (the paths referenced in this Tech Tip assume a recent Ubuntu installation) with BIND installed (BIND 9.8.1 is the most current stable version; we�re using BIND 9.7.0) and a BIG-IP running version 11 licensed for GTM. We will make the Linux BIND server our primary and the GTM our secondary. It should be noted that the end-user cannot tell the difference between a primary or secondary server. They both serve identical zone files. For your purposes, the primary server will be where zone modifications take place while the secondary will receive copies of these zones via a zone transfer. Zones should never be modified on a secondary server.

Traffic needs to be routable between the GTM's self-IP address and the BIND server. Listeners, IP addresses where GTM serves the DNS Express zones, do not need to be able contact the primary DNS server.

Configuring The Primary Server

1. Begin by creating a zone file in /etc/bind/. There are a number of thoughts on naming conventions, but we usually use "db.<zone name>" such as "db.example.com".

db.example.com
--
; name          TTL     class   RR      Nameserver              email-address
@               3600    IN      SOA     ns1.example.com.        admin.example.com. (
                2011100601      ;serial
                3600            ;refresh
                900             ;retry
                604800          ;expire
                3600 )          ;minimum

;Name servers
                IN      NS      ns1.example.com.

@               IN      A       10.0.0.10
ns1             IN      A       10.0.0.1
www             IN      CNAME   example.com.

This should appear to be fairly straight forward for anyone who has dealt with zone files in the past. There are a couple of values, such as the refresh and retry intervals, in the SOA record that may have appeared insignificant previously, but DNS Express relies on them. The refresh interval specifies how frequently DNS Express should check for an updated zone file. The retry interval specifies how frequently DNS Express should try to refresh if the first scheduled refresh is unsuccessful.

Another note, the at sign (@) refers to the current zone and can be used in place of "example.com." where necessary. Unless a domain name is fully qualified, the value of @ will be appended to the name automatically. You'll see this more clearly when we test a zone transfer (AXFR) a little later in the Tech Tip.

2. Reference the new zone file in your named.conf.local file. (Ubuntu separates named.conf into separate files with include statements in named.conf)

named.conf.local
--
zone "example.com" {
        type master;
        file "/etc/bind/db.example.com";
        allow-transfer { 192.168.1.245; };
};

The server will serve the primary zone for example.com and will allow transfers for our GTM's self-IP address at 192.168.1.245.

3. Once these two modifications are in place you'll want to reload the configurations. This can be done using the rndc command, which performs actions on a running instance of named. rndc can be run locally the BIND server or can be configured to run remotely using a TSIG (Transactional Signature) key.

root@f5-test-bind-master:~# rndc reload 
server reload successful

Test your local zone from a remote workstation. Use the dig (Domain Information Groper) command to request an Internet address (IN A) record from the primary BIND server.

user@f5-test-linux:~# dig @102.168.1.200 IN A example.com.

; <<>> DiG 9.7.0-P1 <<>> @10.0.0.52 IN A example.com.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38025
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;example.com.                   IN      A

;; ANSWER SECTION:
example.com.            3600    IN      A       10.0.0.10

;; AUTHORITY SECTION:
example.com.            3600    IN      NS      ns1.example.com.

;; ADDITIONAL SECTION:
ns1.example.com.        3600    IN      A       10.0.0.1

;; Query time: 19 msec
;; SERVER: 192.168.1.200#53(192.168.1.200)
;; WHEN: Thu Oct  6 12:00:00 2011
;; MSG SIZE  rcvd: 79

If you receive an A record in the answer section and it matches the value in the zone file, you've succeeded.

Configuring DNS Express As The Secondary Server

1 .In step 2 of the previous section, we added the "allow-transfer" option to our zone statement in named.conf.local. This option allows our GTM to request a zone transfer from our primary server. We'll want to test this functionality using dig and the AXFR opcode (full zone transfer) before setting up DNS Express.

[f5-test-gtm:Active] config # dig @192.168.1.200 AXFR example.com.

; <<>> DiG 9.7.3-P3 <<>> @192.168.1.200 AXFR example.com.
; (1 server found)
;; global options: +cmd

example.com.            3600    IN      SOA     ns1.example.com. admin.example.com. 2011100601 3600 900 604800 3600
example.com.            3600    IN      NS      ns1.example.com.
example.com.            3600    IN      A       10.0.0.10
ns1.example.com.        3600    IN      A       10.0.0.1
www.example.com.        3600    IN      CNAME   example.com.example.com.
example.com.            3600    IN      SOA     ns1.example.com. admin.example.com. 2011100601 3600 900 604800 3600
;; Query time: 2 msec
;; SERVER: 192.168.1.200#53(192.168.1.200)
;; WHEN: Thu Oct  6 12:00:00 2011
;; XFR size: 6 records (messages 1, bytes 190)

2. If you see a response that resembles your zone, but probably not in the same order, you're doing well.

3. Open a web browser and navigate to the GTM web user interface.

4. Select the "Local Traffic" menu, then "DNS Express Zones", then "DNS Express Zone List".

5. Once at the "DNS Express Zone List" page, select "Create" from the upper right-hand corner.

6. Under the "General Properties" section fill in the following fields:

   Name: example.com (zone name)
   State: Enabled
   Target: 192.168.1.200 (primary zone server)
   Notify Action: Consume (if DNS Express cannot answer the query, the BIG-IP system will attempt to process the packet)

7. Navigate to "Global Traffic", "Listeners"

8. Once in the "Listeners" list select "Create" from the upper right

9. Fill the the listener's "General Properies":

   Destination: IP where DNS Express will serve queries (should match an NS record for the GTM)
   Protocol: UDP
   DNS Profile: dns (DNS Express is enabled by default)

10. Once you've created your listener, you'll want to test your request by pointing dig or nslookup at the listener.

user@f5-test-linux:~# dig @4.3.2.1 IN A www.example.com.

; <<>> DiG 9.7.0-P1 <<>> @4.3.2.1 www.example.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45926
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;www.example.com.               IN      A

;; ANSWER SECTION:
www.example.com.        3600    IN      CNAME   example.com.
example.com.            3600    IN      A       10.0.0.10

;; AUTHORITY SECTION:
example.com.            3600    IN      NS      ns1.example.com.

;; ADDITIONAL SECTION:
ns1.example.com.        3600    IN      A       10.0.0.1

;; Query time: 1 msec
;; SERVER: 4.3.2.1#53(4.3.2.1)
;; WHEN: Thu Oct  6 12:00:00 2011
;; MSG SIZE  rcvd: 112

If your answer reflects the record in your zone file, then you've succeeded. Test changing your zone file on the primary and watching the updates on the GTM.

Troubleshooting Tips

   - Logs are your friend - be sure and check /var/log/syslog on the BIND server and /var/log/ltm on the BIG-IP if things aren't working as planned
   - Correct time matters for zone transfers - if the clocks on the BIND server and GTM are too far apart, zones won't transfer. Set up NTP on both
   - dig give you 95% of all the diagnostic power you need for troubleshooting DNS - familiarize yourself with the man page and you'll be a lot happier

Conclusion

DNS Express is one of the coolest features in GTM version 11 and is well worth the upgrade for it alone. It provides far more in-RAM capacity (tens of millions of records) than most shops will ever need and greatly simplifies existing DNS architecture while adding performance and security benefits. If your GTM is passing any queries to backend DNS servers it would be worthwhile to look into transferring those zones to DNS Express.

In this Tech Tip we covered only the basics of configuring DNS Express as a secondary server to a BIND primary. We didn't touch on the usage of TSIG keys to secure transfers or the use of IP Anycast to further extend GTM�s DDoS capabilities. Both of these topics will be covered shortly in this Tech Tip series, so stay tuned. GTM version 11 offers the most secure, fast, and reliable DNS architecture F5 has released to date. Get your hands on a v11 box, you'll be happy you did.

v11: DNS Express &ndash; Part 1

v11: DNS Express – Part 1