Asterisk PJSIP DNS resolution: SRV, TTL and live-state boundaries

Start with the effective URI and request owner

Record the exact running Asterisk branch, configuration owner and request being investigated: an outbound registration, endpoint request, AoR qualification or explicit dialed SIP URI. Preserve its effective URI, scheme, host, port, transport parameter, outbound proxy and explicit transport object. REGISTER, OPTIONS and INVITE can be owned by different objects and need not share one DNS or proxy path.

Asterisk's PJSIP transport-selection documentation says URI parsing supplies the transport type. A missing transport parameter defaults to UDP for this process, while a SIPS scheme selects TLS. Do not infer a resolver query from a hostname alone; an explicit IP address, port, proxy or already selected route changes the path.

Know when SRV discovery is in the selection path

Asterisk documents DNS SRV resolution for a non-IP host when the URI has no port. The transport type determines the SRV service queried, so TCP and TLS need the type in the URI unless SIPS already selected TLS. Record the actual query name and response rather than testing only the bare domain's A or AAAA record.

RFC 3263 defines SIP server discovery across transport, port and address records. An explicitly configured port can bypass the SRV step in Asterisk's documented selection process. Hard-coding an address or port is therefore a routing change, not a neutral DNS test, and can also change TLS identity, provider support and continuity behavior.

Interpret SRV priority and weight without inventing health

RFC 2782 gives lower numeric priority precedence and uses weight to distribute selection among records at the same priority. Preserve every SRV target, priority, weight, port and TTL, then each target's A and AAAA answers. Priority is not a measured latency score, and weight is not an ordered backup list or a promise that one PBX will alternate predictably.

DNS publication establishes candidates. It does not prove that a target accepts the selected transport, presents the expected TLS identity, recognizes the account, returns a qualifying SIP response or survives an established call. Provider continuity claims require a bounded failure and restoration exercise at the supported interface.

Separate resolver configuration from the PJSIP transaction

Asterisk's res_resolver_unbound reference allows explicit nameservers, a resolv.conf path, a hosts-file path and a trust-anchor file. Explicit nameservers are tried before nameservers from the configured resolv.conf source. Preserve the loaded resolver module and effective files or servers; the operating system's command-line resolver result may not prove what this Asterisk process queried.

The Asterisk DNS API records TTL and secure, bogus or NXDOMAIN result state and describes recurring resolution according to the lowest returned TTL for consumers that request recurring queries. That API capability is not evidence that every PJSIP object continuously reselects targets or tears down live state when an answer changes.

Keep TTL expiry, connection reuse and registration retry separate

A TTL bounds reuse of a DNS answer by a compliant cache; it is not a timer that ends a SIP dialog, closes a TCP or TLS connection or forces an outbound registration to move. Asterisk's transport-selection guide says an existing connection to the resolved IP address and port can be reused. Preserve connection creation and close times, REGISTER response and expiry, next retry and the remote target actually used.

Outbound registration owns its own retry policy and status. A DNS answer can be current while a registration is Stopped after its retry limit or rejected by the peer; a registration can remain on an established connection while another resolver view has changed. Restarting Asterisk collapses resolver, connection and registration state at once and should not be the first diagnostic.

Design a bounded DNS change and recovery acceptance test

Before an authorized change, capture authoritative records and serial, recursive answers from the resolver Asterisk uses, remaining TTL where exposed, PJSIP status, current connection and provider-side binding. Define the expected behavior for new REGISTER, OPTIONS and INVITE requests separately, including address family, transport, TLS name, retry ceiling and rollback.

During the exercise, timestamp the zone change, authoritative availability, each recursive answer, PJSIP transaction, connection transition and provider binding. Confirm both call directions, media and restoration after DNS success. Do not flush shared caches, lower production TTLs, remove healthy targets or restart a PBX without change authority and a rollback plan. No DNS, failover or call behavior was tested for this guide.

Carry each DNS answer into an address-family check

An A or AAAA result is a candidate rather than reachability proof. Use the dual-stack PJSIP guide to confirm a matching transport, listener, route and provider path before changing DNS.

Continue PJSIP DNS evidence into provider-target retry

After proving the live resolver set, use the Voip Unlimited DNS failover workflow to correlate selected targets, qualifying SIP failure and the next transaction.