[SR-Users] Re: Dealing with failed SRV peers

-- Henning Westerholt – https://skalatan.de/blog/ Kamailio services – https://gilawa.com -----Original Message----- From: Дилян Палаузов dpa-kamailio@bapha.be Sent: Friday, December 16, 2022 4:04 PM To: Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org Subject: [SR-Users] Re: Dealing with failed SRV peers Hello, announcing permanently invalid servers over DNS is a valid way to reduce unwanted traffic. https://cwiki.apache.org/confluence/display/SPAMASSASSIN/OtherTricks explains the logic with fake MX records for SMTP. That fake records did help me to reduce backscatters in email terms long time ago. The same logic for announcing fake DNS records shall be applicable also to SIP. Greetings Дилян -----Original Message----- From: Henning Westerholt hw@gilawa.com Reply-To: Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org To: Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org Subject: [SR-Users] Re: Dealing with failed SRV peers Date: 12/15/2022 05:59:12 PM Hello Sebastian,   actually, it’s the fault is by the provider, that they do not manage their DNS records properly. It makes no sense to return non-working systems in the end, but some of them do not care.   I would probably just use the dst_blocklist functionality, probably with a shorter internal TTL. Regarding the peers that are having only one server which fails, I would just route to another provider in this case, if they can not bother to fix it or to provide redundancy.   You could also implement a script that fetches periodically the SRV record, create a dispatcher cfg from it and then uses dispatcher. You could use active OPTIONS ping probing, or also manually deactivate the failed hosts for the time period.   Cheers,   Henning   -- Henning Westerholt –https://skalatan.de/blog/ Kamailio services –https://gilawa.com   From: Sebastian Damm sdamm@pascom.net Sent: Thursday, December 15, 2022 7:29 AM To: Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org Subject: [SR-Users] Dealing with failed SRV peers   Hi,   we have some Kamailios working as outboundproxy. So they get requests from internal systems and send them to different providers. From time to time, one provider returns a server as primary resource which is currently unavailable.   I guess if the internal systems connected directly to the target, they would remember the failed server and remember to always use the server with second priority at least until DNS refresh time. In our setup, since every request is "new" for Kamailio, it doesn't remember, which host is reachable or not.   Example: target: example.com   _sip._udp.example.com SRV resolves to: 10 192.0.2.42 5060 20 198.51.100.42 5060 30 203.0.113.42 5060 192.0.2.42 is unavailable. Still, Kamailio uses it for every new request and failover to 198.51.100.42 occurs only after timeouts hit. Is there a best practice for solving this? I have played around with the dst_blocklist settings, but that caused even more trouble because Kamailio started blocking requests to peers that have only one server in the record having a short hickup.  Thanks in advance for every input, as this is causing trouble every time we run into such a situation.   Regards, Sebastian __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: