| Summary: | DNSSEC validation is being disabled even if DNS servers are available | ||
|---|---|---|---|
| Product: | IPFire | Reporter: | Peter Müller <peter.mueller> |
| Component: | --- | Assignee: | Peter Müller <peter.mueller> |
| Status: | CLOSED ERRATA | QA Contact: | |
| Severity: | Minor Usability | ||
| Priority: | Will affect an average number of users | CC: | arne.fitzenreiter, fkienker, michael.tremer, stefan.schantl |
| Version: | 2 | Keywords: | Security |
| Hardware: | all | ||
| OS: | All | ||
| See Also: | https://bugzilla.ipfire.org/show_bug.cgi?id=11932 | ||
And? What should we do about it? This was basically the contingency plan instead of disabling DNS resolution. https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=e432689aa99ec262879081fc80161c31b8c4a890 So what do you suggest we would do here? (In reply to Michael Tremer from comment #1) > And? What should we do about it? This was basically the contingency plan > instead of disabling DNS resolution. > > https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff; > h=e432689aa99ec262879081fc80161c31b8c4a890 Yes, I know. The title of this bug is misleading. In my case, DNS nameservers _are_ reachable and provide everything Unbound needs to validate DNS data. So DNSSEC must not be disabled. Further, this issue seems to occur only after a reboot; running "/etc/init.d/unbound restart" solves the problem. > > So what do you suggest we would do here? It seems like we have a bug somewhere so DNSSEC validation is being disabled after rebooting an IPFire installation. Since I am currently looking at the initscript because of mirroring DNS root zones, I will take care of this. Sorry for the confusion. Other people seem to report this, too. Unbound is started _before_ PPPoE ethernet connection is established. Thereof, all DNS nameservers will fail DNSSEC test since they are unreachable. Since DNS root servers aren't reachable, either, this will cause to render DNSSEC validation unusable. We should start Unbound _after_ ppp0 came up. @Michael: Comments? How to do this? No, this is correct. We do want DNS resolution when RED is not up (yet). Of course the check fails, but there is a flag that skips them. (In reply to Michael Tremer from comment #5) > No, this is correct. We do want DNS resolution when RED is not up (yet). Of > course the check fails, but there is a flag that skips them. Hmmmm, but since this issue is ocurring since a few weeks, I guess someting must have been changed sometimes. :-\ This used to work for years. Some quick notes: Nov 9 16:10:49 firewall root: unbound initscript: called update_forwarders() Nov 9 16:12:04 firewall root: unbound initscript: called update_forwarders() Nov 9 16:12:25 firewall root: unbound initscript: called update_forwarders() Nov 9 16:12:25 firewall root: unbound initscript: first if passed Nov 9 16:12:55 firewall root: unbound initscript: forwarders: Nov 9 16:12:55 firewall root: unbound initscript: broken forwarders: [upstream DNS 1] [upstream DNS 2] Nov 9 16:16:10 firewall root: unbound initscript: dnssec disabled The delay between the last two log lines is interesting... Some detailled research indicates all nameservers are considered unreachable by test_name_server() in /etc/init.d/unbound : Nov 9 16:23:15 firewall root: unbound initscript: called update_forwarders() Nov 9 16:24:30 firewall root: unbound initscript: called update_forwarders() Nov 9 16:24:52 firewall root: unbound initscript: called update_forwarders() Nov 9 16:24:52 firewall root: unbound initscript: first if passed Nov 9 16:24:52 firewall root: unbound initscript: test_name_server() : [upstream DNS 1] Nov 9 16:25:07 firewall root: unbound initscript: test_name_server() : [upstream DNS 2] Nov 9 16:25:22 firewall root: unbound initscript: forwarders: Nov 9 16:25:22 firewall root: unbound initscript: broken forwarders: [upstream DNS 1] [upstream DNS 2] Nov 9 16:28:37 firewall root: unbound initscript: dnssec disabled Hm, is traffic from firewall|RED allowed at this time? At no time we have any firewall rules out there that won't allow the firewall to talk to RED. What you might be missing here is the default route... In outgoing firewall rules, DNS traffic is limited to the upstream DNS servers (and port 53 TCP & UDP) I have in use. Recently, I changed the allowed source to the RED interface of the firewall (previous, it was "all") - a change which slipped my mind. After setting the source back to "firewall|all interfaces", DNSSEC validation works after a reboot. I assume this is a bug somewhere else then, which prevents traffic to RED under certain circumstances. This ticket is ERRATA, and will be closed in favour of a new one concerning the mentioned bug. I do not think that a new ticket is needed. Should we consider to always open the firewall for the DNS servers to make it impossible that a user accidentially blocks access and prevents the checks from running? Sounds like a sensible solution for me. (In reply to Michael Tremer from comment #11) > I do not think that a new ticket is needed. I would prefer a new one, as the problem was supposed to be somewhere at the Unbound stuff. It seems reasonable to me that the underlying problem (somehow outgoing packets are dropped in early machine state) has some other side-effects, and so I would like to see this in a completely new ticket. If you do not mind, I will close this anyway - in fact, the new ticket is already opened. :-) > > Should we consider to always open the firewall for the DNS servers to make it > impossible that a user accidentially blocks access and prevents the checks > from > running? Sounds like a sensible solution for me. I am not sure about this. In case static upstream nameservers are set, I am completely fine and think of it as a very helpful feature. If nameservers are assigned via DHCP or something similar, this would allow implicit control of outgoing firewall rules, which sounds bad. (In reply to Peter Müller from comment #12) > (In reply to Michael Tremer from comment #11) > > I do not think that a new ticket is needed. > I would prefer a new one, as the problem was supposed to be somewhere at the > Unbound stuff. It seems reasonable to me that the underlying problem > (somehow outgoing packets are dropped in early machine state) has some other > side-effects, and so I would like to see this in a completely new ticket. Tickets can be renamed... But since you already opened a new one, this is moot. > If you do not mind, I will close this anyway - in fact, the new ticket is > already opened. :-) > > > > Should we consider to always open the firewall for the DNS servers to make it > > impossible that a user accidentially blocks access and prevents the checks > > from > > running? Sounds like a sensible solution for me. > I am not sure about this. In case static upstream nameservers are set, I am > completely fine and think of it as a very helpful feature. If nameservers > are assigned via DHCP or something similar, this would allow implicit > control of outgoing firewall rules, which sounds bad. True, but the other option would be to disable DNSSEC which is worse. Or... just a thought... we never use the name servers from the ISP. But then I don't know what would be a good default... Core 124 connecting via DHCP on RED with DNS set via the web interface page Assign DNS-Server. Post upgrade to core 125, after a restart, home page shows unbound in local recursor mode. Going to the Assign DNS-Server page, it displays the correct DNS server IP numbers. Clicking on the Save button corrects the problem and after unbound restarts, the correct DNS server IPs are displayed on the home page. Its a minor issue, but the fix may elude many of the less technical users. (In reply to Fred Kienker from comment #15) > Core 124 connecting via DHCP on RED with DNS set via the web interface page > Assign DNS-Server. > > Post upgrade to core 125, after a restart, home page shows unbound in local > recursor mode. > Going to the Assign DNS-Server page, it displays the correct DNS server IP > numbers. > Clicking on the Save button corrects the problem and after unbound restarts, > the correct DNS server IPs are displayed on the home page. > > Its a minor issue, but the fix may elude many of the less technical users. Yes. However, this issue is a different one so I am closing it. Please open another issue, if necessary. |
I observer warning messages ("DNSSEC has been disabled") on several system since a few days (this might had occurred before, but I did not notice it). However, in both cases upstream DNS servers support validation, so this should not happen. DNS root servers are not directly accessible (filtering outgoing connections), which was not an issue in the past, either. A system behind such a firewall is sometimes able do resolve "dnssec-failed.org", sometimes not. At the moment, further details are unavailable, but need to investigated later on. This is a security risk.