How to make SRV records work with caching resolvers?

[Petr Menšík]

It certainly is the issue of the equipment. It should fetch any name 
address it does not know.

I am thinking without tested it. Would pointing those phones to 
authoritative server directly with a possible caching forwarder help? 
Maybe if you ensure all those records has matching TTL and having all 
records served by the same server itself, it would never offer just 
partial reply.

Proper fix would be update from device vendor however.

On 7/13/22 13:06, Peter 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