Demo
Demo

Knowledge base

PMTA knowledge base›Mechanism§ 11.12

Keeping selected domains resolved at all times

pre-cached domains
Name resolution leaves the delivery path

Normally the engine resolves a name when recipients appear for the domain — and that takes time, the more so the more loaded the resolver is.

The mechanism reverses the order: domains from the file are kept resolved always, whether or not there are messages for them in the queue. They are refreshed on their own schedule, not by the receiver’s record time to live: that time to live is ignored.

The manual names two problems the mechanism solves: resolver load when many domains are loaded at once, and domains with a short record time to live.

There are three settings, all in the <dns> block: the list file (precached-domains-file), the refresh interval (precached-refresh-interval) and the cap on the number of domains (precached-max-domains).

The main trap is the very property the mechanism is set up for. The receiver’s record time to live is ignored, so you will not notice a route change until the next refresh. All that time messages go to the old servers — not into a queue, but precisely to a non-existent or changed address.

Large receivers do change routes, and the short record time to live they use is no accident: it is their way to switch traffic quickly. The precache disables that way.

The second half is quieter: only the first entries up to the cap are taken from the file. A longer list is cut off silently, and domains you considered cached are resolved the ordinary way.

What the Hub does. It does not use it: there is no <dns> block in the configuration, and no list file either.

The mechanism would fit our case exactly — the node sends to a few large receivers, and their names are resolved again and again. But the price is the same: we would see a receiver’s route change with a delay of one refresh interval, and would learn nothing about it.

Example configuration
# three lines: the list, the cap and the refresh schedule
<dns>
    precached-domains-file /etc/pmta/precached-domains.txt    precached-max-domains 500
    precached-refresh-interval 5m
</dns>
One domain per line in the file. Only the first entries up to the cap are taken from it — the rest are cut off silently.
yellow — — directive names, blue — blocks. They are highlighted the same way in the text of the card.
▲

Common mistakes and problems

what people get wrong and how it ends3 mistakes▶

Caching a receiver that changes routes

§ 11.12

What it costsThe record’s own time to live is ignored, and the engine will not notice a route change until the next refresh. All that time messages go to the old servers.
How to spot itConnection failures to a receiver whose DNS data already lists other servers.
How to do it rightCache only domains with stable routes, or choose a refresh interval noticeably shorter than their record time to live.

Putting more domains in the file than the ceiling allows

§ 11.12

What it costsOnly the first entries are taken. The rest are resolved the ordinary way, and nothing reports it — the list looks fully working.
How to spot itSome of the domains from the file are not visible in the cache contents.
How to do it rightCompare the number of lines in the file with the cap and raise the cap or shorten the list.

Setting a large list with a short interval

§ 11.12

What it costsEvery refresh means queries for all domains on the list. A mechanism meant to take load off the resolver starts creating it.
How to spot itThe resolver answers more slowly after the cache is enabled.
How to do it rightDo the load math: the number of domains divided by the interval is queries per second, and they are constant.
Compatibility
PowerMTA 6.0
described in the manual of this version · platform: any
The vendor does not state the first version for every directive — there is no note here. The name also appears in the 5.0 edition of the manual.
⇄

Related entries

3 relations

Works together with

Flush the name cacheClears the name cache for a domain — the only way not to wait for the next refresh. inferenceThe node needs a resolver that does all the work itselfThe mechanism takes load off the resolver exactly for the domains that matter most — but does not cancel the requirements for the resolver itself. inference

Where you can see it

Domains resolved in advanceThe only command that shows what actually got into the precache. § 11.12

How to check on the node
The setting is visible in the configuration, the cache contents — with a node command:
grep -n -A4 '^<dns>' /etc/pmta/config
pmta show precache
wc -l /etc/pmta/precached-domains.txt
The number of lines in the file is worth comparing with the cap: exceeding it means a silently truncated list. The command shows what actually sits in the cache.
◇

What else to read

3 articles

◇A queue is a receiving server together with a sending addressThe engine groups messages by the “recipient domain plus sending address” pair: one domain from two addresses is two independent queues with their own counters, connections and mode.◇Recipients deferred after a temporary refusalA recipient to whom the receiver responded with 4xx moves into a separate waiting area with a per-receiver interval; two commands can release it early.◇A retry ladder of your ownretry-after and backoff-retry-after accept a list of intervals — up to 30 steps, and the last one applies until the bounce.

In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Tune the pace for a provider · Untangle a stuck queue