On Mon, 28 Sep 2020, Lennart Poettering wrote:
stuff that doesn't come from classic Internet DNS cannot possibly be DNSSEC validated.
This statement is incorrect. Please read RFC 8598 and perhaps read up on the handling of Special Use Domain Names and DNSSEC validation. No one expects .local to be signed. This is not an actual problem. You are not unique. Participate at the IETF, write and implement new RFCs that fix your current issues.
If you expect a full blown DNS server on port 53 then it's not what systemd-resolved is or strives to be.
For non-local queries, that is exactly what applications expect and depend on.
So far we side-step the DO issue by returning a clean error when clients set DO: "not implemented"
That is not what I see: paul@thinkpad:~)$ dig +dnssec nohats.ca @127.0.0.53 ; <<>> DiG 9.11.22-RedHat-9.11.22-1.fc33 <<>> +dnssec nohats.ca @127.0.0.53 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6543 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 I get NOERROR, so you should file another systemd-resolved bug report if the expected behaviour was NOTIMP. But even so, DNS libraries getting NOTIMP will just try to go to the next server listed in resolv.conf but there is only 127.0.0.53, so it fails. So you do not "side step" this issue at all. Implementing NOTIMP will change nothing.
, plus a log message in syslog with more info. I'd argue that for the vast majority of users this is perfectly enough.
This is again redefining the use cases and pre-selecting the type of users you wish to support and punting everything not in your use case to the "you are the advanced user, you know how to work around this". I was an enduser with a laptop dead in the water. It did not matter how advanced I am or not. It should not happen, and the fix is not for me to read syslog messages, google for documentation and then manually fix my system. My system should not break.
Because IRL client-side DNSSEC doesn't really exist outside of some very specific circles of DNS nerds, I guess. Yes, I dare to suggest that for your typical GNOME/Fedora Workstation it really doesn't matter.
This is a very outdated view.
I understand that some people want DNSSEC/DO stuff work client side just like that, and as mentioned we'll add that, but let's not pretend this was "obvious" and without pitfalls of its own.
I told you five years ago in Brno at a meeting organized to specifically talk about DNSSEC at the client side these exact same things. Let's not pretend I and others did not raise these issues then already.
I understand some loud people here consider Internet DNS the true gospel, and mDNS and LLMNR and all kinds of other forms of popular name resolution, local and remote heresy
As I suggested in previous emails, stop inventing your personal wheel and go get informed at the IETF about work being done in this space by the main vendors. I've listed the working groups, the drafts and the vendors. Raise any issues you think you have with respect to mDNS, LLMNR and what not. Work with others to define a functional protocol and implementation. Then push it first in fedora and I will happilly be dead in the water and report bugs and submit patches.
Until we implement the DO-bypass stuff
It is not acceptable to break all f33+ and rhel9/centos9 servers "until you implement" whatever it is you need to implement to violate 15+ year old DNS RFCs at the low priority you assign this bug baesd on your selective use cases. This will be my last email in this thread. Paul _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
