> all DNS servers are expected to return the same result
Really? My local DNS server should return the same results as 8.8.8.8? Should one never use unregistered suffixes?
Really? My local DNS server should return the same results as 8.8.8.8? Should one never use unregistered suffixes?
What one should do is only choose DNS servers capable of properly resolving all addresses, as it shouldn’t be the resolver’s responsibility to “shop around” for answers.
Fixing VPN configurations that complicate this should be the responsibility of VPN client software — by providing a forwarding DNS server that falls back to the originally configured servers, say — not the resolver, and similarly for any other cases where standard resolver behavior does not suffice.
Application software, for its part, shouldn’t generally rely on implementation-defined resolver behavior, as doing so is obviously not portable, but that’s less sinful than a VPN relying on client library-level support to work around the fact that it’s exposing a broken network configuration.
Note that I have no axe to grind one way or another in the systemd debate: Linux isn’t me primary OS, but I regularly use and abuse both systemd and non-systemd Linux systems, and all the Linux init systems seem to work at least as well as any other system I regularly use (OS X, FreeBSD, Windows) for most practical purposes.
Strictly speaking, what you are talking about here, in RFC 1034 terminology, is a "stub resolver", the Unix model where there's a fairly dumb DNS client library running in the applications, talking to an external program that actually does the grunt work of query resolution by making back-end transactions and building up the front-end response from them.
A "resolver" actually very much does "shop around for answers", amongst content DNS servers. There's even a (slightly faulty) description of its shopping around algorithm, in RFC 1034 section 5.3.3.
"resolver" is such a confusing term, and so often used contrary to the RFCs in the way that you have here, that years ago I took to explaining the DNS to people using terminology borrowed from HTTP: proxy servers, content servers, and client libraries linked into applications.
If you have an internal DNS resolver which handles some private DNS entries, you should not set up any client with that resolver AND a second resolver which does not also have those entries.
So what the OP it's saying is that the example you provided is something you should never do.
So to clarify the statement: "all DNS resolvers defined on a given client are expected to return the same results"
I don't have a strong position on that argument. Just trying to state it more clearly.
* http://jdebp.eu./FGA/dns-client-all-proxies-must-provide-sam...
And no, you shouldn't just blithely assume that you own parts of the DNS namespace that you do not, either. There are plenty of other people's mistakes to learn from here. Don't repeat them.
* http://jdebp.eu./FGA/dns-use-domain-names-that-you-own.html
If they're internal services the namespace and the trust heirarchy can be private just fine.
Running your own CA works but has two caveats: first, I don't really trust myself to run a CA competently given that almost nobody who runs a CA as their only business function is doing so competently, and second, you have to get your config onto every device on the network. If you let personal devices on the network or even just hard-to-configure things like Chromecasts, you have to get your config onto all of them somehow.
It's quite a bit simpler and more secure to just use .corp.example.com or whatever.
Sure, it's most suitable for a homelab where you can import the certs, with suitable discretion, for yourself only.
>Running your own CA works but has two caveats: first, I don't really trust myself to run a CA competently given that almost nobody who runs a CA as their only business function is doing so competently
Not a massive concern since the context is internal only, but I hear you.
>and second, you have to get your config onto every device on the network.
Yep, this can be tricky in a less controlled environment. I had two scenarios in my mind - Home lab, and enterprise, when I penned that response. There's definitely a third one here, that you have in mind, that I didn't cover.
>It's quite a bit simpler and more secure to just use .corp.example.com or whatever.
Definitely the best option for small to medium companies.
You don't have to deal with any of the issues of public CAs because you control all the machines, running one in a corporate environment is no issue at all and there are plenty of existing products that will do almost all of the work for you.
> you have to get your config onto every device on the network
Which is a single task in an Ansible playbook, Puppet module, or Task in the Windows Task Sequence.
> you have to get your config onto all of them somehow
Usually not, you just need to get your CA on all the devices that are going to connect to your hosted services.