Ignore this one, it's better solved at resolvconf.nix.

I'll make an update.

I think, this is the correct solution. Please review.

I'm not sure. In case of nameservers != [] && useLocalResolver, I might prefer to throw an error, because to me it seems unclear what was meant. As it is now, both options are exposed and can be set explicitly by the user.

In other words, assuming we keep this automagic, in cases like yours I'd expect the configuration explicitly sets useLocalResolver to false.

Your approach would make sense perhaps if we additionally made the option internal, or some such "larger" change of what's being done here.

The problem I'm trying to solve is this one.

I have static configured networking, so I've set networking.nameservers to my upstream servers.

I also run a Bind named service as master for a few domains. As that thing manages the private keys for DNSSEC, I don't want it to do client resolving.

However, without my proposed patch, enabling Bind will override my explicit defined name server configuration and set 127.0.0.1. That's what I mean with principle of least surprise: an explicit configuration should not be ignored by a default setting.

As there is no documentation in either networking.nameservers, nor at bind, unbound and dnsmasq that it sets the resolver config, it is hard for a Nixos user to discover this behaviour. Only by reading the module source of Bind, I learned about the existence of useLocalResolver.

I hope this clears things up.

Aah, I didn't realize there's this common issue due to named being a dual-purpose service in principle (authoritative and not).

I can add some documentation at bind, unbound and dnsmasq to tell about the useLocalResolver existence.

I guess, this could be added to options.services.{bind,unbound,dnsmasq}.enable.description:

   Notice: enabling this also sets the resolver in `/etc/resolv.conf`
   to `127.0.0.1`. To specify `networking.nameservers` yourself, set
   `networking.resolvconf.useLocalResolver = false`.

Please let me know if you think that would be helpful to the user.

Personally, I think my patch does exactly that, let the default be 127.0.0.1 unless the user specifies nameservers themselves.

Cheers.

I marked this as stale due to inactivity. → More info