I’m trying to use DNS SRV while setting a PJSIP trunk between two Asterisk 16 boxes in my lab.
My ultimate goal is use domain name s in trunking instead of IP addresses.
On box A, as a first step, endpoint B is configured with (details skipped):
This works OK: testbed2 is shown as reachable on box A.
I’ve configured on box A a Dnsmasq instance to provide local SRV resolution of foo.nodns.
Il seems to work OK (output is anonymized, errors may have been while doing so):
# dig srv _sip._udp.foo.nodns
; <<>> DiG 9.11.5-P4-5.1+deb10u7-Debian <<>> srv _sip._udp.foo.nodns
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15738
;; flags: qr aa rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 2
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;_sip._udp.foo.nodns. IN SRV
;; ANSWER SECTION:
_sip._udp.foo.nodns. 0 IN SRV 1 0 5060 sbc1.foo.nodns.
;; ADDITIONAL SECTION:
sbc1.foo.nodns. 0 IN A 192.168.4.61
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: mar. janv. 24 17:03:18 CET 2023
;; MSG SIZE rcvd: 106
Now I’m trying to use foo.nodns or sbc1.foo.nodns instead of 192.168.4.61 in PJSIP config on box.
It fails : box A is not even trying to send any OPTION to foo.dns or sbc1.foo.nodns.
Replying to myself, now I don’t think root cause was either a missing dnsmgr.conf or resolve_unbound.conf.
I agree this is quite vague but I now think the root cause was some data persistence that kept this Asterisk instance from sending an OPTION message to the new IP address when name resolution changes.
I have the opportunity to do so, I’ll try to investigate on a newer Asterisk version (Bookworm’s 20.1, hopefully).
To summarize the issue:
I’ve got 3 Asterisk 16.16 instances A, B and C
B and C have almost the same configuration
when changing DNS settings on A, I can switch trunking from A to B or A to C
for an unknown reason, after changing DNS, trunking doesn’t work anymore
after some time and/or after restarting hosts, trunking works again
While debugging, I saw a couple of messages like “resolving foo.example.com” but not enough data within this message to learn the source used to resolve names, nor the value of resolved IP address.