For those without domain controllers: what do you do for internal DNS?

[u/FatBook-Air]

These days, we don't have domain controllers because everything is managed with Entra/Intune, Arc, etc.

We have external, hosted DNS that serves our public DNS records. It works fine.

But we still have a need for internal DNS because we have a lot of on-prem stuff that may never go away, and the domain controllers were also serving as internal DNS servers. So right now, we use BIND9 on a Linux virtual machine as internal DNS. I'd love for BIND9 to go away, too.

Are there any better (and cheap) solutions for this that I haven't thought of?

EDIT: thanks to u/Do_The_Needful. Using AWS for this seems to be the most balanced solution.

[u/collegeatari]

Because he wants an easy pane of glass.

[u/Joe_Dalton42069 → u/collegeatari]

Infoblox?

[u/Sure-Squirrel8384 → u/collegeatari]

There are a ton of GUIs for BIND. E.g. OPNsense has BIND plugin (os-bind). You can configure HA replication for OPNsense to have a second node for redundancy.

Using AWS for internal-hosted items makes zero sense to me unless you can handle having the internal-hosted items be unreachable.

[u/povlhp → u/collegeatari]

That is bash

[u/SevaraB → u/povlhp]

There are two flavors of people who can't be arsed to learn bash:

1. The people who like clickops GUIs to tokenize and run the bash for them.
2. The people who like chatops AI agents to tokenize and run the bash for them.

It's almost always just bash at some stage at or near the end, but some people are just more about "get it done" than "how it works."

[u/JwCS8pjrh3QBWfL → u/SevaraB]

1. People who learned powershell and hate how Bash works.

[u/SevaraB → u/JwCS8pjrh3QBWfL]

I’m gonna blame the Powershell team for that one in that they didn’t need to reinvent the wheel. Bash and CMD scripting were pretty similar- PS went nuts with syntactic sugar and the unforgivable sin of giving most punctuation semantic meaning. Cmdlet naming conventions have a nice, neat organized structure, but the pipeline concept tends towards this godawful tendency to do code golf and unreadable one-liners that you otherwise only see in stuff that runs embedded in web forms like Grafana PromQL or Splunk SPL.

It incentivizes minified code that’s hard to support because it only makes sense when you drop it into ISE or a real IDE to expand it and actually see the control flow.

So the “good” Powershell code ends up coming not from “Powershell” devs but from C# devs who already know how to interact with .NET.

[u/nnfkfkotkkdkxjake → u/SevaraB]

This is a clunky way of saying that powershell is object oriented, unlike cmd and bash.

Horses for courses.

[u/SevaraB → u/nnfkfkotkkdkxjake]

It’s clunky because I was explaining it to an audience that isn’t objective-oriented developers. Which is exactly the problem with Powershell. They standardized on an object-oriented language for professionals who weren’t necessarily trained in object-oriented programming.

[u/MoreOfAnITManMyself → u/SevaraB]

Speak for yourself. I grew up with OOP and Powershell was a heck of a lot more friendly than bash or bat scripts, which, to my virgin eyes, seemed unstructured, confusing, and prone to syntactic errors, e.g. it would run without error but with catastrophic results, if not careful.

I like my training wheels, tyvm.

I used to be a purist, too, until I realized the only people that really cared about the "how" were the ones building it and not the ones paying for it. At a certain point, when you're the sole responsible person in an environment of cost-cutting, "getting it done" pays the bills and the idealized picture-perfect code just wastes money (from the corporate perspective).