DNSSEC validation without current time
Hi folks. I am looking for a way to validate name also on systems, where current time is not available or can be inaccurate. This is related to booting with NTP client, when the only configuration is hostname that has to be resolved. There is a bit circle dependencies. First current time is required for DNSSEC validator to verify signatures of all keys. However that is hard to maintain on systems without RTC clock running when it is down. Raspberry PI is example of such system. Until hostname is known, time cannot be synchronized and corrected to real value. They sort of depend on each other. The only secure way I found is to hardcode IP address into NTP client or obtain IP from other trusted source (DHCP?). Available option is of course to disable validation until valid time is received. It seems to me that is unnecessary lowering the security. I would like some option to limit checking validity period of used keys instead. Just validate existing keys from trust anchor and trust the last key that can validate. I think that is far better than no verification at all. Is it possible to do that in BIND? Maybe bootstrap verification could be done only with delv tool with time-checking disabled. I found no way to do that. Is there good reason why it is not available? Is better method for solving secure configuration of timeless system available? -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: 65C6C973 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC validation without current time
Hi there, On Fri, 15 Dec 2017, Petr Men??k wrote: ... current time is not available or can be inaccurate. ntpdate? -- 73, Ged. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC validation without current time
On Fri, Dec 15, 2017 at 12:45:11PM +0100, Petr Menšík wrote: > Hi folks. > > I am looking for a way to validate name also on systems, where current > time is not available or can be inaccurate. I use a Garmin 18x LVC 1pps GPS receiver device connected to RS-232 serial port. The device plus cables cost me $70 altogether, and ntpd works natively with it using the NMEA refclock driver (there's no need of gpsd). It has a 1s PPS signal accurate to 1us. It is accurate to within +/- 100us on Fedora where due to no hardpps kernel support because of tickless kernel, the PPS signal is timestamped and available on /dev/pps0 but the kernel doesn't use it to directly maintain the clock and it has to be done from userland which is affected by the system load. If you were to recompile a kernel that's configured appropriately, I feel the clock can be synchronized to about 1us accuracy. It is more or less reliable and value for $70 if one wants UTC on their computer without accessing the internet. This is more than sufficient for DNSSEC validation and many other network services, and certainly more accurate than using the ntp.org pools. Mukund ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC validation without current time
Petr Menšík wrote: > > This is related to booting with NTP client, when the only configuration > is hostname that has to be resolved. There is a bit circle dependencies. Yes awkward, and there still aren't any convincing answers. One of the more interesting projects is https://roughtime.googlesource.com/roughtime I have not actually tried it out myself or found out if it can be configured with only IP addresses so that it can get the time without the DNS. Tony. -- f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode Southeast Iceland: Variable 3 or 4, but northerly 4 or 5 at first in east. Moderate or rough. Wintry showers, then fair. Good occasionally poor at first.___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC validation without current time
Dne 15.12.2017 v 13:06 G.W. Haywood via bind-users napsal(a): > Hi there, > > On Fri, 15 Dec 2017, Petr Men??k wrote: > >> ... current time is not available or can be inaccurate. > > ntpdate? > Sure, of course. What would be default host after installation, that can be used in default installation image without manual configuration? And how does it resolve that name, when date of the system is 1970-1-1 or something a only a bit more accurate? Current pool.ntp.org adresses are unsigned now, so that would work anyway. If I want spoof protection, what should I do? -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: 65C6C973 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC validation without current time
On 15-Dec-17 06:45, Petr Menšík wrote: > Hi folks. > > I am looking for a way to validate name also on systems, where current > time is not available or can be inaccurate. > > This is related to booting with NTP client, when the only configuration > is hostname that has to be resolved. There is a bit circle dependencies. > First current time is required for DNSSEC validator to verify signatures > of all keys. However that is hard to maintain on systems without RTC > clock running when it is down. Raspberry PI is example of such system. > Until hostname is known, time cannot be synchronized and corrected to > real value. They sort of depend on each other. The only secure way I > found is to hardcode IP address into NTP client or obtain IP from other > trusted source (DHCP?). > > Available option is of course to disable validation until valid time is > received. It seems to me that is unnecessary lowering the security. I > would like some option to limit checking validity period of used keys > instead. Just validate existing keys from trust anchor and trust the > last key that can validate. I think that is far better than no > verification at all. > > Is it possible to do that in BIND? Maybe bootstrap verification could be > done only with delv tool with time-checking disabled. I found no way to > do that. Is there good reason why it is not available? Is better method > for solving secure configuration of timeless system available? > I added an RTC to my Pis :-) It makes life a lot simpler, even after I wrote a driver and calibration mechanism. But if you have access to a DHCP server, have the client request Option 42; this returns one or more NTP servers' IP addresses in preference order. You can use NTPD (or ntpdate) to get a time. ISC DHCP client supports this option; see dhcp-users if you need help. DNSSEC requires reasonably accurate time, as signatures have validity periods. Your scheme would not work; you need time to validate ANY signature - from the trust anchor down. If there's no time, you can't validate any part of the chain - so you might as well use ordinary DNS. NTP is fairly robust; it uses consensus from multiple servers to establish correct time. For a rogue DNS to inject bad time into your PI, it would have to know which NTP servers you are using. Another option is to use DHCP to get the address of a validating resolver, and rely on that for bootstrapping NTP. Again, this depends on whether your control/trust your DHCP server. More ISPs are providing validatiing DNS server, but it's not universal. Hardcoding one of the public ones (e.g. Google - 8.8.8.8, 8.8.4.4, 2001:4860:4860::, 2001:4860:4860::8844) is fairly safe. NTP server addresses are more volatile, and it's a serious breach of netiquette to hardcode them; there are a number of stories of how this has gone badly wrong for all concerned. The choice depends on your requirements, available resources, and risk tolerance. You also need valid time for many other applications; TSIGs require a reasonably close (on the order of minutes) time sync between sender and receiver. So rather than try to tweak NAMED, focus on getting a reasonable time early in boot - and make sure that dependencies on a valid time are properly expressed in your startup scripts. Bottom line: your problem is getting a reasonable time, not with the consumer(s). Timothe Litt ACM Distinguished Engineer -- This communication may not represent the ACM or my employer's views, if any, on the matters discussed. smime.p7s Description: S/MIME Cryptographic Signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Re: DNSSEC validation without current time
On 15-Dec-17 07:44, Mukund Sivaraman wrote: On Fri, Dec 15, 2017 at 12:45:11PM +0100, Petr Menšík wrote: >> Hi folks. >> >> I am looking for a way to validate name also on systems, where current >> time is not available or can be inaccurate. > I use a Garmin 18x LVC 1pps GPS receiver device connected to RS-232 > serial port. The device plus cables cost me $70 altogether, and ntpd > works natively with it using the NMEA refclock driver (there's no need > of gpsd). It has a 1s PPS signal accurate to 1us. It is accurate to > within +/- 100us on Fedora where due to no hardpps kernel support > because of tickless kernel, the PPS signal is timestamped and available > on /dev/pps0 but the kernel doesn't use it to directly maintain the > clock and it has to be done from userland which is affected by the > system load. If you were to recompile a kernel that's configured > appropriately, I feel the clock can be synchronized to about 1us > accuracy. > > It is more or less reliable and value for $70 if one wants UTC on their > computer without accessing the internet. This is more than sufficient > for DNSSEC validation and many other network services, and certainly > more accurate than using the ntp.org pools. > > Mukund > I use an 19xLVC too (On Raspbian == Debian). But I also have an RTC. GPS does have outages, can take a while to get a fix, and NTP wants consensus. So I use my GPS receiver as a local clock source (preferred), but also configure several servers from the pools as a sanity check - and to deal with any GPS outages/slow starts. It's worked well for me. Along those lines, I haven't splurged yet, but Adafruit has an interesting module for ~$40 (US) with a breakout module, ($45 on a Pi Hat - which is cheaper/easier than building your own PCB), which includes a GPS patch antenna. If you need an external antenna, it comes up to about the cost of the Garmin, but draws only 20ma vs. 90, and is a more modern receiver.) On paper it looks good. See https://www.adafruit.com/?q=ultimate%20gps - I'm not affiliated with Adafruit, and while I've looked at the specs, don't have direct experience. YMMV. Enjoy. Timothe Litt ACM Distinguished Engineer -- This communication may not represent the ACM or my employer's views, if any, on the matters discussed. smime.p7s Description: S/MIME Cryptographic Signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC validation without current time
In article , "G.W. Haywood" wrote: > Hi there, > > On Fri, 15 Dec 2017, Petr Men??k wrote: > > > ... current time is not available or can be inaccurate. > > ntpdate? I think the issue is that he needs to resolve the hostname of the NTP server. -- Barry Margolin Arlington, MA ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC validation without current time
On 12/15/2017 08:10 AM, Timothe Litt wrote: I use an 19xLVC too (On Raspbian == Debian). But I also have an RTC. GPS does have outages, can take a while to get a fix, and NTP wants consensus. So I use my GPS receiver as a local clock source (preferred), but also configure several servers from the pools as a sanity check - and to deal with any GPS outages/slow starts. It's worked well for me. Along those lines, I haven't splurged yet, but Adafruit has an interesting module for ~$40 (US) with a breakout module, ($45 on a Pi Hat - which is cheaper/easier than building your own PCB), which includes a GPS patch antenna. If you need an external antenna, it comes up to about the cost of the Garmin, but draws only 20ma vs. 90, and is a more modern receiver.) On paper it looks good. See https://www.adafruit.com/?q=ultimate%20gps - I'm not affiliated with Adafruit, and while I've looked at the specs, don't have direct experience. YMMV. Thank you for sharing info Mukund and Timothe. I suspect I'll be playing over the holidays. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
FYI: zones created using "rndc addzone" could temporarily fail to inherit option "allow-transfer"
We recently received a bug report that newly-added zones (via rndc addzone) were not inheriting the global allow-transfer directive and could be transferred using AXFR by anyone able to access the server to which they had just been added. Further investigation revealed that the circumstances when this might occur are very specific, transient, and unlikely to affect most production environments. However since we're now aware of this defect we decided that it would be in the best interests of our users to share this knowledge so that administrators can judge whether or not they need to be concerned. We assessed the effects of the defect and concluded that it does not meet our policy criteria for handling as a security defect: https://kb.isc.org/article/AA-00861/ It will be fixed in upcoming releases of BIND: 9.12.0, 9.11.3, 9.10.7, 9.9.11 4836.[bug]Zones created using "rndc addzone" could temporarily fail to inherit an "allow-transfer" ACL that had been configured in the options statement. [RT #46603] BIND administrators need only take notice if they are dynamically adding zones to views (including the default view) that are completely empty of zones (no zones via named.conf, and no dynamic zones added earlier) when named is started. The effect of this bug is that when a zone is being added dynamically, named fails to check for and initialize the view option 'allow-transfer' if this had not already been done previously. This would be unusual in most production implementations because view initialization takes place either when named starts up and loads its already-configured zones, or when named processes 'rndc reload' or 'rndc reconfig' control commands for non-empty views. Additionally, if the dynamic zones are added with their own zone-specific 'allow transfer' option, then this option will be properly applied for that zone (but this does not mitigate the bug for any other zones added without a zone-specific ACL). In summary, this defect will only affect you if you: - Start named with no zones at all in some/all views - After named has started, add zones to empty views using 'rndc addzone' - Rely on dynamic zones inheriting the global or view-specific 'allow-transfer' directive rather than specifying it for each zone - Don't afterwards issue 'rndc reconfig' or 'rndc reload', or restart named One further consideration is whether or not it matters that the zones are temporarily available for zone transfer. ISC would like to thank Andrew Parnell at easyDNS and Dave Knight at Snake Hill Labs for bringing this bug to our attention. Sincerely, ISC Support ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
