Yu Watanabe
137ce9b975
Split out of https://github.com/systemd/systemd/pull/42983 ## Problem `dns_scope_announce()` put the entire zone into a single reply packet — for DNS-SD that is every PTR/SRV/TXT record of every published service. With a few hundred services that grows far past the interface MTU, and past what RFC 6762 section 17 allows: a Multicast DNS packet larger than the MTU is sent using fragments, and such a packet "MUST NOT contain more than one resource record". ## Fix Pack an announcement into as many MTU-sized packets as needed. A record that does not fit the MTU on its own is emitted alone in an oversized packet relying on IP fragmentation — the case section 17 explicitly allows — bounded by its hard 9000-byte ceiling including headers, which also caps jumbo-frame links. Without a usable interface MTU (no link on the scope, or `IFLA_MTU` not read yet) packets are cut to the largest datagram a host of the family must accept unfragmented — RFC 791's 576 bytes for IPv4, RFC 8200 section 5's 1280-byte minimum link MTU for IPv6 — rather than to that ceiling, so an announcement is never fragmented merely because the MTU was not known yet, and the lone-oversized-record path stays reachable. A record that cannot be encoded at any size (an rdata past 64KiB, a character string past 255 bytes) is skipped like one too large for the ceiling rather than failing the whole announcement: `dns_packet_append_rr()` rolls the packet back on every failure, so its neighbours are unaffected either way. The packing lives in `resolved-mdns.c` as `mdns_announcement_packetize()`, taking an answer and the two size bounds and returning finalized packets, so it is testable without a scope, a link or a socket. Emission is best effort per packet — a failed send no longer withholds the rest — and each pass logs the packet and record counts it actually put on the wire.
System and Service Manager
Details
Most documentation is available on systemd's website.
Assorted, older, general information about systemd can be found in the systemd Wiki.
Information about build requirements is provided in the README file.
Consult our NEWS file for information about what's new in the most recent systemd versions.
Please see the Code Map for information about this repository's layout and content.
Please see the Hacking guide for information on how to hack on systemd and test your modifications.
Please see our Contribution Guidelines for more information about filing GitHub Issues and posting GitHub Pull Requests.
When preparing patches for systemd, please follow our Coding Style Guidelines.
If you are looking for support, please contact our mailing list, join our IRC channel #systemd on libera.chat or Matrix channel
Stable branches with backported patches are available in the stable repo.
We have a security bug bounty program sponsored by the Sovereign Tech Fund hosted on YesWeHack
Repositories with distribution packages built from git main are available on OBS, and also repositories with packages built from the latest stable release