Dafuck? Removed for rule 3? !selfhosted@lemmy.world what the?

As far as I’m aware running and getting DNS to work on a home network is precisely everything to do with self-hosting.

I get that I’m being a bit of an opinionated asshole, and maybe my post is not overly constructive, but shit, a good rant to start a discussion should not be a reason for removal, least of all for a rule that has blatantly not been violated and that’s the only actual reason I can think of why I’d been banned.

A good rant is literally the most worthwhile content imho, a good hearty debate invites viewpoints and opinions, even if the OP is unpopular. I hate the sterile, overly polite, overly PC tone enforced on some Lemmy communities.

As long as no one is literally insulting other users or spreading misinformation or being discriminatory/xenophobic based on characteristics. I wasn’t even swearing. I’m so done, I’m blocking all of lemmy.world until they get their shit together.

  • Arthur BesseA
    link
    fedilink
    English
    arrow-up
    3
    ·
    edit-2
    2 days ago

    Yes. It was even the suggested practice at one time:

    https://en.m.wikipedia.org/wiki/.local

    Cool, I didn’t know that. But the article also says they recommend against it now. I see the “Microsoft recommendations” section of the wikipedia article indicates they changed their mind on this several times.

    On the other hand almost nothing uses mDNS.

    In my experience mDNS seems ubiquitous; almost every network connected device I’ve seen in the last couple decades has it enabled by default.

    Fucking bootcampers istg I’m so glad I don’t have to work with y’all and only interact when you deliver my fucking takeaway.

    Huh? What are “bootcampers”? It used to refer to people running windows on intel macs (because apple’s boot loader to allow that was called BootCamp), but that wouldn’t make any sense in this context. Unless you are having your food delivered by people who run Windows on old Apple hardware? 🤔

    Implementers MAY choose to look up such names concurrently via other mechanisms (e.g., Unicast DNS) and coalesce the results in some fashion

    So actually the RFC does not limit whatsoever the resolution of .local domains to mDNS. Implementers, apart from Android do indeed always do look up via both unicast and multicast (if not disabled). Only android limits this to multicast-only.

    I see. Sorry I missed that part of the RFC.

    But, FYI, it is really not only Android that doesn’t send unicast queries for .local names; GNU/Linux distributions running avahi (eg, the distros most people use) also don’t. I don’t have a mac or iphone nearby to confirm but I would assume they are probably resolving .local exclusively via mDNS too. edit: this “Apple devices might not open your internal network’s ‘.local’ domain” support article indicates my assumption is probably correct.

    Also, please don’t tell people to KYS :(

    • LainTrain@lemmy.dbzer0.comOP
      link
      fedilink
      arrow-up
      2
      ·
      edit-2
      2 days ago

      In my experience mDNS seems ubiquitous; almost every network connected device I’ve seen in the last couple decades has it enabled by default.

      Again, having it enabled by default is not an issue. I have it enabled everywhere, as you said - it’s the default. But, it’s also the default that .local is resolved both via multicast and unicast.

      But, FYI, it is really not only Android that doesn’t send unicast queries for .local names; GNU/Linux distributions running avahi (eg, the distros most people use) also don’t.

      Yes they do? Well at least in my case they do. As far as Unix/Linux I have Raspbian, Debian, OpenBSD, OpenWRT, SteamOS (had to hand-wring the DNS there tbf), Ubuntu, Mac OS and Kali and they all resolve just fine. I run my own recursive DNS server for internet and an authoritative zone for my local DNS, a domain ending in .local, and they all resolve .local via my server as is given to them by DHCP.

      The Pi is definitely running Avahi and spamming multicast, when it attempts to resolve .local, it sends out multicast and unicast simultaneously, even with freshly flushed DNS cache.

      But the article also says they recommend against it now.

      That is very new though. .local is still default on fairly recent versions of Winserver (2016), as that article also specifies. I can attest this is also commonly still used by large businesses who don’t want their AD to be related to their TLDs, RFC or no RFC, which makes the android implementation all the more idiotic.

      Don’t tell people to KYS

      Okay. I got a fuckload of insults and dismissal from peabrains ITT in comments above yours, so I may have gone too far in a few places.

      • Arthur BesseA
        link
        fedilink
        English
        arrow-up
        3
        ·
        edit-2
        1 day ago

        The Pi is definitely running Avahi and spamming multicast, when it attempts to resolve .local, it sends out multicast and unicast simultaneously, even with freshly flushed DNS cache.

        I owe you an apology - I see now that my avahi systems are in fact also sending unicast SOA? local. when I resolve a .local name, and presumably if my recursor told them it was responsible for it instead of NXDomain then I would resolve names through it.

        I was pretty sure that it doesn’t do that, but before telling you that it doesn’t I actually did a test and ran tcpdump -ni any port 53 or port 5353 while resolving some .local names. i even noticed that there was that SOA query being sent to and from localhost (to systemd-resolved) but I saw no answer to it and figured that systemd-resolved was the thing silently ignoring that TLD. But: it turns out that the system I tested on has its systemd-resolved configured for DNSOverTLS so I wasn’t seeing those SOA queries being sent on to the recursor on a different port 🤦

        Sorry!

        It does seem to me like a regrettable choice of the RFC authors to allow both, though, as it is easy to accidentally have a situation where the recursor and mDNS return different answers which would lead to inconsistent results when querying both in parallel.