cultural reviewer and dabbler in stylistic premonitions

  • 122 Posts
  • 287 Comments
Joined 3 years ago
cake
Cake day: January 17th, 2022

help-circle


  • as i wrote in another thread:

    Content addressability is absolutely essential for building something that will last, and BlueSky gets that right. Decoupling the many responsibilities which an ActivityPub instance operator has (especially for identity) is also essential, i think, and while BlueSky’s identity solution is less than ideal it’s much better than ActivityPub and I expect it to improve.

    If you’re interested in the topic you probably want to also read the followup post from the same author (after reading the reply linked there from someone on the BlueSky team).

    Christine’s analysis is by far the best I’ve read on the topic, but I think she is too dismissive of the possibility that people will actually build things using ATP in a manner more like ActivityPub (where there doesn’t need to be a global view). It’s also possible/likely that ActivityPub will eventually evolve to adopt content addressability (Christine actually built a proof-of-concept of doing that years ago, linked in her blog post, but there doesn’t appear to be any recent progress in that direction), and decouple identity from responsibility for data availability, and adopt something like BlueSky’s composable moderation.

    Given their respective advantages over the other, i’m pretty sure that both ATP and AP will make changes which make them more like the other in the coming years.




  • Reading through it, I’m not seeing much in favor of ATP

    See the “BlueSky’s strengths” section, particularly the last paragraph of it. Content addressability is absolutely essential for building something that will last, and BlueSky gets that right. Decoupling the many responsibilities which an ActivityPub instance operator has (especially for identity) is also essential, i think, and while BlueSky’s identity solution is less than ideal it’s much better than ActivityPub and I expect it to improve.

    If you’re interested in the topic you probably want to also read the followup post from the same author (after reading the linked reply from someone on the BlueSky team).

    Christine’s analysis is by far the best I’ve read on the topic, but I think she is too dismissive of the possibility that people will actually build things using ATP in a manner more like ActivityPub (where there doesn’t need to be a global view). It’s also possible/likely that ActivityPub will eventually evolve to adopt content addressability (Christine actually built a proof-of-concept of doing that years ago, linked in her blog post, but there doesn’t appear to be any recent progress in that direction), and decouple identity from responsibility for data availability, and adopt something like BlueSky’s composable moderation.

    Given their respective advantages over the other, i’m pretty sure that both ATP and AP will make changes which make them more like the other in the coming years.


  • 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.


  • 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 :(













  • This is an excerpt of OP’s post in question:

    Last android piece of garbage I buy. Is there even a single good reason it restricts .local, as is commonly used for local domains in LAN DNS to some hellish nonsense no one’s ever used called multicast DNS?

    Is .local actually “commonly used for local domains in LAN DNS” or did you just see .local somewhere else (probably using mDNS) and decide to cargo cult it? I’ve never seen someone use it outside the context of zero-configuration networking.

    fyi, besides Android, most Linux distros also ship with mDNS enabled by default, as do all Apple operating systems since the feature was first introduced in an update to Mac OS 9 in 2001. It’s mostly just Windows that doesn’t.

    And before someone says “uhmm but m-muh RFC says so” - no. That RFC only suggests that some people MAY implement it as such, which yeah, sucks, because the RFC if it did it’s job right should forbid it altogether […]

    Which RFC says that? I just checked, and RFC6762 (Multicast DNS) says:

    This document specifies that the DNS top-level domain “.local.” is a special domain with special semantics, namely that any fully qualified name ending in “.local.” is link-local, and names within this domain are meaningful only on the link where they originate. This is analogous to IPv4 addresses in the 169.254/16 prefix or IPv6 addresses in the FE80::/10 prefix, which are link-local and meaningful only on the link where they originate.

    Any DNS query for a name ending with “.local.” MUST be sent to the mDNS IPv4 link-local multicast address 224.0.0.251 (or its IPv6 equivalent FF02::FB).

    Also, as per (the immediately prior) RFC6761 (“Special-Use Domain Names”), RFC6762 explicitly adds .local to the IANA registry of special-use domain names.

    HTH!




  • there is no provider on the planet that can freeze state of RAM in a way that would be useful for this

    You are very mistaken, this is a well-supported feature in most modern virtualization environments.

    Here are XenServer docs for it. And here is VMWare’s “high-frequency” snapshots page.

    Sometimes, law enforcement authorities only need to contact cloud provider A when they have a warrant for (or, perhaps, no warrant but a mere request for) data about some user C who is indirectly using A via some cloud-hosted online service B.

    A(mazon) will dutifully deliver to the authorities snapshots of all of B’s VMs, and then it is up to them if they limit themselves to looking for data about C… while the staff of company B can honestly say they have not received any requests from law enforcement. (sorry my best source on this at the moment is sadly trust me bro; I’ve heard from an AWS employee that the above scenario really actually does happen.)