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
- dragonflymrCirrostratus
Hi Steve,
It's me again :-) I guess I figured out most of the art of moving External DNS (EDNS) to BIG-IP (either to DNS Express or on BIG-IP BIND). There is few little things lest and I will really appreciate if you help mi to figure those out:
- Why there is no way (at least from GUI) to convert Slave ZoneRunner Zone to Master? It would really help in smooth transition form testing to production. Idea here is to first create Slave type and enable receiving NOTIFY from EDNS and initiate IXFRs - so Slave Zone is all the time up-to-date. Then this slave zone sends NOTIFY to DNS Express Zone. Result is DNS Express Zone is as well up-to-date during test. Then after test are over and Zone management should be transfered to BIG-IP, ZoneRunner Zone is changed to Master - but this seems to be not possible via GUI.
- As far as I understand standards Master ZoneRunner Zone can't accept NOTIFY or initiate IXRFs - because it's Master. So after initial AXFR any change on EDNS are not transfered to Master ZoneRunner Zone - Am I right?
-
Last and most painful thing is making this work with Route Domains (RD). Seems that this is not working at all. I know that there is option to set Route Domain when defining Namesever but all my test (13.1.1.3 and 4) suggest that this setting is ignored. AXFR and IXFR is always send via Self IP defined on VLAN in Common RD0 - did you ever tried setup with Route Domains? I was not able to find any KB or Bug Tracker with info that this feature is not working :-(. I tried:
- Route Domain RD1 in Common with VLAN to EDNS assigned to it; All DNS objects created in Common; RD1 selected in Nameserver
- Route Domain RD100 created in partition TEST and set as default RD; VLAN to EDNS assigned to RD100; All DNS objects created in TEST partition
Last question is about manually (via CLI) converting BIND Slave zone to Master. Is that possible or maybe rather is that safe? My idea was to:
- Stop named daemon, edit named.conf (db files for Slave and Master seems to be exactly the same so no mods necessary)
- Edit named.conf with appropriate changes to Slave Zone definition
- Save edited named.conf and start named daemon
Is there a chance it will work? I know that .jnl files are created for Zones - seems that those are containing changes to Zone file done via GUI. Periodically those changes are synced with zone db file. So I am not sure if I should remove .jnl or left it.
Thanks in advance, Piotr
- Steve_LyonsRet. Employee
@Misty, yes as mentioned in previous comments it is HIGHLY recommended to use separate virtual servers for authoritative lookups and recursive lookups. This allows you to define different security policies for both. Most large enterprises do not allow internal users to hit their external authoritative DNS servers and they certainly do not allow external users to access their recursive DNS servers. In fact many organizations have separate servers for these functions but because F5 is a full proxy and allows for granular security per virtual server you can host both functions on a single BIG-IP. With all of this you as an organization need to determine your security requirements and implement your BIG-IP in a manner that allows you to meet those requirements. F5 as a product can perform an unbelievable amount of technical functions though the engineers developing the solution should determine how and if you should.
Ok now with all of that if you really want to use a single virtual server to restrict recursive lookups only then yes you can still create an iRule. Please check out DevCentrals code share and iRule content to see how. Hope this helps.
- Misty_SpillersNimbostratus
That would stop all traffic though, I just wanted to stop recursion. Almost seems like I would have to have 2 listeners. One for DNSExpress to answer for zones it is authoritative for and one for normal DNS queries that our customers would use. IS that how it works? I really don't want the Internet to have access to recursion. When I had BIND accessible it was respecting the named.conf settings on recursion
EDIT: Actually it looks like this is the kind of iRule I need. It's a bit of reading. https://devcentral.f5.com/articles/dns-irules-protect-yourself-from-amplification-attacks
- Steve_LyonsRet. Employee
@Misty, well there are several ways to accomplish this within LTM alone. Within the listener you can define a source subnet. You can also configure allow specific vlans in the listener. If you have several subnets that you would like to allow I would recommend using an iRule to allow subnets with a default action of drop. I shared this iRule a few weeks ago on LinkedIn.
@Piotr - You can try this link: https://ine.com/collections/f5-networks/products/exam-302-big-ip-dns-specialist
- Misty_SpillersNimbostratus
Steve, one more question for you.
Now that I have set up a DNS cache, it seems to be letting anyone on the Internet do recursion. I need to limit this to a couple of IP blocks. In the configuration we discussed what is the best way to do this?
Thank you!
- dragonflymrCirrostratus
@Steve - DNS Cache solution is working great (did such setups in the past) but I wonder how to use to as well provide local resolution via for example DNS Express. Something like:
All Internet related queries will use root hints All queries fro company.com will use DNS Express feed from BIND - so it would be possible to manage company.com zone directly on BIG-IP. If I am not wrong it's only possible if zone is handled by local BIND?
Piotr
- dragonflymrCirrostratus
Hi,
"There is also a great F5 DNS INE course which covers various Design and Architectures for F5 DNS in Section 1"
Link seems to be broken, or you have to be registered user at https://members.ine.com/auth/login?
Piotr
Nice work Steve answering these requests.
Couple extra pieces of information that may support the question:
Recursive Resolver Lab Material: https://clouddocs.f5.com/training/community/dns/html/class2/module5/module5.html
There is also a great F5 DNS INE course which covers various Design and Architectures for F5 DNS in Section 1: https://streaming.ine.com/c/exam-302-big-ip-dns-specialist
- Steve_LyonsRet. Employee
No problem! Glad this is working for you.