Forum Discussion
Jon_Macy
Altostratus
AltostratusLTM with DNS - logging query answers DNS_RESPONSE clientside
Hi All
We have our DNS services behind LTM VIPs. We have the DNS license and are using DNS_QUERY and DNS_RESPONSE events for logging queries and answers. We are not using Express, BIGIP Bind, nor GTM configurations - straight LB work. Last week I was investigating some optimizations and wanted to add Answer header information, specifically the truncate flag. This will allow us to gather some stats on the amount of UDP to TCP based queries occuring. I added [DNS::header tc] to the log message on DNS_RESPONSE and proceeded to test from a client system using DIG for a test SRV record that exceeded 512bytes using UDP. DIG did the expected things and sent a UDP query, got a response with truncate on, and re-queried with TCP. All good. However, when I looked at the logs, [DNS::header tc] was always returning 0. From network trace, I see client to VIP, SNAT to service, service to SNAT, VIP to client. The client side traffic is as expected - no EDNS0, buffer set to 512bytes, etc. As well the answer in UDP shows the truncate flag set to 1. Further examination showed that while the client had specified no EDNS0, buffer 512bytes, etc., the SNAT to DNS service traffic showed EDNS0 on and buffer of 4096bytes. I asked our F5 account rep if he had any insights and he agreed that DNS_RESPONSE seems to be pulling from server-side. I tried using [clientside {DNS::header tc}] in the logging statement, but got the same results - truncate still shows 0.
Questions:
1. Is there a way to tell LTM to respect the client settings for the server side communications?
2. Can I get the client-side info in the DNS_RESPONSE event?
Thanks
Juergen_MangMVP
I have no experience with DNS, but you can try this: https://clouddocs.f5.com/api/irules/clientside.html
Jon_MacyThanks but I tried that with using [clientside {DNS::header tc}] in the logging statement, but got the same results - truncate still shows 0.
- Juergen_Mang
I am unsure what you attempt to achieve. Do you want to log the truncated flag in a request or the truncated flag in the response? As far i know, only the response has the flag populated and in the request this flag is always set to 0.
- Jon_Macy
Yes the logging is on the DNS_RESPONSE. We log both the query and the response. In the response (UDP), we want to capture the truncate flag. This allows us to then relate the initial UDP query to the following TCP query for the same record. The stats and metrics would be useful to scale and optimize.
- Juergen_Mang
But why [clientside {DNS::header tc}]?
How I read the documentation, this should work as you expected and already tested.
when DNS_RESPONSE { log local0. [DNS::header tc] }If you want to log the dns natively without DNS specific iRules you can use this iRules: https://github.com/JuergenMang/f5-dns-logging
- Jon_Macy
I would agree that DNS_RESPONSE should be giving me what I want, however, testing ahs shown that it only considers the server side conversation (F5 SNAT to Pool instance). It will not/does not give you access to the client side header info. I can see it plainly in traces. A side note - it appears that F5 LTM with DNS Profile (nothing else, straight LB) does not pass through the client side DNS header on the query. In my tests, I set my client side to no EDNS, 512bytes UDP and sent the query in. The F5, reformulates the query and sends EDNS0 and 4096bytes to the pool member. WHen the poolmember responds back, the F5 then attempts to send the response evaluating the client side header flags. In the traces, I see it set the truncate flag in the header on the client side response. The only thing I can figure is F5 is doing the "fiddling" on the client response post the iRule processing.