trust-dns: init at 0.22.0

[uninsane]

trust-dns is a Rust-based DNS client/server/resolver. the server uses .zone files that are largely compatible with bind. i've had a server deployed to ns{1,2}.uninsane.org for about a week using this derivation: seems to be stable enough for casual use.

this package also ships a DNS client and a resolver. BIND also ships a dig-like client but lives in pkgs/servers/dns. so i'm replicating that convention.

example use:

$ nix build '.#trust-dns'
# fetch example zone and config
$ wget https://raw.githubusercontent.com/bluejekyll/trust-dns/main/tests/test-data/named_test_configs/example.com.zone
$ wget https://raw.githubusercontent.com/bluejekyll/trust-dns/main/tests/test-data/named_test_configs/include.example.com.zone
$ wget https://raw.githubusercontent.com/bluejekyll/trust-dns/main/tests/test-data/named_test_configs/ipv4_only.toml
$ ./result/bin/named --config ipv4_only.toml --zonedir . --port 1053
# in a different shell, query the nameserver
$ dig @127.0.0.1 -p 1053 alias.example.com
# ...
;; ANSWER SECTION:
alias.example.com.	86400	IN	CNAME	www.example.com.

;; ADDITIONAL SECTION:
www.example.com.	86400	IN	A	127.0.0.1
;; Query time: 0 msec
;; SERVER: 127.0.0.1#1053(127.0.0.1) (UDP)

Description of changes

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 23.05 Release Notes (or backporting 22.11 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
  • (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes
• Fits CONTRIBUTING.md.

[mattmelling]

Result of nixpkgs-review pr 205866 run on x86_64-linux 1

1 package built:

• trust-dns

[NickCao]

Tested building and running resolve example.com

[happysalada]

@uninsane hey thanks for the contribution!
I couldn't help but notice you have a nice nixos module to run this on your instance, would you want to contribute it to nixpkgs ?
There would be a couple of changes (like testing DynamicUser for example), but I would be happy to help you test.

[uninsane]

I couldn't help but notice you have a nice nixos module to run this on your instance, would you want to contribute it to nixpkgs ?

this module? i'm open to upstreaming whatever in there makes sense. i'd be hesitant to push the zone file generation code into nixpkgs for a few reasons (*), but perhaps upstreaming the systemd service (after hardening) along with a more literal translation of the options that generate the trust-dns config file, e.g.:

options.services.trust-dns = {
  enable = ...;
  package = ...;
  settings = submodule {
    freeformType = toml.type;   # toml = pkgs.formats.toml { };
    options = {
      # mention a few of the most common options here.
      # since this is a freeform type the user can put anything they might want in trust-dns's config.toml here whether mentioned or not.
      listen_addrs_ipv4 = ...;
      listen_addrs_ipv6 = ...;
      listen_port = ...;
      log_level = ...;  # enum, default: INFO. would replace the `quiet` flag i use today
      zones = mkOption {
        type = listOf (submodule {
          options = {
            zone = ...;  # string (DNS name)
            zone_type = ...; # enum, default "Primary"
            file = ...; # path to a user-supplied .zone file
          };
        });
      };
    };
  };
};

@happysalada would you be happy with something shaped more like the above, at least as a starting point? (*) i don't want to move the zone generation into nixpkgs because i'm not 100% happy with the ergonomics of my own implementation, plus it's a file format shared by things like BIND so would ideally be factored out of the specific service somehow (maybe a pkgs.formats.zone someday?).

[happysalada]

Thanks for coming by so quickly!
Yeah i meant this module.
I agree with what you are proposing plus hardening, that seems like a great first step. The other thing we would have is to give nice defaults.
Some modules also have a step by step documentation, that would be amazing, willing to make some proposals there that you can modify. The idea being that someone without too much prior knowledge would be able yo run his own dns resolver.

I understand regarding the zone format. To be honest just having a service is a huge first step that also make it easy for people to suggest ideas.

Available anytime for review / test/ and documentation suggestions.

[uninsane]

alright, i’ll factor out something like the above into a PR as i find time for it, sometime in the next few weeks :)On Jun 5, 2023, at 01:20, Yt ***@***.***> wrote: Thanks for coming by so quickly! Yeah i meant this module. I agree with what you are proposing plus hardening, that seems like a great first step. The other thing we would have is to give nice defaults. Some modules also have a step by step documentation, that would be amazing, willing to make some proposals there that you can modify. The idea being that someone without too much prior knowledge would be able yo run his own dns resolver. I understand regarding the zone format. To be honest just having a service is a huge first step that also make it easy for people to suggest ideas. Available anytime for review / test/ and documentation suggestions. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[happysalada]

No rush ! Thanks again for opening this PR !