Confused about DNS forwarding and local domains

Moogle Stiltzkin

not sure about the other user, but one use case was getting the green lock sign for https so you stop getting nagged that your https cert is invalid

https://www.youtube.com/watch?v=qlcVx-k-02E

so instead you do what wolfgang proposes, using the dns for local only, for the purpose of getting a valid working https cert using letsencrypt to work for a local only environment.

it also solves the issue of using digit lan ips and port numbers, and switch to some simple standard url but for local use.

and to make things cleaner, use a proxy manager like nginx proxy manager so you can reduce the usage of ports in the url.

not sure the security implications of this, but this is what wolfgang and technotim in their youtube said to do for local users running their own self hosting services to access their app web services locally.

keyser

@Jeremy11one said in Confused about DNS forwarding and local domains:

Here's a 2018 Microsoft page I found with contrary advice: link. I'm interested in your opinion to see if there's something that article hasn't taken into consideration.

While generally @johnpoz does have a point on the issues with leaky DNS when using public domains internally, it should be noted it only happens if mistakes are made in internal DNS setup (like fx. Transparent vs. Static, and searchdomains and such).

There are a lot of arguments for using a public internal domain when it comes to user transparency/understanding and just generally making lives easier because of “easy use” of short hostnames instead of FQDN. Also, I highly disagree with the argument that a private domain internally makes things easier - it does not in the majority of management cases with large userbases. It will create a lot of double maintenance in DNS, proxies and firewall setups (reflection) if your userbase generally are using webbased tools in their interaction with company ressources that are a mix of internally and externally hosted servers. Much easier to maintain with a public internal domain, and no need for NAT reflection which is a PITA.

So both solutions works and each have their advantages. It’s safe to assume MS made that recommendation from years of support and understanding what problems was caused by each model.
Yes, a private domain is the “correct” technical solution, but ease of use and maintenance has a tendency to win ;-)
It should be noted as we increasingly move towards SAAS in cloudservices, the public internal domain advantage in maintenance does “diminish” as those require you to make double maintenance in DNS if they are named in the public domain.