Any DNS query for a name ending with “.local.” MUST be sent to the
mDNS IPv4 link-local multicast […]
Implementers MAY choose to look up such names concurrently via other
mechanisms (e.g., Unicast DNS) and coalesce the results in some
fashion. Implementers choosing to do this should be aware of the
potential for user confusion when a given name can produce different
results depending on external network conditions […]
The RFC warns about these exact issues. You MAY do something else, but then the blame is on you…
So why does Google enforce mDNS when it leads to this confusion?
Everywhere else, Windows, Linux, iOS, etc etc. as far as I can tell mDNS doesn’t happen with .local as the default, nevermind only option.
Only the android devices throw a fit because of Google enforcing bizarre legacy technology of use to no one.
Maybe there’s a way to hint to the problematic android devices that it’s a no-no by restricting all multicast traffic of any kind on network level? Is that even possible?
That’s kind of what happens when somebody re-uses already assigned namespaces for a different purpose. Same with other domains, or if you mess with IP addresses or MAC addresses. The internet is filled with RFCs and old standards that need to be factored in. And I don’t really see Google at fault here. Seems they’ve implemented this to specification. So technically they’re “right”. Question is: Is the RFC any good? Or do we have any other RFCs contradicting it? Usually these things are well-written. If everything is okay, it’s the network administrators fault for configuring something wrong… I’m not saying that’s bad… It’s just that computers and the internet are very complicated. And sometimes you’re not aware of all the consequences of the technical debt… And we have a lot of technical debt. Still, I don’t see any way around implementing a technology and an RFC to specification. We’d run into far worse issues if everyone were to do random things because they think they know something better. It has to be predictable and a specification has to be followed to the letter. Or the specification has to go altogether.
Issue here is that second “may” clause. That should be prohibited from the beginning, because it just causes issues like this. That’s kind of what Google is doing now, though. If you ask me, they probably wrote that paragraph because it’s default behaviour anyways (to look up previously unknown TLDs via DNS). And they can’t really prevent that. But that’s what ultimately causes issues. So they wrote that warning. Only proper solution is to be strict and break it intentionally, so no-one gets the idea to re-use .local… But judging from your post, that hasn’t happened until now.
Linux, MacOS etc are also technically “right” if they choose to adopt that “may” clause. It just leads to the consequences lined out in the sentence. They’re going to confuse users.
You’d think with how often android is updated ridding us of this technical debt is very easy. Disable multicast DNS, add a hidden setting tucked away in a menu somewhere to re-enable it. Ez pz.
If you use a .local domain, your device MUST ask the mDNS address (224.0.0.251 or FF02::FB) and MAY ask another DNS provider. Successful resolution without mDNS is not an intended feature but something that just happens to work sometimes. There’s a reason why the user interfaces of devices like Ubiquiti gateways warn against assigning a name ending in .local to any device.
I personally have all of my locally-assigned names end with .lan, although I’m considering switching to a sub-subdomain of a domain I own (so instead of mycomputer.lan I’d have mycomputer.home.mydomain.tld). That would make the names much longer but would protect me against some asshat buying .lan as a new gTLD.
And more importantly the devices don’t, it’s very noticeable via wireshark. The only multicast traffic comes from Android, every other OS does not bother, ironically not even Mac OS, whom is responsible for the whole Avahi/Bonjour nonsense to start with.
That would make the names much longer but would protect me against some asshat buying .lan as a new gTLD.
Another user pointed out that .home.arpa seems to be reserved, thus hopefully protected from TLD hijack which is what I’m worried about as well. I’d make it .homelab. I wonder if one can restrict recursion on certain domains?
If one server is marked as authoritative, but to recurse for other things, will it recurse for it’s authoritative domain, or give NXDOMAIN?
I do own a domain name via cloudflare so I might just utilize that, but I don’t like it.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !selfhosted@lemmy.world
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don’t control.
Rules:
Be civil: we’re here to support and learn from one another. Insults won’t be tolerated. Flame wars are frowned upon.
No spam posting.
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it’s not obvious why your post topic revolves around selfhosting, please include details to make it clear.
Don’t duplicate the full text of your blog or github here. Just post the link for folks to click.
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
No trolling.
Resources:
selfh.st Newsletter and index of selfhosted software and apps
The RFC warns about these exact issues. You MAY do something else, but then the blame is on you…
So why does Google enforce mDNS when it leads to this confusion?
Everywhere else, Windows, Linux, iOS, etc etc. as far as I can tell mDNS doesn’t happen with .local as the default, nevermind only option.
Only the android devices throw a fit because of Google enforcing bizarre legacy technology of use to no one.
Maybe there’s a way to hint to the problematic android devices that it’s a no-no by restricting all multicast traffic of any kind on network level? Is that even possible?
That’s kind of what happens when somebody re-uses already assigned namespaces for a different purpose. Same with other domains, or if you mess with IP addresses or MAC addresses. The internet is filled with RFCs and old standards that need to be factored in. And I don’t really see Google at fault here. Seems they’ve implemented this to specification. So technically they’re “right”. Question is: Is the RFC any good? Or do we have any other RFCs contradicting it? Usually these things are well-written. If everything is okay, it’s the network administrators fault for configuring something wrong… I’m not saying that’s bad… It’s just that computers and the internet are very complicated. And sometimes you’re not aware of all the consequences of the technical debt… And we have a lot of technical debt. Still, I don’t see any way around implementing a technology and an RFC to specification. We’d run into far worse issues if everyone were to do random things because they think they know something better. It has to be predictable and a specification has to be followed to the letter. Or the specification has to go altogether.
Issue here is that second “may” clause. That should be prohibited from the beginning, because it just causes issues like this. That’s kind of what Google is doing now, though. If you ask me, they probably wrote that paragraph because it’s default behaviour anyways (to look up previously unknown TLDs via DNS). And they can’t really prevent that. But that’s what ultimately causes issues. So they wrote that warning. Only proper solution is to be strict and break it intentionally, so no-one gets the idea to re-use .local… But judging from your post, that hasn’t happened until now.
Linux, MacOS etc are also technically “right” if they choose to adopt that “may” clause. It just leads to the consequences lined out in the sentence. They’re going to confuse users.
You’d think with how often android is updated ridding us of this technical debt is very easy. Disable multicast DNS, add a hidden setting tucked away in a menu somewhere to re-enable it. Ez pz.
If you use a .local domain, your device MUST ask the mDNS address (224.0.0.251 or FF02::FB) and MAY ask another DNS provider. Successful resolution without mDNS is not an intended feature but something that just happens to work sometimes. There’s a reason why the user interfaces of devices like Ubiquiti gateways warn against assigning a name ending in .local to any device.
I personally have all of my locally-assigned names end with .lan, although I’m considering switching to a sub-subdomain of a domain I own (so instead of mycomputer.lan I’d have mycomputer.home.mydomain.tld). That would make the names much longer but would protect me against some asshat buying .lan as a new gTLD.
No it must not lol what? The RFC says “may”.
And more importantly the devices don’t, it’s very noticeable via wireshark. The only multicast traffic comes from Android, every other OS does not bother, ironically not even Mac OS, whom is responsible for the whole Avahi/Bonjour nonsense to start with.
Another user pointed out that .home.arpa seems to be reserved, thus hopefully protected from TLD hijack which is what I’m worried about as well. I’d make it .homelab. I wonder if one can restrict recursion on certain domains?
If one server is marked as authoritative, but to recurse for other things, will it recurse for it’s authoritative domain, or give NXDOMAIN?
I do own a domain name via cloudflare so I might just utilize that, but I don’t like it.