Can you make a comment on where to find these values?

Why is this a system user and in group root?

This service could also use systemd's DynamicUser, but using stubby as a group would be also a good start.

I think after = [ "network.target" ] should be here as well, not entirely sure though, since this module does DNS..

network.target is correct, since there might be static ip addresses, the service should bind to.

If you set the users home directory and createHome = true then you won't need this, the tmpfiles. and the WorkingDirectory attribute. Default permissions for a home directory are 700 though. Why did you use 750 with the root group? root can always read everything anyways.

From the man page it seems that stateDir is not even needed actually. Just using ${pkgs.stubby}/bin/stubby -C ${confFile} should work too, without any of the directory set up commands.

This might be a good case to use the toYAML function in lib. You could have a single option services.stubby.config of type attrsOf unspecified, set a default value of { resolution_type = "GETDNS_RESOLUTION_STUB"; ... } and then users can override this config with their own values without removing all others (not 100% sure about that though). Then you can use toYAML to generate the config. This has the benefit of not messing up string formatting in any, being easier to enter in Nix, and also being able to override all default settings (the edns_client_subnet_private: 1 can't be overridden here, and every overridable option would need its own option). extraConfig also becomes irrelevant.

To still enable the user to pass their own config file without having to convert it to Nix, you could have another option configFile which would be set to the generated yaml file from config by default.

Oh and you could even still keep all the options with the descriptions if you want, using such a config option backed by toYAML can do that.

Hmm, I seem to be having some trouble using toYAML for this. Right now, toYAML just calls builtin.toJSON, which produces a JSON configuration file. The trouble is, stubby has an altogether different (and more complex) JSON format that it also accepts, and so they don't line up quite right. It also seems to expect a complete configuration file in the JSON case, rather than merging explicitly set values with the defaults the way it does with YAML.

I will keep experimenting. It's possible I'm still doing something wrong. Are there plans to produce proper YAML with toYAML in the future?

Well that's not good what they're doing.. Because YAML is a superset of JSON, every JSON is also a valid YAML.

From their source I found that they use the YAML processing when the file ends with .yml or .yaml though (see https://github.com/getdnsapi/stubby/blob/4b9b0362f97d8db61cd0294c57f583437a5f47b4/src/stubby.c#L280-L281), so I think it should work if you do that.

Hmmm, so it still seems something about their parser isn't happy with JSON. I took a confirmed-valid YAML configuration (the default), yaml.loaded and json.dumped to JSON, and started the daemon by pointing it at that config file, and I still got the following:

Apr 08 18:30:28 nixos stubby[14459]: Error parsing config file "/var/lib/stubby/.stubby.yml": Did not update the context

To be fair, their parser also occasionally has trouble with even valid YAML (IPv6 addresses with leading and trailing colons).

Oh god, they're rolling their own YAML parser and it doesn't even work correctly :/ (yes YAML parsers are hard but JSON compatibility is the least they could do)

Can you file an issue at their repo for this? If they don't fix this soon this module will just have to roll with the inflexible configuration method. I don't think adjusting our toYAML function for this is reasonable, as it does indeed work correctly (and since it outputs JSON, Nix can easily parse it again with builtins.fromJSON).

totally agree regarding the functionality of toYAML vs them rolling their own parser. I will open that issue. In the meantime, I add in your suggestions to the previous way.

In any case, thank you for making me aware of toYAML , as it's bound to come in handy sooner than later.

Since the user now doesn't require any directory, you can remove the whole users.extraUsers.. part, and as suggested by @Mic92 use systemd's DynamicUser feature (documented in man systemd.exec). Just setting serviceConfig.DynamicUser = true; should do it. Then this User = can also be removed.

This works very well, thanks.

I've never played around with capabilities in systemd, are both of these required for the unprivileged user to bind to ports < 1024?

Yep, stubby (and DNS-over-TLS in general, I think) binds by default to 853. It's possible to listen on higher ports, however. I am working on a function in the let expression using lib.splitString that should allow this capability to be set only when absolutely necessary (i.e., if the listening port is < 1024).

This value doesn't seem to be used anywhere

This option and a few others should probably be of types.int instead of types.str

this results in a coercion error, because these values are interpolated into the configuration file string. Does it make more sense to coerce them beforehand in the let expression, or should we just declare them as types.str?

you can use the function toString to convert them: tls_query_padding_blocksize: ${toString cfg.queryPaddingBlocksize}

Should be types.bool, also for subnetPrivate (and update option descriptions accordingly)

And for booleans you can use a simple if cfg.roundRobinUpstreams then "1" else "0"

Is the same as default = defaultUpstream;

When I only specify:

{}: {
services.stubby.enable = true;
}

I get:

error: list index 1 is out of bounds, at /home/joerg/git/nixpkgs/nixos/modules/services/networking/stubby.nix:13:23
(use '--show-trace' to show detailed location information)
make: *** [Makefile:7: test] Error 1
make: Leaving directory '/home/joerg/git/nixos-shell'

Do the default values still work here?

oof! good catch. thanks.