Honestly, just spend the five bucks a year and reserve a real domain name with auto renew. You don't need to make it publicly resolvable, but you'll be 100% sure all of your internal service names won't ever conflict with anything used in the real world. If you pick the right registrar, you can easily get your hands on a wildcard DNS cert as well through Let's Encrypt, so you can protect your internal services with HTTPS!
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.
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.
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.
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.
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.)
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.
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.
> 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.
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.
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.
Microsoft had .corp as a placeholder for years, intending admins to input their own domains. (Which many promptly never did.) However, I'm not aware of them ever recommending or using .local for anything.
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.
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
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.
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]
"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 !
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`?
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?
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.
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.
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 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.
Ah, thanks (both of you). Yeah, I'd seen that before, recognise it now that you mention it. But it had completely slipped my mind, so I really couldn't fathom what skin colour had to do with this.
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.
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
> 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...
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.
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.
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!
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.
> (...) 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'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.
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.
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"
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.
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`.
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:
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:
"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."
> 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."
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.”
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.
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?
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.
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
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.
I 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.
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.
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.
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.
> 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):
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 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.
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.
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.
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
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.)
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.
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]
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.)
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.)
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.
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."
- .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.
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.
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.
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.