[systemd-devel] mDNS resolution with systemd

Sun Feb 18 00:57:00 UTC 2024

Hi,

I am one of avahi maintainers. While it is nice to have it configurable, 
it SHOULD work the best with default settings. It SHOULD always offer 
all interface addresses, unless there is well documented reason why to 
avoid that. Avahi does not implement NSEC and does not work well with 
both IPv6 and IPv4 queries, if the received does support only one 
family. Making it well behaved and working also with other 
implementations is not trivial task.

I haven't read whole history of this discussion, but not following RFC 
should be well justified. I haven't seen such justification here. Apple 
engineers working on mdns specs are experts in the area, they very 
likely know why they demand MUST words in their RFCs.

Regards,
Petr

On 1/19/24 10:31, Jean-Marie Delapierre wrote:
> Le 20/12/2023 à 14:30, Belanger, Martin a écrit :
>>> Hi,
>>>
>>> On one of my servers, I use avahi to realize mDNS resolution. With 
>>> avahi I am
>>> able to choose on which ip version I want avahi to answer to mdns 
>>> requests
>>> (ipv4 or ipv6). In my opinion, this is convenient on local networks 
>>> with both
>>> stacks, espacially for tracking purposes on the network).
>> This is indeed convenient, however according to RFC 6762, paragraph 
>> 6.2 [1]:
>>
>>     When a Multicast DNS responder sends a Multicast DNS response 
>> message
>>     containing its own address records, it MUST include all addresses
>>     that are valid on the interface on which it is sending the message,
>>
>> I interpret this as MUST include both IPv4 and IPv6 addresses (i.e. per
>> standard the IP family should not be configurable). One way to solve 
>> this
>> would be to disable IPv4 (or IPv6) on an interface so that the 
>> interface only
>> has IPv4 or IPv6 addresses assigned to it.
>>
>> [1] https://datatracker.ietf.org/doc/html/rfc6762#section-6.2
>>
>>> I have understood that avahi has to be replaced by systemd-networkd 
>>> and/or
>>> systemd-resolved and I have tried to implement the save behavior 
>>> with it...
>>> Without success (may be I have not found the correct place to adjust 
>>> it).
No here, I have to intervene. I do not know why avahi has to be replaced 
by systemd-resolved. We are working on fixing bugs in avahi. While the 
code is far from perfect, it has been used for years. Afaik resolved 
implements just hostname resolution. Does not offer service registration 
and browsing of network services. I know there is some ongoing work on 
that, but then it still needs to persuade applications to switch to it. 
That would be much more work than just fixing bugs in existing avahi, 
which I would propose instead. We are accepting pull requests (again).
>>>
>>> Following are the capabilities I would like to find in systemd for 
>>> mDNS resolution
>>> (espacially on a server) :
>>>
>>> - One can specify If he wants systemd to respond only  in ipv4 or 
>>> ipv6 (or both,
>>> by default ?) ;
>>>
>>> - In ipv4, one can specify the sub-network on which he wants systemd to
>>> respond to mdns requests (in my opinion, the full ipv4 adresse is to be
>>> elaborated by systemd-network) ;
>>>
>>> - in ipv6, one can specify the prefix on which he wants systemd to 
>>> respond to
>>> mdns requests (in my opinion, the full ipv6 adresse is to be 
>>> elaborated by
>>> systemd-network) ;
>>>
>>> Thank you in advance for reading me.
>>>
>>> Regards.
>>>
>>> Jean-Marie Delapierre
>
> I agree with your answer , but ...
>
> - The goal of mDNS is to resolve adresses only on a local network , 
> not the internet . On the internet , one has to respect the standards 
> , but , on his own local network , it can admited that he does what he 
> wants .
You can implement your own protocols, but is it a good idea? I do not 
think so. The standard has a good reasons to demand all addresses. It 
then makes obvious when reflectors create conflicts with your registered 
name.
>
> - The goal of any software is not only to respect a standard . It also 
> has to allow the users to do what they want to do . As much as I 
> understand that the default behavior of systemd HAS to be the full 
> respect of the standard , as much it has to allow fine tuning for the 
> user to do what he wants on his private local network . For example , 
> look on all the options you have to configure your local ethernet 
> network . Most people don't use them and are happy with the default 
> configuration , but some ...
Can you instead explain, what exactly is your use case? Why do you want 
to hide something and not propagate it? It is a request for additional 
work, why it should be done? Are you willing to contribute code for it?
>
> so, I suggest systemd-resolved to propose two options for mDNS 
> resolution :
>
> - in ipv4 : none (ipv4 answering is disabled as if the interface would 
> have no ipv4 adress) , all (default) , a list of ipv4 subnetworks 
> (answering the adress on each subnetwork if avalaible) .
>
> - in ipv6 : none (ipv6 answering is disabled as if the interface would 
> have no ipv6 adress) , all (default) , a list of ipv6 prefixes 
> (answering the adress on each prefix if avalaible) .
>
> Thank you in advance for reading me.
>
> Regards.
>
> Jean-Marie Delapierre
>
-- 
Petr Menšík
Software Engineer, RHEL
Red Hat, https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x4931CA5B6C9FC5CB.asc
Type: application/pgp-keys
Size: 9736 bytes
Desc: OpenPGP public key
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20240218/70785192/attachment-0001.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20240218/70785192/attachment-0001.sig>