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.
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.
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.
The only thing I can imagine would be if you accidentally created a root for .arpa.
.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.
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.
.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
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].
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
Where did you see that? would be interesting to have reference for a couple people
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)
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.)
Also, yeah, they almost had me with those .99 figures :-/
>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.
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.
[edit] Oh, Active Directory