Description of problem: With DNSSEC validation enabled there is a chicken egg problem especially if you have a system with no hardware clock (Rasperry Pi in my case). You will see error messages like this: Feb 14 18:58:40 raspi.localdomain named[722]: managed-keys-zone: No DNSKEY RRSIGs found for 'dlv.isc.org': success Feb 14 18:58:40 raspi.localdomain named[722]: validating ./NS: got insecure response; parent indicates it should be secure Feb 14 18:58:40 raspi.localdomain named[722]: insecurity proof failed resolving './NS/IN': 2001:4860:4860::8844#53 Feb 14 18:58:40 raspi.localdomain named[722]: validating ./NS: got insecure response; parent indicates it should be secure Feb 14 18:58:40 raspi.localdomain named[722]: insecurity proof failed resolving './NS/IN': 2001:4860:4860::8888#53 Feb 14 18:58:40 raspi.localdomain named[722]: validating ./NS: no valid signature found Feb 14 18:58:40 raspi.localdomain named[722]: no valid RRSIG resolving './NS/IN': 202.12.27.33#53 Feb 14 18:58:40 raspi.localdomain named[722]: validating ./NS: no valid signature found Feb 14 18:58:40 raspi.localdomain named[722]: no valid RRSIG resolving './NS/IN': 192.58.128.30#53 Feb 14 18:58:40 raspi.localdomain named[722]: validating ./NS: no valid signature found DNSSEC is only working if your system has a correct time. But if chrony is not started yet DNSSEC will fail. There is no After or Required entry for chrony in the named.service file. Version-Release number of selected component (if applicable): Version : 9.10.4 Release : 4.P5.fc25 How reproducible: Enable dnssec-validation on Rasperry Pi. DNS will not work. Steps to Reproduce: 1. 2. 3. Actual results: DNS does not work. Expected results: DNS should work. Additional info: You also have to put the NTP servers with IP addresses instead of names in /etc/chrony.conf. There should be these entires in named.service. Similar issue is the aiccu service #1243152 . After=chrony-wait.service Requires=chrony-wait.service This is a general thing. Services which can only start with correct system time should have this specified in their service file.
Hello. While I see your point and agree that this is a bad situation, we could cause more issues with this change, than you may think. The default BIND configuration is to serve as local recursive resolver. This means that it is expected you will have the localhost address in your /etc/resolv.conf. Now NTP can and usually uses host names for time servers. By introducing the dependency on NTP in BIND service file, we would block NTP from resolving host names and thus creating dependency loop. In your use case I would say it is expected to modify the configuration for the specific use case. You can do so e.g. by creating a drop-in configuration for named.service to add this additional dependency. Details are explained in 'systemd.unit' man page.
After talking to the chronyd developer, on systems without RTC you could use the '-s' option for chronyd (by modifying the unit file), which will restore the time from a driftfile. This is necessary to set up only once and it should work fine after that.
I tested with the -s option. This gives an SELinux error because chronyd has no permission to access /etc/adjtime. Here my fix: module my-chronyd 1.0; require { type adjtime_t; type chronyd_t; class file { getattr open read }; } #============= chronyd_t ============== allow chronyd_t adjtime_t:file { getattr open read }; After this is is working but I get errors or warnings like this: Feb 20 20:10:59 raspi.localdomain named[702]: validating de/DNSKEY: got insecure response; parent indicates it should be secure Feb 20 20:10:59 raspi.localdomain named[702]: insecurity proof failed resolving 'de/DNSKEY/IN': 2001:4860:4860::8888#53 Feb 20 20:10:59 raspi.localdomain named[702]: validating dlv.isc.org/SOA: got insecure response; parent indicates it should be secure Feb 20 20:10:59 raspi.localdomain named[702]: validating dlv.isc.org/SOA: got insecure response; parent indicates it should be secure Feb 20 20:10:59 raspi.localdomain named[702]: no valid RRSIG resolving 'de.dlv.isc.org/DS/IN': 2001:4860:4860::8888#53 Feb 20 20:10:59 raspi.localdomain named[702]: validating dlv.isc.org/SOA: got insecure response; parent indicates it should be secure Feb 20 20:10:59 raspi.localdomain named[702]: no valid RRSIG resolving 'heise.de.dlv.isc.org/DS/IN': 2001:4860:4860::8888#53 Feb 20 20:10:59 raspi.localdomain named[702]: insecurity proof failed resolving 'heise.de.dlv.isc.org/DLV/IN': 2001:4860:4860::8888#53 Feb 20 20:11:00 raspi.localdomain named[702]: validating 0.a.2.ip6.arpa/SOA: got insecure response; parent indicates it should be secure Feb 20 20:11:00 raspi.localdomain named[702]: no valid RRSIG resolving '0.e.2.0.2.0.a.2.ip6.arpa/DS/IN': 2001:4860:4860::8888#53 I don't have errors line this when I restart named or when I use my original setup where chronyd has the correct time before named starts. The dependency is what I mean with chicken egg problem. In the scenario I use now I have to put NTP servers with IP addresses in /etc/chrony.conf like this: #pool 2.fedora.pool.ntp.org iburst pool 2a03:aa00::136:55 iburst pool 2001:bc8:2717:100::1 iburst pool 2602:ffa1:200::3 iburst pool 2600:3c00::e:d0bb iburst This is of course not an ideal solution. But the above solution with the -s options also seems to be not ideal because of these validation warnigs. At least you get name resolution at all which I did not have without the -s solution. I guess I will stay with my current config since DNSSEC is working without errors. Only drawback is that I have to configure NTP hosts with IP addresses. BTW: my /etc/resolv.conf looks like this: search localdomain lxcdomain nameserver ::1
The SELinux issue is now tracked in bug #1425466.
This message is a reminder that Fedora 25 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '25'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 25 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
Still valid for any recent version. According to bind-users list answers [1], there is no simple solution for it. Suggested solution offered getting first ntp addresses without dnssec enabled, receiving candidate time. Then enable dnssec validation and retry with this candidate time. If the time was correct, validation will pass and the same set of records should be received also second time. If received addresses differs, just use addresses from validated version. [1] https://lists.isc.org/pipermail/bind-users/2017-December/099319.html
This bug appears to have been reported against 'rawhide' during the Fedora 29 development cycle. Changing version to '29'.
This message is a reminder that Fedora 29 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '29'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 29 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 29 changed to end-of-life (EOL) status on 2019-11-26. Fedora 29 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.