I previously posted a writeup based on Arch Wiki instructions, and upon updating to 3.5.5 this no longer works.

The config file still exists, but mDNS will not operate.

I’ve managed to enable the avahi-daemon.service unit file and this validly now registers the interface link to mDNS per the avahi log, but systemd-resolve still shows it as unsupported (i.e., -mDNS listed with the wlan0 link).

It appears that the Arch Wiki now redirects mdns to the Avahi page, and has instructions for enabling Avahi. However, it previously linked to systemd-resolve for instructions including NetworkManager as well - clearly this changed (yes the wiki entry still exists), and the configuration I had previously (also explained in the Arch Wiki) does not work. But I can’t find any reasoning behind this. It’s also clear that NetworkManager is still being used by the system, but this

Does anyone have any more pertinent and explicit information I can read up about these changes? The nerd in me wants to know the reasoning 😅

  • CodexHere@alien.topOPB
    link
    fedilink
    English
    arrow-up
    1
    ·
    10 months ago

    I think you’re misunderstanding the concept of “.local TLD is considered unsafe.”

    It’s not UNSAFE unsafe… It’s unsafe to resolve .local TLD yourself as it’s a protocol specifically to avoid having a DNS server. Resolving yourself on a DNS would result in conflicts, which is the “unsafe” part.

    As for the comment you linked to, this directly coincides with why it’s not a DNS Search, and is a “unicast” (actually it’s a multicast, not unicast) protocol.

    • ventrid09190@alien.topB
      link
      fedilink
      English
      arrow-up
      1
      ·
      10 months ago

      Maybe poor choice of words on my part. I was referring more to mDNS being vulnerable to impersonation and MITM attacks as what’s unsafe, not using .local in and of itself.

      • CodexHere@alien.topOPB
        link
        fedilink
        English
        arrow-up
        1
        ·
        10 months ago

        Sure… but literally any type of lookup is vulnerable to MITM without something like DNSSEC, which isn’t too common outside of enterprise or managed DNS servers like cloudflare, etc (which still require configuration). Most users, unless they WORK in InfoSec, literally don’t bother with (or even are aware of) it.

        At that point you’re kinda just drawing up what-if’s - and while technically valid, it’s also a very limited concern.

        It’s more common to access a computer by hostname on a LAN than it is to have a MITM on your network. If you do, you have bigger concerns.