I am trying to get dane and dane-only to work for my smtp client and this 127.0.0.53 is getting in the way because it is the first in my list of DNS servers but does not support DNSSEC
Research
Webmin → Networking → Network Configuration → Hostname and DNS Client → DNS servers:
Global
Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Link 2 (ens3)
Current Scopes: DNS
Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 10.0.0.1
DNS Servers: 127.0.0.53 10.0.0.1
DNS Domain: example.com
My Options
make the DNS server order: 10.0.0.1, 127.0.0.53
remove 127.0.0.53
make systemd-resolve DNSSEC enabled
The Question
What is 127.0.0.53 for, I know you send DNS queries to it and get responses (stub resolver?) but what is it’s purpose on my system and do I need it?
You might have noticed that the rest of this blog post focused pretty much exclusively on desktop use cases. Your server is probably not using a VPN. It’s probably not using mDNS. It’s probably not expected to be able to resolve local hostnames.
Conclusion: most servers don’t need split DNS! Servers do benefit from systemd-resolved’s systemwide DNS cache, so running systemd-resolved on servers is still a good idea. But it’s not nearly as important for servers as it is for desktops.
There are some disadvantages for servers as well. First, systemd-resolved is not intended to be used on DNS servers. If you’re running a DNS server, you’ll need to disable systemd-resolved before setting up BIND or Unbound instead.
Should the virtualmin installer of disabled systemd-resolved ?
I’d probably recommend you not waste time on DNSSEC. It doesn’t really provide any useful security beyond what TLS provides, and TLS is a lot easier to setup and maintain.
You know more than everyone who has answered in this thread so far (other than me, maybe).
You’re correct, this is the default resolver configuration on modern systems. It isn’t weird, it isn’t unusual, it’s not a mystery. It’s usually systemd-resolved, as you note. That’s a caching resolver intended for local use.
Asking if you “need it” is a question only you can answer. You need it if you don’t want to do some work to change the way resolution works on your system. There are many tools that can provide this service (local caching DNS resolution), and you don’t even really need caching local DNS on a server, in a lot of cases, since you’re not going to be doing a lot of time-sensitive DNS requests. Since it’s not a desktop, most things that need DNS are not interactive…a few ms to go out to 8.8.8.8 or 1.1.1.1 probably isn’t going to be noticeable. (Though if you use a lot of APIs that are involved in interactive services, then you should have local caching DNS.)
My main purpose of this is so I can use DANE on Postfix which requires DNSSEC verification.
Postfix is doing local DNS requests for DNSSEC verification but because systemd-resolved is not configured to pass DNSSEC information (by default), DANE verification will always fail so I cannot take advantage of TLSA records on remote domains.
In postfix (as a SMTP client) if I use dane-only (mandatory DANE) emails will always fail when DNSSEC fails or does not get a response, but in the case of dane (opportunistic DANE) which is the default, most peoples emails (definitely on Ubuntu) will fail when a no successful DNSSEC response is received, but fall back to a standard email delivery so in this case noone will actually see an erro r unless they read the logs.
I am currently writing up my notes on this before testing and making a descision on the best way to implement successful DNSSEC locally, there are a few ways.
