Demo
Demo

Knowledge base

PMTA knowledge base›Mechanism§ 4.2.3

The node needs a resolver that does all the work itself

recursive name service
A referral instead of an answer is lost time

The manual states the requirement briefly: the engine needs a recursive name service — a resolver that accepts a query and carries resolution through to the end itself.

Some resolvers do not do recursion and answer with a referral: “ask over there.” Such a response does not carry what the engine needs, and the engine discards it — and repeats the query, counting on the cause being temporary or on another server answering.

When several such responses arrive from the same server, the engine writes a warning to the log. This is the only signal: delivery does not stop, it just goes more slowly.

The manual names two causes, both about resolver configuration: refusing to serve recursion and exhausting the limit on concurrent recursive queries.

The main trap is that this is not a failure but a slowdown. Nothing breaks: messages go out, queues move, there are no errors. Everything just gets slower, and finding the cause from the symptoms is nearly impossible — it is visible only in the log, which nobody looks at when things work.

The second half is the limit on concurrent recursive queries. It kicks in under load, that is, exactly when the resolver is needed most: a mailing has started, there are many domains, many queries — and the resolver starts answering with referrals. On a calm node everything looks healthy.

What the Hub does. It does not set resolvers: there is no name-server line in the configuration, so the engine uses the operating system’s settings — the ones the hosting provider left.

The Hub does not monitor this either: warnings about non-recursive responses live in the node’s log, which the Hub does not parse. So we would not notice this kind of slowdown.

Example configuration
# your own resolvers instead of the hosting provider's: the engine rotates through them
name-server 10.1.2.3
name-server 8.8.8.8
Without these lines the engine uses the operating system’s resolvers. Two or more are enough so that the failure of one does not stop name resolution.
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 ends2 mistakes▶

Considering the resolver healthy because messages go out

§ 4.2.3

What it costsNon-recursive responses do not break delivery — they slow it down. There are no symptoms and no errors, but queues move worse than they could. The cause is visible only in the log.
How to spot itDelivery is slower than expected with no visible cause; the log has warnings about non-recursive responses.
How to do it rightCheck the resolver’s settings — quotas and access lists; if it is someone else’s, set up your own.

Checking the resolver on a calm node

§ 4.2.3

What it costsThe limit on concurrent recursive queries kicks in under load. A check in quiet times succeeds, while during a mailing the same resolver starts answering with referrals.
How to spot itName resolution is fine during the check and slow during a mailing.
How to do it rightLook at the log during load, not after it.
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

2 relations

Depends on

name-serverGlobalChapter 3 sets which resolvers to use; this entry says what they must be like. inference

Where you can see it

The node's own logRepeated referrals from one server produce a log warning — the only sign of this malfunction. § 4.2.3

Referenced from

Name cacheThe numeric sign of the qualitative requirement written in the node preparation. § 4.2.3The name lookup did not complete — and no conclusion is drawnThe resolver requirement whose violation produces this failure. § 4.2.3Resolve a name and connectThe mechanism the command works with. § 6.3.8The receiver declares an encryption requirement in its DNS zoneA resolver with DNSSEC support is needed — without it DANE records deserve no trust and the mechanism does not work. § 10.5Keeping selected domains resolved at all timesThe mechanism takes load off the resolver exactly for the domains that matter most — but does not cancel the requirements for the resolver itself. inference

How to check on the node
The only signal is warnings in the log; the resolver itself is checked with a command:
grep -i 'recursi\|referral' /var/log/pmta/pmta.log | tail -20
pmta resolve gmail.com
Log entries mean the resolver answers with referrals. The second command shows whether resolution goes all the way through — but on a calm node it may succeed, while under load the same resolver will start sending referrals.
◇

What else to read

3 articles

◇What makes a virtual machine riskyRunning on a virtual machine is possible, but the manual does not recommend it without sufficient hardware and properly tuned hypervisor settings: under load the node may stop responding.◇The activation key is a prerequisite for installation, not a step after itWithout an activation key from SparkPost support the engine neither installs nor runs, and the license tier sets the outbound connection ceiling: on Standard everything above 200 is ignored.◇What the node tells about itself and through which channelsSeven observation surfaces: the web monitor, the console in four formats, the log, accounting, accounting search, metrics and export to external analytics.

In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Prepare a node for sending · Untangle a stuck queue