My devices should not be going around making assumptions about what is and isn’t assigned by someone else somewhere when the only thing that should concern them is what the DNS server tells them is the case.
Also NAT does literally nothing other than being a massive PITA, so… yeah, I don’t think there’s much I can agree with in your rant.
Only true if you don’t know what you’re doing. The only reason any network is safe at all is NAT and Firewalls that come with it.
I don’t have to worry about devices on a local network in as far as firewalls go, I can expose anything I want, in fact I delete iptables at first sight on any new distro install or VM, so long as none of it is port forwarded and everything is behind NAT it’s all okay. My network is my castle. Thanks technology! Thanks smart people for figuring this out!
Once you wrap your head around the fact your computer has IPs assigned statically or by DHCP per interface per network, not like a MAC address per device as IPv6 wants it to be which is the wrong way to think, you won’t have any more trouble with NAT.
Like, oh no, fully functional point to point connectivity across the internet, how terrible
Yes when you start out you may think so, but as you get into it you realise that actually complexity exists because it serves a purpose. IPv6 has to bolt on privacy extensions and then also still include NAT and actual tons of space for loopback because it’s fundamentally incompatible with how the internet works otherwise.
And yes, practically it’s a security nightmare to have any IP of any computer accessible from the internet. If you go around configuring firewalls forever you might get it right but oh boy one mistake and you’re done for. Instead, consider NAT, the solution to all problems. I’m writing this behind quadruple NAT rn and it’s honestly fairly easy to manage, I’ve been too lazy to change it, not that I’d advise anything more than 1 necessarily.
Edit: .home.arpa is actually designated as local TLD, and is what I use for a crappy old tablet that doesn’t support mDNS
Yikes! That’s a lot to type to hammer in a nail that sticks out (Android). Thanks but no thanks. I’ll find some way to cripple mDNS on the non-compliant device instead.
So are you saying you run some sort of mDNS server(not sure what the word would be there)/provider? Why? How?
Only true if you don’t know what you’re doing. The only reason any network is safe at all is NAT and Firewalls that come with it.
I don’t have to worry about devices on a local network in as far as firewalls go, I can expose anything I want, in fact I delete iptables at first sight on any new distro install or VM, so long as none of it is port forwarded and everything is behind NAT it’s all okay. My network is my castle. Thanks technology! Thanks smart people for figuring this out!
NAT is not a security mechanism. If you set up a NAT with an otherwise permissive firewall, your router will happily forward any incoming packets destined for RFC 1918 addresses inside, no questions asked. I use this for a “lab” network that I sometimes want accessible from the bigger LAN - the lab router doesn’t have any rules for dropping incoming packets (only blocks some outgoing traffic), and all I have to do on the main router to get this working is to set a static route to the internal lab network through the lab router’s “external” IP.
And yes, practically it’s a security nightmare to have any IP of any computer accessible from the internet. If you go around configuring firewalls forever you might get it right but oh boy one mistake and you’re done for. Instead, consider NAT, the solution to all problems. I’m writing this behind quadruple NAT rn and it’s honestly fairly easy to manage, I’ve been too lazy to change it, not that I’d advise anything more than 1 necessarily.
accept established, related; drop incoming. That’s all you need to get the same security as a NAT with a proper firewall. Outgoing connections will get marked and have return traffic allowed, everything incoming without related outgoing traffic gets dropped. Want to “port forward”? Add a rule that allows incoming traffic to a specific IP/port/protocol triplet. Done. Don’t know how to make sure a client stays reachable on a specific address? Give it that specific IP address in addition to the one it autogenerates. This was always possible with IPv4, too, it’s just that the tiny address space made it impractical to use.
How do you get the equivalent of NAT punchthrough (which is unreliable with many NAT implementations) when you want to do a VoIP call without having to bounce all the data through a central server? Simple, you can just tell both clients the other one’s IP and port, have them spam each other for a tiny while with messages and eventually a message gets through both firewalls. It is very similar to NAT punchthrough, except you don’t have to guess how the NATs work and it’ll reliably connect.
Yikes! That’s a lot to type to hammer in a nail that sticks out (Android). Thanks but no thanks. I’ll find some way to cripple mDNS on the non-compliant device instead.
Not sure why you’d regularly need to type out the whole thing. Also not sure why you picked .local when .lan is also incorrectly used for this purpose and is shorter (and isn’t yet assigned to any conflicting technology)
So are you saying you run some sort of mDNS server(not sure what the word would be there)/provider? Why? How?
The point of mDNS is that devices auto discover each other on a network without a central authority. The word multicast in multicast DNS is the key. And the reason I use it is because… it just works. There’s no need to configure it, it works like this by default on pretty much every OS. Set the hostname and you’re done, .local now works. You can even bridge it across networks with a mDNS repeater available on many routers.
Given the ambiguity of certificates everywhere, malicious devices on the local network posing as a different server are not an issue (and it’s not like they couldn’t hijack the IP address in any flat network anyway).
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?
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.
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.
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
Well don’t build your network around unassigned TLDs.
Also NAT does literally nothing other than being a massive PITA, so… yeah, I don’t think there’s much I can agree with in your rant.
Like, oh no, fully functional point to point connectivity across the internet, how terrible
Edit: .home.arpa is actually designated as local TLD, and is what I use for a crappy old tablet that doesn’t support mDNS
It’s assigned in my local DNS server, cheers.
My devices should not be going around making assumptions about what is and isn’t assigned by someone else somewhere when the only thing that should concern them is what the DNS server tells them is the case.
Only true if you don’t know what you’re doing. The only reason any network is safe at all is NAT and Firewalls that come with it.
I don’t have to worry about devices on a local network in as far as firewalls go, I can expose anything I want, in fact I delete iptables at first sight on any new distro install or VM, so long as none of it is port forwarded and everything is behind NAT it’s all okay. My network is my castle. Thanks technology! Thanks smart people for figuring this out!
Once you wrap your head around the fact your computer has IPs assigned statically or by DHCP per interface per network, not like a MAC address per device as IPv6 wants it to be which is the wrong way to think, you won’t have any more trouble with NAT.
Yes when you start out you may think so, but as you get into it you realise that actually complexity exists because it serves a purpose. IPv6 has to bolt on privacy extensions and then also still include NAT and actual tons of space for loopback because it’s fundamentally incompatible with how the internet works otherwise.
And yes, practically it’s a security nightmare to have any IP of any computer accessible from the internet. If you go around configuring firewalls forever you might get it right but oh boy one mistake and you’re done for. Instead, consider NAT, the solution to all problems. I’m writing this behind quadruple NAT rn and it’s honestly fairly easy to manage, I’ve been too lazy to change it, not that I’d advise anything more than 1 necessarily.
Yikes! That’s a lot to type to hammer in a nail that sticks out (Android). Thanks but no thanks. I’ll find some way to cripple mDNS on the non-compliant device instead.
So are you saying you run some sort of mDNS server(not sure what the word would be there)/provider? Why? How?
NAT is not a security mechanism. If you set up a NAT with an otherwise permissive firewall, your router will happily forward any incoming packets destined for RFC 1918 addresses inside, no questions asked. I use this for a “lab” network that I sometimes want accessible from the bigger LAN - the lab router doesn’t have any rules for dropping incoming packets (only blocks some outgoing traffic), and all I have to do on the main router to get this working is to set a static route to the internal lab network through the lab router’s “external” IP.
accept established, related; drop incoming. That’s all you need to get the same security as a NAT with a proper firewall. Outgoing connections will get marked and have return traffic allowed, everything incoming without related outgoing traffic gets dropped. Want to “port forward”? Add a rule that allows incoming traffic to a specific IP/port/protocol triplet. Done. Don’t know how to make sure a client stays reachable on a specific address? Give it that specific IP address in addition to the one it autogenerates. This was always possible with IPv4, too, it’s just that the tiny address space made it impractical to use.
How do you get the equivalent of NAT punchthrough (which is unreliable with many NAT implementations) when you want to do a VoIP call without having to bounce all the data through a central server? Simple, you can just tell both clients the other one’s IP and port, have them spam each other for a tiny while with messages and eventually a message gets through both firewalls. It is very similar to NAT punchthrough, except you don’t have to guess how the NATs work and it’ll reliably connect.
Not sure why you’d regularly need to type out the whole thing. Also not sure why you picked .local when .lan is also incorrectly used for this purpose and is shorter (and isn’t yet assigned to any conflicting technology)
The point of mDNS is that devices auto discover each other on a network without a central authority. The word multicast in multicast DNS is the key. And the reason I use it is because… it just works. There’s no need to configure it, it works like this by default on pretty much every OS. Set the hostname and you’re done, .local now works. You can even bridge it across networks with a mDNS repeater available on many routers.
Given the ambiguity of certificates everywhere, malicious devices on the local network posing as a different server are not an issue (and it’s not like they couldn’t hijack the IP address in any flat network anyway).
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?
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.
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.