I would like to request pausing any new systemd-resolved features
system-wide, until its current bugs and deficiencies are resolved
sufficiently.
And no, repeating that non-sense again, saying DNSSEC is only the server
stuff nobody needs on desktop, would not count as fixed bug.
Every TLS endpoint needs certificate. DNS has also signatures on zone
data, which should be verified even over encrypted channel.
Visit [1] to read more about difference between the two terms. And how
they go along each other.
In our view, current systemd-resolved has brought many regressions into
F33. Let's wait with its new features, users can enable DNS over TLS any
time already. Fix please years old issues first.
1.
https://blog.apnic.net/2018/08/20/dnssec-and-dns-over-tls/
Best Regards,
Petr
On 9/29/20 10:29 PM, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/DNS_Over_TLS
== Summary ==
Fedora will attempt to use DNS over TLS (DoT) if supported by
configured DNS servers.
== Owner ==
* Name: [[User:catanzaro|Michael Catanzaro]]
* Email: <mcatanzaro(a)redhat.com>
* Name: [[User:Zbyszek|Zbigniew Jędrzejewski-Szmek]]
* Email: <zbyszek(a)in.waw.pl>
== Detailed Description ==
We will build systemd with `-Ddefault-dns-over-tls=opportunistic` to
protect DNS queries against passive network attackers. An active
network attacker can trivially subvert this protection, but we cannot
make DoT mandatory because other operating systems do not do so and
many (or most?) DNS servers do not support it. DoT will only be used
if the configured DNS server supports it and if it is not blocked by
an active network attacker.
Note that DoT is different from DNS over HTTPS (DoH). In particular,
DoT is not an anti-censorship tool like DoH. It does not look like
regular HTTPS traffic, and it can be blocked by network administrators
if desired, so it should not be a problem for corporate networks.
== Benefit to Fedora ==
DNS queries are encrypted and private by default, if the user's ISP
supports DoT. Most probably don't, but users who manually configure a
custom DNS server (e.g. Cloudflare or Google) will automatically
benefit from DNS over TLS.
== Scope ==
* Proposal owners: change meson flags in systemd.spec
* Other developers: N/A (nothing should be required)
* Release engineering: [
https://pagure.io/releng/issue/9772 #9772] (a
check of an impact with Release Engineering is needed)
* Policies and guidelines: N/A (nothing should be required)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: Nope
== Upgrade/compatibility impact ==
DoT will be enabled automatically on upgrade to F34. If DoT is
unsupported, systemd-resolved will fall back to unencrypted DNS, so
there should be no compatibility impact.
== How To Test ==
Load any website in a web browser. If you succeed, then name
resolution probably works.
Try using `resolvectl query fedoraproject.org` to see that resolvectl
still works.
Bonus points: set your DNS server to 1.1.1.1 or 8.8.8.8, then use
Wireshark to see if your DNS is really encrypted or not.
== User Experience ==
Users should not notice any difference in behavior.
== Dependencies ==
No dependencies.
== Contingency Plan ==
* Contingency mechanism: revert the change
* Contingency deadline: can be done at any time, before F34 beta
freeze would be best
* Blocks release? No
* Blocks product? No
== Documentation ==
See the section `DNSOverTLS=` in the manpage `resolved.conf(5)`
== Release Notes ==
systemd-resolved now enables DNS over TLS (DoT) support by default, in
opportunistic mode. DoT will be used only if supported by your DNS
server, and provides only best-effort encryption to protect against
passive network observers. For compatibility with existing DNS
servers, systemd-resolved will fall back to unencrypted DNS if DoT
does not appear to be supported, reducing the security benefit. If you
wish to manually configure systemd-resolved to prevent fallback to
unencrypted DNS, set `DNSOverTLS=yes` in `/etc/systemd/resolved.conf`.
Note that DoT is different than DNS over HTTPS (DoH) in that it does
not use HTTPS and is therefore easy to distinguish from HTTPS traffic.
--
Petr Menšík
Software Engineer
Red Hat,
http://www.redhat.com/
email: pemensik(a)redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB