dns: support legacy queries

[mhusaam]

dns: add support for Legacy Unicast Responses

For example, in case the query is of the type "One-Shot Multicast
DNS Queries", the questions also need to be sent along with the
answer, like a conventional DNS response (RFC 6762 Section 6.7).
Therefore, we save the question section while parsing DNS question.

dns: save question section when parsing DNS question

As per RFC 6762 Section 6.7 (Legacy Unicast Responses)

"If the source UDP port in a received Multicast DNS query is not port
5353, this indicates that the querier originating the query is a
simple resolver such as described in Section 5.1, "One-Shot Multicast
DNS Queries", which does not fully implement all of Multicast DNS.
In this case, the Multicast DNS responder MUST send a UDP response
directly back to the querier, via unicast, to the query packet's
source IP address and port. This unicast response MUST be a
conventional unicast response as would be generated by a conventional
Unicast DNS server; for example, it MUST repeat the query ID and the
question given in the query message."

Therefore, umdns should not ignore DNS questions coming from non-
multicast sources, and also provide question section which is not
usually provided in mDNS responses.

Signed-off-by: Mohd Husaam Mehdi husaam.mehdi@iopsys.eu

[nbd168]

I just took a quick look at this PR, and I have some feedback:
From my understanding of legacy queries, it is expected that you get one response packet per request packet.
In the current code structure, parse_question() directly sends out reply packets, which is fine (though a bit inefficient) for multicast, but could be a problem for legacy unicast.
My suggestion would be to rework the code, so that parse_question only collects answers in a struct blob_buf, and dns_handle_packet() sends out the response packet(s) if needed. That way you don't have to pass the question buffer deeper down the call chain and can keep it locally inside dns_handle_packet(). In fact, there you can simply reuse the question count and the full question buffer for the response packet.

[mhusaam]

Okay, will look into it this way.

[mhusaam]

Hi @nbd168,

I see that blob_buf is not needed because we can take advantage of the existing dns_packet_answer() function to add answers to the packet. If we want to send all the answers in one response, we do not call dns_packet_send() immediately, but wait and call it in dns_handle_packet().

Kindly review.

[mhusaam]

Minor update: included sign-off and relevant RFC text in the commit message.

[Rondom]

@ynezz @blogic You had done some initial review in #12. Could you have a look on this continuation of that PR?