Forum Discussion

Jon_Macy's avatar
Jon_Macy
Icon for Altostratus rankAltostratus
Nov 13, 2023

LTM 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

application delivery
dns
load balancing
LTM
  • Jon_Macy's avatar
    Jon_Macy
    Icon for Altostratus rankAltostratus
    Nov 20, 2023

    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.

  • Juergen_Mang's avatar
    Juergen_Mang
    Icon for MVP rankMVP
    Nov 20, 2023

    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's avatar
    Jon_Macy
    Icon for Altostratus rankAltostratus
    Nov 20, 2023

    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's avatar
    Juergen_Mang
    Icon for MVP rankMVP
    Nov 20, 2023

    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's avatar
    Jon_Macy
    Icon for Altostratus rankAltostratus
    Nov 20, 2023

    Thanks but I tried that with using [clientside {DNS::header tc}] in the logging statement, but got the same results - truncate still shows 0.