Bug 1424719 - DNSSEC validation does not work if time is set incorrectly (e.g. on system without RTC)
Summary: DNSSEC validation does not work if time is set incorrectly (e.g. on system wi...
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: bind
Version: 29
Hardware: armv7hl
OS: Linux
unspecified
low
Target Milestone: ---
Assignee: Petr Menšík
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-02-18 17:27 UTC by Frank Ansari
Modified: 2019-11-27 19:34 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-11-27 19:34:16 UTC
Type: Bug


Attachments (Terms of Use)

Description Frank Ansari 2017-02-18 17:27:04 UTC
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.

Comment 1 Tomáš Hozza 2017-02-20 11:39:32 UTC
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.

Comment 2 Tomáš Hozza 2017-02-20 11:49:12 UTC
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.

Comment 3 Frank Ansari 2017-02-20 19:30:17 UTC
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

Comment 4 Miroslav Lichvar 2017-02-21 13:52:45 UTC
The SELinux issue is now tracked in bug #1425466.

Comment 5 Fedora End Of Life 2017-11-16 19:38:48 UTC
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.

Comment 6 Fedora End Of Life 2017-12-12 10:17:36 UTC
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.

Comment 7 Petr Menšík 2018-03-28 14:29:06 UTC
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

Comment 8 Jan Kurik 2018-08-14 11:00:41 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 29 development cycle.
Changing version to '29'.

Comment 9 Ben Cotton 2019-10-31 20:39:22 UTC
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.

Comment 10 Ben Cotton 2019-11-27 19:34:16 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.