DNS
"No such host" in Asterisk
Asterisk could not resolve the hostname it was asked to dial, so no channel was ever created. Before blaming DNS, note that a real DNS failure would break every call on the box - not one route.
What it looks like in the log
[2026-08-17 08:55:14] WARNING[2288][C-00000144] chan_sip.c: No such host: trunk-What it means
The lookup failed at getaddrinfo(), which means the name never resolved to an address and the leg died before any SIP traffic was attempted.
The hostname printed in the warning is the whole diagnosis. Look at the example above: trunk- is not a hostname anyone configured. It is the remains of a dial string built from a variable that resolved to nothing, leaving the prefix behind.
Most common causes
-
01A variable that resolved empty inside the host part
The dominant cause. A dial string like
SIP/${NUM}@trunk-${REGION}with an empty region produces exactly the truncated name above. -
02A typo in the peer or trunk name
A name that does not exist in the config and is not resolvable as a hostname either falls through to a DNS lookup and fails here.
-
03A peer name Asterisk treated as a hostname
If the named peer is not defined, Asterisk assumes it must be a host and tries to resolve it. The warning is about DNS but the cause is a missing peer definition.
-
04A genuine DNS problem
Real, but rare, and identifiable by scope: it affects everything at once rather than a single route. If only one destination fails, DNS is working.
-
05An IPv6-only or SRV-only record
A host that publishes only records the current configuration will not use can fail to resolve in a way that looks like absence.
How to tell which one it is
Read the hostname in the warning literally and ask whether it is a name anyone would have written. Truncated names, trailing hyphens, doubled separators and stray characters all point at variable substitution rather than at DNS.
Then check whether other calls on the same box succeeded at that timestamp. If they did, name resolution on the host is fine and the problem is the string, not the resolver.
How to fix it
-
Trace the variable building the dial string
Find where the empty component was supposed to be set and why it was not. The fix belongs there, not at the Dial.
-
Define the peer if it is meant to be one
A dial target intended as a configured peer needs to exist as one, otherwise Asterisk will keep treating it as a hostname.
-
Guard the dial string before dialling
Checking the component variables are non-empty before Dial() converts this into a clean dialplan branch.
-
Verify resolution from the box itself
If the name in the warning is genuinely correct, resolve it from the Asterisk host as the asterisk user before concluding the resolver is at fault.