On Thu, Jul 14, 2022 at 06:22:47PM +0200, Ondřej Surý wrote: ! Could you for the purpose of the debugging share the DNS traffic between the phone device and the resolver? ! ! I think stepping back a little might help debug the issue. Perhaps people on the list might notice something that might help. ! ! Ondrej
Hi Ondrej, thanks for Your reply. I tried to obtain something reproducible, but with no luck. These failures are a bit difficult to catch, they happen mostly deep at night, for whatever reason. (And in any case a reset of the phone does fix the issue.) Once I tried to analyze the failure and noticed the partial information in the additional section, as described - so I thought I had identified the issue (and should occasionally learn how this should actually work - as I did now). Now when I log the entire DNS traffic, I don't see the same pattern appearing again. (Obviousely there can be many other reasons for a temporary outage.) The plan is now to put this on hold until it appears at annoying daytimes again, and ideally obtain a kind of VoIP-proxy or PBX to put in between. -- PMc ! > On 13. 7. 2022, at 13:18, Peter <p...@citylink.dinoex.sub.org> wrote: ! > ! > ! > My Telco has removed the A record for their VoIP server, and now has ! > only SRV data there - which seems not to work properly. ! > ! > The SRV data contains various services (SIP via UDP, TCP, secure ! > TCP, whatever), and these get individual expiry counters in the ! > caching resolver. ! > So when a telephone sends a query, the caching resolver will provide ! > that data in the "Additional section" - but only those records that ! > have not yet expired. ! > ! > If the configured service (the one the telephone should use) is no ! > longer contained in the answer (but others are still present), the ! > telephone goes offline until all the records have expired and a new ! > authoritative query is made. ! > ! > The Telco is of no help - they just want to sell their own equipment. ! > ! > The telphones (Alcatel) are the usual linux plastic box, and I cannot ! > easily hack these. It probably does not behave fully correct, but ! > also not fully wrong. ! > ! > In BIND/named I didn't find an easy approach to fix the issue - it ! > doesn't look like it is supposed to be fixed there. And before I go ! > for the more difficult approaches, I would like to ask how this ! > is actually supposed to work, at all. ! > ! > ! > -- PMc ! > -- ! > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ! > ! > ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. ! > ! > ! > bind-users mailing list ! > bind-users@lists.isc.org ! > https://lists.isc.org/mailman/listinfo/bind-users ! -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
