dnsdist: Add new parameter to newPacketCache "truncatedNoAnswerTTL"

[dmccombs]

• Program: dnsdist
• Issue type: Feature request

Short description

Add new parameter to newPacketCache to allow caching TC responses with no rdata.

Usecase

To allow caching of empty TC responses for some short amount of time and avoid sending every query to the backends.

Description

Normally, truncated responses from backends with the TC flag set, and no answers provided, do not get cached due to the lack of any record data with a TTL. This means that any recurring UDP queries miss cache and are sent to the backends (likely even to an authoritative from there) only to again respond to the client to retry over TCP.

This can generate a lot of unnecessary traffic to both backends and potentially out to authoritatives for popular queries with large answers.

I propose adding a new parameter to newPacketCache called something like truncatedNoAnswerTTL that functions much like the existing temporaryFailureTTL. It should default to 0, but can be set to a value of number of seconds for which any empty truncated responses from backends will be cached. This would allow operators to choose to have the bulk of these queries hit cache automatically, immediately returning a TC response to clients to retry over TCP. This would reduce load on backends and potentially out to other providers, without having to explicitly configure rules to do this for popular problem queries.

An example of the type of query response that would be cached in this case:

> dig cisco.com TXT @ns1.cisco.com +ignore +nord +notcp

; <<>> DiG 9.20.2 <<>> cisco.com TXT @ns1.cisco.com +ignore +nord +notcp
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53389
;; flags: qr aa tc; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 40d4b3216c382f5801000000671ab934a4cb63cc710d088a (good)
;; QUESTION SECTION:
;cisco.com.                     IN      TXT

;; Query time: 56 msec
;; SERVER: 72.163.5.201#53(ns1.cisco.com) (UDP)
;; WHEN: Thu Oct 24 17:16:24 EDT 2024
;; MSG SIZE  rcvd: 66

[phonedph1]

#13531

[dmccombs]

@phonedph1 yes, definitely related, but just wanted to propose a specific option to implement without getting lost in the noise of the comments there.

[rgacogne]

It makes a lot of sense to me, I'd gladly merge a pull request implementing this.

[dmccombs]

Thanks @rgacogne. Hopefully I'll have a chance to work on this and get a PR opened as time allows.