When a carrier hostname suddenly stops resolving

Test from the effective service context

Fast answer: on this build, Asterisk is not a systemd service you can query for health in the usual way — vicidial.service (Type=forking) starts Asterisk and the dialer screens at boot, then exits, so systemctl is-active vicidial reporting inactive afterward is normal, not a fault. asterisk -rx 'core show uptime' is the real health check regardless of what systemctl reports about either unit.

Because Asterisk here runs as an ordinary long-lived process rather than a hardened systemd unit with its own network namespace or chroot, a DNS lookup run in an ordinary root shell on this same host generally sees exactly the same resolver configuration Asterisk itself does. The 'the daemon sees a different context than my shell' failure mode this article once led with is real on other deployments — a distro package running Asterisk under a dedicated systemd unit with its own User=, PrivateNetwork=, or inside a container — but it is not the likely story on a stock ViciBox box. Read the plain resolver configuration first, and only chase a namespace difference if you are troubleshooting a deployment that genuinely confines Asterisk that way.

A message such as subscriber absent can be downstream noise when the upstream hostname never resolved in the first place.

resolv.conf and systemd-resolved are not the only two possible owners of resolution on a Linux host in general, even though this build most likely uses one of them plainly. A NetworkManager dispatcher script, a container runtime's own DNS injection, or a local caching resolver bound only to loopback can each rewrite or shadow resolv.conf independently of both. If neither of the two checks below explains what you are seeing, name and rule out whichever of those your own environment actually runs before assuming the carrier record itself is at fault.

A trunk, in this article, is the specific signaling connection between this server and one carrier's network — the thing whose hostname is failing to resolve. See VICIdial terminology for complete beginners: users, phones, campaigns and leads for the rest of this glossary.

grep -E '^nameserver' /etc/resolv.confif systemctl is-active --quiet systemd-resolved; then  resolvectl status || echo "systemd-resolved is active, but resolvectl status failed"else  echo "systemd-resolved is not active or its status could not be checked"fisystemctl list-unit-files | grep -i vicidialasterisk -rx 'core show uptime'TARGET_HOST='sip.carrier.example'getent ahosts "$TARGET_HOST" || echo "no address (exit $?)"

Read A, AAAA and SRV answers separately

An A record maps a name to IPv4, AAAA maps it to IPv6 and SRV describes a service target plus port/priority. A carrier may publish one, several or none of these, and the SIP client must be configured for the record family it actually follows.

A carrier may publish several SRV records with priority and weight values; the client’s support and configuration determine how it uses those targets. If your SIP stack is configured to use only the single target you saw the day you set the trunk up, a carrier that later shifts traffic to a second SRV target during their own maintenance can look, from your side, exactly like this article's symptom — a suddenly unreachable target — even though DNS itself never broke.

The .example values below are reserved placeholders. Replace them only with the approved hostname; an empty answer can be valid for an unused record type, so compare with the carrier's current written specification.

TARGET_HOST='sip.carrier.example'dig +noall +comments +answer A "$TARGET_HOST"dig +noall +comments +answer AAAA "$TARGET_HOST"dig +noall +comments +answer SRV "_sip._udp.$TARGET_HOST"

Inspect permissions and routing

Confirm the service can traverse every parent directory leading to resolver files and can reach the configured DNS servers. A permission change high in the path can break lookups without changing the DNS data itself.

Compare A, AAAA and SRV behavior and note whether the application follows the record type expected by the carrier profile.

A firewall change is worth ruling out here too, separately from resolver configuration: a DNS query itself uses UDP or TCP port 53 outbound, and a rule tightened on this host's own outbound path — as opposed to the inbound rules this build's own firewalld normally governs — can produce exactly this symptom, a lookup that times out rather than one that returns NXDOMAIN. Confirm outbound reachability to the configured DNS servers on port 53 specifically, not just general internet connectivity, before ruling this out.

• Every directory from / down to /etc is at least traversable by the account performing the lookup.
• resolv.conf itself, or the file systemd-resolved actually reads from, is owned and readable as expected.
• The DNS servers named in either file are reachable on port 53 from this host, not only from your own workstation.

Verify more than name resolution

After fixing the resolver path, confirm fresh DNS answers, socket creation, registration or trunk health and an end-to-end call. Cached answers can make a partial recovery look complete.

Record the resolver source of truth and its ownership so later configuration management does not overwrite the repair.

• A fresh dig against the carrier hostname, run again after the fix, not reused from before it.
• Check the relevant PJSIP or chan_sip endpoint and registration state when this trunk uses registration; an IP-authenticated trunk may not register.
• One synthetic call actually completes end to end over the recovered trunk.

Rollback the narrow resolver change

If an approved resolver or service-context change fails, restore the exact prior managed file/unit setting rather than hand-writing a new resolv.conf. Configuration management, a local stub resolver and a container/chroot can each own different files.

After reversal, query again from the effective context and verify registration/trunk health plus one synthetic call. A cached shell answer alone is not recovery evidence.

Record who changed the resolver configuration, when, and why, in the same change system that tracks the rest of this server's configuration — not only in this incident's own notes. A resolver change that fixes today's symptom but is never folded back into configuration management is exactly the kind of drift that reappears the next time the server is rebuilt or the next admin reads a stale file expecting it to still be authoritative.

• Restore the prior owner-managed resolver or unit configuration.
• Confirm fresh answers and socket/trunk state without flushing globally.
• Escalate when the authoritative carrier answer or intended record family is unknown.