When Asterisk (using the PJSIP channel driver) is instructed to dial 6000@gen.uk, it does not simply look up an A record and connect. Instead, it follows a defined resolution hierarchy to discover the correct transport, port, and destination IP address. This mirrors the process described in RFC 3263 (Locating SIP Servers).

Resolution Hierarchy Overview

Asterisk/PJSIP works through the following steps in order:

1. NAPTR lookup — discovers available transports and points to SRV records
2. SRV lookup — discovers the hostname and port for a specific transport
3. A (or AAAA) record lookup — resolves the SRV target hostname to an IP address
4. Fallback A record lookup — used if no NAPTR or SRV records exist

Step 1 — NAPTR Lookup

Asterisk queries for NAPTR records on the domain gen.uk.

NAPTR (Naming Authority Pointer) records advertise which SIP transports are available and map them to SRV service names.

Example DNS response:

<code>;; ANSWER SECTION:
gen.uk.  3600  IN  NAPTR  10  10  "S"  "SIPS+D2T"  ""  _sips._tcp.gen.uk.
gen.uk.  3600  IN  NAPTR  20  10  "S"  "SIP+D2T"   ""  _sip._tcp.gen.uk.
gen.uk.  3600  IN  NAPTR  30  10  "S"  "SIP+D2U"   ""  _sip._udp.gen.uk.
</code>

Field breakdown:

Asterisk selects the record with the lowest order value that matches a transport it has configured. In this example, if TLS is configured, it would follow <em>_sips.</em>_tcp.gen.uk.; otherwise it would fall through to <em>_sip.</em>_udp.gen.uk..

Step 2 — SRV Lookup

Using the SRV target identified in the NAPTR record, Asterisk queries for SRV records. Assuming UDP is selected:

Query: <em>_sip.</em>_udp.gen.uk

Example DNS response:

<code>;; ANSWER SECTION:
_sip._udp.gen.uk.  3600  IN  SRV  10  20  5060  sip1.gen.uk.
_sip._udp.gen.uk.  3600  IN  SRV  10  10  5060  sip2.gen.uk.
_sip._udp.gen.uk.  3600  IN  SRV  20  10  5060  sip3.gen.uk.
</code>

Field breakdown:

Asterisk will attempt sip1.gen.uk and sip2.gen.uk first (both priority 10, with sip1 weighted higher), and only try sip3.gen.uk if both priority-10 targets fail.

Step 3 — A Record Lookup for SRV Target

Asterisk now resolves the hostname returned by the SRV record to an IP address.

Query: sip1.gen.uk

Example DNS response:

<code>;; ANSWER SECTION:
sip1.gen.uk.  3600  IN  A  203.0.113.10
</code>

Query: sip2.gen.uk

<code>;; ANSWER SECTION:
sip2.gen.uk.  3600  IN  A  203.0.113.11
</code>

Query: sip3.gen.uk

<code>;; ANSWER SECTION:
sip3.gen.uk.  3600  IN  A  203.0.113.12
</code>

Asterisk now has a complete destination: 203.0.113.10:5060 over UDP, and will attempt to send the SIP INVITE there.

Step 4 — Fallback A Record Lookup

If no NAPTR records and no SRV records exist for gen.uk, Asterisk falls back to a direct A record lookup on the domain itself, using the default SIP port.

Query: gen.uk

Example DNS response:

<code>;; ANSWER SECTION:
gen.uk.  3600  IN  A  203.0.113.50
</code>

Asterisk will then attempt to connect to 203.0.113.50:5060 over UDP (the default transport and port when no other information is available).

Summary of the Full Resolution Chain

<code>Dial: 6000@gen.uk
        │
        ▼
1. NAPTR query → gen.uk
   └─ Returns: _sip._udp.gen.uk (SRV target)
        │
        ▼
2. SRV query → _sip._udp.gen.uk
   └─ Returns: sip1.gen.uk:5060 (priority 10, weight 20)
               sip2.gen.uk:5060 (priority 10, weight 10)
               sip3.gen.uk:5060 (priority 20, weight 10)
        │
        ▼
3. A record query → sip1.gen.uk
   └─ Returns: 203.0.113.10
        │
        ▼
4. INVITE sent to 203.0.113.10:5060 (UDP)
</code>

If steps 1–3 yield no results, the fallback is:

<code>A record query → gen.uk → 203.0.113.50
INVITE sent to 203.0.113.50:5060 (UDP)
</code>

Practical Notes

• PJSIP respects DNS TTLs — if a record expires mid-call, re-resolution occurs on the next transaction rather than mid-session.
• Transport must be configured — if NAPTR advertises TLS (SIPS+D2T) but no TLS transport is defined in pjsip.conf, Asterisk skips that NAPTR record and tries the next.
• dig can be used to manually trace this chain:

<code class="language-bash"># Step 1 — NAPTR
dig NAPTR gen.uk

# Step 2 — SRV (UDP example)
dig SRV _sip._udp.gen.uk

# Step 3 — A record for SRV target
dig A sip1.gen.uk
</code>

• Asterisk logging — enabling VERBOSE and DEBUG logging in Asterisk will show the DNS resolution steps in the CLI output, which is useful when diagnosing call routing failures.