Replacing a DNS Server with F5 BIG-IP DNS
First things first, you have decided to deploy F5 BIG-IP DNS to replace a BIND server after receiving notifications from your information assurance officer or your friendly LinkedIn community that additional CVE's have been identified for the version of BIND you are running. In this particular instance you already have a BIG-IP in your DMZ acting as your reverse proxy. You have purchased the best bundle though have only deployed what you know, APM and LTM (common scenario).
After upgrading to version 13 after its release in February 2017 and then determining the latest hotfix using https://support.f5.com/csp/article/K9502, you navigate within the TMUI to System > Resource Provisioning and simply provision DNS.
Once complete you will need to configure your existing BIND server to allow zone transfers to the BIG-IP. In this case, we will define a self-IP on the BIG-IP.
Without the BIG-IP Self IP Defined "allow-transfer { localhost;};"
With the BIG-IP Self IP Defined "allow-transfer { localhost; 10.10.10.2;};"
Once you have allowed the zone transfer, you will create the zone on the BIG-IP and perform the zone transfer.
- On the Main tab, click DNS > Zones > ZoneRunner > Zone List . The Zone List screen opens.
- Click Create.The New Zone screen opens.
- From the View Name list, select the view that you want this zone to be a member of. Note: The default view is external.
- In the Zone Name field, type a name for the zone file in this format, including the trailing dot: db.[viewname].[zonename]. For example, db.external.lyons.demo.com.
- From the Zone Type list, select Master.
- From the Records Creation Method list, select Transfer from Server.
- Within Options, include the following
allow-update { localhost;}; allow-transfer { localhost; }; also-notify { ::1 port 5353; };
- In the Records Creation area, type the values for the SOA and NS record parameters.
- Click Finished
Ok, so you might be asking yourself right about now, "I thought ZoneRunner was a BIND instance?" In this scenario you are correct which is why we are going to slave from on-box BIND to ensure BIND is never accessible externally and we only respond to DNS queries using DNSExpress. Now can you slave from an off-box DNSExpress instance, of course though that is outside the scope of this article.
Prior to creating our DNS profile and listeners, we are going to configure DNS logging. For this use case, we are going to configure logging to the on-box syslog instance.
- In the GUI, navigate to: System > Logs > Configuration > Log Publishers: Create
- Create a new DNS Log Publisher using the defaults unless defined below.
Name: dns-local-syslog
Destinations: Move local-syslog to the Selected column
- In the GUI, navigate to: DNS > Delivery > Profiles > Other > DNS Logging: Create
- Create a new DNS Profile using the defaults unless defined below.
Name: dns-logging
Log Publisher: Select dns-local-syslog
Log Responses: Enabled
Include Query ID: Enabled
Note: For the purposes of this article, we are going to enable all DNS logging options.
Now that we have logging set up to use by our DNS profile, we are going to going ahead and create that object.
- In the GUI, navigate to: DNS > Delivery > Profiles > DNS: Create Create a new DNS profile as shown in the table below. Keep the defaults if not noted in the table.
Name: AuthoritativeNS
Unhandled Query Action: Drop
Use BIND Server on Big-IP: Disabled
Logging: Enabled
Logging Profile: dns-logging
Now that we have created our DNS profile, we are going create our DNS listeners. Remember, F5 is a default deny device so without creating something to listen on all attempts to connect to or query the BIG-IP will be denied.
We are going to create external Listeners that will be our target IP address when querying BIG-IP DNS.
- In the GUI, navigate to: DNS > Delivery > Listeners > Listener List: Create
- Create a two new listeners using the defaults unless defined below.
Name: external-listener-UDP
Destination: Host: 10.1.100.53
VLAN Traffic: Enabled on..
VLANs and Tunnels: external
DNS Profile: AuthoritativeNS
Name: external-listener-TCP
Destination: Host: 10.1.100.53
VLAN Traffic: Enabled on..
VLANs and Tunnels: external
Protocol: TCP
DNS Profile: AuthoritativeNS
So up to this point we have configured your legacy DNS server to perform a DNS transfer with the BIG-IP, created a zone within ZoneRunner, performed the zone transfer from your legacy DNS device, created a DNS profile and listeners on the BIG-IP. Ok, bear with me we are almost done. Our next step is configuring the local device as a name server and then create a DNSExpress zone that you will be performing a zone transfer to using the on-box BIND instance. So let's begin.
- In the GUI, navigate to: DNS > Delivery > Nameservers > Nameserver List: Create
- In this case we will simply provide a Name and leave all other defaults.
Name: BIG-IP1
- Select Finish
In the GUI, navigate to: DNS > Zones > Zones > Zone List: Create
Name: lyons.demo.com
Server: BIG-IP1
Notify Action: Consume
Verify Notify TSIG: Uncheck
Zone Transfer Clients: Move BIG-IP1 from Available to Active
Select Finish
In the GUI, navigate to: DNS > Zones > Zones > Zone List: Create
Name: 198.199.10.in-addr.arpa
Server: BIG-IP1
Notify Action: Consume
Verify Notify TSIG: Uncheck
Zone Transfer Clients: Move BIG-IP1 from Available to Active
Select Finish
Now, our final step...validation. From the cli, simply run a dnsxdump to ensure records have been transferred to DNSExpress as shown below. If you would like to see zone transfers in actions, simply create a resource record within ZoneRunner and run a tail -f on the /var/log/ltm.
You are now complete and have a fully functional authoritative DNS server for your organization without the vulnerabilities of BIND or in an effort to simply consolidate services. If you have any problems at all, please don't ever hesitate to reach out directly. Now my answer may be contact support though I have no problem walking through a scenario or troubleshooting attempt with you.
Reference Documentation
Published Feb 23, 2018
Version 1.0
Misty_SpillersNimbostratus
We really would like F5 to be an all in one DNS solution, unless you have a really good reason why it should not be. We won't have 1000s of people doing recursive DNS but we need to do it. So CAN DNS Express do recursion, with cache to the on box BIND, if yes how? I have followed your steps, but if I disable "use BIND Server on BIG-IP" recursion no longer works.
I have successfully configured DNS Express to respond to authoritative zones using the on box BIND by follow the steps in your original post. I can disable "use BIND Server on BIG-IP" and this works. just not sure about recursion. Thank you so much for all your time on this, it's been a little difficult finding someone to help with architecture, mainly because these are so many options.
dragonflymrCirrostratus
Wow, thanks a lot for your time and effort, really appreciate!
From above it's clear that anything configured in BIND Forwarder Server list is not used by BIG-IP for internal name resolution - that is 100% clear now.
Still I am not sure in what situation IPs configured in BIND Forwarder Server list are used. Maybe some small real life example that you can share?
Thanks again,
Piotr
Hopefully these screenshots help clarify.
First I configured google DNS in the BIND forwarder server list and I am unable to resolve. I then configured it in the DNS lookup server list and can successfully resolve.
Here you can see based on name of the pool I am using different configurations. First pool I have no DNS configured and when attempting to save based on fqdn pool I receive an error to configure DNS. In the 2nd pool I configured google DNS in my BIND forwarder server list and receive an error to configure DNS when trying to save a fqdn pool. Lastly, I configured google dns in my DNS server list and can successfully create an fqdn pool.
Hope this helps clarify! Let me know.
- dragonflymr
Couldn't resist :-))
Wow, so my understanding was totally wrong :-( To be 100% sure if I am getting things right - if for example FQDN nodes are used then DNS servers configured in DNS lookup server list will be used (never from BIND forwarder server list) - right?
Then if we will configure DNS listener without Pool and there are entries in BIND forwarder server list those will be used to resolve request coming to configured DNS resolver - right?
If above is correct I would never, ever figure it out from build-in help description :-(
Piotr
Hahahaha, why didn't you say so! J/K
Sure, the DNS lookup server list specifies the name servers that the system uses to validate DNS lookups, and resolve host names.
The BIND forwarder server list specifies BIND servers that the system can use to perform DNS lookups. BIND allows you to cache and store DNS requests and responses on a local server and minimize DNSserver requests, and bandwidth.
So what this is really saying is that the DNS lookup server list is for system specific name resolution. The BIND forwarder server list is for name resolution for external entities if using the BIG-IP as a name resolution source.
- dragonflymr
Well, not a great answer indeed :-) but thanks a lot for answer!
What I am actually trying to figure out is difference between entering IP in DNS Lookup Server List and BIND Forwarder Server List.
I assume that both are used by BIG-IP to perform queries (like to resolve NTP server FQDN to IP or other FQDNs BIG-IP itself has to resolve) - hope I am right here?
If is main difference between this two config options that second one allows BIG-IP to store responses in local BIND cache? So in compare to first option not every request has to be send to external DNS (if response already exist in local BIND cache)?
Or I totally misunderstand how this options work?
Piotr
Hi Piotr. I probably don't have a great answer for you but I will do my best. Also, it seems as though some of the questions/responses have been mixed together with different use cases. With that, I attempt to never use the Bind Forwarders Server List. It provides no high availability or health checking of what you are performing name resolution against. It has and will likely always be a recommended best practice to use pools when configuring the BIG-IP to act as a recursive DNS server. Also, this isn't documented and may be my own experience though I have experienced times when I expect name resolution attempts to continue down the list of BIND Forwarders and DNS servers in the system general settings though it doesn't and name resolution fails on the first attempt. This behavior was not expected from me so therefor I really like the use of DNS pools with DNS health monitors to validate the members are available. I know this probably isn't what you were looking for but I hope it convinces you to use DNS pools! :)
- dragonflymr
Hi Steve,
Great recap, thanks a lot. You mentioned using Bind forwarders - could you explain a bit how those work and when it makes sense to use them. I was always curious about this option when configuring DNS on BIG-IP. Tried to find some good explanation but failed :-(
Piotr
Hi Misty! I apologize for the delayed response on each of these. So, let's take a look at the different use cases.
Authoritative - Client queries BIG-IP for authoritative DNS response based on a zone it currently owns or has been granted delegation to.
High-level different configuration options. 1. DNS Express consumes zone from off box bind. 2 DNS Express consumes zone from on box bind when managed by on box bind. 3. DNS Express consumes zone from on box bind which is performing zone transfers from off box bind or other BIG-IP DNS instance.
Within the DNS profile, it is recommended to disable the use of Bind to ensure DNS Express is the only component responding to queries. Likely this will be a separate virtual server than what you are using for recursive lookups and therefore using a different DNS profile.
Recursive DNS - Client or DNS server queries BIG-IP DNS and BIG-IP DNS then queries a separate DNS instance for an authoritative DNS response and BIG-IP then provides that response to the client.
High-level different configuration options. 1. DNS Express handles recursion with no DNS caching. 2. DNS Express handles recursion with DNS caching. 3. On box bind handles DNS recursion with no DNS caching. 4. On box bind handles DNS recursion with DNS caching.
I still recommend disabling Bind here though for functionality purposes it is not required. Things to validate. Process Recursion Desired is enabled in the DNS profile which is done so by default. If you are using Bind forwarders, ensure they are configured in System > Configuration > DNS > BIND Forwarder Server List. Also if using Bind ensure recursion is enabled in the named.conf file. If you are using a pool of DNS servers (recommended), ensure it is assigned to the listener or Virtual Server. Please let me know your results and I will help get this working with you. Don't forget tools like dig, nslookup and tcpdump. I prefer dig and tcpdump when troubleshooting any DNS related issue. tcpdump ensures the client is actually hitting my DNS listener and dig validates DNS resolution. Let me know.
- Misty_Spillers
Hi Steve, my question expands a little on the last one (with no answer)
Here is what I'm thinking the answer to the first part is. When you define a zone in DNS Express it will answer the clients, not bind. At least this is what it looks like.
My question is this:
Our DNS servers need to be fully functional as there will be people using them directly for DNS. When I disable "use BIND Server on BIG-IP" recursion no longer works and it won't answer for zones it doesn't know about. (I really hope I'm saying that correctly) Is that expected? Do I have to enable "use BIND Server on BIG-IP" for this to work?
