Re: Updated criteria proposal: networking requirements

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Because of attitude documented in change for systemd-resolved [1], I expect the only change to get this improved would be switch from systemd-resolved to anything more DNSSEC friendly. I don't understand why, but it seems systemd team is avoiding working DNSSEC as much as they can. Yet it was fixed ALMOST after change related to original issue #4621 [2], reported 4 years before even the original change in Fedora were started.

I will attempt to prepare a better working alternative for the next release or the one after it.

1. https://fedoraproject.org/wiki/Changes/systemd-resolved#DNSSEC
2. https://github.com/systemd/systemd/issues/4621

On 09. 06. 22 20:32, Adam Williamson wrote:
On Thu, 2022-06-09 at 19:50 +0200, Petr Menšík wrote:
I would propose also ability keep DNSSEC validation passthru. If
infrastructure provides cryptographic records, they should be available
also on the installed host. Without extra modifications.

Ie. if delv @$NS is validated for all network DNS servers, then delv
should validate too. But that would rule out systemd-resolved in current
configuration. delv is a command from bind-utils.

Is that too much to ask?
I would generally be hesitant to make anything that does not currently
work a release criterion. That is effectively requesting development by
the back door. It also seems to sort of go against reality - we are
apparently fine shipping distributions where this doesn't work, because
we've just done it, and there is not an outcry in the press or on
social media (AFAICS) that this doesn't work. That tends to imply we
don't need to block our releases on it.

Basically, if the implied request here is "make it so Fedora really
cares whether dnssec works", I'd kinda suggest that should be a Change
first. If it's accepted as a Change and gets implemented successfully,
then we could maybe consider whether it's a sufficiently important
feature to be release blocking. If we haven't even (as a project)
decided it's a desirable feature and proved we can implement it (that's
what the Change process is for), blocking the release on it seems
rather premature...

--
Petr Menšík
Software Engineer, RHEL
Red Hat, http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux