It’s for internal resources. You can really use whatever subdomain you want internally, but this decision would be to basically say to registrars, this TLD is reserved, we will never sell this TLD to anyone to use. That way you know that if you use it internally, there’s no way a whoopsie would happen where your DNS server finds a public record for this TLD.
Can you explaim further: I’m savvy enough to install a custom kernel for a 14 year old arm board and flush drive boot sector with U boot, etc, so I can use it as a dedicated DAAP server, but Networking somehow eludes me
Sure. Though I’m not an expert on mDNS or anything. It stands for multi cast DNS. In a normal scenario, when your PC tries to connect to a local resource at its hostname it will use a local DNS server (or its own cache). It’s like a phone book. I know who I’m looking for, I just need to look in the phone book and see what their IP is. With mDNS there is no server. You’ll have a service that will plan to respond at a particular .local hostname, so like jellyfin.local (this is just an example, I don’t know if it has mDNS) but that isn’t registered on a server. Instead when your PC wants to reach jellyfin it will send a multi-cast to the other local devices and say “ok, I’m looking for some guy named jellyfin.local, which one of y’all is that?” And the jellyfin server will respond and say “yo what up, this is my ip address”
So anyway, that only works with .local addresses. You could use .local with a regular dns server, but then you may run into a conflict. So that would be the benefit of reserving .internal
.local is definitely local but it’s common for it to be used with mDNS primarily. To the second part of your question, yes that’s correct, since it will be reserved it will not be any public DNS server, even if it did look outside it wouldn’t find anything.
It’s for internal resources. You can really use whatever subdomain you want internally, but this decision would be to basically say to registrars, this TLD is reserved, we will never sell this TLD to anyone to use. That way you know that if you use it internally, there’s no way a whoopsie would happen where your DNS server finds a public record for this TLD.
I assumed that was what .local was all about
.local is for mDNS addresses.
Can you explaim further: I’m savvy enough to install a custom kernel for a 14 year old arm board and flush drive boot sector with U boot, etc, so I can use it as a dedicated DAAP server, but Networking somehow eludes me
Sure. Though I’m not an expert on mDNS or anything. It stands for multi cast DNS. In a normal scenario, when your PC tries to connect to a local resource at its hostname it will use a local DNS server (or its own cache). It’s like a phone book. I know who I’m looking for, I just need to look in the phone book and see what their IP is. With mDNS there is no server. You’ll have a service that will plan to respond at a particular .local hostname, so like jellyfin.local (this is just an example, I don’t know if it has mDNS) but that isn’t registered on a server. Instead when your PC wants to reach jellyfin it will send a multi-cast to the other local devices and say “ok, I’m looking for some guy named jellyfin.local, which one of y’all is that?” And the jellyfin server will respond and say “yo what up, this is my ip address”
So anyway, that only works with .local addresses. You could use .local with a regular dns server, but then you may run into a conflict. So that would be the benefit of reserving .internal
Thanks this is helpful. So .local hasn’t been reserved for only on local LAN, and .internal would be registered so ot never looks outside of lan?
.local is definitely local but it’s common for it to be used with mDNS primarily. To the second part of your question, yes that’s correct, since it will be reserved it will not be any public DNS server, even if it did look outside it wouldn’t find anything.
Thanks, i appreciate you taking time to answer