Recursive DNS resolution (DoT), allowing queries UDP/53 while BIG-IP forwards over TCP/853
How can I configure BIG-IP to perform recursive DNS resolution over DNS-over-TLS (DoT), allowing standard DNS clients to send queries over UDP/53 while BIG-IP forwards those queries securely over TCP/853? It is possible without a external resolver ?
Recommendation for Adv. Lab
Hi Everyone, I'm relatively new to F5 BIG-IP and want to improve my hands-on skills. I have a chance to build a good lab, but I'm struggling to find real-world use cases and troubleshooting scenarios. Currently, I can only run basic tests with DVWA, but I want to simulate a complex environment. Could you recommend any resources (videos, docs, or lab guides or anything can help) specifically for LTM, AWAF, DNS and APM, use-case scenarios, troubleshooting exercises, architectures etc. Any guidance to help me bridge the gap between basic setup and professional practice would be greatly appreciated. Thanks in advance!
F5 DNS Logs in JSON Format
I am currently receiving F5 DNS logs in syslog format, but I need them in JSON format. I have already created the log destination and log publisher, and also verified using Telemetry Streaming, but the logs are still not in JSON format. Is there a way to configure F5 DNS to send logs in JSON format? Any guidance would be appreciated. Thanks!
Single LTM with multiple GTM domains
I am currently working on a Datacenter migration and we are re-IP'ing everything and rebuilding all the network appliances. I am working out the BEST, least impactful, way to migrate the GTM appliances to the new DC's. Here is the overall situation. Everything is the same version running 15.x.x with a mix of rSeries hardware running VE's and iSeries hardware also running VE's. Existing DC's: GTM Domain with two GTM's in different DC's Multiple LTM's all joined to the GTM New DC's: Two GTM's in different DC's, blank configuration Multiple LTM's all joined with the existing DC GTM's I know that I can add the new GTM's to the existing DC GTM domain, let them sync up, then update the NS records to migrate the DNS flows over to the new DC, but that also sync's over all the technical debt and limits my pre-testing abilities. I would like to setup a new GTM Domain in the new DC, build some automation for the WideIP / Pool creation, and manually review / rebuild all the necessary records in the new DC. My hangup is that this is ONLY possible if the LTM appliance can join multiple GTM domains. Can a single LTM appliance join multiple GTM domains and report status to multiple appliances? I don't have an easy way to build a test environment and build this out with VE's and validate so I am hoping for some input from the community.
Does XC DNS support health monitoring for CNAME records?
Hi everyone, I have a question regarding health monitor with CNAME records in the XC DNS Load Balancer. If I configure a Type A DNS Load Balancer in XC, I can attach a DNS pool with health monitor. However, if I configure a Type CNAME DNS Load Balancer with a CNAME-type pool, I can't select any health monitor for the CNAME pool. Our goal is to monitor a server service hosted in a third-party cloud and avoid the cloud edge service going down. Once the XC DNS detect a service failure, then it will reply with the fallback dns record (from another cloud service) to the user. Is there have any other way to monitor the health of CNAME pool ? Regards, Dingcan't access on prem dns when using F5LTM as a gateway
The title is the tl/dr. I have a server on an internal network that is set up to use our F5 as a gateway. I have all of the forwarding vip's set up and routed through snat pools. and if i set the server to use an external dns like google or opendns everything seems to work perfectly. however the server is being set up as an smtp server and needs to rely on our on prem dns for some mail destinations. side note, if forwarding vip's are set for snat automap, on prem dns works fine. i did watch traffic with tcpdump from the F5, on the internal network when using nslookup with both on prem and off prem dns servers, i could see traffic hit the outbound forwarding vip. however watching traffic on the external network, traffic appeared on the outbound forwarding vip's when using external dns servers. on prem seem to have died somewhere in the F5. can i fix this by just adding another outbound vip set to snat outmap to manage dns traffic? is that an appropriate fix?
F5 upgrades
We are upgrading F5 tenants from 17.1 to 17.5. We have Two R-series pairs at each data center ( ex:main and colo) Within the data center, they are in HA active standby and the 4 are in a GSLB group . Each host has one tenant During the upgrade process, I disabled GTM Sync on the F5 that is going to be upgraded. Is it recommended? I plan on having traffic moved to this active box at ex colo from the other data center main, I won't be making any config changes . After the applications move to this side, LTM pools show up on this side and global availability will have the upgraded side up. just want to make sure, if that is disabled, do we need to leave them disabled and sync them after all the 4 F5s are upgraded? during this process, can we make changes with the data center on LTM pools? Thank youDNS/GTM health monitor big3d timeout because of alias config
Hello Everyone, I was testing some experimental config for DNS/GTM where the health monitor does not monitor the pool members but a specific IP address configured in the "alias" and it does not work as the error says bigd timeouts to report the state. For LTM http/https health monitors the "alias" option works but not for gtm/dns. I think I discovered a bug as this is rare use case to not monitor the pool members themselves. I have changed the ip to 1.1.1.1 just for the picture screenshot 😄 Also in the logs after gtm and big3d is enabled I see the logs below and too bad that F5 DNS does not have monitor debug like LTM to just enable a debug for a monitor and not the entire box. ----- Will not probe x.x.x.x:80 ( in DC /Common/niki-dc because will be done by other GTM (<unknown>:<unknown>) Unable to identify which gtm server represents the local device
