Change:
Describe the bug the unbound config is sensitive to key ordering, but nix is not. this breaks when the nix order differes from the order unbound expects, eg for /. this may affect other combinations as well. To Reproduce configure unbound with access control using tags, eg Screenshots Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
I'm not sure how we could solve this. How about adding a specific option for ?
sounds reasonable. had a cursory glance at the config man page and haven't found any dependencies like that listed there (not any others--any!). we might just have to react as things break :(
I'll open a PR then.
If should always be possible to do something like this if you need a specific ordering of keys (untested)
ping
that does work, it's what we had before as a quick get-it-running-again after the rfc42 update of the module. tried to turn it into proper settings as was intended by the makers, and stuff promptly broke. :D
It's totally fine that unbound is a freeform module and the benefits outweigh the drawbacks by far. Acutally I think this might even be worth an upstream bugreport, because having the order matter in a config file is almost always bad UX.
definitely true, but a look at the unbound config parser suggests that this won't be changing quickly. while their config does look like yaml it definitely isn't. on the flip side, seems to be the only option needing such special treatment in nix.
I ran into an issue where putting a 'forward-zone' before 'server' in settings upsets unbound.
I ran into this issue for domain-insecure, local-zone, and local-data when they appeared before server. Interestingly, I don't have this issue with forward-zone. In my previous working config these were after and worked in that position but don't work here where they're placed before . I've confirmed that the lines themselves are character-for-character identical. It seems like server should also be hardcoded to come first
would indeed do that.
What you are describing is a different issue and stems from wrong configuration on your end. You will have to nest your within inside the settings. I think the module should run  on the generated config to catch these errors at build time.
The is an entirely different clause than the clause, according to , and shouldn't be specified in it, contrary to what you suggested. As for running at build time, it has been discussed and in above comments.
Yeah in my case it wasn't forward-zone causing any issues. The other zones were as I said character-for-character identical (including indentation) to a working version and the only difference was the ordering. Great to see that it's getting fixed as well

Discussion:
)) else throw (traceSeq v "services.unbound.settings: unexpected type"); <del> confFile = pkgs.writeText "unbound.conf" (concatStringsSep "n" ((mapAttrsToList (toConf "") cfg.settings) ++ [""])); </del> <ins> confNoServer = concatStringsSep "n" ((mapAttrsToList (toConf "") (builtins.removeAttrs cfg.settings [ "server" ])) ++ [""]); confServer = concatStringsSep "n" (mapAttrsToList (toConf "  ") (builtins.removeAttrs cfg.settings.server [ "define-tag" ])); confFile = pkgs.writeText "unbound.conf" '' server: ${optionalString (cfg.settings.server.define-tag != "") (toOption "  " "define-tag" cfg.settings.server.define-tag)} ${confServer} ${confNoServer} ''; </ins> rootTrustAnchorFile = "${cfg.stateDir}/root.key";

# prevent race conditions on system startup when interfaces are not yet # configured ip-freebind = mkDefault true; <ins> define-tag = mkDefault ""; </ins> }; remote-control = { control-enable = mkDefault false;