How to make SRV records work with caching resolvers?

[Peter]

Hi,

  In July last year I asked about a problem with an IP telephone
mis-handling the DNS responses (and got the clear answer that the
telephone is to blame).

I quote my original message here:

On Wed, Jul 13, 2022 at 01:06:13PM +0200, 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.

Accidentially reading the docs for 9.18 instead of my 9.16 (which
is differently structured), I found the solution: "minimal-responses".

This does away with the Additional section entirely, so there is no
longer a problem with incomplete data considered as complete by the
client.

The actual issue is slightly different than described above:

The client telephone is expected to query a NAPTR for the SIP server.
That NAPTR provides three records, which should be queried as SRV and
again provide three records each. So in total there are 13 records
(including the finally used A record), and that doesn't fit into
576 bytes.

So, apparently, named/BIND sends only some selection of Additional
records, based on it's own discretion. And that doesn't work with the
broken client. Either /all/ or /nothing/ would work, and
"minimal-responses" enforces the /nothing/ option. 

It seems the problem is now solved.