Last Modified: May 29, 2024
Affected Product(s):
BIG-IP All
Known Affected Versions:
15.1.0, 15.1.0.1, 15.1.0.2, 15.1.0.3, 15.1.0.4, 15.1.0.5, 15.1.1, 15.1.2, 15.1.2.1, 15.1.3, 15.1.3.1, 15.1.4, 15.1.4.1, 15.1.5, 15.1.5.1, 15.1.6, 16.1.0, 16.1.1, 16.1.2, 16.1.2.1, 16.1.2.2
Fixed In:
17.0.0, 16.1.3, 15.1.6.1
Opened: Mar 01, 2022 Severity: 3-Major
Each time the iRule command RESOLV::lookup is invoked with a different target IP address or internal virtual server, a unique resolver context is created. However, for performance and memory preservation reasons, all ephemeral resolvers are backed by the same set of DNS caches. This means that repeated identical queries to different ephemeral resolvers will always return the answer from the cache that was retrieved by the first ephemeral resolver (until the TTL of the record expires). While this is fine in the traditional use of DNS, this may be problematic in certain specific use-cases. For example, this does not allow for per-user DNS servers to return different results for the same query. This technique could be used by an iRule to retrieve user-specific information to then spin up user-unique virtual environments.
Inability to support specific use-cases in a BIG-IP iRule.
Sending repeated queries for the same FQDN to different ephemeral resolvers (before the TTL expires) and expecting different results back.
None
Versions with the fix include a new DB key called dnscache.ephemeralsnocache, which defaults to "disable". When set to "disable", the system behaves exactly as in previous releases. When set to "enable", ephemeral resolvers spawned in an iRule by the RESOLV::lookup command no longer cache anything, thus allowing for use-cases similar to the example mentioned under Symptoms.