No hard opinion, but I'd probably put tools for zone-file generation separately, as they could be used more universally (typically in other DNS servers).

🤔 though perhaps I'm personally still unclear why

{ name = "ns"; value = "192.168.1.1"; }

seems easier than

"ns A 192.168.1.1"

(using interpolations if need be)

No hard opinion, but I'd probably put tools for zone-file generation separately, as they could be used more universally (typically in other DNS servers).

Where would you put it?

thinking though perhaps I'm personally still unclear why

{ name = "ns"; value = "192.168.1.1"; }

seems easier than

"ns A 192.168.1.1"

(using interpolations if need be)

The idea was to abstract away the implementation details (aka. zone file).
This way:

• the user can rely on nix, rather than reading through the zone-file specs before setting up a DNS server
• the user input can be type-checked

Reasoning on why not nix A 192.168.1.1

• As a user i wouldn't be sure if this implies a leading whitespace or not.
• As a user i'd have to check the file specs to see if it's possible to mix Tabs/Spaces, and check the module source to see which one is used

Also: This format works quite nicely with more complex setups, e.g.:

  records = map # add default type (not required since it's already A)
    (x: x // { type = "A"; }) [
    { name = "toaster"; value = "10.0.3.1"; }
    { name = "localnews"; value = ip; }
    { name = "router"; value = ip; }
    { name = "ns"; value = ip; }
  ] ++ # reserved devices (aka poor man's zeroconf)
  map (x: { name = x.hostName; value = x.ipAddress; }) machines;

the user input can be type-checked

I'd rather have the zone checked by a DNS server (during build time of the configs).

Overall it's perhaps a personal preference of not introducing yet another format unless there's some significant benefit, but I might be a little biased due to knowing the zonefile format (though I know lots of nix as well).

Also: This format works quite nicely with more complex setups

I'm not sure whether it's such a big difference; I think nix is quite good with string manipulation, though perhaps those functions are a little more cumbersome:

lib.concatMapStringsSep "\n" (x: "${x.hostName} A ${x.ipAddress}")

the user input can be type-checked

I'd rather have the zone checked by a DNS server (during build time of the configs).

The DNS server still checks the format, this merely adds an additional check during compile-time (to prevent failure upon deployment).

Overall it's perhaps a personal preference of not introducing yet another format unless there's some significant benefit, but I might be a little biased due to knowing the zonefile format (though I know lots of nix as well).

Also: This format works quite nicely with more complex setups

I'm not sure whether it's such a big difference; I think nix is quite good with string manipulation, though perhaps those functions are a little more cumbersome:

lib.concatMapStringsSep "\n" (x: "${x.hostName} A ${x.ipAddress}")

I guess you are right, it's a matter of preference, everyone can easily write his/her own zone-file generator on a per-project basis.

To add a comparison of the two configuration methods (both would be possible after the change):

{
  name = ".";
  file =
    let
      enries = [
        { name = "ns"; value = "192.168.1.1"; }
        { name = "webserver"; value = "192.168.1.1"; }
      ];
      primary_name = "ns.example.org";
      mail = "admin.example.org";
    in
      pkgs.writeText "root.zone" ''
        $TTL 3600
        . IN SOA ${primary_name}. ${mail}. ( 1 8h 2h 4w 1d )
        . IN NS ${primary_name}.
        ${lib.concatMapStringsSep "\n" (x: "${x.name} A ${x.value}") entries}
      '';
}

{
  name = "example.org";
  file = {
    serial = 1;
    name_primary = "ns"; # default value - not required
    owner = "admin.example.org"; # default generated value - not required
    records = [
      { name = "ns"; value = "192.168.1.1"; }
      { name = "webserver"; value = "192.168.1.1"; }
    ];
  };
}

Note: this is pseudo code (aka i didn't run it)

No hard opinion, but I'd probably put tools for zone-file generation separately, as they could be used more universally (typically in other DNS servers).

Where would you put it?

Probably somewhere inside the lib attribute (i.e. lib/*.nix), but I don't know if there would be consensus about it in the community. It's true it seems way more specific than what I see in there now. It could e.g. get moved there later after something like this PR gets merged.

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

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