Weird: Cloudflare 1.1.1.1 DNS server not working with sofia_dig
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. - When I do a dig / host lookup directly outside freeswitch using 1.1.1.1, it works. - sofia_dig with any other DNS server (8.8.8.8, 9.9.9.9 etc) works. PCAP shows DNS traffic being sent and received normally. In the non working scenario, the response from 1.1.1.1 simply has zero ips. See below. [image: image.png] -- - Aron Podrigal
We noticed something similar with 1.1.1.1 and srv records a while ago. Didn't spend much time on it just told customer to use a resolver that works. On Friday, December 10, 2021, Podrigal, Aron <aronp@guaranteedplus.com> 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. - When I do a dig / host lookup directly outside freeswitch using 1.1.1.1, it works. - sofia_dig with any other DNS server (8.8.8.8, 9.9.9.9 etc) works. PCAP shows DNS traffic being sent and received normally. In the non working scenario, the response from 1.1.1.1 simply has zero ips. See below.
</mail/u/0/s/?view=att&th=17da4c1a164bfbe4&attid=0.0.1&disp=emb&realattid=ii_kwzyxhsx1&zw&atsh=1>
--
- Aron Podrigal
You can check DNS response. I think there may be a set flag that indicates "partial response." In this case, the client should switch transport used to send requests from UDP to TCP. As I know Freewithch (libsofia) do not support DNS request via TCP and this lead to failed DNS lookup. On Fri, Dec 10, 2021 at 8:10 PM Brian : <brians@iptel.co> wrote:
We noticed something similar with 1.1.1.1 and srv records a while ago. Didn't spend much time on it just told customer to use a resolver that works.
On Friday, December 10, 2021, Podrigal, Aron <aronp@guaranteedplus.com> 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. - When I do a dig / host lookup directly outside freeswitch using 1.1.1.1, it works. - sofia_dig with any other DNS server (8.8.8.8, 9.9.9.9 etc) works. PCAP shows DNS traffic being sent and received normally. In the non working scenario, the response from 1.1.1.1 simply has zero ips. See below.
</mail/u/0/s/?view=att&th=17da4c1a164bfbe4&attid=0.0.1&disp=emb&realattid=ii_kwzyxhsx1&zw&atsh=1>
--
- Aron Podrigal
_________________________________________________________________________
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 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 http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users https://freeswitch.com
On Saturday 11 December 2021 at 14:12:14, Sergey Safarov wrote:
You can check DNS response. I think there may be a set flag that indicates "partial response." In this case, the client should switch transport used to send requests from UDP to TCP.
As I know Freewithch (libsofia) do not support DNS request via TCP and this lead to failed DNS lookup.
That's not what the source code seems to indicate. src/mod/endpoints/mod_sofia/sip-dig.c contains: -------- The sip-dig utility accepts following command line options: -p protoname Use named transport protocol. The protoname can be either well-known, e.g., "udp", or it can specify NAPTR service and SRV identifier, e.g., "tls-udp/SIPS+D2U/_sips._udp.". --udp Use UDP transport protocol. --tcp Use TCP transport protocol. --tls Use TLS over TCP transport protocol. --sctp Use SCTP transport protocol. --tls-sctp Use TLS over SCTP transport protocol. --no-sctp Ignore SCTP or TLS-SCTP records in the list of default transports. This option has no effect if transport protocols has been explicitly listed. -4 Query IP4 addresses (A records) -6 Query IP6 addresses (AAAA records). -v Be verbatim. -------- I do wonder whether that last comment should be "Be verbose", but I can't say for certain :) However, this strongly suggests that sofia_dig / sip_dig does support TCP lookups. I have no idea whether that means it will automatically fail over to a TCP lookup if the UDP response is "too large". Antony. -- Normal people think "If it ain't broke, don't fix it". Engineers think "If it ain't broke, it doesn't have enough features yet". Please reply to the list; please *don't* CC me.
In our case this definitely wasn't the issue. 1.1.1.1 just didn't respond to some queries for SRV records at all or sent back an error response. It was a geo thing too. In emea it worked fine. In Africas it didn't. Like I said we had more things to be worrying about so we didn't spend a lot of time on it. On Saturday, December 11, 2021, Sergey Safarov <s.safarov@gmail.com> wrote:
You can check DNS response. I think there may be a set flag that indicates "partial response." In this case, the client should switch transport used to send requests from UDP to TCP.
As I know Freewithch (libsofia) do not support DNS request via TCP and this lead to failed DNS lookup.
On Fri, Dec 10, 2021 at 8:10 PM Brian : <brians@iptel.co> wrote:
We noticed something similar with 1.1.1.1 and srv records a while ago.
Didn't spend much time on it just told customer to use a resolver that works.
On Friday, December 10, 2021, Podrigal, Aron <aronp@guaranteedplus.com>
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. - When I do a dig / host lookup directly outside freeswitch using 1.1.1.1, it works. - sofia_dig with any other DNS server (8.8.8.8, 9.9.9.9 etc) works. PCAP shows DNS traffic being sent and received normally. In the non working scenario, the response from 1.1.1.1 simply has zero ips. See below.
</mail/u/0/s/?view=att&th=17da4c1a164bfbe4&attid=0.0.1&disp=emb&realattid=ii_kwzyxhsx1&zw&atsh=1>
--
- Aron Podrigal
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 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 http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users https://freeswitch.com
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 google.com Preference Weight Transport Port Address ================================================================================ @1.1.1.1 1 1.000 udp 5060 1.1.1.1 2 1.000 tcp 5060 1.1.1.1 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.
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 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> 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 google.com Preference Weight Transport Port Address
================================================================================ @1.1.1.1 1 1.000 udp 5060 1.1.1.1 2 1.000 tcp 5060 1.1.1.1 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 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 http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users https://freeswitch.com
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 ;; Truncated, retrying in TCP mode. Server: 127.0.0.53 Address: 127.0.0.53#53 Non-authoritative answer: 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 naptr = 100 10 "U" "LoST:listServicesByLocation" "!.*! https://api.ok.nga911.com/api/v1/lost/list-services-by-location!" . ok.nga911.com naptr = 100 10 "U" "LoST:listServices" "!.*! https://api.ok.nga911.com/api/v1/lost/list-services!" . ok.nga911.com naptr = 100 10 "U" "LIS:HELD" "!.*! https://psap.ok.nga911.com/LIS/!" . ok.nga911.com naptr = 50 500 "S" "SIPS+D2W" "" _sips._ws.ok.nga911.com. ok.nga911.com naptr = 30 300 "S" "SIP+D2U" "" _sip._udp.ok.nga911.com. ok.nga911.com naptr = 20 200 "S" "SIP+D2T" "" _sip._tcp.ok.nga911.com. ok.nga911.com naptr = 100 10 "U" "LoST:findServiceByLocation" "!.*! https://api.ok.nga911.com/api/v1/lost/find-service-by-location!" . ok.nga911.com naptr = 40 400 "S" "SIPS+D2T" "" _sip._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 naptr = 30 300 "S" "SIP+D2U" "" _sip._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> 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 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> 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 google.com Preference Weight Transport Port Address
================================================================================ @1.1.1.1 1 1.000 udp 5060 1.1.1.1 2 1.000 tcp 5060 1.1.1.1 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 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 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 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 http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users https://freeswitch.com
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
participants (6)
-
Antony Stone
-
Avi Marcus
-
Brian :
-
Podrigal, Aron
-
Sergey Safarov
-
Shaun Stokes