DNS works over UDP by default, that is unless the UDP response contains the Truncated flag which tells the client to use TCP instead. More information here: https://ns1.com/blog/when-dns-uses-udp-versus-tcp I've tested this myself, FreeSWITCH ignores the Truncated flag and continues to use UDP anyway. It seems that FreeSWITCH is not RFC 2671 compliant, this would need to be developed. There is a related open issue: https://github.com/signalwire/freeswitch/issues/907 ________________________________ From: FreeSWITCH-users <freeswitch-users-bounces@lists.freeswitch.org> on behalf of Sergey Safarov <s.safarov@gmail.com> Sent: 12 December 2021 20:37 To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org> Subject: Re: [Freeswitch-users] Weird: Cloudflare 1.1.1.1 DNS server not working with sofia_dig To reproduce the issue you can create a NAPTR record with lot of data and then try to make a call to a domain that resolved via NAPTR/SRV In my case Example [safarov@safarov-dell ~]$ nslookup -type=NAPTR ok.nga911.com<http://ok.nga911.com> ;; Truncated, retrying in TCP mode. Server: 127.0.0.53 Address: 127.0.0.53#53 Non-authoritative answer: ok.nga911.com<http://ok.nga911.com> naptr = 100 10 "U" "LoST:findServiceByCivicAddress" "!.*!https://api.ok.nga911.com/api/v1/lost/find-service-by-civic-address!" . ok.nga911.com<http://ok.nga911.com> naptr = 100 10 "U" "LoST:listServicesByLocation" "!.*!https://api.ok.nga911.com/api/v1/lost/list-services-by-location!" . ok.nga911.com<http://ok.nga911.com> naptr = 100 10 "U" "LoST:listServices" "!.*!https://api.ok.nga911.com/api/v1/lost/list-services!" . ok.nga911.com<http://ok.nga911.com> naptr = 100 10 "U" "LIS:HELD" "!.*!https://psap.ok.nga911.com/LIS/!" . ok.nga911.com<http://ok.nga911.com> naptr = 50 500 "S" "SIPS+D2W" "" _sips._ws.ok.nga911.com<http://ws.ok.nga911.com>. ok.nga911.com<http://ok.nga911.com> naptr = 30 300 "S" "SIP+D2U" "" _sip._udp.ok.nga911.com<http://udp.ok.nga911.com>. ok.nga911.com<http://ok.nga911.com> naptr = 20 200 "S" "SIP+D2T" "" _sip._tcp.ok.nga911.com<http://tcp.ok.nga911.com>. ok.nga911.com<http://ok.nga911.com> naptr = 100 10 "U" "LoST:findServiceByLocation" "!.*!https://api.ok.nga911.com/api/v1/lost/find-service-by-location!" . ok.nga911.com<http://ok.nga911.com> naptr = 40 400 "S" "SIPS+D2T" "" _sip._tls.ok.nga911.com<http://tls.ok.nga911.com>. Authoritative answers can be found from: NAPTR response UDP will not contain the whole responce. you can see ;; Truncated, retrying in TCP mode. If response via UDP do not contains ok.nga911.com<http://ok.nga911.com> naptr = 30 300 "S" "SIP+D2U" "" _sip._udp.ok.nga911.com<http://udp.ok.nga911.com>. Then FS will fail place a call. On Sun, Dec 12, 2021 at 10:15 PM Avi Marcus <avi@avimarcus.net<mailto:avi@avimarcus.net>> wrote: Also FreeSWITCH Version 1.10.7-release-19-883d2cb662~64bit (-release-19-883d2cb662 64bit) On debian 9.13 `sofia_dig -v @1.1.1.1<http://1.1.1.1> google.com<http://google.com>` works, with and without the -v flag. -Avi Marcus On Sun, Dec 12, 2021 at 8:22 PM Antony Stone <Antony.Stone@freeswitch.open.source.it<mailto:Antony.Stone@freeswitch.open.source.it>> wrote: On Friday 10 December 2021 at 06:54:23, Podrigal, Aron wrote:
Hi,
I am experiencing weird behavior.
I have my nameserver set to 1.1.1.1, doing sofia_dig returns no results, one request out of five succeeds.
I cannot reproduce that (FreeSwitch 1.10.7 running under Debian 10 / Devuan 3): freeswitch> sofia_dig -v @1.1.1.1<http://1.1.1.1> google.com<http://google.com> Preference Weight Transport Port Address ================================================================================ @1.1.1.1<http://1.1.1.1> 1 1.000 udp 5060 1.1.1.1 2 1.000 tcp 5060 1.1.1.1 google.com<http://google.com> 1 0.250 udp 5060 2a00:1450:4009:81e::200e 1 0.250 tcp 5060 2a00:1450:4009:81e::200e 1 0.250 udp 5060 142.250.187.206 1 0.250 tcp 5060 142.250.187.206 I get a result every single time. Antony. -- <flopsie> yes, but this is #lbw, we don't do normal Please reply to the list; please *don't* CC me. _________________________________________________________________________ The FreeSWITCH project is sponsored by SignalWire https://signalwire.com Enhance your FreeSWITCH install with disruptive priced SMS and PSTN services. Build your next product on our scalable cloud platform. Join our online community to chat in real time https://signalwire.community Professional FreeSWITCH Services sales@freeswitch.com<mailto:sales@freeswitch.com> https://freeswitch.com Official FreeSWITCH Sites https://freeswitch.com/oss https://freeswitch.org/confluence https://cluecon.com FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org<mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users https://freeswitch.com _________________________________________________________________________ The FreeSWITCH project is sponsored by SignalWire https://signalwire.com Enhance your FreeSWITCH install with disruptive priced SMS and PSTN services. Build your next product on our scalable cloud platform. Join our online community to chat in real time https://signalwire.community Professional FreeSWITCH Services sales@freeswitch.com<mailto:sales@freeswitch.com> https://freeswitch.com Official FreeSWITCH Sites https://freeswitch.com/oss https://freeswitch.org/confluence https://cluecon.com FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org<mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users https://freeswitch.com