Parsing TTL from DNS packets: doable?

[ReneeRussell]

I am being asked to parse out TTL from DNS response packets, but am seeing difficulties with this.

   1) DNS packets don't have any strings to anchor a position off of and so would just be pulling straight positional data which in essence would then activate against ALL packets, further there would be difficulties with sanity checking the data.

   2) the number of TTL in each packet is dependent on the answers contained in the packet, this would mean setting up an array and stuffing the results inside, but again the problem comes down to finding the number of answers and setting up a loop to get them all.

This does not appear to me a good case for parsing but wanted to see if anyone had any helpful suggestions or pointers that I might not have considered.

[WilliamMotley1]

There are already TTL-related meta registered by DNS_verbose_lua:

    analysis.service:  dns low ttl

    analysis.service:  dns extremely low ttl

    analysis.service:  dns extremely low auth ttl

Threshold for "low" is 600.

Threshold for "extremely low" is 60.

[ReneeRussell]

I believe those are what has inspired the request to parse the TTLS into meta so that if those trigger then they can see what the value was and if the packet had multiple responses, which one 'popped' the threshold.

[WilliamMotley1]

If all TTLs were registered as meta you still wouldn't have a way to tie a given TTL meta to the name/address meta from the record.

While it doesn't help programmatic analysis, you can infer a relationship in the event view.  Meta will be listed in the order it was registered.  So look for the host or address immediately preceding e.g. "dns low ttl":

alias.host:  www.example.com

alias.host:  www.example.org

analysis.service:  dns low ttl

In the above, "dns low ttl" would be for the record for www.example.org.