Asterisk PJSIP keeps using the old DNS target

Define the old target and the expected transition

Preserve the affected request owner, URI, proxy, selected transport, previous remote IP and port, newly expected target and the first timestamp at which the change should have been observable. State whether the symptom affects REGISTER, OPTIONS, INVITE or all three. A dashboard label such as Registered does not identify the connection or target used by later calls.

Do not assume the bare hostname's A record owns the path. Reconstruct the URI scheme, transport parameter and explicit port, then the NAPTR or SRV name when applicable and the target's address records. Also record any configured outbound proxy and hosts-file override.

Compare authoritative data with Asterisk's resolver path

Query the authoritative source and the recursive resolver Asterisk actually uses at nearly the same time, recording answer, TTL, response code, DNSSEC state where relevant and resolver identity. Inspect the loaded resolver module and res_resolver_unbound settings if that module owns resolution. A correct authoritative answer with an older recursive answer is a DNS propagation or cache state, not a PJSIP transport failure.

An operating-system lookup can be a useful control but is not sufficient when Asterisk uses different explicit nameservers, resolv.conf or hosts data. Redact internal names and addresses before sharing logs, and do not change resolver scope or trust settings to make one lookup agree.

Identify the target used by the actual SIP transaction

Bound PJSIP logging to one authorized attempt and correlate the request with registration status, the remote socket and a packet or firewall record where permitted. For TCP or TLS, determine whether Asterisk reused an existing connection to the previous IP and port. For UDP, preserve the resolved destination and selected local transport separately.

A stale-looking socket can outlive a DNS answer. Conversely, a new DNS result can be selected but fail before the SIP request completes because the remote service, address family, certificate or firewall path is unavailable. Keep lookup, connection, send and response as distinct evidence stages.

Read TTL and retry clocks independently

Preserve the observed DNS TTL, the time each cache answered, registration expiry, last response, configured retry intervals, maximum retries and next scheduled attempt. TTL expiry does not force an already open connection to close, while reaching the registration retry ceiling can leave the object Stopped even after DNS becomes healthy.

Do not repeatedly reload, unregister or restart while collecting the timeline. Those actions erase the state needed to distinguish resolver cache, connection reuse, registration policy and provider rejection, and can trigger avoidable authentication or abuse controls.

Correct the demonstrated owner and verify service recovery

Correct only the evidenced boundary: authoritative record, recursive cache, Asterisk resolver configuration, explicit URI or port, SRV transport label, proxy owner, address-family reachability, TLS name or trust, connection state or outbound-registration retry policy. Apply changes through the supported standalone Asterisk or FreePBX owner and schedule disruptive activation.

Repeat the same bounded request and preserve its query, selected target, connection, SIP response and provider binding. Then verify required inbound and outbound calls, media, emergency routing under the provider-approved process and restoration behavior. No resolver, PJSIP object, provider path, failover event or call was tested for this diagnostic.

Keep DNS freshness separate from family reachability

A current AAAA answer can still lead to an unreachable path or missing matching transport. The IPv6 diagnostic verifies the selected address, local bind, route and response without treating DNS removal as the first fix.

Separate stale DNS from a non-qualifying SIP failure

The Voip Unlimited DNS diagnostic checks whether the client used a stale target or correctly stayed on a transaction that did not meet RFC 3263 retry conditions.