Hello, in this case this DNS record comes from a provider, and they want to receive traffic over it. So, I doubt that this was done intentionally from them, its more an oversight or process issue on their side.
Cheers, Henning -- Henning Westerholt – https://skalatan.de/blog/ Kamailio services – https://gilawa.com -----Original Message----- From: Дилян Палаузов <[email protected]> Sent: Friday, December 16, 2022 4:04 PM To: Kamailio (SER) - Users Mailing List <[email protected]> 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 <[email protected]> Reply-To: Kamailio (SER) - Users Mailing List <[email protected]> To: Kamailio (SER) - Users Mailing List <[email protected]> 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 <[email protected]> Sent: Thursday, December 15, 2022 7:29 AM To: Kamailio (SER) - Users Mailing List <[email protected]> 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 [email protected] 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 [email protected] 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 [email protected] Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
