shell-things/etc/systemd/resolved.conf.d
2020-09-27 14:34:54 +03:00
..
00-everywhere.conf systemd-resolved.conf.d: everywhere -> 00-everywhere 2020-07-24 12:16:31 +03:00
adguard-dot.conf systemd-resolved & unbound: update AdGuard IPs 2020-09-27 14:34:54 +03:00
cloudflare-strict.conf etc/systemd/resolved: add [adguard,cloudflare}-strict.conf 2020-07-18 02:20:56 +03:00
nextdns-compat.conf systemd/resolved.conf.d: add generic NextDNS confs 2020-08-09 00:07:06 +03:00
nextdns-strict.conf systemd/resolved.conf.d: add generic NextDNS confs 2020-08-09 00:07:06 +03:00
quad9-compat.conf etc/systemd-resolved: rework all files more or less 2020-07-04 19:06:18 +03:00
quad9-strict.conf etc/systemd-resolved: rework all files more or less 2020-07-04 19:06:18 +03:00
README.md systemd-resolved.conf.d: everywhere -> 00-everywhere 2020-07-24 12:16:31 +03:00

systemd-resolved additional config files

Files explained

  • 00-everywhere.conf - configuration that doesnt affect DNS servers, attempts to use DNSSEC and DoT and if it fails, doesnt care and uses insecure configuration.
  • quad9-compat.conf - non-tech person config for Quad9, same as above except specifies the server.
  • quad9-strict.conf - tech person config demanding DNSSEC and DoT from Quad9
  • README.md - you are reading it right now.

General commentary

I have moved duplicate comments to this file, so it will possibly look weird or miss original context.

  • Based on my test DNSOverTLS is not supported in Ubuntu 18.04.x LTS (however at the time of writing this README.md, the current version is Ubuntu 20.04.0) (systemd v237). DNSOverTLS became supported in v239, strict mode (yes) in v243 (big improvements in v244).
    • TODO: find out when SNI became supported, I have just spotted it in the fine manual in 2020-06-??.
  • Domains has to be .~ for them to override DHCP. See https://www.internetsociety.org/blog/2018/12/dns-privacy-in-linux-systemd without which I wouldnt have got this right.
  • DNSSEC may not work if the system is down for a long time and not updated. Thus allow-downgrade may be better for non-tech people, even with the potential downgrade attack. There are also captive portals, affecting DNSOverTLS. Both take true or false or their own special option, for DNNSEC the allow-downgrade, for DNSOverTLS opportunistic.

Other links I have found important and my files are based on: