fix: unrequired records should be sent as additional records

[ArcticLampyrid]

https://datatracker.ietf.org/doc/html/rfc6763#section-12

[willstott101]

Thanks, I want to try and get a new release out this weekend. Apologies for the quiet.

I appreciate the link to the spec, even so could you add a brief description of the changes you've made? Just to help me understand the diff a bit quicker.

[ArcticLampyrid]

A DNS response can be divided into answers and additional answers. The answers should only include the domain name requested by the user (in the past, it included data not requested by the user), while the additional answers are used to include data not requested by the user but possibly needed in subsequent requests, to reduce the number of broadcast packets.

[willstott101]

Thanks for this improvement, but I'm not quite prepared to merge it right now. I'm inclined to think I would prefer we collated a de-serialized DNS response as structs and then packet-ised it, rather than stream-producing something only a few hundred bytes long. That would be easier to test and reason about IMO

[willstott101]

I can see why you've removed the collation here (as every single handle_question might move the builder to the additional section), but it does seem unfortunate.

   When possible, a responder SHOULD, for the sake of network
   efficiency, aggregate as many responses as possible into a single
   Multicast DNS response message.  For example, when a responder has
   several responses it plans to send, each delayed by a different
   interval, then earlier responses SHOULD be delayed by up to an
   additional 500 ms if that will permit them to be aggregated with
   other responses scheduled to go out a little later.

This library doesn't ever meaningfully delay responses atm, so sending all answers in a single packet seems perfectly sensible to me, and ideally I'd like to keep it that behaviour.

https://datatracker.ietf.org/doc/html/rfc6762#section-6.4

[willstott101]

I like this move to pure functions from functions that take a builder, but the reality of the resulting handle_question function is just too difficult to read for me. There is so much repetition of add_answer and it's arguments I can barely keep up. There must be a better solution.