trust-dns: init at 0.22.0 #205866
trust-dns: init at 0.22.0 #205866
Conversation
[trust-dns](https://github.com/bluejekyll/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.
|
Result of 1 package built:
|
|
@uninsane hey thanks for the contribution! |
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 |
|
Thanks for coming by so quickly! 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. |
|
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: ***@***.***>
|
|
No rush ! Thanks again for opening this PR ! |
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.orgfor 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:
Description of changes
Things done
sandbox = trueset innix.conf? (See Nix manual)nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)nixos/doc/manual/md-to-db.shto update generated release notes