What domain name to use for your home network(ctrl.blog)
ctrl.blog
What domain name to use for your home network
https://www.ctrl.blog/entry/homenet-domain-name.html
173 comments
I'm not saying your wrong, but frankly, it's 2021, and it should be a lot easier than this to set up hosts internally for home use. We've largely had the internet broadly for the last 25 years, and the average person should not have to be an expert on wildcard certs/DNS/zeroconf if they want to just have a server running locally.
In fact, that's part of the reason things have gone to the cloud, because what should be local internet style appliances (think of a media server that you just plug in and works with your stereo/tv) can't find each other easily -- all because you can't resolve a freakin name on the local DNS without setting up bonjour or your own DNS server.
In fact, that's part of the reason things have gone to the cloud, because what should be local internet style appliances (think of a media server that you just plug in and works with your stereo/tv) can't find each other easily -- all because you can't resolve a freakin name on the local DNS without setting up bonjour or your own DNS server.
No, things have gone to the cloud because it's a source of recurring revenue.
Is it damn hard to have a cable modem + router box and a WiFi access point in your home? Likely it's a no-brainer; each of them is at least as complex as a DNS server. Incentives matter.
Is it damn hard to have a cable modem + router box and a WiFi access point in your home? Likely it's a no-brainer; each of them is at least as complex as a DNS server. Incentives matter.
Give your local box a static IP from a LAN range, give it a name in .local or .lan domain, and you're likely fine.
The more interesting stuff begins when you want several boxes, and also your laptops, phones, tablets, etc to form a reasonable LAN, while accessing the internet. Bonus points for remote access to your LAN from outside it using your laptop or phone. Etc, etc.
The more interesting stuff begins when you want several boxes, and also your laptops, phones, tablets, etc to form a reasonable LAN, while accessing the internet. Bonus points for remote access to your LAN from outside it using your laptop or phone. Etc, etc.
Why is a local domain useful? I mean, what's wrong with your local machines having only a hostname with no domain at all?
I haven't seen many real world software supports lookup remote with a hostname, probably windows itself is the only one that I have seen? Meanwhile, url is almost the universal way for lookup remote machine (besides, of course, IP).
That's what mDNS (multicast-DNS) is for (mentioned in the article as the reason to never use .local as a DNS TLD because that conflicts with mDNS). The old Windows hostname lookup is predecessor of modern mDNS, but surprisingly Windows was one of the slowest to adopt modern mDNS. (In part because Microsoft backed a competitor named PNRP: they thought it would be great to have a Distributed Hash Table [DHT] as the data store for hostname lookup rather than just relying on pure "dumb" multicast shouting for anyone on the local segment who can here it. It wasn't a bad idea but managing DHTs is complex and mDNS was a simpler standard.)
At this point almost every major OS (including Windows 10 after the right feature update) mDNS mostly just works out of the box: ask for somehostname.local and if a system responds "oh, that's my hostname" things mostly just work. (mDNS was once called "Bonjour" if that helps connect the dots on what it is and how long many OSes have supported it.)
So don't use .local for DNS and mDNS works fine in so many cases these days you don't really need set a DNS for your local systems anyway. (Though if you do want a setup, I think this article is correct and home.arpa is the safest option available. .lan is also a bad idea because it isn't RFC protected and could be bought by someone as gTLD just as Google bought .dev.)
At this point almost every major OS (including Windows 10 after the right feature update) mDNS mostly just works out of the box: ask for somehostname.local and if a system responds "oh, that's my hostname" things mostly just work. (mDNS was once called "Bonjour" if that helps connect the dots on what it is and how long many OSes have supported it.)
So don't use .local for DNS and mDNS works fine in so many cases these days you don't really need set a DNS for your local systems anyway. (Though if you do want a setup, I think this article is correct and home.arpa is the safest option available. .lan is also a bad idea because it isn't RFC protected and could be bought by someone as gTLD just as Google bought .dev.)
If you want to protect a webserver inside your home (which seems like a good idea in 2021), you're going to need SSL -- and that requires a domain.
Self signed ssl certs were kinda a solution to this -- and then were largely rejected as being absolutely "insecure" because they, well, were absolutely insecure.
Self signed ssl certs were kinda a solution to this -- and then were largely rejected as being absolutely "insecure" because they, well, were absolutely insecure.
No domain at all means it’s possibly publicly resolvable. You don’t want to name your internal webserver just “ws” because this resolves to 64.70.19.33.
DNS was not the reason for the cloud. The devices you talk of exist and DNS is not an issue. Some central discovery server can point you in the right direction if you do not want to set up your own dns. The problem is these products suck really bad. The hardware makers do not get top grade software developers and they do not support their devices for long enough so you get the recent issue with the home cloud nas product that exposed everyones data to the internet and an attacker remotely wiped them all.
I would much rather pay google $1/month to hold my data fairly securely than have to trust WD/Seagate/whoever to secure it.
And for IoT bits the problem is solved, Apple Home allows local only IoT devices and if you have an ipad or apple tv in your network you can always reach your iot devices without having to care about DNS. You might complain that this is a centralized cloud service but thats not far off what DNS is. You have to ask someone where your network is.
I would much rather pay google $1/month to hold my data fairly securely than have to trust WD/Seagate/whoever to secure it.
And for IoT bits the problem is solved, Apple Home allows local only IoT devices and if you have an ipad or apple tv in your network you can always reach your iot devices without having to care about DNS. You might complain that this is a centralized cloud service but thats not far off what DNS is. You have to ask someone where your network is.
You could just create your own cert and add it to all of your devices, I suppose
That doesn't work for certain devices, TV's/IoT devices, etc.
> Honestly, just spend the five bucks a year and reserve a real domain name with auto renew.
It really doesn't make much sense to propose as a solution to a potential configuration problem subscribing to a service with the goal of never using it.
It wouldn't be far-fetched to suggest reserving a subdomain of a domain you already own and use for that specific purpose, but paying for a subscription just to configure your internal DNS doesn't sound reasonable at all.
It really doesn't make much sense to propose as a solution to a potential configuration problem subscribing to a service with the goal of never using it.
It wouldn't be far-fetched to suggest reserving a subdomain of a domain you already own and use for that specific purpose, but paying for a subscription just to configure your internal DNS doesn't sound reasonable at all.
Mixing LAN and Internet scopes makes me uneasy. In my LANs the local domain is <location_name>.local, because .local is one of the reserved top domain names, and it shouldn't be resolvable outside the LAN.
https://tools.ietf.org/id/draft-chapin-rfc2606bis-00.html#rf...
https://tools.ietf.org/id/draft-chapin-rfc2606bis-00.html#rf...
Read the article. Don’t use .local (except for mDNS.)
Now it's evident I answered reflexively without reading the article. I like the concept of <server>.<location>.local/localdomain so host names never collided when you connected through VPN from one to another. That can still be done with <server>.<location>.home.arpa, but it feels ugly. I guess I'll get used to it.
> Don’t use .local (except for mDNS.)
Going forward, I agree. However for many years, the recommendation from large providers (including Microsoft) WAS to use .local
I've got .local as my internal network. For some people, it's not a trivial job to re-domain everything.
Going forward, I agree. However for many years, the recommendation from large providers (including Microsoft) WAS to use .local
I've got .local as my internal network. For some people, it's not a trivial job to re-domain everything.
If your L2 DNS (hostnames, typically auto-generated) doesn't match your L3 DNS (handpicked) you're going to eventually have a Bad Time.
They don't give a reason. I don't believe the author. I think it will not only technically work fine, but it's a good idea and better than using what the author suggests.
They do give a reason: mDNS is a standard that was assigned .local. mDNS is useful for a number of reasons. (One of its original codenames was "Bonjour" if that helps connect the dots on how old mDNS is at this point.)
It's not worth the effort to break mDNS because lots of apps can use mDNS, it's a useful standard. In fact, in many LANs today (on modern operating systems inc. relatively recent versions of Windows 10 as Microsoft was one of the last to adopt mDNS) mDNS does almost everything people would want DNS to do in LAN scope anyway and you could get away with not assigning any local DNS and just using mDNS services.
It's not worth the effort to break mDNS because lots of apps can use mDNS, it's a useful standard. In fact, in many LANs today (on modern operating systems inc. relatively recent versions of Windows 10 as Microsoft was one of the last to adopt mDNS) mDNS does almost everything people would want DNS to do in LAN scope anyway and you could get away with not assigning any local DNS and just using mDNS services.
This would still forward your unresolved to public DNS, exposing your internal infra, which as I understand it is one of the things this article is looking at preventing
'exposing your internal infra'
I've worked in gov places where they care about this detail. It's quite a sad 'security by hiding' mentality.
Oh no someone knows my current IP is 192.168.0.100 <scared/>
I've worked in gov places where they care about this detail. It's quite a sad 'security by hiding' mentality.
Oh no someone knows my current IP is 192.168.0.100 <scared/>
It is part of a bigger strategy called 'security in depth'. At least that is how I understand it.
I'm pretty sure some people would be interested if they figured out you have a subdomain named say, name-your-password-manager.example.com. Motivated attackers could then attempt to exploit your password manager through websites you're likely to visit.
> If you pick the right registrar, you can easily get your hands on a wildcard DNS cert as well through Let's Encrypt.
I, sadly, went for Namecheap, and they don't integrate with let's encrypt :(
I know I could use the http challenge solver, but I would have to expose a publicly-available endpoint and I would prefer to avoid that !
I, sadly, went for Namecheap, and they don't integrate with let's encrypt :(
I know I could use the http challenge solver, but I would have to expose a publicly-available endpoint and I would prefer to avoid that !
You can change your DNS provider without changing the registrar.
Lots of DNS servers won’t let you resolve to local IPs. Google’s public DNS does. So I do that but I have to set all my machines to use those DNS.
five bucks for the first year, then considerably more to renew
The blog post misses the (controversial if you're one of the ex-applicants) decision by ICANN to ban .corp, .home and .mail from ever appearing on the internet. So you've got those options too.
Or in ICANN management-speak: "Whereas, the Board considered that the applicants were not aware before the application window that the strings .CORP, .HOME, and .MAIL would be identified as high-risk, and that the delegations of such high-risk strings would be deferred indefinitely." [1]
[1]https://features.icann.org/addressing-new-gtld-program-appli...
Or in ICANN management-speak: "Whereas, the Board considered that the applicants were not aware before the application window that the strings .CORP, .HOME, and .MAIL would be identified as high-risk, and that the delegations of such high-risk strings would be deferred indefinitely." [1]
[1]https://features.icann.org/addressing-new-gtld-program-appli...
"to be not assigned" is generally less safe than "assigned for local use". E.g. 1.1.1.0/24 was first held back too see if bogus traffic would decreased then a ssigned for research purposes then assigned for cloudflare DNS causing a lot of grief for corporate networks that used 1.1.1.1 or 1.1.1.2 for network clustering or portal gateways instead of ones explicitly assigned for internal use.
>"to be not assigned" is generally less safe than "assigned for local use"
Normally I would agree. But in this case, 5 years (2018-2013), a $185,000 refund, high-profile media coverage and an explicit "deferred indefinitely" statement later ? I don't think any of us will see .CORP, .HOME and .MAIL on the internet in our lifetimes !
Normally I would agree. But in this case, 5 years (2018-2013), a $185,000 refund, high-profile media coverage and an explicit "deferred indefinitely" statement later ? I don't think any of us will see .CORP, .HOME and .MAIL on the internet in our lifetimes !
It actually mentioned .home as something not to use (along with .lan and.homenetwork)
Maybe the GP meant "missed" as in "was wrong about".
[EDIT:] (I'm not saying it is; just that GP may think so.) [/EDIT]
[EDIT:] (I'm not saying it is; just that GP may think so.) [/EDIT]
For non-TLDs, example.com is also good.
https://en.wikipedia.org/wiki/Example.com
https://en.wikipedia.org/wiki/Example.com
I truly do not understand why this problem has gone on for so long. It's clear that many people think `.home.arpa` is ugly. It boggles my mind that the IETF and ICANN can't come up with some agreement to get `.home` or something similar codified like RFC 7788 tried to do. This just seems like a fight between giant bureaucracies while meanwhile the users suffer and bad decisions like assigning `.dev` are made. I get that there are rules around this sort of critical infrastructure and its management, but come ON. /rant
With the rant ended: can anyone explain to me why all the relevant organizations can't get together and assign a TLD for this purpose that doesn't end in `.arpa`?
With the rant ended: can anyone explain to me why all the relevant organizations can't get together and assign a TLD for this purpose that doesn't end in `.arpa`?
Delegating .dev was fine. Sick of hearing about this. As the meme goes, "well, well, well, if it isn't the consequences of my own actions." Everyone who got burned by .dev got what they deserve and needs to grow up already, take responsibility for themselves, and get over it.
Delegating .dev was not fine. Does everything need to be for rent?
The name system is a unique non-renewable resource. And it's not like ICANN gave people a lot of choice for unregistered domains.
By your logic, I suppose .onion was not fine either, till cca 2015 when it got special-use status? And all the name system alternatives should be abolished, because we need to rent their TLDs to some uninterested party?
The name system is a unique non-renewable resource. And it's not like ICANN gave people a lot of choice for unregistered domains.
By your logic, I suppose .onion was not fine either, till cca 2015 when it got special-use status? And all the name system alternatives should be abolished, because we need to rent their TLDs to some uninterested party?
> I suppose .onion was not fine either, till cca 2015 when it got special-use status?
You are correct.
You are correct.
In similar news, do not use "dev.host", because someone owns it[0] and can and will do increasingly hilarious things to your traffic.
[0] me
[0] me
IMO the best approach is to register somedomain.com and use its subdomains. It’s guaranteed not to interfere with anything, you can get LE certificate, you can make it available from the Internet if necessary.
This is definitely the correct answer if you own a domain that you can use for your home network.
It has none of the downsides/gotchas from a technology point of view. Just have to make sure to renew your domain registration!
It has none of the downsides/gotchas from a technology point of view. Just have to make sure to renew your domain registration!
That's what I do, local.domain.com.
I also have a wildcard le cert for *.local.domain.com.
I also have a wildcard le cert for *.local.domain.com.
Or even better perhaps, home.domain.com.
I’ve been doing that since the beginning of my career, I don’t know what’s so hard about this.
somedomain.com is not guaranteed not to interfere!
example.com is guaranteed not to interfere (and example.org)
http://www.iana.org/domains/reserved
example.com is guaranteed not to interfere (and example.org)
http://www.iana.org/domains/reserved
I believe you took their post too literally; they mean to go register some domain you would like to have (such as ilovemycoolhouse.com or bearinabigblue.house) and use it, because the only way it will ever interfere with something is if you cause it to.
I hope you never forget to renew that registration...
Decent registrars provide auto renewal, and terms of multiple years. They also email you in advance of a card expiration and domain expiration. At a certain point you have to take some responsibility.
I agree! It always boggles my mind how people and companies can forget to renew their domain names when you receive so many email reminders now a days.
It is quite easy, the original owner/ responsible PoC left long ago, or the email goes to an barely read inbox/ group or bounces completely.
If a task only recurs less frequently like say every 3-5 years, it is more likely to be forgotten it is the same whether it is individual or companies.
If a task only recurs less frequently like say every 3-5 years, it is more likely to be forgotten it is the same whether it is individual or companies.
If that person leaves or the notifications are ignored that would happen with any method that involves any interaction whatsoever. At a certain point someone has to take some amount of responsibility for this, and if they don't it's going to fail _eventually_.
True, there is onus is on the organization to setup processes to handle all this. However it is not all that surprising these things gets missed , like i said if the process is not repeated frequent enough any organization memory is likely to loose track of it . no different from human memory really.
> the original owner/ responsible PoC left long ago
"Person of Colo(u)r"?
"Person of Colo(u)r"?
Point of Contact
My card expired, plenty of renewal reminders but I knew it was on auto-renew so ignored them as usual. Domain stopped resolving. Thankfully nowadays you can recover, in the past it meant you'd lost the domain for good.
This is one of those situations where too many warnings just causes users to ignore things. The only warning I needed - your card expired - was either missing or hidden in the morass of "ordinary" warnings.
It happens.
This is one of those situations where too many warnings just causes users to ignore things. The only warning I needed - your card expired - was either missing or hidden in the morass of "ordinary" warnings.
It happens.
This is a non-issue when you can pick a registrar (i.e. Route53) that will auto-renew for you.
> I believe you took their post too literally; they mean to go register some domain you would like to have
yes, and that's EXACTLY what example.com is for, this precise circumstance
smh
yes, and that's EXACTLY what example.com is for, this precise circumstance
smh
Are you arguing that the person should have used example.com in their comment as an example domain or are you suggesting people use a subdomain of example.com for their home network?
You're acting smug but nobody can tell why right now
You're acting smug but nobody can tell why right now
in case it isn't obvious, OP is saying to use YOUR domain, not the domain 'somedomain.com'
[deleted]
> Do not use undelegated domain names like .lan, .home, .homenet, .network, nor should you make up your own domain name.
...why?
My DNS server, my rules, no? Why should I feel obligated to follow ICANN? Obviously, I'll need to make changes if someone ever registers the domain with ICANN (and I want to access the ICANN version), but other than that...
...why?
My DNS server, my rules, no? Why should I feel obligated to follow ICANN? Obviously, I'll need to make changes if someone ever registers the domain with ICANN (and I want to access the ICANN version), but other than that...
For what it's worth, this does work. For now.
The main issue is if it gets sold later, or assigned by RFC. As an example, more than one company I've worked for used .dev as a TLD for their dev environments, with local DNS to override it. Once google bought .dev, this meant that:
- we couldn't access anything Google put on .dev
- suddenly, all of our test sites had HTTPS forced, because .dev was HSTS preloaded by Google
The point here is that an unexpected change that you might not be aware is coming can break your setup in ways that are awkward to resolve - eg HSTS preloading means that you can no longer access non HTTPS endpoints unless you do it by IP and that leads to a frustrating afternoon - and it's inevitably always when you don't want it.
Like it or not, ICANN operates the DNS space. There's a proper way to get your own piece of this space, and you can run home or business networks under your own piece and you have a guarantee that no one will break you - because it's yours.
(edited for formatting)
The main issue is if it gets sold later, or assigned by RFC. As an example, more than one company I've worked for used .dev as a TLD for their dev environments, with local DNS to override it. Once google bought .dev, this meant that:
- we couldn't access anything Google put on .dev
- suddenly, all of our test sites had HTTPS forced, because .dev was HSTS preloaded by Google
The point here is that an unexpected change that you might not be aware is coming can break your setup in ways that are awkward to resolve - eg HSTS preloading means that you can no longer access non HTTPS endpoints unless you do it by IP and that leads to a frustrating afternoon - and it's inevitably always when you don't want it.
Like it or not, ICANN operates the DNS space. There's a proper way to get your own piece of this space, and you can run home or business networks under your own piece and you have a guarantee that no one will break you - because it's yours.
(edited for formatting)
And as an extra point - can you actually guarantee that all your DNS lookups hit your DNS server first?
That's harder than it sounds, with more and more apps implementing their own DNS over HTTPS clients - Firefox does it for instance, so does Chrome.
That's harder than it sounds, with more and more apps implementing their own DNS over HTTPS clients - Firefox does it for instance, so does Chrome.
If you run your own router: yes up to a certain point.
https://www.myhelpfulguides.com/2018/07/30/redirect-hard-cod...
Afaik nobody has a fix for the client hostility that DoH brings to the table.
https://www.myhelpfulguides.com/2018/07/30/redirect-hard-cod...
Afaik nobody has a fix for the client hostility that DoH brings to the table.
I think the fact that I can slurp, block, and/or modify all the unencrypted DNS requests of every device on my network to be the hostile thing.
Yes we have all abused unencrypted DNS to take the littlest bit of control back from hostile devices but we’re the minority of a minority who lose out in this situation where everyone else is now shielded from random sketchy Wi-Fi hotspots, and their ISP.
Yes we have all abused unencrypted DNS to take the littlest bit of control back from hostile devices but we’re the minority of a minority who lose out in this situation where everyone else is now shielded from random sketchy Wi-Fi hotspots, and their ISP.
I think not giving the option to configure DNS servers or outright ignoring configured DNS servers to be incredibly hostile. Redirecting unencrypted DNS traffic is a defensive escalation. Putting your arms up as a fist comes at your face is not a hostile action.
Honestly, my initial reaction to that is "well, this is a great example why I don't like Firefox's DNS-over-HTTPS thing." Firefox should follow the OS's DNS settings, not make assumptions about how I run my network.
But a great counterargument would be "too bad, Firefox and now Google are doing it anyway, you lost and this is the world we live in, so deal with it." And, you'd have a point!
But a great counterargument would be "too bad, Firefox and now Google are doing it anyway, you lost and this is the world we live in, so deal with it." And, you'd have a point!
How come DNS requests initiated from Chrome/FF still reach my pi-hole and get blocked just fine?
I would think this browsers' solution would have prevented that.
The issue here being: what happens when you have your proxy configured as "proxy.lan" but you make a typo when entering it in local DNS or in your browser settings? That DNS request for "proxy.lan" will now go all the way out to the root servers for every page load, multiple times.
Not so important for you with your 200 tabs open, but quite important to the people maintaining the root servers who see a significant percentage of all queries being for bogus domains that don't exist.
Not so important for you with your 200 tabs open, but quite important to the people maintaining the root servers who see a significant percentage of all queries being for bogus domains that don't exist.
> (...) but quite important to the people maintaining the root servers who see a significant percentage of all queries being for bogus domains that don't exist.
I get the boys out rule sentiment, but isn't resolving domain names, even those that don't exist, the whole purpose of root servers?
I mean, your suggestion reads like asking not to type URLs wrong because a significant percentage of requests are 404s.
I get the boys out rule sentiment, but isn't resolving domain names, even those that don't exist, the whole purpose of root servers?
I mean, your suggestion reads like asking not to type URLs wrong because a significant percentage of requests are 404s.
>... even those that don't exist, the whole purpose of root servers?
The root servers shouldn't be a dumping ground for unnecessary traffic when proper DNS configuration is not that difficult.
The root servers shouldn't be a dumping ground for unnecessary traffic when proper DNS configuration is not that difficult.
I'm not sure you're getting it. You're complaining about a scenario where there's a misconfiguration error that's totally unintentional. No one is intentionally driving traffic to domains that don't exist. In fact, of said traffic hits the root servers, odds are that the system is effectively down and not receiving the traffic it's expected to receive, and a few developers are trying to figure out what's broken.
What if you make a typo on .home.arpa? e.g., .home.arps? How is that any different?
Because all DNS software is supposed to know that the .arpa domain name is managed by the IETF and not ICANN. Or, rather, they know not to try to resolve it. There are a handful of different .arpa domains in use, and they all require special handling from your DNS server. E.g. reverse DNS/rDNS uses in-addr.arpa., and the DNS server in even the dumbest consumer-grade router will know how to respond to requests under that domain.
that doesn't mean anything if you typo on ".arpa".
No DNS hardware is smart enough to know that you meant ".arpa" not ".apra" you actually typed in.
Typos are not really a valid argument, it can happen for any type of domain.
No DNS hardware is smart enough to know that you meant ".arpa" not ".apra" you actually typed in.
Typos are not really a valid argument, it can happen for any type of domain.
If you want to be a polite DNS resolver operator, root servers from B to G allow zone transfer, so you can just host the root zone locally. This way none of the typos or other bogus requests will leave your network.
Try using something under .local and see how much fun you have.
That's what a former employer had set up for their internal environments.
Worked great until mDNS came along and Apple devices insisted that .local had to go through mDNS rather than our DNS servers.
The Mac users had a constant stream of complaints because of it: "I can't connect to the printer", "Shared drives don't work", "I can't access the CI environment in Safari/Chrome/whatever"
That's what a former employer had set up for their internal environments.
Worked great until mDNS came along and Apple devices insisted that .local had to go through mDNS rather than our DNS servers.
The Mac users had a constant stream of complaints because of it: "I can't connect to the printer", "Shared drives don't work", "I can't access the CI environment in Safari/Chrome/whatever"
Place I worked at set up the network using .local around 2010 when mDNS was already common. Turns out the admin had seen/heard of .local and thought that's what it was for. A little knowledge is a dangerous thing...
Does every single network client on your network use your DNS server for name resolution? No DNS-over-HTTPS? No widgets configured to talk to public DNS servers?
Also, does your DNS server correctly filter "out"-of-bailiwick responses for .lan etc. zones that are actually perfectly well in-bailiwick because they're from the actual delegated-by-the-real-root-servers nameservers, they're just not from your private server that you've configured? If not, I can execute a cache-poisoning attack against you.
Also, does your DNS server correctly filter "out"-of-bailiwick responses for .lan etc. zones that are actually perfectly well in-bailiwick because they're from the actual delegated-by-the-real-root-servers nameservers, they're just not from your private server that you've configured? If not, I can execute a cache-poisoning attack against you.
I'm with ya.
I use `.zz`.
It's short, easy to type, and in order for that to be assigned out, we'd need an entirely new country to be created (one that decided the other bazillion free CCTLDs are not to their liking). And like you say, I only run into a problem if I decide I want to access things from said country.
Would I do this in any professional setting? Absolutely not. For my own stuff at home? The risk is pretty minimal and the work involved in updating if I ever have to is not too bad.
DHCP automatically registers everything under <hostname>.zz, and I cname well-known things from <thing>.svc.zz to the appropriate hostname so I can hit, e.g., `blueiris.svc.zz` or `homeassistant.svc.zz`.
For SSL I just run my own CA.
I use `.zz`.
It's short, easy to type, and in order for that to be assigned out, we'd need an entirely new country to be created (one that decided the other bazillion free CCTLDs are not to their liking). And like you say, I only run into a problem if I decide I want to access things from said country.
Would I do this in any professional setting? Absolutely not. For my own stuff at home? The risk is pretty minimal and the work involved in updating if I ever have to is not too bad.
DHCP automatically registers everything under <hostname>.zz, and I cname well-known things from <thing>.svc.zz to the appropriate hostname so I can hit, e.g., `blueiris.svc.zz` or `homeassistant.svc.zz`.
For SSL I just run my own CA.
You can use ZZ freely, as it's an ISO 3166 code reserved for private use. AA, QM to QZ and XA to XZ are also reserved.
Not exactly. The RFC that would make it safe is draft status, and the draft is set to expire in <2 months and does not come off as particularly confident itself:
https://tools.ietf.org/id/draft-ietf-dnsop-private-use-tld-0...
> are thought to be plausible choices for the implementation of private namespaces
https://tools.ietf.org/id/draft-ietf-dnsop-private-use-tld-0...
> are thought to be plausible choices for the implementation of private namespaces
The RFC may expire, but it quotes the ISO3166 guidelines as to why .zz is safe for personal use. Those guidelines will not change because of this draft:
[ISO3166 clause 8.1.3] "User assigned code element":
"If users need code elements to represent country names not included in this part of ISO 3166, the series of letters AA, QM to QZ, XA to XZ, and ZZ, and the series AAA to AAZ, QMA to QZZ, XAA to XZZ, and ZZA to ZZZ respectively and the series of numbers 900 to 999 are available."
[ISO3166 clause 8.1.3] "User assigned code element":
"If users need code elements to represent country names not included in this part of ISO 3166, the series of letters AA, QM to QZ, XA to XZ, and ZZ, and the series AAA to AAZ, QMA to QZZ, XAA to XZZ, and ZZA to ZZZ respectively and the series of numbers 900 to 999 are available."
> The RFC may expire, but it quotes the ISO3166
This is not the argument you think that it is.
> zz is safe for personal use. Those guidelines will not change
Right. Safe for personal use within the range of uses for ISO 3166—guaranteed not to collide with any future two-letter country code. It's not a commitment from ICANN, which remains free to say, "ISO 3166 guarantees no collisions for AA. We choose, therefore, to open up bidding to auction off aa, which is expected to fetch a pretty penny as the first of a limited set of possible TLDs that are < 3 characters long."
This is not the argument you think that it is.
> zz is safe for personal use. Those guidelines will not change
Right. Safe for personal use within the range of uses for ISO 3166—guaranteed not to collide with any future two-letter country code. It's not a commitment from ICANN, which remains free to say, "ISO 3166 guarantees no collisions for AA. We choose, therefore, to open up bidding to auction off aa, which is expected to fetch a pretty penny as the first of a limited set of possible TLDs that are < 3 characters long."
> My DNS server, my rules, no?
That's the same line taken by network admins who think they know better than using RFC1918 IP ranges for their LAN.
That's the same line taken by network admins who think they know better than using RFC1918 IP ranges for their LAN.
Worked at a company which did this (dating back to when they probably figured they’d never need to connect to the net).
As a satellite office and an acquisition, we played all kinds of games to try to figure out whether we should send a given IP address out to the Internet or to corporate. Apple’s IP range was entirely overlapping and of course the corporate networking group just threw up their hands and said “send it to us; the internet is not a business critical function.”
This was in the early 2000s, not the early 90s.
As a satellite office and an acquisition, we played all kinds of games to try to figure out whether we should send a given IP address out to the Internet or to corporate. Apple’s IP range was entirely overlapping and of course the corporate networking group just threw up their hands and said “send it to us; the internet is not a business critical function.”
This was in the early 2000s, not the early 90s.
I'm not suggesting this would be intelligent for anything larger than your own home network!
I briefly considered their advice and am now using the-com-remote-home8080-amail.local.fu why? because it Further Upsets authoritarians.
To pick your own free TLD just run a nameserver check against the TLD on [1] and watch out for TLDs that hit root servers
[1] https://dns.google/resolve?micro.soft&type=NS
To pick your own free TLD just run a nameserver check against the TLD on [1] and watch out for TLDs that hit root servers
[1] https://dns.google/resolve?micro.soft&type=NS
As long as you properly configure your server to not bother the root servers, then sure. Do what you want. But you need to set up the TLD zone in addition to your domain zone. It’s extra work.
On your network, sure.
But you seem to be on our network with all of us and so here you need to obey our rules or things won't go so well for you.
But you seem to be on our network with all of us and so here you need to obey our rules or things won't go so well for you.
Oh yeah? What are you going to do? Complain that you can’t run the root nameservers and try to blackhole my traffic but fail since I am DHCP configured by my ISP?
Sounds like a toothless threat.
Sounds like a toothless threat.
Just tossing this out there- apple only claimed .local in rfc as of 2013. There are plenty of 'legacy' production environments that I support that still use .local without issue with mac clients. Its possible there would be a collision- but in practice the pain point is not enough concern for many with the limited subset of apple devices on their corporate networks.
Still pissed that apple was straight up allowed to usurp that tld instead of something like .mdns.local or .autoconf
Also, please dont use .com/net/org for local networks. All you are going to do is punish yourself when you go to setup you AD domain. However if you want to setup a subdomain that you are willing to make the AD server authoritative for you may end up with less pain. If you have to use your own domain keep in mind that if you go to setup AD in your home/lab/small biz you will need to add records for your webserver/mailserver etc since AD will want to be the authoritative dns server for its domain. There are ways around this, but I digress. Using a public tld can cause pain, just be aware of that.
Still pissed that apple was straight up allowed to usurp that tld instead of something like .mdns.local or .autoconf
Also, please dont use .com/net/org for local networks. All you are going to do is punish yourself when you go to setup you AD domain. However if you want to setup a subdomain that you are willing to make the AD server authoritative for you may end up with less pain. If you have to use your own domain keep in mind that if you go to setup AD in your home/lab/small biz you will need to add records for your webserver/mailserver etc since AD will want to be the authoritative dns server for its domain. There are ways around this, but I digress. Using a public tld can cause pain, just be aware of that.
My solution was to use a single domain for everything, with different locations broken out under their own subdomains. My colocated rack is "fmt2". VPSs are under normal IATA 3-letter codes. Homes, not just mine, are under "<STREET_NUMBER><STREET_NAME_INITIAL>". Internal services available for all homes are under "int". And so on. There are a bunch of reserved names under each to provide consistent access to per-location devices and services... "network" for a jump-off point to other devices, "edge<N>" for internet-connected routers, "sw<N>" for switches, "svc<N>" for per-location services (Wireguard, DNS, DHCP, NTP, LDAP, RADIUS, BIRD, HTTP/HTTPS, Home Assistant, Home Bridge), "ap<N>" for access points, "print<N>" for document printers, "fdm<N>" for 3D printers, ad nauseum. It's worked great to keep things organized. It also simplifies certificates since I can use wildcards.
I had set up some minecraft servers in my k8s homelab behind a proxy that routes clients to the right server depending on the domain name they're connecting to.
Everything inside the k8s homelab uses subdomains of k.myvanitydomain.com. The minecraft proxy is at mc.k.myvanitydomain.com. So, to connect to the "valinor" minecraft server, it's just valinor.mc.k.myvanitydomain.com. Dead simple (to me).
I tried explaining that to my kids and suddenly I knew what it was like for whoever explained to me the whole /ls/<chubby_cell>/borg/<borg_cell>/bns/<mdb_user>/<job_name>/<index> setup from google prod
Everything inside the k8s homelab uses subdomains of k.myvanitydomain.com. The minecraft proxy is at mc.k.myvanitydomain.com. So, to connect to the "valinor" minecraft server, it's just valinor.mc.k.myvanitydomain.com. Dead simple (to me).
I tried explaining that to my kids and suddenly I knew what it was like for whoever explained to me the whole /ls/<chubby_cell>/borg/<borg_cell>/bns/<mdb_user>/<job_name>/<index> setup from google prod
I just use a real domain name, so I can easily obtain LE certs. Only the internal DNS server will actually return internal addresses.
A real domain name is the way to go. The convenience of using LE wildcard certificates is huge.
However, running split-horizon DNS is not straightforward, at least in a home setting. I don't see a huge problem with putting a couple of internal addresses in external DNS servers.
However, running split-horizon DNS is not straightforward, at least in a home setting. I don't see a huge problem with putting a couple of internal addresses in external DNS servers.
lexicon cloudflare --auth-token $(gopass cloudflare) create my-real-domain.xyz A --name my-rpi --content 192.168.1.201I have simple requirements, so I just have a few normal records for the external DNS (primarily for LE to use, but also to make it easier for me to find my way back into my home network when I'm out and about). For internal addresses, I just use overrides in Pi-Hole.
I 100% agree that the whole reason for this setup is my LE cert. For whatever reason, some of my internal services with self-signed certs are not usable with Chrome, and some are. I don't know what pushes Chrome over the edge so it won't let you override. So I set up an internal reverse proxy with nginx to front-end all my internal services, then I only have to worry about keeping the LE cert installed in one spot.
I 100% agree that the whole reason for this setup is my LE cert. For whatever reason, some of my internal services with self-signed certs are not usable with Chrome, and some are. I don't know what pushes Chrome over the edge so it won't let you override. So I set up an internal reverse proxy with nginx to front-end all my internal services, then I only have to worry about keeping the LE cert installed in one spot.
You don't necessarily need a split-horizon DNS. You only need a few records for the LE wildcard certificate to renew. In fact, DNS-01 only seems to require a single TXT record to resolve.
In theory you could set up a small home server or dev machine script that pulls in a wildcard certificate and let all the real A/AAAA queries go to your LAN DNS server (or resolve through mDNS!). A record that doesn't resolve in global DNS won't usually cause much trouble in local DNS either.
Putting internal IP addresses in your DNS could pose problems for (small) companies using this trick (because it allows hackers to map out your network) and it could cause confusion (when systems reverse-lookup domains and suddenly a spoofed 10.0.0.1 address is shown as myfunkyservice.sigjuice.xyz in the log files). The issues are minor and unlikely to be a problem, but they're there to serve as footguns years down the line.
In theory you could set up a small home server or dev machine script that pulls in a wildcard certificate and let all the real A/AAAA queries go to your LAN DNS server (or resolve through mDNS!). A record that doesn't resolve in global DNS won't usually cause much trouble in local DNS either.
Putting internal IP addresses in your DNS could pose problems for (small) companies using this trick (because it allows hackers to map out your network) and it could cause confusion (when systems reverse-lookup domains and suddenly a spoofed 10.0.0.1 address is shown as myfunkyservice.sigjuice.xyz in the log files). The issues are minor and unlikely to be a problem, but they're there to serve as footguns years down the line.
I didn't say split-horizon DNS is needed for getting LE certs. Just that a real domain name is a requirement to obtain LE certs in the first place.
How will an A/AAAA query from something like https://my-rpi.my-real-domain.xyz resolve using mDNS?
All DNS queries go to my LAN DNS server by default. I don't particularly care that I can't create A/AAAA records on my LAN DNS server (which is a Time Capsule, btw) to keep the queries inside.
To me, the potential leakage of internal addresses/names is an acceptable tradeoff for the convenience.
Btw, how is a reverse DNS lookup ever going to do what you mention? I am not creating any PTR records anywhere.
How will an A/AAAA query from something like https://my-rpi.my-real-domain.xyz resolve using mDNS?
All DNS queries go to my LAN DNS server by default. I don't particularly care that I can't create A/AAAA records on my LAN DNS server (which is a Time Capsule, btw) to keep the queries inside.
To me, the potential leakage of internal addresses/names is an acceptable tradeoff for the convenience.
Btw, how is a reverse DNS lookup ever going to do what you mention? I am not creating any PTR records anywhere.
Split horizon:
I run DNSMasq on port 53, to serve DHCP and local DNS queries. DNSMasq forwards queries it can't answer (queries for "real" domains) to Unbound on port 1053.
It's not split horizon, because Unbound only serves the LAN - I don't serve DNS to the world - and because Unbound isn't an authoritative nameserver. But it's not that hard to make DNSMasq serve zones, and it's not hard to make DNSMasq serve those zones only to queries from the intarwebs, and serve the DHCP 'zone' to local queries.
And anyway, I guess you could use something ugly like BIND instead of Unbound, if you need an industrial-grade authoritative DNS server facing the internet.
I run DNSMasq on port 53, to serve DHCP and local DNS queries. DNSMasq forwards queries it can't answer (queries for "real" domains) to Unbound on port 1053.
It's not split horizon, because Unbound only serves the LAN - I don't serve DNS to the world - and because Unbound isn't an authoritative nameserver. But it's not that hard to make DNSMasq serve zones, and it's not hard to make DNSMasq serve those zones only to queries from the intarwebs, and serve the DHCP 'zone' to local queries.
And anyway, I guess you could use something ugly like BIND instead of Unbound, if you need an industrial-grade authoritative DNS server facing the internet.
This is a no brainer for any serious setup. We use our main domain to add subdomains which point to local services.
> Your time is better spent ensuring all your devices support mDNS resolution
Heh. I starred this Android feature request and kind of regret it because it's been a continuous stream of "+1" emails (but I want to stay subscribed in case some meaningful conversation happens at last):
https://issuetracker.google.com/issues/140786115
(A login is required; any Google account will do)
Heh. I starred this Android feature request and kind of regret it because it's been a continuous stream of "+1" emails (but I want to stay subscribed in case some meaningful conversation happens at last):
https://issuetracker.google.com/issues/140786115
(A login is required; any Google account will do)
For all the things saying not to use it, I've not run in to any issues with .local. It's reserved so it won't be delegated on the internet, it makes sense as a word and mDNS continues to work correctly. So far I haven't seen any devices that try to resolve over mDNS instead of DNS.
I use .lan and will continue to do so. .home.arpa is fine for 1 lan, but if you want to connect to multiple lans, it no longer works well. Add to the fact the amount of typing. .lan should be reserved so that people can use it for addressing multiple local area networks. We already have .local for mDNS which is perfect for the single lan setup. If they won't do it de jure, then users like myself will make this standard de facto.
What method are people using to configure this oin their own network? The router supplied by my ISP doesn't support using a custom DNS server like a pihole, unfortunately. I don't consider using /etc/hosts a longterm worthwhile solution. I'd love to find another useful way of setting this up.
I was lucky enough to ask my ISP to set their box to bridge mode and have my request granted, then attached my own router.
I just looked, and my router does indeed support bridged mode. That might be my answer. Thanks for pointing this out!
Does your router support disabling DHCP? You can just run your own DHCP server in that case.
It does. I might go with this option. It seems like it'll be easier than running the router in bridged mode, and adding another physical router.
That's what I do, even though I run my own router. The pi-hole acts as both DNS and DHCP.
It sets the DNS domain correctly via DHCP, unlike a lot of routers.
It sets the DNS domain correctly via DHCP, unlike a lot of routers.
I use NextDNS, so in the configuration for my LAN devices i have rewrites that maps host.somewhere.com to 192.168.x.x.
The external DNS maintains a single host record for VPN access, and since NextDNS also handles external requests, i have to set different hostnames for internal/external access.
It's (probably not) optimal, but it works. It was pretty much the same approach i used with PiHole/AdGuard Home.
Edit: To allow multiple hostnames i use a wildcard certificate from LetsEncrypt, though once i'm connected through VPN it doesn't matter much as it will resolve the internal hostname just fine.
It's (probably not) optimal, but it works. It was pretty much the same approach i used with PiHole/AdGuard Home.
Edit: To allow multiple hostnames i use a wildcard certificate from LetsEncrypt, though once i'm connected through VPN it doesn't matter much as it will resolve the internal hostname just fine.
For those curious about the (spoiler) .arpa domain, here’s an RFC https://www.rfc-editor.org/rfc/rfc3172
This still won't fix the bat-shit-stupid idea of browser developers to just forward anything they think is not resolvable (and often even if it IS a valid local FQDN) to the next best search engine...
Well, browsers do a very sensible thing of attempting to anything that is a valid domain names. For everything else, including undelegated (and therefore unresolvable) top-level domains get passed on as search queries. Forwarding as much traffic to search engines is how they make money, after all. If you don’t like it, stick to valid domains.
IIRC all browsers try to perform name resolution if you append "/" at the end of your input in the address bar. After that fails they redirect to a search engine, but not before.
An interesting trick I discovered is that you can make a public domain point to a local IP.
So I could make foo.mylocal.com point to 127.0.0.1 or the printer, or anything else really.
So I could make foo.mylocal.com point to 127.0.0.1 or the printer, or anything else really.
This isn't networking advice, but its what I've done either professionally and for home in some limited cases.
For fee paying networks, the "router" will most likley be in charge of some sort of DNS. If thats the case its made canonical for a subdomain that one owns. If you're lazy, just plain split horizon. However limit it strictly to DHCP. As soon as you start re-writing public services, you're sunk.
Side note, its a really good time to start putting in location data into subdomains. using option 60(might not be this, its been a while) you can work out what switch the request came from and add a different subdomain based on that you can make subdomains like server01.rack3.datacenter.country.company.com. this allows you to make search params to create local services. ie "time" would first check rack3, then datacenter, then country, then company.
For fee paying networks, the "router" will most likley be in charge of some sort of DNS. If thats the case its made canonical for a subdomain that one owns. If you're lazy, just plain split horizon. However limit it strictly to DHCP. As soon as you start re-writing public services, you're sunk.
Side note, its a really good time to start putting in location data into subdomains. using option 60(might not be this, its been a while) you can work out what switch the request came from and add a different subdomain based on that you can make subdomains like server01.rack3.datacenter.country.company.com. this allows you to make search params to create local services. ie "time" would first check rack3, then datacenter, then country, then company.
also my home domain name is "phartiphuckballs.com"
This is a complete tangent, but does anyone else really hate white text on black background? After reading only a few lines my eyes hurt and I have ghosting where the lines were when I look away. Websites like this one are basically unusable for me
Turn off dark mode in your system settings if you don't want dark mode. It's black-on-white in light mode.
I think it’s a device issue for you. My device sees it as black text on a white background.
For us laymen, why would you need/want a domain name for a home network?
So you don't need to memorize and hard-code IP addresses for your network services.
* router.home.arpa * nas.home.arpa * printer.home.arpa * htpc.home.arpa
* router.home.arpa * nas.home.arpa * printer.home.arpa * htpc.home.arpa
Yes, but that can be achieved by using a hostname alone (router, nas, printer, htpc...). What does the domain bring?
How, exactly, is that hostname being resolved, though? There is no magical protocol to resolve TLD-less hostnames in DNS. Your router probably adds entries for `hostname.dhcp-domain` but since `dhcp-domain` is empty, you end up with just `hostname`. No, go ahead and name a device `com` and see what happens. Your router will have a hard time resolving `example.com`. This is why you put your stuff behind apurpose-built TLD like `home.arpa.`
In some cases today that hostname is being resolved via mDNS, which is a good reason to get into the habit of using .local for mDNS addresses. Using somehostname.local on many OSes today forces DNS lookups to always and only use mDNS and avoids accidentally calling DNS. (So long as you don't break mDNS support on your local network by doing something like trying to use .local for traditional DNS.)
mDNS is probably sufficient for most people and you don't need to setup old school DNS on a local network. (But if you do, a purpose-built TLD like home.arpa is a good choice.)
mDNS is probably sufficient for most people and you don't need to setup old school DNS on a local network. (But if you do, a purpose-built TLD like home.arpa is a good choice.)
Prevent collision with public domains. “ws” has an A record. It’s possible that your local Webserver also is named ws.
With all new gTLDs it’s easy to have a collision when someone buys the “router” TLD.
With all new gTLDs it’s easy to have a collision when someone buys the “router” TLD.
What about .localhost? Asking for a friend.
That is actually another special-use domain name that is supposed to be resolved by the local stub resolver to 127.0.0.1 and ::1. It’s not suitable for use on your local network, however.
It’s supposed to be resolved to a loopback address. Chrome forces it to 127.0.0.1, because Google knows better than you. Obviously. <https://bugs.chromium.org/p/chromium/issues/detail?id=489973>
Can't we use .test and .example as well? They are reserved for testing locally, and although it sounds weird, ie nas.test, it will work.
* [rfc6761](https://datatracker.ietf.org/doc/html/rfc6761)
* [rfc6761](https://datatracker.ietf.org/doc/html/rfc6761)
There is a .casa TLD that you can use. It’s inexpensive to register, too.
I have to chime in here now and call the article what it is: wrong at least in regards to misinformation about ".local".
> DNS clients may defer the resolution of .local spTLDs to the system’s mDNS resolvers instead of its DNS resolver.
This is not true. First off: You can always misconfigure your DNS resolver, but usually they can be used in parallel. Multicast DNS usually is only used when your router is too stupid to manage the hostname; and if multicast DNS is active on every host, then it's a setting that fixes even that broken router.
Also, "hostname.local" will never conflict with DNS based service discovery [1] of resolving a host via multicast DNS. And even if so, you can just use one of the other reserved multicast addresses and be done with it.
As long as you don't use e.g. "._tcp." or "._udp." inside your hostname, you never have domain name conflicts.
I think there's also a huge misconception about what DNS-based service discovery is.
In DNS-SD, there are questions to a service identifier with a PTR inside, and the response contains A,AAAA,SRV and TXT entries to describe everything you need to know to make a connection to the correct host, ip, port and version of the service.
Airprint, airplay, airscan and others additionally use their service name as a prefix in regards to the IANA-registered service names [2] so printers, scanners and other Multicast-DNS compatible hardware never conflicts with the existing network.
/ragecomment
Personally, I would actually embrace the use of .local, because it allows you to build a self-discovery service that is unrelated to DHCP and unrelated to ARP mechanisms, and works peer-to-peer; as long as the IPs are in the same NAT or, with IPv6/UDP6, have at least one discoverable scope.
In DNS-SD, you literally just have to be able to reach other IPs, and you have a working handshake mechanism to discover other devices without having to know their hostnames, IPs, or anything. It's pretty amazing once you realize its network automation potential.
Source: Me, building a web browser that uses peer-to-peer TLS encryption on "username._stealth._tcp.tholian.network" and "username._stealth._tcp.tholian.local" [3]
[1] https://www.ietf.org/rfc/rfc6763.txt
[2] http://dns-sd.org/ServiceTypes.html
[3] https://github.com/tholian-network/stealth
> DNS clients may defer the resolution of .local spTLDs to the system’s mDNS resolvers instead of its DNS resolver.
This is not true. First off: You can always misconfigure your DNS resolver, but usually they can be used in parallel. Multicast DNS usually is only used when your router is too stupid to manage the hostname; and if multicast DNS is active on every host, then it's a setting that fixes even that broken router.
Also, "hostname.local" will never conflict with DNS based service discovery [1] of resolving a host via multicast DNS. And even if so, you can just use one of the other reserved multicast addresses and be done with it.
As long as you don't use e.g. "._tcp." or "._udp." inside your hostname, you never have domain name conflicts.
I think there's also a huge misconception about what DNS-based service discovery is.
In DNS-SD, there are questions to a service identifier with a PTR inside, and the response contains A,AAAA,SRV and TXT entries to describe everything you need to know to make a connection to the correct host, ip, port and version of the service.
Airprint, airplay, airscan and others additionally use their service name as a prefix in regards to the IANA-registered service names [2] so printers, scanners and other Multicast-DNS compatible hardware never conflicts with the existing network.
/ragecomment
Personally, I would actually embrace the use of .local, because it allows you to build a self-discovery service that is unrelated to DHCP and unrelated to ARP mechanisms, and works peer-to-peer; as long as the IPs are in the same NAT or, with IPv6/UDP6, have at least one discoverable scope.
In DNS-SD, you literally just have to be able to reach other IPs, and you have a working handshake mechanism to discover other devices without having to know their hostnames, IPs, or anything. It's pretty amazing once you realize its network automation potential.
Source: Me, building a web browser that uses peer-to-peer TLS encryption on "username._stealth._tcp.tholian.network" and "username._stealth._tcp.tholian.local" [3]
[1] https://www.ietf.org/rfc/rfc6763.txt
[2] http://dns-sd.org/ServiceTypes.html
[3] https://github.com/tholian-network/stealth
I use homenet.<my lastname>.tld
What if it's an office building?
Buy a real domain name and use that. It is probably cheaper than a single square foot of office space.
(This can either be your normal domain name that you already have, using split DNS to make more things resolve on the internal network, or an entirely separate domain name, whichever is operationally easier for you.)
(This can either be your normal domain name that you already have, using split DNS to make more things resolve on the internal network, or an entirely separate domain name, whichever is operationally easier for you.)
But homes could do that too.
I bet many homes have more money for domain names than some shops/offices.
Just wondering why they didn't call it 'localnet' or some other unused synonym for local.
I bet many homes have more money for domain names than some shops/offices.
Just wondering why they didn't call it 'localnet' or some other unused synonym for local.
Weird, my Linksys WRT1900AC applies `.home` to its local DNS, but this article says not to?
Don’t use the .home domain. It was mistakenly recommended in RFC 7788. But that RFC was updated by RFC 8375 recommending the home.arpa domain.
(RFCs are published by the IETF who manages the .arpa TLD. That’s one of the few TLDs not managed by ICANN for historical reasons. The .home TLD falls under ICANN’s root domain, so the RFC shouldn’t have assigned it.)
(RFCs are published by the IETF who manages the .arpa TLD. That’s one of the few TLDs not managed by ICANN for historical reasons. The .home TLD falls under ICANN’s root domain, so the RFC shouldn’t have assigned it.)
Ah, thanks. Oddly, it is the default and the current firmware won't let me change it.
I use a sub-domain of a domain I registered. For example, I use in.[myname].ca.
> Do not use undelegated domain names like .lan
OpenWRT: *glances aside nervously*
OpenWRT: *glances aside nervously*
.lan should be OK, it has no it’s own RFC, but it is a reserved domain nevertheless: https://datatracker.ietf.org/doc/html/rfc6762#appendix-G
> We do not recommend use of unregistered top-level
> domains at all, but should network operators decide to do this, the
> following top-level domains have been used on private internal
> networks without the problems caused by trying to reuse ".local." for
> this purpose:
This is hardly ‘reserved’. It just describes existing practice without in any way designating it as safe, recommended or future-proof.
> domains at all, but should network operators decide to do this, the
> following top-level domains have been used on private internal
> networks without the problems caused by trying to reuse ".local." for
> this purpose:
This is hardly ‘reserved’. It just describes existing practice without in any way designating it as safe, recommended or future-proof.
It's fine as long as people keep using it.
I use cozy.systems
I just set static IPs for important things and put them in my domain. There's also MDNS although most of the MDNS responders are pretty fat for what they do. I tried hacking some basic MDNS stuff into busybox a few years ago but never cleaned it up and sent a patch.
"pennygetyourownwifi" works for me.
I think it’s safe to assume that the one gtld ICANN will never sign off on - even if they sell .home, .lan, and everything else - is .icann
So if they won’t give us a tld to use, just use that :)
So if they won’t give us a tld to use, just use that :)
No mention of .internal
https://datatracker.ietf.org/doc/html/draft-wkumari-dnsop-in...
(Though maybe it's not a great name for this particular application, it seems to make a lot of sense for enterprise level infrastructure)
https://datatracker.ietf.org/doc/html/draft-wkumari-dnsop-in...
(Though maybe it's not a great name for this particular application, it seems to make a lot of sense for enterprise level infrastructure)
That's an Internet Draft, not a standard or even at least a published RFC. An Internet Draft cannot be used Internet-Drafts as reference material or cited as anything other than "work in progress."
There are some more reserved domains in RFC 6761 (https://datatracker.ietf.org/doc/html/rfc6761) though:
- .test (Application software SHOULD NOT recognize test names as special, and SHOULD use test names as they would other domain names. [...] Caching DNS servers SHOULD recognize test names as special and SHOULD NOT, by default, attempt to look up NS records for them, or otherwise query authoritative DNS servers in an attempt to resolve test names. Instead, caching DNS servers SHOULD, by default, generate immediate negative responses for all such queries.)
- .localhost (Users are free to use localhost names as they would any other domain names. Users may assume that IPv4 and IPv6 address queries for localhost names will always resolve to the respective IP loopback address.)
- .invalid (Users are free to use "invalid" names as they would any other domain names. Users MAY assume that queries for "invalid" names will always return NXDOMAIN responses. Name resolution APIs and libraries SHOULD recognize "invalid" names as special and SHOULD always return immediate negative responses. Name resolution APIs SHOULD NOT send queries for "invalid" names to their configured caching DNS server(s).)
- .example, .example.com, .example.net (Users SHOULD understand that example names are reserved for use in documentation.)
Unfortunately, none of these address the same needs as .internal would.
There are some more reserved domains in RFC 6761 (https://datatracker.ietf.org/doc/html/rfc6761) though:
- .test (Application software SHOULD NOT recognize test names as special, and SHOULD use test names as they would other domain names. [...] Caching DNS servers SHOULD recognize test names as special and SHOULD NOT, by default, attempt to look up NS records for them, or otherwise query authoritative DNS servers in an attempt to resolve test names. Instead, caching DNS servers SHOULD, by default, generate immediate negative responses for all such queries.)
- .localhost (Users are free to use localhost names as they would any other domain names. Users may assume that IPv4 and IPv6 address queries for localhost names will always resolve to the respective IP loopback address.)
- .invalid (Users are free to use "invalid" names as they would any other domain names. Users MAY assume that queries for "invalid" names will always return NXDOMAIN responses. Name resolution APIs and libraries SHOULD recognize "invalid" names as special and SHOULD always return immediate negative responses. Name resolution APIs SHOULD NOT send queries for "invalid" names to their configured caching DNS server(s).)
- .example, .example.com, .example.net (Users SHOULD understand that example names are reserved for use in documentation.)
Unfortunately, none of these address the same needs as .internal would.
> Users may assume that IPv4 and IPv6 address queries for localhost names will always resolve to the respective IP loopback address.
Is the RFC assuming that there is only one loopback address for each protocol? That may be true for IPv6, but in IPv4 the entire 127.0.0.0/8 range is reserved for loopback. You can bind services to addresses anywhere in that range ("ip addr add 127.0.0.100/8 dev lo; nc -l 127.0.0.100 1234") which can only be accessed through that specific loopback address. So is this saying that .localhost domains must always resolve to some loopback address in IPv4 queries, or to 127.0.0.1 in particular?
There was a proposal to do something similar for IPv6 (using a 1::/32 prefix[0]) but it doesn't seem to have advanced much since 2013.
[0] https://tools.ietf.org/id/draft-smith-v6ops-larger-ipv6-loop...
Is the RFC assuming that there is only one loopback address for each protocol? That may be true for IPv6, but in IPv4 the entire 127.0.0.0/8 range is reserved for loopback. You can bind services to addresses anywhere in that range ("ip addr add 127.0.0.100/8 dev lo; nc -l 127.0.0.100 1234") which can only be accessed through that specific loopback address. So is this saying that .localhost domains must always resolve to some loopback address in IPv4 queries, or to 127.0.0.1 in particular?
There was a proposal to do something similar for IPv6 (using a 1::/32 prefix[0]) but it doesn't seem to have advanced much since 2013.
[0] https://tools.ietf.org/id/draft-smith-v6ops-larger-ipv6-loop...
I tried to get my company's IT department to put my latest project on a .internal domain. They wouldn't go for it, even though it can and will only be used by people internally.
They bound it to a sub domain of the company's main web site claiming that Microsoft (maybe something with Active Directory? Or Azure?) doesn't support any domains that you don't actually own.
I wouldn't be surprised if this is false because the people in charge of the domains think GoDaddy is awesome. Would love to hear an HN expert tell me if they're full of crap or not.
They bound it to a sub domain of the company's main web site claiming that Microsoft (maybe something with Active Directory? Or Azure?) doesn't support any domains that you don't actually own.
I wouldn't be surprised if this is false because the people in charge of the domains think GoDaddy is awesome. Would love to hear an HN expert tell me if they're full of crap or not.
While it is certainly possible that a Microsoft-managed network places additional restrictions on what addresses are used, there are several good reasons to not to create unique "snowflake" situations for individual applications.
There might be silent assumptions everywhere what domain addresses answer to, in log collection, in monitoring, in address management tools. Simple things like domain search strings becomes harder. Any non trivial enterprise is going to have a ton of these (semi-)automated tools that your address will end up in.
It also carries the risk of complicating future work. The company might merge with another company. Or imagine a mandate where all communication will need to switch to TLS, only to discover there are addresses used under other domains internally.
There might be silent assumptions everywhere what domain addresses answer to, in log collection, in monitoring, in address management tools. Simple things like domain search strings becomes harder. Any non trivial enterprise is going to have a ton of these (semi-)automated tools that your address will end up in.
It also carries the risk of complicating future work. The company might merge with another company. Or imagine a mandate where all communication will need to switch to TLS, only to discover there are addresses used under other domains internally.
You don't suddenly want to be restricted to HTTPS only (i.e. when Google bought .dev). There's also the minor risk of someone eventually buying your domain and causing all kinds of funky hell, like setting proxies to your internal network (through WPAD) and the names of local services (printer, router, etc.) being queried to a real DNS server because your computer sometimes appends the domain name to TLD-less queries. I've seen it happen that someone set something like example.com as their local domain (including in the DHCP config) who then saw constant slowdowns as their browser tried to resolve http://local-service/ as http://local-service.example.com/, going out to the internet every time, and not caching the error response.