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
diromeCirrus
Hi steve,
- If you are going to on-box BIND, why in the profile DNS the "use bind in server bigip" is disable? and
- What will be the procedure to fill with all zones that reside in the off-box bind to the on-box bind?
Off the top of my head I'll be honest I am not sure. I did some research and I personally was not able to find official numbers since much of this is based on memory resources available to the BIG-IP itself. Therefor a lot will depend on platform and DNS provisioning (dedicated, nominal or minimum). With that, I can tell you one of our teams tested up to 100k zones with memory to spare. I know this is not the answer you are looking for so I will continue to try and find more official sizing information though I cannot promise it exists.
- Raphael1
Nimbostratus
How many dns zones can DNS Express support in V13.1?
In this article off-box bind is used to initially feed on-box bind with existing zone data from off-box bind. After we can forget off-box bind - Am I right?
Steve: Correct
If above is correct then on-box bind is used to keep zone data on disk in opposite to DNSExpress. That is necessary to feed DNSExpress with zone data for example after BIG-IP reboot. Am I closer to the truth now?
Steve: Yes the zone data is held and managed by zonerunner. The only thing DNSExpress is doing at this point is actually responding to DNS queries for performance and security purposes.
I assume that naming zone in ZoneRunner with db. prefix is mandatory for some reason?
Steve: This is not an F5 naming convention but rather Bind in general to include all flavors.
What still puzzles me is if I really get why on-box bind is necessary - just to store zone file on disk?
Steve: DNSExpress was never designed to be a DNS management tool but rather a proprietary implementation to server up DNS responses. ZoneRunner was put in place in the event an organization does not want to interface with an off box bind or any other DNS server for that matter and let F5 perform all functions to include managing zones and records.
dragonflymrCirrostratus
Hi,
I really appreciate your time and effort to explain this. Seems that I really need to refresh my knowledge about DNS on BIG-IP instead of asking no so smart questions.
I browsed trough docs I have and maybe I am a bit closer:
- ZoneRunner is just GUI to manage both DNS zone files and the BIND configuration file
- DNSExpress is DNS in the RAM on BIG-IP
- On-box bind is place to keep zone data persistent
In this article off-box bind is used to initially feed on-box bind with existing zone data from off-box bind. After we can forget off-box bind - Am I right?
Then:
- On-box bind zone data is managed using ZoneRunner
- After change to on-box bind zone (via ZoneRunner GUI) Notify is send to DNSExpress
- Then DNSExpress initiates zone transfer from on-box bind
If above is correct then on-box bind is used to keep zone data on disk in opposite to DNSExpress. That is necessary to feed DNSExpress with zone data for example after BIG-IP reboot.
Am I closer to the truth now?
I assume that naming zone in ZoneRunner with db. prefix is mandatory for some reason?
What still puzzles me is if I really get why on-box bind is necessary - just to store zone file on disk?
Piotr
Piotr, we are on the same page now. So this article is specific to actually replacing a BIND box and no longer using an off box bind server as the authoritative DNS server in a master/slave relationship. With that, in order to provide administrators a UI to create/modify/delete records, zones, etc. you must use ZoneRunner. If you are simply trying to configure DNSExpress to accept zone transfers and respond to DNS queries versus the hidden master, you are correct that ZoneRunner is not needed. Check out the solution article below. This actually provides guidance to the question above about having multiple Authoritative DNS Servers. It covers creating a pool of DNS Servers. Hope this clarifies everything.
https://support.f5.com/csp/article/K13940auth1
Replacing DNS Server 1. Zone created in ZoneRunner (On-box bind instance), zone transfer requested by ZoneRunner to Off-box bind. 2. Off-box bind sends zone to ZoneRunner 3. Also-Notify initiates zone transfer to DNSExpress 4. Changes in ZoneRunner initiate a notify message to DNSExpress for additions, changes, deletions, etc.
Using Hidden Master 1. Zone created in DNSExpress, zone transfer requested by DNSExpress to Off-box bind. 2. Off-box bind sends zone info to DNSExpress 3. Changes on off-box bind generate notify message to send zone changes directly to DNSExpress
- dragonflymr
Hi,
Wow!! Thanks for in depth explanation. I think I understand most but still have some issues :-(
Sure I know that zone transfer will be sourced from off-box bind, what I menat was that on off-box bind zone transfers from BIG-IP self ip has to be allowed (on off-box bind) - sorry for not being precise.
You say:
The zone transfer is triggered when you create the zone in ZoneRunner.
So after saving zone DNSExpress on BIG-IP initiates zone transfer using self IP as source and configured NS IP as destination? If above is true then why to create nameserver BIG-IP1? Or BIG-IP1 is in fact responsible for doing zone transfer from off-box bind.
So flow is:
- BIG-IP1 is sending zone transfer request to off-box bind
- BIG-IP1 is sending notify to DNSExpress
- DNSExpress initiates zone transfer from BIG-IP1
- Off-box is sending notify to BIG-IP1 (I think configuring notify on off-box bind was not mentioned in article?)
- BIG-IP1 sends zone transfer request to off-box bind
- BIG-IP1 sends notify to DNSExpres
- DNSExpress sends zone transfer request to BIG-IP1
Is above correct or I mixed thing up completely?
I am especially confused why BIG-IP1 (on-box bind) is necessary here? Is that because DNSExpress is not able to send zone transfer request to off-box directly and needs on-box bind for that? Or some other reason?
Piotr
These are not dumb questions at all. If I have left anyone not 100% confident on the how and why I need to provide more details.
Assuming we have some authoritative bind server in internal VLAN. This is set to allow zone transfer from BIG-IP Self IP (10.10.10.2).
Steve: Not transfer from the BIG-IP, transfer to the BIG-IP Self IP. The BIG-IP is the client in this case as we reference receiving zone transfers from an external Bind server. This is the initial step to update the zone on the local BIG-IP Bind instance. The transfer between on box (BIG-IP) Bind and DNSExpress occurs later and is the reason for the also-notify message in the named.conf. That also notify is referring to DNSExpress.
Then zone transfer is triggered, by what BIG-IP object - Nameserver (BIG-IP1)?
Steve: The zone transfer is triggered when you create the zone in ZoneRunner. Once the zone is created, an unsolicited zone transfer request is sent from the on box (BIG-IP) Bind instance. Moving forward, in your case where you still have a hidden master, any updates will generate a NOTIFY message which is sent to the BIG-IP and the BIG-IP will request a zone transfer with those updates.
If so how BIG-IP1 know to which internal bind server connect? From NS records created in Zone (DNS > Zones > ZoneRunner > Zone List)?
Steve: Yes sir. If you notice near the top of the article it asks in the newly created zone to create NS and SOA records. This is how the BIG-IP BIND instance knows what the authoritative DNS server for that zone and where to request the zone transfers from.
Or maybe BIG-IP1 is working as authoritative hidden master (not some external bind srv on internal VLAN) that is source for zone transfer to DNSExpress?
Steve: I hope the comments above helped clarify the last question.
Keep the questions coming if it is still not clear. I can assure you I don't mind a bit and just want to help other engineers and admins feel more comfortable with the BIG-IP and its capabilities.
- dragonflymr
Hi, Thanks for explanation. Still not clear :-(. Assuming we have some authoritative bind server in internal VLAN. This is set to allow zone transfer from BIG-IP Self IP (10.10.10.2).
Then zone transfer is triggered, by what BIG-IP object - Nameserver (BIG-IP1)?
If so how BIG-IP1 know to which internal bind server connect? From NS records created in Zone (DNS > Zones > ZoneRunner > Zone List)?
Or maybe BIG-IP1 is working as authoritative hidden master (not some external bind srv on internal VLAN) that is source for zone transfer to DNSExpress?
Sorry for dumb questions but I am really lost :-(
@Piotr, thanks for the question. To clarify what my use case is, I am using an old off box bind server to perform a zone transfer with ZoneRunner on the BIG-IP. ZoneRunner is the BIG-IP's on box bind. From a security perspective I don't want to expose bind to external users who will be hitting my authoritative DNS server which is why I am provisioning DNSExpress to perform this function. As for the name server, I am simply configuring that to accept zone transfers from the on box bind to DNSExpress. The last screenshot shows a log that stats successful zone transfer from 127.0.0.1 which is the transfer from ZoneRunner to DNSExpress. Hope this helps.
