[Feature request][resolved] Resolved configuration for custom DNS records ?

[yw662]

Describe the solution you'd like
Since resolved is a DNS cache server, it should be able to define its own DNS records and rules. However we can now only define those records through /etc/hosts, which is not capable for all kind of records, like CNAME.

Describe alternatives you've considered
There should be a rule set or record set configuration in resolved.conf or somewhere.

[poettering]

Hmm, so you want /etc/hosts but for all RR types? And only honoured for local resolution?

[yw662]

Maybe not /etc/hosts but the configuration for a real DNS server, and it is not only local resolution, but also for VM and containers inside, and, you know, the extra stub.

[vlada-dudr]

Could be nice to pair it with DHCP, so networkd can pass the hostnames obtained via DHCP requests to resolved, or static leases could be configured with hostnames which can be in turn added to resolved.

Or it could be good for local development stuff, when it is convinient to redirect dns in more elaborate way then just by single hostnames.

[itoffshore]

Custom DNS records would be also be nice for custom MX records for mail servers that are not publicly available (& are only available over a wireguard VPN)

People who self host often protect their infrastructure in this manner nowadays.

[vlada-dudr]

Yeah, but if you don't have public MX you receive no mail... I can imagine some non-A records might be useful while developing something using them. Or if one would be using resolved as main "resolver" in a network. Or as DNS "router" with some ad-hoc overrides? Is it even good idea to run a network like that?

[itoffshore]

@vlada-dudr - Various DNS records are useful internally for services on non public ip's (that provide non public services for your infrastructure)

[vlada-dudr]

Yeah, but that seems to be out of scope of resolved. I am not part of the team though

[pwithnall]

For implementing web filtering for parental controls in the desktop, we’re currently providing our own NSS module which filters requests to a sinkhole if they’re blocked, and passes them through to the next NSS module otherwise.

If resolved provided a way to load custom DNS records on a per-user basis (that would probably mean some external configuration tying each user to a different routing domain), and supported A, AAAA and CNAME records (for redirecting to a sinkhole, and redirecting to a safe domain, e.g. www.youtube.com → restrict.youtube.com, respectively), then malcontent could probably drop its NSS module and just have a config orchestration component instead. Dropping our NSS module would mean lower resource usage across all processes which use the NSS name resolver.

Feel free to say this doesn’t fit in with what you want systemd-resolved to do! Our NSS module is working well for what we need. I just thought I’d mention in case it does fit in well with people’s eventual ideas for this feature request.

[itoffshore]

I've had a bit of a DNS journey since my comment above.

• I include here some ideas for how I solved my DNS / Mail problems (I wanted reliable & HA)
• I tried a whole bunch of DNS servers in rootless podman (the below + technitium / NSD)
• Technitium in Linux triggers LKRG (Linux Kernel Runtime Guard)

---

Knot DNS in rootless podman (as Authoritative custom DNS)

• Knot has a nice client knotc for adding records. Their documentation is excellent. Security is very good with zone transfers over mutual tls & automatic acl

• Knot DNS works really well with systemd-networkd && resolved (on remote secondaries) - I never had a single issue (running under OpenSUSE Micro OS) - except if the primary broke. I configured the Knot secondaries to also write DNS records to disk to be more resilient

• resolved & NetworkManager + Knot DNS as primary at home was a bit more problematic occasionally (but often enough to be annoying) :

  • I run the containers over a netbird vpn (& bound to it's interface) - to provide private internal DNS to my infrastructure

  • Netbird uses eBPF to intercept DNS queries & this possibly interferes with NetworkManager

  • resolved => unbound (as forwarder) => Knot DNS (primary) runs really well

  • unbound + valkey (open source redis) - is also good (valkey is optional)

  • Having caches in resolved & unbound means dns is always fast at home

  • With unbound + valkey lookups will be fast on boot too

---

There was a bit of a learning curve - but still a useful exercise

• The above setup has been reliable for a few months now.
• Proper MX records for your relays makes postfix a bit more HA (it retries each MX record in turn as per rfc)
• Alpine Linux based images are a very good choice
• scratch images if you need more security