4 ms·

> 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 unregister

> 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?

JdeBP 9y ago
All listed proxy DNS servers should provide the same view of the DNS namespace. If your local proxy DNS server provides a different view to Google Public DNS, then it is wrong to list them together. * http://jdebp.eu./FGA/dns-client-all-proxies-must-provide-same-service.html 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 http://jdebp.eu./FGA/dns-use-domain-names-that-you-own.html
rosser 9y ago
I think the argument is that if you do put both your local DNS server and 8.8.8.8 in your /etc/resolv.conf, then yes, they should return the same results. Put another way, a configuration file that enumerates DNS servers isn't the appropriate place to "merge" things. I don't have a strong position on that argument. Just trying to state it more clearly.
wrs 9y ago
If you limit requests to the different servers to the domains they cover, that's fine (various resolvers do this in different ways). If you tell the resolver they're all equivalent, they need to all be equivalent.
- joombaga 9y ago
  Understood; thanks for clarifying.
jasomill 9y ago
No, one should probably never use unregistered suffixes. But that’s not to say that all DNS names should be public, nor that NAT is practically avoidable, so this is beside the point. 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.
- JdeBP 9y ago
  Aside: You are using "resolver" to describe the wrong thing. RFC 1034 employs "resolver" to describe the entire subsystem that user programs use to access what it calls "name servers". It theoretically allows, because it isn't intended to be Unix-centric, systems where all of the query resolution mechanism is potentially in some form of shared subsystem that runs inside each applications program. 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. * http://jdebp.eu./FGA/dns-server-roles.html http://jdebp.eu./FGA/dns-server-roles.html
geofft 9y ago
Well, certainly you should never use unregistered suffixes because how else are you going to get SSL certificates for your internal services?
- FooHentai 9y ago
  Self signing, or if your feeling fancy issue from your own CA and import the root cert on your clients. If they're internal services the namespace and the trust heirarchy can be private just fine.
  - geofft 9y ago
    Self-signing is a great way to invite phishing attacks against your end users: if they're used to clicking through cert warnings all the time, they won't notice when something has actually gone wrong. 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.
    - FooHentai 9y ago
      >Self-signing is a great way to invite phishing attacks against your end users: if they're used to clicking through cert warnings all the time, they won't notice when something has actually gone wrong. 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.
FooHentai 9y ago
No. What is meant here is that whenever multiple DNS resolvers are configured on a particular DNS client, those resolvers should share an identical view of the DNS landscape for that client to consume. 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"

> 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?

JdeBP 9y ago

All listed proxy DNS servers should provide the same view of the DNS namespace. If your local proxy DNS server provides a different view to Google Public DNS, then it is wrong to list them together. * http://jdebp.eu./FGA/dns-client-all-proxies-must-provide-same-service.html 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 http://jdebp.eu./FGA/dns-use-domain-names-that-you-own.html

rosser 9y ago

I think the argument is that if you do put both your local DNS server and 8.8.8.8 in your /etc/resolv.conf, then yes, they should return the same results. Put another way, a configuration file that enumerates DNS servers isn't the appropriate place to "merge" things. I don't have a strong position on that argument. Just trying to state it more clearly.

wrs 9y ago

If you limit requests to the different servers to the domains they cover, that's fine (various resolvers do this in different ways). If you tell the resolver they're all equivalent, they need to all be equivalent.

joombaga 9y ago
Understood; thanks for clarifying.

jasomill 9y ago

No, one should probably never use unregistered suffixes. But that’s not to say that all DNS names should be public, nor that NAT is practically avoidable, so this is beside the point. 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.

JdeBP 9y ago
Aside: You are using "resolver" to describe the wrong thing. RFC 1034 employs "resolver" to describe the entire subsystem that user programs use to access what it calls "name servers". It theoretically allows, because it isn't intended to be Unix-centric, systems where all of the query resolution mechanism is potentially in some form of shared subsystem that runs inside each applications program. 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. * http://jdebp.eu./FGA/dns-server-roles.html http://jdebp.eu./FGA/dns-server-roles.html

geofft 9y ago

Well, certainly you should never use unregistered suffixes because how else are you going to get SSL certificates for your internal services?

FooHentai 9y ago
Self signing, or if your feeling fancy issue from your own CA and import the root cert on your clients. If they're internal services the namespace and the trust heirarchy can be private just fine.
- geofft 9y ago
  Self-signing is a great way to invite phishing attacks against your end users: if they're used to clicking through cert warnings all the time, they won't notice when something has actually gone wrong. 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.
  - FooHentai 9y ago
    >Self-signing is a great way to invite phishing attacks against your end users: if they're used to clicking through cert warnings all the time, they won't notice when something has actually gone wrong. 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.

FooHentai 9y ago

No. What is meant here is that whenever multiple DNS resolvers are configured on a particular DNS client, those resolvers should share an identical view of the DNS landscape for that client to consume. 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"