Re: 2038 problem and BIND.
On 9/19/2010 6:57 AM, kalpesh varyani wrote: I would just like to know, how BIND takes care of the 2038 problem. Since now DNSSEC has a lot to do with timings, there could be issues if someone would set the signature expiry time to a large value (possibly after Y2K38). This can create problems, if care is not taken in BIND code. Or does BIND code is designed so that it relies on the OS to deal with this problem? Note that signature expiration times are used to protect from replay attacks. If you are signing zones with expiration dates 28 years in the future, you may want to consider if this is a good idea or not. All signature expire times are in MMDDHHMMSS format in the zone data and are handled correctly as far as BIND deals with it. If your OS deals with the 2038 issue correctly, then BIND will as well. I do also assume that there will be a few BIND releases between now and then and that you will be upgrading accordingly. AlanC signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: 2038 problem and BIND.
On Mon, 20 Sep 2010, Alan Clegg wrote: All signature expire times are in MMDDHHMMSS format in the zone data and are handled correctly as far as BIND deals with it. If your OS deals with the 2038 issue correctly, then BIND will as well. RFC 4034 says that the signature validity times are unsigned 32 bit whereas time_t is typically signed. The error that kalpesh varyani pointed out looked to me like bind was treating the expiry time as signed 32 bit. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7, DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR ROUGH. RAIN THEN FAIR. GOOD. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: NSEC3 salt lifetime (and some other DNSSEC params): sane value?
Date: Mon, 20 Sep 2010 11:03:31 +0200 From: Kalman Feher kalman.fe...@melbourneit.com.au Sender: bind-users-bounces+oberman=es@lists.isc.org Apologies in advance for the longer than intended reply. I've spent a lot of time reviewing documents regarding timing values and they vary quite widely. One observation I've made is that many recommendations, especially those that are a little older, are predicated on the assumption that the process of signing is difficult and complicated. So last year I saw recommendations of ZSKs for a year and KSKs for 2 or more. As signing became easier and TLDs made their submission policies for DS (or pub key) clearer these numbers have dropped. I'm now seeing recommendations of 1-3 months for ZSKs and 6-12 months for KSKs. The advice on this has always been all over the map, but the most common recommendation I have seen, and I have been seeing it for years, is to roll ZSKs about once a month and KSKs annually. I recommend anyone attempting to secure their DNS read the NIST Computer Security Resource Center document SP800-81 Rev.1, Secure Domain Naming System (DNS) Guide at: http://csrc.nist.gov/publications/nistpubs/800-81r1/sp-800-81r1.pdf It recommends rolling th KSK every 12 to 24 months and the ZSK every 1 to 3 months. These values are unchanged from the original SP800-81 issues back at least two years ago and probably three. Everyone I have spoken with who works with crypto feels that, barring a math breakthough, these numbers are VERY conservative. I might also mention that US government system are required to follow the recommendations of SP800-81r1. If you automate it, which is relatively easy today, then having shorter times makes sense on a number of levels. -It allows potentially lower bit sizes, due to the time/size trade off. -It ingrains the process within your operational procedures. Really large gaps between events can lead to a loss of skills or capability. (has anyone seen that HSM we bought 2 years ago?). That may or may not happen of course, but its good to exercise procedures. -You can use roll over times as natural change windows for new algorithms or new procedures. And the likelihood of changes in the next 2 years is very high since registries are still adapting and learning. I can see no point in the use of lower bit size keys. Current systems are able to deal with the sizes now in use. Shortening keys simply weakens the system. I agree with your concern with long intervals between signing. Blowing a key roll is a really unpleasant things and will get more so as more and more servers start doing validation. The value of the above benefits will vary depending on how many domains you have across how many different TLDs. The more of either, the greater the benefit of an automated and reasonably regular roll over. Good advice! Online/offline keys Sometimes this may be a choice, other times legislative or standards compliance will require certain behaviour. I've seen some documents require that even ZSKs remain offline (government agencies mostly), but generally its not considered much benefit if it rolls over reasonably often. KSKs are more commonly recommended to remain offline, but that definition can vary as well. A genuine HSM (Hardware Security Module), is not likely to be found in the bulk of DNSSEC deployments, due to cost, complexity and operational staff skills. Thus most operations will find it easier to generate keys either on the master server (perhaps the only server with key generating software) or close by (another server that is nevertheless online). If you don't use an offline HSM, then your alternatives will require you to have shorter roll over times in my opinion. HSMs are the way to go...if you can afford them. Prices vary a LOT from expensive to WOW! (So does functionality, and DNSSEC will typically take very little.) Because of dynamic DNS requirements, keeping the private ZSK on-line is allowed, even for government sites, though ONLY in cases where dynamic DNS is used or the back-end DNS management system requires it. Government sites may not keep the KSK on-line. See SP800-81r1 Section 9.4 for details. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: NSEC3 salt lifetime (and some other DNSSEC params): sane value?
On 20/09/10 6:09 PM, Kevin Oberman ober...@es.net wrote: Date: Mon, 20 Sep 2010 11:03:31 +0200 From: Kalman Feher kalman.fe...@melbourneit.com.au Sender: bind-users-bounces+oberman=es@lists.isc.org Apologies in advance for the longer than intended reply. I've spent a lot of time reviewing documents regarding timing values and they vary quite widely. One observation I've made is that many recommendations, especially those that are a little older, are predicated on the assumption that the process of signing is difficult and complicated. So last year I saw recommendations of ZSKs for a year and KSKs for 2 or more. As signing became easier and TLDs made their submission policies for DS (or pub key) clearer these numbers have dropped. I'm now seeing recommendations of 1-3 months for ZSKs and 6-12 months for KSKs. The advice on this has always been all over the map, but the most common recommendation I have seen, and I have been seeing it for years, is to roll ZSKs about once a month and KSKs annually. I recommend anyone attempting to secure their DNS read the NIST Computer Security Resource Center document SP800-81 Rev.1, Secure Domain Naming System (DNS) Guide at: http://csrc.nist.gov/publications/nistpubs/800-81r1/sp-800-81r1.pdf It recommends rolling th KSK every 12 to 24 months and the ZSK every 1 to 3 months. These values are unchanged from the original SP800-81 issues back at least two years ago and probably three. Everyone I have spoken with who works with crypto feels that, barring a math breakthough, these numbers are VERY conservative. I might also mention that US government system are required to follow the recommendations of SP800-81r1. If you automate it, which is relatively easy today, then having shorter times makes sense on a number of levels. -It allows potentially lower bit sizes, due to the time/size trade off. -It ingrains the process within your operational procedures. Really large gaps between events can lead to a loss of skills or capability. (has anyone seen that HSM we bought 2 years ago?). That may or may not happen of course, but its good to exercise procedures. -You can use roll over times as natural change windows for new algorithms or new procedures. And the likelihood of changes in the next 2 years is very high since registries are still adapting and learning. I can see no point in the use of lower bit size keys. Current systems are able to deal with the sizes now in use. Shortening keys simply weakens the system. That depends on what one assumes to be the base size. It also depends on what one intends to use the keys for. The bulk of the advice within 800-81r1 assumes the target is a single or small number of production domains. The operational recommendations would become unwieldy very fast at large scales. The .GOV registry also has different policies around keys than other registries. Key groups (or lack thereof) being an obvious difference, and one that may impact how you feel about life times and bit sizes. The other item of concern not directly addressed by 800-81r1 (since its target audience wouldn't care that much), is the impact of signing many (hundreds or thousands) domains. Bit sizes, life times, signing jitter and overall domain size become of far more concern when your server will be signing effectively all the time. Even allowing for dedicated signing systems, you'll care a lot more about these issues. Another report that may be more appropriate if you have a large number of domains is the Shinkuro Setting the parameters report. http://www.dnssec-deployment.org/documents/SettingtheParameters.pdf. It is aimed at larger collections of domains and thus the advice is focused at issues of load and signing capacity. This isn't a matter of which report is better. Rather, which recommendation is applicable to my organisation?. The NIST suggestions (if you are not a government body) are entirely reasonable if your domain count is low. As the domain count enters triple digits, other advice and research may be more appropriate. I agree with your concern with long intervals between signing. Blowing a key roll is a really unpleasant things and will get more so as more and more servers start doing validation. The value of the above benefits will vary depending on how many domains you have across how many different TLDs. The more of either, the greater the benefit of an automated and reasonably regular roll over. Good advice! Online/offline keys Sometimes this may be a choice, other times legislative or standards compliance will require certain behaviour. I've seen some documents require that even ZSKs remain offline (government agencies mostly), but generally its not considered much benefit if it rolls over reasonably often. KSKs are more commonly recommended to remain offline, but that definition can vary as well. A genuine HSM (Hardware Security Module), is not likely to be found in
Auto signing ARM
I'm trying to get named and my management tool cooperating
with named on DNSSEC key management.
I'm seeing behavior with auto-signing that doesn't strictly
match the ARM and would like to know what's correct. I'm
also not clear on what named expects for some cases.
4 questions after a little context:
9.7.1-P2
Consider this configuration snippet:
View internal in {
key-directory /...
...
}
zone xx.example.net in {
auto-dnssec maintain;
type master;
file ...
allow-transfer ...
update policy {
grant ...
}
}
I run (This is a test, /dev/urandom isn't used in real life)
dnssec-keygen -q -a NSEC3RSASHA1 -b 1024 -P now -A +3mo -r /dev/urandom -K
/... xx.example.net.
I get a Kxx.example.net+... file with all the right permissions.
Now, according to the ARM:
4.9.5 DNSKEY rollovers via UPDATE
It is possible to perform key rollovers via dynamic update. You need to add
the K* files for the new keys
so that named can find them. You can then ***add the new DNSKEY RRs via
dynamic update***. named
will then cause the zone to be signed with the new keys. When the signing is
complete the private type
records will be updated so that the last octet is non zero.
But: if I DON'T add the keys by dynamic update, but instead issue an
rndc sign xx.example.net in internal
The new key shows up in the zone. As expected, nothing is signed.
So, it seems that it is NOT necessary to insert the DNSKEY RRs
via dynamic update. Either dynamic update or rndc wakes up named and
causes a scan of the keys directory.
1) Before I decide whether to rely on it, is this a bug or a feature?
Dynamic update is a bit less work - but avoids having the control
channel open beyond the local host. So there are trade-offs.
In the same area of the ARM, the 5011 section seems to be a good way
to let the slave servers learn about key changes. The section talks
about dnssec-signzone -S as the way to trigger distribution.
2) I would expect that a key to a dnssec-auto maintain zone via
the dynamic update/rndc sign route would also satisfy the 5011
requirements. Is that correct?
3) If dnssec-revoke or dnssec-settime are invoked, I assume that
rndc sign would trigger publication. If one would rather do everything
with dynamic update, what's the simplest transaction that will trigger
Re-scanning the changed key? Do I have to read the key file insert
the key?
That leaves the DS records for internally delegated zones. As best
I can tell, I still need to find the parent zone and insert them via
dynamic update. But: in the case where the parent zone is served by
the same view in the same server, named has everything it needs to
autogenerate DS record(s) when a DNSKEY is published and install it in
the parent. Well, maybe which hash type(s) are desired, but that would
be easy to put in a .conf file...
4) Shouldn't named handle this?
-
This communication may not represent my employer's views,
if any, on the matters discussed.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
DDNS Updates fail When More Than 15 Authoritative Servers (NS records) are listed in a Dynamically Updated Zone
[I apologize in advance if this is a double post. I'm not sure if my original went through] I was implementing ISC Bind 9.5 at a client site last month and had a single zone that accepted DDNS updates only from the ISC DHCP service. The environment consisted of a Master BIND server and almost 25 Windows slave servers. All DNS servers were listed as authoritative at first. This caused DDNS updates from DHCP to fail with the following message: Unable to add forward map from host.domain.com to 10.10.10.10: DNS format error. After spending quite a bit of time troubleshooting this issue with no luck, I was finally successful with DDNS updates after I reduced the number of authoritative servers for the dynamic zone to 15. Since I have done this, the issue has not resurface. Can anyone help explain to me why this happened and if there is anything I can do to avoid this from happening in the future? Thanks, Christopher Cain E: ch...@christophercain.ca ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DDNS Updates fail When More Than 15 Authoritative Servers (NS records) are listed in a Dynamically Updated Zone
It probably has something to do with the packet size. You can't easily fit 25 NS records into a 512 byte UDP packet. You really don't want to have more than 8 published NS records for most purposes. Chris Buxton BlueCat Networks On Sep 20, 2010, at 2:30 PM, Christopher Cain wrote: [I apologize in advance if this is a double post. I'm not sure if my original went through] I was implementing ISC Bind 9.5 at a client site last month and had a single zone that accepted DDNS updates only from the ISC DHCP service. The environment consisted of a Master BIND server and almost 25 Windows slave servers. All DNS servers were listed as authoritative at first. This caused DDNS updates from DHCP to fail with the following message: Unable to add forward map from host.domain.com to 10.10.10.10: DNS format error. After spending quite a bit of time troubleshooting this issue with no luck, I was finally successful with DDNS updates after I reduced the number of authoritative servers for the dynamic zone to 15. Since I have done this, the issue has not resurface. Can anyone help explain to me why this happened and if there is anything I can do to avoid this from happening in the future? Thanks, Christopher Cain E: ch...@christophercain.ca ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
