Proposed top-level domain string for private use: ".internal"
icann.org
icann.org
Essentially you should always use a domain you control both outside and inside, like a regular gTLD or ccTLD.
Pretty much every single company I've worked for with AD has broken this rule.
But I suppose that I still ran the risk that the subdomain could "become real", or draw attention from security admins, or I would change ISPs.
How? I’m not saying this is great practice — there are certainly better options — but no one outside your network will ever know about it. It also won’t matter if you switch ISPs.
It was hard to fix because they couldn’t get the spoofed domain, and there were so many copies of bad links everywhere.
You NEED to use https when visiting any .dev domain. Google has put it on the HSTS preload list.
It took me a while to find out why my browser kept redirecting me to https when I wanted to use http (local development). Curl worked fine…
IMHO http has no use in the modern world.
Just for the record, anybody can add their own domain to HSTS via the submission site[1].
>Register a TLD which is informal standard for development websites and environments (.dev)
>Charge an excessive amount of money for it
>To make sure you ruin everyone's day, put it on a HSTS preload list
>Refuse to elaborate
You cant make it up.
The first point is valid but that is mostly ICANN's fault, they should have proposed it as reserved instead of selling it.
FAFO, as they say.
The only thing I can imagine would be if you accidentally created a root for .arpa.
Is it really going to assign "lancelot.roundtable.local" to my washing machine on a whim, which leaves the microwave unresolvable?
Can't I instruct the mDNS server running on my machine to respond to a particular name ending in .local?
Can't eg. dnsmasq insert itself into a conversation on 224.0.0.251 saying "Let me answer this question" for certain queries?
> mDNS implementations
> RFC 6762 was authored by Apple Inc. employees Stuart Cheshire and Marc Krochmal, and Apple's Bonjour zeroconf networking software implements mDNS. That service will automatically resolve the private IP addresses of link-local Macintosh computers running MacOS and mobile devices running iOS if .local is appended to their hostnames. In addition, Bonjour devices will use those .local hostnames when advertising services to DNS Service Discovery clients.
> Most Linux distributions also incorporate and are configured to use zeroconf.
> ..The connection of Macintosh and Linux computers or zeroconf peripherals to Windows networks can be problematic if those networks include name servers that use .local as a search domain for internal devices.
> At one time, Microsoft at least suggested the use of .local as a pseudo-TLD for small private networks with internal DNS servers.
> ..However, more recent articles have cautioned or advised against such use of the .local TLD.
> Microsoft TechNet article 708159[7] suggested .local
> ..but later recommended against it.
> The Microsoft Learn article "Selecting the Forest Root Domain"[8] cautioned against using .local
> By default, a freshly installed Windows Server 2016 Essentials also adds .local as the default dns-prefix when a user doesn't select the advanced option, resulting in a domain with .local extension.
Not that Microsoft should have made that recommendation, but hindsight and all that.
.local actually exists. It is used for mDNS.
I use this for all my internal domains, haha. I guess this is why we need a proper tld like this.
.test
.example
.invalid
.localhost
.test
.example
.invalid
.localhost
What I've seen lately is '.int' for internal usage. While this is a valid TLD, it is only for international organizations, and it is not possible for "normal" people to reserve a domain with that TLD, so unless your company is called "WHO" or similar, you shouldn't have any problems...
Example is best used in documentation only.
Invalid is weird and confusing.
Localhost as a TLD should still be on the machine itself. Keeping in mind that 127.0.0.1 is not the only loopback address at your disposal – you have the whole /8. You could bind different services on different loopback ip addresses and then assign host names in the .localhost tld to those.
So for example you could run different Wordpress instances locally on your machine on ips 127.87.80.2, 127.87.80.3, and 127.87.80.4, so that each can run on port 80 without colliding with one another, and without resorting to having non-80/non-443 ports.
Then have corresponding entries in /etc/hosts
127.87.80.2 dogblog.localhost
127.87.80.3 cooking.localhost
127.87.80.4 travel.localhost
And use those domains to access each of those from your browser. Then you don’t even need to keep all services behind the same Nginx instance for example, as you otherwise would do if you had different domain names but was using 127.0.0.1 and port 80 for all of them.
Whereas having the localhost tld refer to hosts elsewhere on a physical network.. that’s about equally as weird and confusing as “invalid”.
Tell that to Google Chrome developers, who are so arrogant they think they know better than the operating system, and force-resolve *.localhost. to 127.0.0.1
Reading that sentence implies a single loop back address. I appreciate that IPv6 “fixed” this confusion by having a single loop back address of ::1. While you are correct that IPv4 reserved the entire /8 in practice the expectation is generally that 127.0.0.1 is the loopback address, and using other addresses in the 127/8 space tends to lead to unexpected issues across many pieces of software. The intention of the .localhost domain is to ensure that DNS resolutions never resolves to something external, for security reasons.
See also, RFC 5735: “… This is ordinarily implemented using only 127.0.0.1/32 for loopback.” — https://datatracker.ietf.org/doc/html/rfc5735
You should not used them in production.
Are all options as well.
1. MS made recommendations to use .local
2. Apple networks started to use Bonjour and used .local, breaking on networks that used .local already
3. RFC was submitted
4. MS recommended against using .local or any domain you do not own fully
Yep. We use two domains - everything on A is "public" and everything on "B" is internal. The root of "B" is a static page on AWS that is gated behind our VPN so it serves as a quick "can you hit our infra at all" check when troubleshooting, and catches the people who are convinced they've enabled their VPN.
One thing to note here that we haven't solved (We've only got two "infra" people, we're a small company) is how you handle an internal portal to an external service. If our public domain is maccard.com and private is maccard.dev, where does internal-admin.maccard.com _actually_ live? Our solve for this is we have an internal.maccard.com for this very specific use case, but I'd much rather it was admin.live.maccard.dev
And having a website on the domain.tld adds shenanigans.
One of many examples I had is when Outlook loses connection to Exchange (eg S2S VPN is down) it starts autodiscovery process, hits domain.tld (because users have email@domain.tld, duh) and complains to user with a scary messages (which are also blocks the process until the users hit something). Which is totally understandable, because the website is on some public hosting, so CN in the cert is from the public host at best and != domain.tld.
Using corp.domain.tld or even techdomain.tld solves this totally and also let you use public certs (LE in the current era) even on the 'local' side of the network.
We actually have the DNS for our private domain set publicly, and all the actual work happens on a load balancer which is on the network. We're fully remote so this avoids the "my communal WiFi provider seems to have issues with the VPN" (which is what we had when we used split DNS)
Also as another commenter mentioned, it is impossible to tell based on the name if it is an internal or external resource
I'm curious what split DNS offers that a separate internal zone wouldn't.
made me think this wasnt such a great idea. particularly the part about facebook employees not being able to use their keycards to enter the buildings at the same time as the site outage.
The number of cases where this is actually a legitimate concern, IMO, is extremely small, and I'm personally of the opinion that using Internet-public domains for internal purposes is generally fine. But it's still important to point out that the number of cases is not zero.
But you can still have completely separate DNS for the inside. Using a shared DB for both would probably be recommended to avoid conflicts.
Zone content enumeration in DNSsec was fixed by NSEC3 records (RFC5155, March 2008)
Where did you see that? would be interesting to have reference for a couple people
Also, yeah, they almost had me with those .99 figures :-/
It's a lot better now. Ever since companies started moving from on-prem Exchange to O365 in droves I've noticed that most orgs I work with (painfully) updated their domain so their user principals align w/ their O365 mailbox.
There's only one customer I have that still uses a ".local" domain for AD, and they got bought out last year. (By an org that uses a real FQDN.)
Naturally, this went terribly as soon any of their sites had their own connection to the internet.
I had another much smaller client who's leadership insisted that because they were using it the owners would have to just have to not use it. Some sort of imagined IP squatters rights, I guess. I doubt the DoD accommodated them.
[edit] Oh, Active Directory
"Whereas, on 30 July 2014, the ICANN Board New gTLD Program Committee adopted the Name Collision Management Framework. In the Framework, .CORP, .HOME, and .MAIL were noted as high-risk strings whose delegation should be deferred indefinitely".[1]
It seems that ICANN did consider this choice among others, but reject for the lack of meaningfulness:
> The qualitative assessment on the latter properties was performed in the six United Nations languages (Arabic, Chinese, English, French, Russian and Spanish). [...] Many candidate strings were deemed unsuitable due to their lack of meaningfulness. [...] In this evaluation, only two candidates emerged as broadly meeting the assessment criteria across the assessed languages. These were “INTERNAL” and “PRIVATE”. Some weaknesses were identified for both of these candidates. [...]
I wonder if this means that they only scored the highest among others and all candidate strings were indeed unsuitable, but that they had to pick one anyway. I'm not even sure that laypersons can relate `.internal` with the stuff for "internal" uses.
Isn't it the default domain name for OpenWRT? Just like the default ip addresses are 192.168.*
https://www.w3.org/community/httpslocal/ https://httpslocal.github.io/proposals/ https://httpslocal.github.io/usecases/
I wish some of this work would continue as well.
Will this be possible with .internal ?
Yup, same here. Great in combination with ACME DNS-01 so your DNS server can request all those certificates and then push them out to your devices. (Otherwise the hostnames need to be externally accessible, which means either exposing the internal devices, or mucking around with split-view DNS. The former is a terrible idea, the latter is also DNS server complexity and worse than doing DNS-01 IMHO.)
I do appreciate the threat model of one device getting owned leaks all your certs but security is always a trade-off between security and convenience. It also lowers the load upon the LE servers, for what that's worth
Just 5 letters is less annoying to type repeatedly than .internal, while still conveying the overall purpose relatively well.
It might just be my laziness talking though.
Also, since intra is typically used as a prefix, it seems strange to use it bare. People familiar with intranets will probably make (or assume) the connection, but others might find it unclear while "internal" would likely not be.
Even so, I do prefer .intra for selfish reasons.
.lan is so "back to office"
... possibly a better link.
If you need DNS, register and use a real domain name. Everything else is going to be a hack. Anyone tech-savvy enough to know what an internal, unroutable TLD is, and have a use for one, is going to be just as comfortable and capable of managing a real domain.
I support the idea of something like .internal, but I'm certain it will be made useless for its intended purpose in short order.
Messing up your .internal configuration won’t result in leaking queries to the public.
And maybe secondarily this may encourage tool development for supporting internal names and make it easier for setting up informal or per department configurations.
Domain names are not slaved to DNS, they predate DNS by over a decade, and there is room for more than one naming system.
If DNS has to surrender one of their precious, precious, TLDs (lord knows there are soooo few to choose from) which, again, existed BEFORE DNS was even a twinkle in Paul Mockapetris' eye, so be it.
A quick google did not deliver a decent reserved domain, but multiple people suggested .home
If .localnet ever becomes a real TLD, well, I'm pretty sure the entire global infra is going to collapse and not necessarily be my problem.
Edit: And to be clear, I'm doing this for my house, not some enterprise setup; using real actual FQDN for internal services at a company, especially one that is multi-site/cloud, is still the best advice.
For example, in Google, https://go/foo had "go" as technically a TLD, and the memorable suffix that followed was already part of the path and not the domain name. It made it easy to type or include anywhere, including chats, posters, presentation slides, etc.
If they were to follow this proposal instead, you'd be typing or including https://go.internal/foo , which while more explicit largely defeats the point of the short URL.
This was very common in Windows shops back in the NT and even post-NT4 days to leverage the hostname as the URL (http://exchange, http://sharepoint, and so on).
Here are some more details: https://support.microsoft.com/en-us/help/300684/deployment-a... and https://admx.help/?Category=Windows_10_2016&Policy=Microsoft... which does the DNS resolution even for these less than ideal domains.
I think the right solution is that we should require domain registration (google.internal, microsoft.internal, etc.) to avoid these conflicts. A public CA may be able to verify ownership, avoiding the need for private CAs.
I built a service [1] that does this and is compatible with Let's Encrypt. The trick is that I only allow users to set ACME-DNS01 TXT records, not A/AAAA/CNAME records. So you'll still need to run internal DNS for those.
What's different is that the public suffixes I operate cannot publicly host content, which should protect the service from the abuse concerns that plagued Freenom and other free public suffixes. That reduces cost and should keep the site running.
I recommend buying your own domain if you don't mind the cost. A free solution for domains with TLS on internal networks is valuable to many.
https://en.wikipedia.org/wiki/Top-level_domain#Reserved_doma...
> The domain "localhost." and any names falling within ".localhost." are special in the following ways:
> 4. [---] Instead, caching DNS servers SHOULD, for all such address queries, generate an immediate positive response giving the IP loopback address
address=/localhost/127.0.0.1
address=/localhost/::1
The GP describes resolver software, which corresponds to item 6.3.3, not a caching server. This does specify the same behavior.
In RFC terminology, "MUST" > "SHOULD" > "MAY", so there is some wiggle room there.
6.3.2 permits Chromium and other apps to hardcode localhost names as such, instead of using a resolver.
A very popular vector for adware/malware is to take over the system resolver, or replace the DNS client configuration, so this is one reason Chromium jealously guards 127.0.0.0/8
https://www.iana.org/assignments/special-use-domain-names/sp...
Would the only difference then be the name ".internal" or is there another difference/advantage versus ".home.arpa"?
Maybe they can reserve both .interNAL and its convenient abbreviation, which just happens to be written backwards because it's DNS.
Seriously, .lan is just a convention. For all I care they could come up with any three-letter thingy, as long as there's a mutual understanding that no global DNS will ever resolve it.
Best to avoid it for that purpose:
1. "Using '.local' as a private top-level domain conflicts with Multicast DNS and may cause problems for users." https://www.rfc-editor.org/rfc/rfc6762#appendix-G
2. ".local has since been designated for use in link-local networking, in applications of multicast DNS (mDNS) and zero-configuration networking (zeroconf) so that DNS service may be established without local installations of conventional DNS infrastructure on local area networks." https://en.wikipedia.org/wiki/.local
3. "PSA: Don't use domain.local" https://old.reddit.com/r/sysadmin/comments/a9sfks/psa_dont_u...
4. "Why using .local as your domain name extension is a BAD idea!" https://community.veeam.com/blogs-and-podcasts-57/why-using-...
For a simple home network setup, as long as naming conflicts can be managed, it looks like mDNS is quite handy.
On a side note, I find .local to be best suited for the purpose, since from the language perspective it's easier on international users than .localhost
The newly proposed .internal comes close, but .local still looks more semantically flexible or maybe this is a cognitive bias of mine.
Microsoft Buys Corp.com So Bad Guys Can’t https://krebsonsecurity.com/2020/04/microsoft-buys-corp-com-...
The only option to somewhat-securely run TLS would be to have the company run their own internal CA, and trust its root certificate on all internal clients.
(to be fair, you generally can't get an .int domain registered. "int is considered to have the strictest application policies of all TLDs, as it implies that the holder is a subject of international law.")
… now that I think about it, "foo.in/ternal" makes so much more sense …
There's an existing TLD that is a string prefix of the new TLD.
Apart from lookalike attacks I'm also wondering if this will do weird things while you type in an address, e.g. if you try to type "foo.internal" and pause for a second after "foo.int"… your application may run off and do lookups or even prefetches.
What you are losing is the modicum of confidence that a website is the real deal because another party (that browser and OS manufacturers trust) took the time to, at the very least, verify ownership of the domain.
I've been exploring private-use-only domain registration at https://www.getlocalcert.net/, which is compatible with LetsEncrypt.
“ICANN has picked the TLD string that it will recommend for safe use behind corporate firewalls on the basis that it will never, ever be delegated.
The string is .internal, and the choice is now open for public comment”
Saved you a click :)
Alternatively I use a map file loaded into the memory of a loopback-bound forward proxy. No DNS.
I also use loopback-bound authoritative DNS to a limited extent as it provides wildcards.
There are ways to avoid using DNS.
Most web developers do not understand DNS, or at least dislike it, and some get annoyed by the HOSTS file. Quite funny. But I'm not a developer. DNS is something I understand well enough, I like it, and, in addition, the HOSTS file is useful for me. But sometimes it's most useful for me to avoid DNS.
pdns_recursor can serve /etc/hosts
https://docs.powerdns.com/recursor/settings.html
unbound can serve "local data"
https://unbound.docs.nlnetlabs.nl/en/latest/manpages/unbound...
dnsd from busybox can serve a HOSTS file
(exec 2>/dev/null;while read a b c ;do echo "$b $a";done < /etc/hosts|busybox dnsd -c /dev/stdin -p1153 -i 10.21.66.4)
echo . > data
while read a b c;do echo =$b:$a:1;done < /etc/hosts >> data
tinydns-data
ROOT=. IP=10.21.66.4 GID=0 UID=0 tinydns
rsync/mrsync could be used to keep computer A and computer B's HOSTS files the same
Or ssh to transfer the HOSTS file from A to B.
echo cat /etc/hosts |ssh -T computerB "cat > /etc/hosts"
echo getent hosts name|ssh -T computerB
httpd /etc --port 1153 --addr 10.21.66.4
tnftp -4o'|grep name' http://10.21.66.4:1153/hosts
But I'm not interested in using the HOSTS file in this way on the local network. I'm more interested in IP addresses than "domain names". I am not a fan of web browsers; I make HTTP requests from the shell command prompt and from shell scripts. For example, I like to create shortcuts for certain IP addresses so I do not have to type them, e.g., when using netcat. For me, the HOSTS file works perfectly for that purpose. I use this functionality every day.
Not every computer on my local network has the same ability to lookup names and IP addresses. Most have zero access to DNS data. No lookups. Some may only be able to lookup a few remote addresses. I might put those in the computer's HOSTS file.
Domain names are overrated. Web marketing hype. For example, no one uses a domain name to log into their router. But no one at home is getting internet access without typing an IP address at least once to set up a router. If I want to type a short, memorable name instead of an IP number to reach a computer on the local network I can make an entry in /etc/hosts. Using computers that have no /etc/hosts and no control over DNS sucks. Let web developers use those computers.
How many times have I seen developers copy entire portions of RFC 1035 into their code as a "comment". Too many to count. They will always struggle to understand it.
https://assets.avm.de/files/docs/fritzbox/fritzbox-7590-ax-v...
"You can also enter the IP address of the FRITZ!Box or the emergency IP.
The preset IP address is: http://192.168.178.1
The emergency IP address is: http://169.254.1.1"
Typing "fritz.box" into a browser is useless unless one already has an internet connection.
If it's a remote DNS query then is that really "internal networking".
Looks like there's an ad for NFTs at fritz.box along with some links to Javascript files and nothing else. No content. I think I'd rather just use a local address.
It does look like the domain fritz.box is not owned by AVM, the manufacturer of the device. Apparently they didn't manage to register this domain once .box became available. So in the future they might want to use fritzbox.internal, if this proposal gets approved.
Typing "fritz.box" into a browser without an internet connection will not accomplish anything. To even get an IP address for "fritz.box" there needs to be either (a) an appropriate entry in /etc/hosts assuming the browser does not ignore /etc/hosts, (b) a DNS server on a loopback address or (c) a DNS server on the local network, _and_ the DNS server needs to have the IP address for "fritz.box" (so the person would have to know the address already, before connecting to the internet) _and_ the browser has been configured to use that local DNS server.
To demonstrate, assuming there is not a DNS server listening on the loopback address 127.23.59.88, change the DNS settings in the operating system to 127.23.59.88. Then try typing "fritz.box" to set up the router.
The reason an "alternative" method is provided in the instructions is because without an internet connection, typing "fritz.box" will not accomplish anything except generating an error.
The reason the company suggests that people type "fritz.box" instead of an IP address is likely because the operator of "fritz.box" website is advertising NFTs for sale. Not to mention the data collection the operator of fritz.box and potentially their marketing partners will gain with respect to people who own these routers. For example, everytime someone is configuring their router and types "fritz.box" the operator of "fritz.box" website gets to know about it.
The "alternative" method is the most reliable method, and the most private one. If we review the manuals for thousands of routers, we learn it is the most common method.