The net runs on numbers. The numbers have to be translated into/from the DNS name to the numbers.
Nominating a DNS name as internal is doesn’t change the fact that we still have to, at some stage, find the (local) network mask that that corresponds to.
What am I missing?
Update: I’m not sure I formed my question correctly because I’m none the wiser. That’s my fault, I think.
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.
A DNS Proxy/Forwarder server? That’s where you would configure how your .internal domain resolves to IPs on your internal network. Machines inside the network make their DNS queries to that server, which either serves them from cache, or from the local mappings, for forwards them off to a public/ISP server.
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).
Don’t follow. Help me out someone please.
The net runs on numbers. The numbers have to be translated into/from the DNS name to the numbers.
Nominating a DNS name as internal is doesn’t change the fact that we still have to, at some stage, find the (local) network mask that that corresponds to.
What am I missing?
Update: I’m not sure I formed my question correctly because I’m none the wiser. That’s my fault, I think.
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
A DNS Proxy/Forwarder server? That’s where you would configure how your .internal domain resolves to IPs on your internal network. Machines inside the network make their DNS queries to that server, which either serves them from cache, or from the local mappings, for forwards them off to a public/ISP server.