How to make SRV records work with caching resolvers?

[Peter]

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 <pmc at 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 at lists.isc.org
! > https://lists.isc.org/mailman/listinfo/bind-users
!