From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI, NORMAL_HTTP_TO_IP,NUMERIC_HTTP_ADDR,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,T_SCC_BODY_TEXT_LINE,WEIRD_PORT autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id 752FF262B1 for ; Wed, 6 Mar 2024 08:29:27 +0100 (CET) Received: (qmail 32311 invoked by uid 550); 6 Mar 2024 07:25:31 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 32278 invoked from network); 6 Mar 2024 07:25:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709710154; x=1710314954; darn=lists.openwall.com; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=myy3gIWxfiNK6OK/dg02siQL2G52HgeSiEstpnQaOCQ=; b=J2bPL+OIPrFkasiOzRJRKZ2YIYSU2gPlBTZ1u0TjVWmUFaYwRYs29xXLawFt6k0cXl aN+VgjSlHdEeNMQ3QX4SLTTw16+ky3JlmO+HoBu3bbHZ4agpE0PxX3uQzInOgaHV38GL 7asz9JXXoOAFnBsDU4MjsY2amLELWoggO0yHe9arxoAI89rUrylI6B3Ozkb6esc0i1ui 9KctEEOQgRiNGlN+8weHKFKQKo9T3PU/9QbVTfJQiz0i4SJv4bWp8SaizijJkRWEpoHK MFRBeYDBW0hBfC7ew7fzxpgB/ykJOw9eyfjT3TXG2i4BziNxlIgGRDFcD6am0FNJAKX5 cltA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709710154; x=1710314954; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=myy3gIWxfiNK6OK/dg02siQL2G52HgeSiEstpnQaOCQ=; b=HrIemSyg9H1dpdNstjvtj8qLJuOKF0qF23Kr9SBGXhoqshpphW0HPgLuH9pNgE69kp J9Lgm66KIQgM0/44XkKgC2Hi+w0YRoP9XtLRPGyX3JjnWN7AXPJ532uBcS/JuaiqBsiU K7HgYZt9F+ovx0YKPqLlbFwELufznKZvgFxuxbmwfjmqfYC4uKInrS3g7epO0N5x28rZ I/LakxAjZsEnUygPogeRcxoCsqY2Fu9slKy+qnrOdYbqmnhVnAFc0JwxnAhMkLbxvPia B/rtpikS9PjgaglgqkZW7g3/PIDnHvmU9mociDP0qbt4Pu5v4VLbxGi7oJ4lnU1aLIjc /u6A== X-Gm-Message-State: AOJu0YweB66H3MC35Eli2EvSRlxzN4PBbq0kIeVVgA9K3P/95Y3mELft jO01LFmcPIC6MvCaiDTdh/e1iExTsvWR6s7O1Ig/rBTLWYcLWmTToxujBaqdI+7o9STs+ZU/+79 BBRXT5qQAcXHbL7Ap3GaAXlPm+zrXXw4L7Eo= X-Google-Smtp-Source: AGHT+IGu4xikF/+0ZvkANR8bwdcNpPYsS0209Ttg1tbO0q4W7ycwZua4eY6RTsT5Jm4pWvfRtHtNvbCnR4+Fdp81WDw= X-Received: by 2002:a17:906:f2c9:b0:a45:8621:feec with SMTP id gz9-20020a170906f2c900b00a458621feecmr4136072ejb.38.1709710154278; Tue, 05 Mar 2024 23:29:14 -0800 (PST) MIME-Version: 1.0 From: David Schinazi Date: Tue, 5 Mar 2024 23:29:03 -0800 Message-ID: To: musl@lists.openwall.com Content-Type: multipart/alternative; boundary="0000000000006a30650612f8eaa7" Subject: [musl] mDNS in musl --0000000000006a30650612f8eaa7 Content-Type: text/plain; charset="UTF-8" Hi everyone, I was debugging a network connectivity issue on Alpine and have tracked it down to lack of support for mDNS in musl gethostbyname / getaddrinfo [1]. I looked through the musl codebase to understand why, and it would be pretty straightforward to fix. I'd be interested in writing a patch for this, so I was wondering: would you be at all interested in potentially taking such a patch? Some more info on mDNS: all names that end in ".local" are reserved for use by mDNS, and instead of sending them to the DNS resolver, they're sent locally over multicast - and the machine with that name replies with its IP address. It's used today to discover printers and pretty much everything in home networks. >From looking through musl, both gethostbyname() and getaddrinfo() route through __lookup_name(), which eventually calls name_from_dns(). From looking at that function, the issue is that it doesn't treat .local specifically - instead of sending those queries to multicast, it sends them to the regularly configured DNS nameservers. The fix would be to modify name_from_dns() [2] such that if `name` ends in ".local", then pass in a different conf variable to __res_msend_rc(). The conf variable contains (amongst other things) the DNS nameservers to send the query to. So, when the name ends in .local, instead of passing in the regular nameservers, we pass the multicast addresses and ports dedicated to mDNS (224.0.0.251:5353 and [ff02::fb]:5353). And that's it! This implementation is compatible with the "One-Shot Multicast DNS Queries" mode of the mDNS RFC [3]. (Other versions of libc have a mode to send the query over dbus to avahi so that it can cache mDNS results locally. But that's the more complicated "Continuous Multicast DNS Querying" mode of the RFC, and we don't need that here.) So what do you think, would you be interested in support for mDNS? (In case it matters, I've made changes in getaddrinfo inside Apple's libc, so I'm comfortable in this kind of code even though I have zero prior experience with musl) Thanks, David [1] https://wiki.alpinelinux.org/wiki/MDNS [2] https://git.musl-libc.org/cgit/musl/tree/src/network/lookup_name.c#n143 [3] https://www.rfc-editor.org/rfc/rfc6762.html#section-5.1 --0000000000006a30650612f8eaa7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi everyone,

I was debugging a network = connectivity issue on Alpine and have tracked it down to lack of support fo= r mDNS in musl gethostbyname / getaddrinfo [1]. I looked through the musl c= odebase to understand why, and it would be pretty straightforward to fix. I= 'd be interested in writing a patch for this, so I was wondering: would= you be at all interested in potentially taking such a patch?=C2=A0

Some more info on mDNS: all names that end in ".loca= l" are=C2=A0reserved for use by mDNS, and instead of sending them to t= he DNS resolver, they're sent locally over multicast - and the machine = with that name replies with its IP address. It's used today to discover= printers and pretty much everything in home networks.

=
From looking through musl, both gethostbyname() and getaddrinfo() rout= e through=C2=A0__lookup_name(), which eventually calls=C2=A0name_from_dns()= . From looking at that function, the issue is that it doesn't treat .lo= cal specifically - instead of sending those queries to multicast, it sends = them to the regularly configured DNS nameservers.

= The fix would be to modify name_from_dns() [2] such that if `name` ends in = ".local", then pass in a different conf variable to __res_msend_r= c(). The conf variable contains (amongst other things) the DNS nameservers = to send the query to. So, when the name ends in .local, instead of passing = in the regular nameservers, we pass the multicast addresses and ports dedic= ated to mDNS=C2=A0(224.0.0.251:5353= and [ff02::fb]:5353).

And that's it! This imp= lementation is compatible with the "One-Shot Multicast DNS Queries&quo= t; mode of the mDNS RFC [3]. (Other versions of libc have a mode to send th= e query over dbus to avahi so that it can cache mDNS results locally. But t= hat's the more complicated "Continuous Multicast DNS Querying"= ; mode of the RFC, and we don't need that here.)

So what do you think, would you be interested in support for mDNS? (In c= ase it matters, I've made changes in getaddrinfo inside Apple's lib= c, so I'm comfortable in this kind of code even though I have zero prio= r experience with musl)

Thanks,
--0000000000006a30650612f8eaa7--