With limited amount of changes it would be possible to respond to more than just one name request. As far as I understood RFC 4795 it is also not forbidden for a single IP to be represented by multiple names.

That's my reading of RFC 4795 as well. I didn't have the need for multiple names so far, but it sounds like this would be a useful feature for llmnrd.

The scenario I'm thinking of is, that a system has a generic name, ie "my-device.local" and a specific name "my-device-some-serial-number.local". This works with mdns, but not with this llmnr implementation.

The "--hostname" / "-H" parameter could be given multiple times.

Implementation idea:

• Change https://github.com/tklauser/llmnrd/blob/master/llmnrd.c#L209 and take multiple, up to compile-time defined N names.

• Change llmnr_init to take an array pointer.

• Change https://github.com/tklauser/llmnrd/blob/master/llmnr.c#L43 (static char llmnr_hostname[LLMNR_LABEL_MAX_SIZE + 2];) to be an array of N char string entries.

I think we could even dynamically allocate buffers depending on the arguments given instead of restricting the number of names to an arbitrary number N at compile time. I'd probably keep the buffers separate from llmnr_hostname.

• llmnr_set_hostname would always change the first entry.

Given the dynamically allocated buffer is feasible, I think we wouldn't need to change llmnr_set_hostname at all.

• https://github.com/tklauser/llmnrd/blob/master/llmnr.c#L58 llmnr_name_matches: Loop over the array of char strings to determine if any of the entries match.

If compiled with N=1 which matches current behaviour, there is only a little run-time overhead in llmnr_name_matches when the loop counter variable is evaluated.

Sounds acceptable to me. If we go for the separate buffers, there would even be less overhead if there are no additional names.

WDYT?

If the idea sounds right to you, I could make a first draft MR.

Sounds good to me in general. Please feel free to send a PR and we can further iterate on that. Thanks!