Bug ID 1084173: Unable to specify "no caching desired" for ephemeral DNS resolvers (i.e. RESOLV::lookup).

Last Modified: Aug 23, 2022

Bug Tracker

Affected Product:  See more info
BIG-IP All(all modules)

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

Symptoms

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.

Impact

Inability to support specific use-cases in a BIG-IP iRule.

Conditions

Sending repeated queries for the same FQDN to different ephemeral resolvers (before the TTL expires) and expecting different results back.

Workaround

None

Fix Information

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.

Behavior Change