text:
Network Working Group O. Kolkman Request for Comments: 4641 R. Gieben Obsoletes: 2541 NLnet Labs Category: Informational September 2006 DNSSEC Operational Practices Status of This Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document describes a set of practices for operating the DNS with security extensions (DNSSEC). The target audience is zone administrators deploying DNSSEC. The document discusses operational aspects of using keys and signatures in the DNS. It discusses issues of key generation, key storage, signature generation, key rollover, and related policies. This document obsoletes RFC 2541, as it covers more operational ground and gives more up-to-date requirements with respect to key sizes and the new DNSSEC specification. Table of Contents 1. Introduction ....................................................3 1.1. The Use of the Term 'key' ..................................4 1.2. Time Definitions ...........................................4 2. Keeping the Chain of Trust Intact ...............................5 3. Keys Generation and Storage .....................................6 3.1. Zone and Key Signing Keys ..................................6 3.1.1. Motivations for the KSK and ZSK Separation ..........6 3.1.2. KSKs for High-Level Zones ...........................7 3.2. Key Generation .............................................8 3.3. Key Effectivity Period .....................................8 3.4. Key Algorithm ..............................................9 3.5. Key Sizes ..................................................9 3.6. Private Key Storage .......................................11 4. Signature Generation, Key Rollover, and Related Policies .......12 4.1. Time in DNSSEC ............................................12 4.1.1. Time Considerations ................................12 4.2. Key Rollovers .............................................14 4.2.1. Zone Signing Key Rollovers .........................14 188.8.131.52. Pre-Publish Key Rollover ..................15 188.8.131.52. Double Signature Zone Signing Key Rollover ..................................17 184.108.40.206. Pros and Cons of the Schemes ..............18 4.2.2. Key Signing Key Rollovers ..........................18 4.2.3. Difference Between ZSK and KSK Rollovers ...........20 4.2.4. Automated Key Rollovers ............................21 4.3. Planning for Emergency Key Rollover .......................21 4.3.1. KSK Compromise .....................................22 22.214.171.124. Keeping the Chain of Trust Intact .........22 22.214.171.124. Breaking the Chain of Trust ...............23 4.3.2. ZSK Compromise .....................................23 4.3.3. Compromises of Keys Anchored in Resolvers ..........24 4.4. Parental Policies .........................................24 4.4.1. Initial Key Exchanges and Parental Policies Considerations .....................................24 4.4.2. Storing Keys or Hashes? ............................25 4.4.3. Security Lameness ..................................25 4.4.4. DS Signature Validity Period .......................26 5. Security Considerations ........................................26 6. Acknowledgments ................................................26 7. References .....................................................27 7.1. Normative References ......................................27 7.2. Informative References ....................................28 Appendix A. Terminology ...........................................30 Appendix B. Zone Signing Key Rollover How-To ......................31 Appendix C. Typographic Conventions ...............................32 1. Introduction This document describes how to run a DNS Security (DNSSEC)-enabled environment. It is intended for operators who have knowledge of the DNS (see RFC 1034 [1] and RFC 1035 [2]) and want to deploy DNSSEC. See RFC 4033 [4] for an introduction to DNSSEC, RFC 4034 [5] for the newly introduced Resource Records (RRs), and RFC 4035 [6] for the protocol changes. During workshops and early operational deployment tests, operators and system administrators have gained experience about operating the DNS with security extensions (DNSSEC). This document translates these experiences into a set of practices for zone administrators. At the time of writing, there exists very little experience with DNSSEC in production environments; this document should therefore explicitly not be seen as representing 'Best Current Practices'. The procedures herein are focused on the maintenance of signed zones (i.e., signing and publishing zones on authoritative servers). It is intended that maintenance of zones such as re-signing or key rollovers be transparent to any verifying clients on the Internet. The structure of this document is as follows. In Section 2, we discuss the importance of keeping the "chain of trust" intact. Aspects of key generation and storage of private keys are discussed in Section 3; the focus in this section is mainly on the private part of the key(s). Section 4 describes considerations concerning the public part of the keys. Since these public keys appear in the DNS one has to take into account all kinds of timing issues, which are discussed in Section 4.1. Section 4.2 and Section 4.3 deal with the rollover, or supercession, of keys. Finally, Section 4.4 discusses considerations on how parents deal with their children's public keys in order to maintain chains of trust. The typographic conventions used in this document are explained in Appendix C. Since this is a document with operational suggestions and there are no protocol specifications, the RFC 2119 [7] language does not apply. This document obsoletes RFC 2541 [12] to reflect the evolution of the underlying DNSSEC protocol since then. Changes in the choice of cryptographic algorithms, DNS record types and type names, and the parent-child key and signature exchange demanded a major rewrite and additional information and explanation. 1.1. The Use of the Term 'key' It is assumed that the reader is familiar with the concept of asymmetric keys on which DNSSEC is based (public key cryptography [17]). Therefore, this document will use the term 'key' rather loosely. Where it is written that 'a key is used to sign data' it is assumed that the reader understands that it is the private part of the key pair that is used for signing. It is also assumed that the reader understands that the public part of the key pair is published in the DNSKEY Resource Record and that it is the public part that is used in key exchanges. 1.2. Time Definitions In this document, we will be using a number of time-related terms. The following definitions apply: o "Signature validity period" The period that a signature is valid. It starts at the time specified in the signature inception field of the RRSIG RR and ends at the time specified in the expiration field of the RRSIG RR. o "Signature publication period" Time after which a signature (made with a specific key) is replaced with a new signature (made with the same key). This replacement takes place by publishing the relevant RRSIG in the master zone file. After one stops publishing an RRSIG in a zone, it may take a while before the RRSIG has expired from caches and has actually been removed from the DNS. o "Key effectivity period" The period during which a key pair is expected to be effective. This period is defined as the time between the first inception time stamp and the last expiration date of any signature made with this key, regardless of any discontinuity in the use of the key. The key effectivity period can span multiple signature validity periods. o "Maximum/Minimum Zone Time to Live (TTL)" The maximum or minimum value of the TTLs from the complete set of RRs in a zone. Note that the minimum TTL is not the same as the MINIMUM field in the SOA RR. See [11] for more information. 2. Keeping the Chain of Trust Intact Maintaining a valid chain of trust is important because broken chains of trust will result in data being marked as Bogus (as defined in [4] Section 5), which may cause entire (sub)domains to become invisible to verifying clients. The administrators of secured zones have to realize that their zone is, to verifying clients, part of a chain of trust. As mentioned in the introduction, the procedures herein are intended to ensure that maintenance of zones, such as re-signing or key rollovers, will be transparent to the verifying clients on the Internet. Administrators of secured zones will have to keep in mind that data published on an authoritative primary server will not be immediately seen by verifying clients; it may take some time for the data to be transferred to other secondary authoritative nameservers and clients may be fetching data from caching non-authoritative servers. In this light, note that the time for a zone transfer from master to slave is negligible when using NOTIFY [9] and incremental transfer (IXFR) [8]. It increases when full zone transfers (AXFR) are used in combination with NOTIFY. It increases even more if you rely on full zone transfers based on only the SOA timing parameters for refresh. For the verifying clients, it is important that data from secured zones can be used to build chains of trust regardless of whether the data came directly from an authoritative server, a caching nameserver, or some middle box. Only by carefully using the available timing parameters can a zone administrator ensure that the data necessary for verification can be obtained. The responsibility for maintaining the chain of trust is shared by administrators of secured zones in the chain of trust. This is most obvious in the case of a 'key compromise' when a trade-off between maintaining a valid chain of trust and replacing the compromised keys as soon as possible must be made. Then zone administrators will have to make a trade-off, between keeping the chain of trust intact -- thereby allowing for attacks with the compromised key -- or deliberately breaking the chain of trust and making secured subdomains invisible to security-aware resolvers. Also see Section 4.3. 3. Keys Generation and Storage This section describes a number of considerations with respect to the security of keys. It deals with the generation, effectivity period, size, and storage of private keys. 3.1. Zone and Key Signing Keys The DNSSEC validation protocol does not distinguish between different types of DNSKEYs. All DNSKEYs can be used during the validation. In practice, operators use Key Signing and Zone Signing Keys and use the so-called Secure Entry Point (SEP) [3] flag to distinguish between them during operations. The dynamics and considerations are discussed below. To make zone re-signing and key rollover procedures easier to implement, it is possible to use one or more keys as Key Signing Keys (KSKs). These keys will only sign the apex DNSKEY RRSet in a zone. Other keys can be used to sign all the RRSets in a zone and are referred to as Zone Signing Keys (ZSKs). In this document, we assume that KSKs are the subset of keys that are used for key exchanges with the parent and potentially for configuration as trusted anchors -- the SEP keys. In this document, we assume a one-to-one mapping between KSK and SEP keys and we assume the SEP flag to be set on all KSKs. 3.1.1. Motivations for the KSK and ZSK Separation Differentiating between the KSK and ZSK functions has several advantages: o No parent/child interaction is required when ZSKs are updated. o The KSK can be made stronger (i.e., using more bits in the key material). This has little operational impact since it is only used to sign a small fraction of the zone data. Also, the KSK is only used to verify the zone's key set, not for other RRSets in the zone. o As the KSK is only used to sign a key set, which is most probably updated less frequently than other data in the zone, it can be stored separately from and in a safer location than the ZSK. o A KSK can have a longer key effectivity period. For almost any method of key management and zone signing, the KSK is used less frequently than the ZSK. Once a key set is signed with the KSK, all the keys in the key set can be used as ZSKs. If a ZSK is compromised, it can be simply dropped from the key set. The new key set is then re-signed with the KSK. Given the assumption that for KSKs the SEP flag is set, the KSK can be distinguished from a ZSK by examining the flag field in the DNSKEY RR. If the flag field is an odd number it is a KSK. If it is an even number it is a ZSK. The Zone Signing Key can be used to sign all the data in a zone on a regular basis. When a Zone Signing Key is to be rolled, no interaction with the parent is needed. This allows for signature validity periods on the order of days. The Key Signing Key is only to be used to sign the DNSKEY RRs in a zone. If a Key Signing Key is to be rolled over, there will be interactions with parties other than the zone administrator. These can include the registry of the parent zone or administrators of verifying resolvers that have the particular key configured as secure entry points. Hence, the key effectivity period of these keys can and should be made much longer. Although, given a long enough key, the key effectivity period can be on the order of years, we suggest planning for a key effectivity on the order of a few months so that a key rollover remains an operational routine. 3.1.2. KSKs for High-Level Zones Higher-level zones are generally more sensitive than lower-level zones. Anyone controlling or breaking the security of a zone thereby obtains authority over all of its subdomains (except in the case of resolvers that have locally configured the public key of a subdomain, in which case this, and only this, subdomain wouldn't be affected by the compromise of the parent zone). Therefore, extra care should be taken with high-level zones, and strong keys should be used. The root zone is the most critical of all zones. Someone controlling or compromising the security of the root zone would control the entire DNS namespace of all resolvers using that root zone (except in the case of resolvers that have locally configured the public key of a subdomain). Therefore, the utmost care must be taken in the securing of the root zone. The strongest and most carefully handled keys should be used. The root zone private key should always be kept off-line. Many resolvers will start at a root server for their access to and authentication of DNS data. Securely updating the trust anchors in an enormous population of resolvers around the world will be extremely difficult. 3.2. Key Generation Careful generation of all keys is a sometimes overlooked but absolutely essential element in any cryptographically secure system. The strongest algorithms used with the longest keys are still of no use if an adversary can guess enough to lower the size of the likely key space so that it can be exhaustively searched. Technical suggestions for the generation of random keys will be found in RFC 4086 [14]. One should carefully assess if the random number generator used during key generation adheres to these suggestions. Keys with a long effectivity period are particularly sensitive as they will represent a more valuable target and be subject to attack for a longer time than short-period keys. It is strongly recommended that long-term key generation occur off-line in a manner isolated from the network via an air gap or, at a minimum, high-level secure hardware. 3.3. Key Effectivity Period For various reasons, keys in DNSSEC need to be changed once in a while. The longer a key is in use, the greater the probability that it will have been compromised through carelessness, accident, espionage, or cryptanalysis. Furthermore, when key rollovers are too rare an event, they will not become part of the operational habit and there is risk that nobody on-site will remember the procedure for rollover when the need is there. From a purely operational perspective, a reasonable key effectivity period for Key Signing Keys is 13 months, with the intent to replace them after 12 months. An intended key effectivity period of a month is reasonable for Zone Signing Keys. For key sizes that match these effectivity periods, see Section 3.5. As argued in Section 3.1.2, securely updating trust anchors will be extremely difficult. On the other hand, the "operational habit" argument does also apply to trust anchor reconfiguration. If a short key effectivity period is used and the trust anchor configuration has to be revisited on a regular basis, the odds that the configuration tends to be forgotten is smaller. The trade-off is against a system that is so dynamic that administrators of the validating clients will not be able to follow the modifications. Key effectivity periods can be made very short, as in a few minutes. But when replacing keys one has to take the considerations from Section 4.1 and Section 4.2 into account. 3.4. Key Algorithm There are currently three different types of algorithms that can be used in DNSSEC: RSA, DSA, and elliptic curve cryptography. The latter is fairly new and has yet to be standardized for usage in DNSSEC. RSA has been developed in an open and transparent manner. As the patent on RSA expired in 2000, its use is now also free. DSA has been developed by the National Institute of Standards and Technology (NIST). The creation of signatures takes roughly the same time as with RSA, but is 10 to 40 times as slow for verification [17]. We suggest the use of RSA/SHA-1 as the preferred algorithm for the key. The current known attacks on RSA can be defeated by making your key longer. As the MD5 hashing algorithm is showing cracks, we recommend the usage of SHA-1. At the time of publication, it is known that the SHA-1 hash has cryptanalysis issues. There is work in progress on addressing these issues. We recommend the use of public key algorithms based on hashes stronger than SHA-1 (e.g., SHA-256), as soon as these algorithms are available in protocol specifications (see [19] and [20]) and implementations. 3.5. Key Sizes When choosing key sizes, zone administrators will need to take into account how long a key will be used, how much data will be signed during the key publication period (see Section 8.10 of [17]), and, optionally, how large the key size of the parent is. As the chain of trust really is "a chain", there is not much sense in making one of the keys in the chain several times larger than the others. Asalways, it's the weakest link that defines the strength of the entire chain. Also see Section 3.1.1 for a discussion of how keys serving different roles (ZSK vs. KSK) may need different key sizes. Generating a key of the correct size is a difficult problem; RFC 3766 [13] tries to deal with that problem. The first part of the selection procedure in Section 1 of the RFC states: 1. Determine the attack resistance necessary to satisfy the security requirements of the application. Do this by estimating the minimum number of computer operations that the attacker will be forced to do in order to compromise the security of the system and then take the logarithm base two of that number. Call that logarithm value "n". A 1996 report recommended 90 bits as a good all-around choice for system security. The 90 bit number should be increased by about 2/3 bit/year, or about 96 bits in 2005. [13] goes on to explain how this number "n" can be used to calculate the key sizes in public key cryptography. This culminated in the table given below (slightly modified for our purpose): +-------------+-----------+--------------+ | System | | | | requirement | Symmetric | RSA or DSA | | for attack | key size | modulus size | | resistance | (bits) | (bits) | | (bits) | | | +-------------+-----------+--------------+ | 70 | 70 | 947 | | 80 | 80 | 1228 | | 90 | 90 | 1553 | | 100 | 100 | 1926 | | 150 | 150 | 4575 | | 200 | 200 | 8719 | | 250 | 250 | 14596 | +-------------+-----------+--------------+ The key sizes given are rather large. This is because these keys are resilient against a trillionaire attacker. Assuming this rich attacker will not attack your key and that the key is rolled over once a year, we come to the following recommendations about KSK sizes: 1024 bits for low-value domains, 1300 bits for medium-value domains, and 2048 bits for high-value domains. Whether a domain is of low, medium, or high value depends solely on the views of the zone owner. One could, for instance, view leaf nodes in the DNS as of low value, and top-level domains (TLDs) or the root zone of high value. The suggested key sizes should be safe for the next 5 years. As ZSKs can be rolled over more easily (and thus more often), the key sizes can be made smaller. But as said in the introduction of this paragraph, making the ZSKs' key sizes too small (in relation to the KSKs' sizes) doesn't make much sense. Try to limit the difference in size to about 100 bits. Note that nobody can see into the future and that these key sizes are only provided here as a guide. Further information can be found in [16] and Section 7.5 of [17]. It should be noted though that [16] is already considered overly optimistic about what key sizes are considered safe. One final note concerning key sizes. Larger keys will increase the sizes of the RRSIG and DNSKEY records and will therefore increase the chance of DNS UDP packet overflow. Also, the time it takes to validate and create RRSIGs increases with larger keys, so don't needlessly double your key sizes. 3.6. Private Key Storage It is recommended that, where possible, zone private keys and the zone file master copy that is to be signed be kept and used in off- line, non-network-connected, physically secure machines only. Periodically, an application can be run to add authentication to a zone by adding RRSIG and NSEC RRs. Then the augmented file can be transferred. When relying on dynamic update to manage a signed zone [10], be aware that at least one private key of the zone will have to reside on the master server. This key is only as secure as the amount of exposure the server receives to unknown clients and the security of the host. Although not mandatory, one could administer the DNS in the following way. The master that processes the dynamic updates is unavailable from generic hosts on the Internet, it is not listed in the NS RR set, although its name appears in the SOA RRs MNAME field. The nameservers in the NS RRSet are able to receive zone updates through NOTIFY, IXFR, AXFR, or an out-of-band distribution mechanism. This approach is known as the "hidden master" setup. The ideal situation is to have a one-way information flow to the network to avoid the possibility of tampering from the network. Keeping the zone master file on-line on the network and simply cycling it through an off-line signer does not do this. The on-line version could still be tampered with if the host it resides on is compromised. For maximum security, the master copy of the zone file should be off-net and should not be updated based on an unsecured network mediated communication. In general, keeping a zone file off-line will not be practical and the machines on which zone files are maintained will be connected to a network. Operators are advised to take security measures to shield unauthorized access to the master copy. For dynamically updated secured zones [10], both the master copy and the private key that is used to update signatures on updated RRs will need to be on-line. 4. Signature Generation, Key Rollover, and Related Policies 4.1. Time in DNSSEC Without DNSSEC, all times in the DNS are relative. The SOA fields REFRESH, RETRY, and EXPIRATION are timers used to determine the time elapsed after a slave server synchronized with a master server. The Time to Live (TTL) value and the SOA RR minimum TTL parameter [11] are used to determine how long a forwarder should cache data after it has been fetched from an authoritative server. By using a signature validity period, DNSSEC introduces the notion of an absolute time in the DNS. Signatures in DNSSEC have an expiration date after which the signature is marked as invalid and the signed data is to be considered Bogus. 4.1.1. Time Considerations Because of the expiration of signatures, one should consider the following: o We suggest the Maximum Zone TTL of your zone data to be a fraction of your signature validity period. If the TTL would be of similar order as the signature validity period, then all RRSets fetched during the validity period would be cached until the signature expiration time. Section 7.1 of [4] suggests that "the resolver may use the time remaining before expiration of the signature validity period of a signed RRSet as an upper bound for the TTL". As a result, query load on authoritative servers would peak at signature expiration time, as this is also the time at which records simultaneously expire from caches. To avoid query load peaks, we suggest the TTL on all the RRs in your zone to be at least a few times smaller than your signature validity period. o We suggest the signature publication period to end at least one Maximum Zone TTL duration before the end of the signature validity period. Re-signing a zone shortly before the end of the signature validity period may cause simultaneous expiration of data from caches. This in turn may lead to peaks in the load on authoritative servers. o We suggest the Minimum Zone TTL to be long enough to both fetch and verify all the RRs in the trust chain. In workshop environments, it has been demonstrated [18] that a low TTL (under 5 to 10 minutes) caused disruptions because of the following two problems: 1. During validation, some data may expire before the validation is complete. The validator should be able to keep all data until it is completed. This applies to all RRs needed to complete the chain of trust: DSes, DNSKEYs, RRSIGs, and the final answers, i.e., the RRSet that is returned for the initial query. 2. Frequent verification causes load on recursive nameservers. Data at delegation points, DSes, DNSKEYs, and RRSIGs benefit from caching. The TTL on those should be relatively long. o Slave servers will need to be able to fetch newly signed zones well before the RRSIGs in the zone served by the slave server pass their signature expiration time. When a slave server is out of sync with its master and data in a zone is signed by expired signatures, it may be better for the slave server not to give out any answer. Normally, a slave server that is not able to contact a master server for an extended period will expire a zone. When that happens, the server will respond differently to queries for that zone. Some servers issue SERVFAIL, whereas others turn off the 'AA' bit in the answers. The time of expiration is set in the SOA record and is relative to the last successful refresh between the master and the slave servers. There exists no coupling between the signature expiration of RRSIGs in the zone and the expire parameter in the SOA. If the server serves a DNSSEC zone, then it may well happen that the signatures expire well before the SOA expiration timer counts down to zero. It is not possible to completely prevent this from happening by tweaking the SOA parameters. However, the effects can be minimized where the SOA expiration time is equal to or shorter than the signature validity period. The consequence of an authoritative server not being able to update a zone, whilst that zone includes expired signatures, is that non-secure resolvers will continue to be able to resolve data served by the particular slave servers while security-aware resolvers will experience problems because of answers being marked as Bogus. We suggest the SOA expiration timer being approximately one third or one fourth of the signature validity period. It will allow problems with transfers from the master server to be noticed before the actual signature times out. We also suggest that operators of nameservers that supply secondary services develop 'watch dogs' to spot upcoming signature expirations in zones they slave, and take appropriate action. When determining the value for the expiration parameter one has to take the following into account: What are the chances that all my secondaries expire the zone? How quickly can I reach an administrator of secondary servers to load a valid zone? These questions are not DNSSEC specific but may influence the choice of your signature validity intervals. 4.2. Key Rollovers A DNSSEC key cannot be used forever (see Section 3.3). So key rollovers -- or supercessions, as they are sometimes called -- are a fact of life when using DNSSEC. Zone administrators who are in the process of rolling their keys have to take into account that data published in previous versions of their zone still lives in caches. When deploying DNSSEC, this becomes an important consideration; ignoring data that may be in caches may lead to loss of service for clients. The most pressing example of this occurs when zone material signed with an old key is being validated by a resolver that does not have the old zone key cached. If the old key is no longer present in the current zone, this validation fails, marking the data "Bogus". Alternatively, an attempt could be made to validate data that is signed with a new key against an old key that lives in a local cache, also resulting in data being marked "Bogus". 4.2.1. Zone Signing Key Rollovers For "Zone Signing Key rollovers", there are two ways to make sure that during the rollover data still cached can be verified with the new key sets or newly generated signatures can be verified with the keys still in caches. One schema, described in Section 220.127.116.11, uses double signatures; the other uses key pre-publication (Section 220.127.116.11). The pros, cons, and recommendations are described in Section 126.96.36.199. 188.8.131.52. Pre-Publish Key Rollover This section shows how to perform a ZSK rollover without the need to sign all the data in a zone twice -- the "pre-publish key rollover". This method has advantages in the case of a key compromise. If the old key is compromised, the new key has already been distributed in the DNS. The zone administrator is then able to quickly switch to the new key and remove the compromised key from the zone. Another major advantage is that the zone size does not double, as is the case with the double signature ZSK rollover. A small "how-to" for this kind of rollover can be found in Appendix B. Pre-publish key rollover involves four stages as follows: ---------------------------------------------------------------- initial new DNSKEY new RRSIGs DNSKEY removal ---------------------------------------------------------------- SOA0 SOA1 SOA2 SOA3 RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2) RRSIG11(SOA3) DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY10 DNSKEY10 DNSKEY10 DNSKEY11 | DNSKEY11 DNSKEY11 RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY) RRSIG1 (DNSKEY) RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY) ---------------------------------------------------------------- Pre-Publish Key RolloverEID 791 (Verified) is as follows: Section: 3.5 Original Text: As the chain of trust really is "a chain", there is not much sense in making one of the keys in the chain several times larger then the others. Corrected Text: As the chain of trust really is "a chain", there is not much sense in making one of the keys in the chain several times larger than the others.Notes:
then -> than
from pendingPre-Publish Key Rollover initial: Initial version of the zone: DNSKEY 1 is the Key Signing Key. DNSKEY 10 is used to sign all the data of the zone, the Zone Signing Key. new DNSKEY: DNSKEY 11 is introduced into the key set. Note that no signatures are generated with this key yet, but this does not secure against brute force attacks on the public key. The minimum duration of this pre-roll phase is the time it takes for the data to propagate to the authoritative servers plus TTL value of the key set. new RRSIGs: At the "new RRSIGs" stage (SOA serial 2), DNSKEY 11 is used to sign the data in the zone exclusively (i.e., all the signatures from DNSKEY 10 are removed from the zone). DNSKEY 10 remains published in the key set. This way data that was loaded into caches from version 1 of the zone can still be verified with key sets fetched from version 2 of the zone. The minimum time that the key set including DNSKEY 10 is to be published is the time that it takes for zone data from the previous version of the zone to expire from old caches, i.e., the time it takes for this zone to propagate to all authoritative servers plus the Maximum Zone TTL value of any of the data in the previous version of the zone. DNSKEY removal: DNSKEY 10 is removed from the zone. The key set, now only containing DNSKEY 1 and DNSKEY 11, is re-signed with the DNSKEY 1. The above scheme can be simplified by always publishing the "future" key immediately after the rollover. The scheme would look as follows (we show two rollovers); the future key is introduced in "new DNSKEY" as DNSKEY 12 and again a newer one, numbered 13, in "new DNSKEY (II)": ---------------------------------------------------------------- initial new RRSIGs new DNSKEY ---------------------------------------------------------------- SOA0 SOA1 SOA2 RRSIG10(SOA0) RRSIG11(SOA1) RRSIG11(SOA2) DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY10 DNSKEY10 DNSKEY11 DNSKEY11 DNSKEY11 DNSKEY12 RRSIG1(DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY) ---------------------------------------------------------------- ---------------------------------------------------------------- new RRSIGs (II) new DNSKEY (II) ---------------------------------------------------------------- SOA3 SOA4 RRSIG12(SOA3) RRSIG12(SOA4) DNSKEY1 DNSKEY1 DNSKEY11 DNSKEY12 DNSKEY12 DNSKEY13 RRSIG1(DNSKEY) RRSIG1(DNSKEY) RRSIG12(DNSKEY) RRSIG12(DNSKEY) ---------------------------------------------------------------- Pre-Publish Key Rollover, Showing Two Rollovers Note that the key introduced in the "new DNSKEY" phase is not used for production yet; the private key can thus be stored in a physically secure manner and does not need to be 'fetched' every time a zone needs to be signed. 188.8.131.52. Double Signature Zone Signing Key Rollover This section shows how to perform a ZSK key rollover using the double zone data signature scheme, aptly named "double signature rollover". During the "new DNSKEY" stage the new version of the zone file will need to propagate to all authoritative servers and the data that exists in (distant) caches will need to expire, requiring at least the Maximum Zone TTL. Double signature ZSK rollover involves three stages as follows: ---------------------------------------------------------------- initial new DNSKEY DNSKEY removal ---------------------------------------------------------------- SOA0 SOA1 SOA2 RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2) | RRSIG11(SOA1) DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY10 DNSKEY10 DNSKEY11 | DNSKEY11 RRSIG1(DNSKEY) RRSIG1(DNSKEY) RRSIG1(DNSKEY) RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY) | RRSIG11(DNSKEY) ---------------------------------------------------------------- Double Signature Zone Signing Key RolloverEID 35 (Verified) is as follows: Section: 18.104.22.168 Original Text: Pre-publish key rollover involves four stages as follows: ---------------------------------------------------------------- initial new DNSKEY new RRSIGs DNSKEY removal ---------------------------------------------------------------- SOA0 SOA1 SOA2 SOA3 RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2) RRSIG11(SOA3) DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY10 DNSKEY10 DNSKEY10 DNSKEY11 DNSKEY11 DNSKEY11 RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY) RRSIG1 (DNSKEY) RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY) ---------------------------------------------------------------- Corrected Text: Pre-publish key rollover involves four stages as follows: ---------------------------------------------------------------- initial new DNSKEY new RRSIGs DNSKEY removal ---------------------------------------------------------------- SOA0 SOA1 SOA2 SOA3 RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2) RRSIG11(SOA3) DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY10 DNSKEY10 DNSKEY10 DNSKEY11 | DNSKEY11 DNSKEY11 RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY) RRSIG1 (DNSKEY) RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY) ---------------------------------------------------------------- Pre-Publish Key RolloverNotes:
The mis-alignment of the indicated line breaks the intended
presentation of the procedure; cf. subsequent RFC text.
from pendinginitial: Initial Version of the zone: DNSKEY 1 is the Key Signing Key. DNSKEY 10 is used to sign all the data of the zone, the Zone Signing Key. new DNSKEY: At the "New DNSKEY" stage (SOA serial 1) DNSKEY 11 is introduced into the key set and all the data in the zone is signed with DNSKEY 10 and DNSKEY 11. The rollover period will need to continue until all data from version 0 of the zone has expired from remote caches. This will take at least the Maximum Zone TTL of version 0 of the zone. DNSKEY removal: DNSKEY 10 is removed from the zone. All the signatures from DNSKEY 10 are removed from the zone. The key set, now only containing DNSKEY 11, is re-signed with DNSKEY 1. At every instance, RRSIGs from the previous version of the zone can be verified with the DNSKEY RRSet from the current version and the other way around. The data from the current version can be verified with the data from the previous version of the zone. The duration of the "new DNSKEY" phase and the period between rollovers should be at least the Maximum Zone TTL. Making sure that the "new DNSKEY" phase lasts until the signature | expiration time of the data in the initial version of the zone is recommended. This way all caches are cleared of the old signatures.EID 790 (Verified) is as follows: Section: 188.8.131.52 Original Text: Double signature ZSK rollover involves three stages as follows: ---------------------------------------------------------------- initial new DNSKEY DNSKEY removal ---------------------------------------------------------------- SOA0 SOA1 SOA2 RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2) RRSIG11(SOA1) DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY10 DNSKEY10 DNSKEY11 DNSKEY11 RRSIG1(DNSKEY) RRSIG1(DNSKEY) RRSIG1(DNSKEY) RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY) ---------------------------------------------------------------- Double Signature Zone Signing Key Rollover Corrected Text: Double signature ZSK rollover involves three stages as follows: ---------------------------------------------------------------- initial new DNSKEY DNSKEY removal ---------------------------------------------------------------- SOA0 SOA1 SOA2 RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2) | RRSIG11(SOA1) DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY10 DNSKEY10 DNSKEY11 | DNSKEY11 RRSIG1(DNSKEY) RRSIG1(DNSKEY) RRSIG1(DNSKEY) RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY) | RRSIG11(DNSKEY) ---------------------------------------------------------------- Double Signature Zone Signing Key RolloverNotes:
The mis-alignment of the indicated 3 lines breaks the
intended presentation of the procedure; cf. subsequent RFC text.
The initial report was corrected by Yue Luo 2007-11-16 so that "RRSIG11" in the last row is in "New DNSKEY" stage instead of "initial" stage.However, this duration could be considerably longer than the Maximum Zone TTL, making the rollover a lengthy procedure. Note that in this example we assumed that the zone was not modified during the rollover. New data can be introduced in the zone as long as it is signed with both keys. 184.108.40.206. Pros and Cons of the Schemes Pre-publish key rollover: This rollover does not involve signing the zone data twice. Instead, before the actual rollover, the new key is published in the key set and thus is available for cryptanalysis attacks. A small disadvantage is that this process requires four steps. Also the pre-publish scheme involves more parental work when used for KSK rollovers as explained in Section 4.2.3. Double signature ZSK rollover: The drawback of this signing scheme is that during the rollover the number of signatures in your zone doubles; this may be prohibitive if you have very big zones. An advantage is that it only requires three steps. 4.2.2. Key Signing Key Rollovers For the rollover of a Key Signing Key, the same considerations as for the rollover of a Zone Signing Key apply. However, we can use a double signature scheme to guarantee that old data (only the apex key set) in caches can be verified with a new key set and vice versa. Since only the key set is signed with a KSK, zone size considerations do not apply. -------------------------------------------------------------------- initial new DNSKEY DS change DNSKEY removal -------------------------------------------------------------------- Parent: SOA0 --------> SOA1 --------> RRSIGpar(SOA0) --------> RRSIGpar(SOA1) --------> DS1 --------> DS2 --------> RRSIGpar(DS) --------> RRSIGpar(DS) --------> Child: SOA0 SOA1 --------> SOA2 RRSIG10(SOA0) RRSIG10(SOA1) --------> RRSIG10(SOA2) --------> DNSKEY1 DNSKEY1 --------> DNSKEY2 DNSKEY2 --------> DNSKEY10 DNSKEY10 --------> DNSKEY10 RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) --------> RRSIG2 (DNSKEY) RRSIG2 (DNSKEY) --------> RRSIG10(DNSKEY) RRSIG10(DNSKEY) --------> RRSIG10(DNSKEY) -------------------------------------------------------------------- Stages of Deployment for a Double Signature Key Signing Key Rollover initial: Initial version of the zone. The parental DS points to DNSKEY1. Before the rollover starts, the child will have to verify what the TTL is of the DS RR that points to DNSKEY1 -- it is needed during the rollover and we refer to the value as TTL_DS. new DNSKEY: During the "new DNSKEY" phase, the zone administrator generates a second KSK, DNSKEY2. The key is provided to the parent, and the child will have to wait until a new DS RR has been generated that points to DNSKEY2. After that DS RR has been published on all servers authoritative for the parent's zone, the zone administrator has to wait at least TTL_DS to make sure that the old DS RR has expired from caches. DS change: The parent replaces DS1 with DS2. DNSKEY removal: DNSKEY1 has been removed. The scenario above puts the responsibility for maintaining a valid chain of trust with the child. It also is based on the premise that the parent only has one DS RR (per algorithm) per zone. An alternative mechanism has been considered. Using an established trust relation, the interaction can be performed in-band, and the removal of the keys by the child can possibly be signaled by the parent. In this mechanism, there are periods where there are two DS RRs at the parent. Since at the moment of writing the protocol for this interaction has not been developed, further discussion is out of scope for this document. 4.2.3. Difference Between ZSK and KSK Rollovers Note that KSK rollovers and ZSK rollovers are different in the sense that a KSK rollover requires interaction with the parent (and possibly replacing of trust anchors) and the ensuing delay while waiting for it. A zone key rollover can be handled in two different ways: pre-publish (Section 18.104.22.168) and double signature (Section 126.96.36.199). As the KSK is used to validate the key set and because the KSK is not changed during a ZSK rollover, a cache is able to validate the new key set of the zone. The pre-publish method would also work for a KSK rollover. The records that are to be pre-published are the parental DS RRs. The pre-publish method has some drawbacks for KSKs. We first describe the rollover scheme and then indicate these drawbacks. -------------------------------------------------------------------- initial new DS new DNSKEY DS/DNSKEY removal -------------------------------------------------------------------- Parent: SOA0 SOA1 --------> SOA2 RRSIGpar(SOA0) RRSIGpar(SOA1) --------> RRSIGpar(SOA2) DS1 DS1 --------> DS2 DS2 --------> RRSIGpar(DS) RRSIGpar(DS) --------> RRSIGpar(DS) Child: SOA0 --------> SOA1 SOA1 RRSIG10(SOA0) --------> RRSIG10(SOA1) RRSIG10(SOA1) --------> DNSKEY1 --------> DNSKEY2 DNSKEY2 --------> DNSKEY10 --------> DNSKEY10 DNSKEY10 RRSIG1 (DNSKEY) --------> RRSIG2(DNSKEY) RRSIG2 (DNSKEY) RRSIG10(DNSKEY) --------> RRSIG10(DNSKEY) RRSIG10(DNSKEY) -------------------------------------------------------------------- Stages of Deployment for a Pre-Publish Key Signing Key Rollover When the child zone wants to roll, it notifies the parent during the "new DS" phase and submits the new key (or the corresponding DS) to the parent. The parent publishes DS1 and DS2, pointing to DNSKEY1 and DNSKEY2, respectively. During the rollover ("new DNSKEY" phase), which can take place as soon as the new DS set propagated through the DNS, the child replaces DNSKEY1 with DNSKEY2. Immediately after that ("DS/DNSKEY removal" phase), it can notify the parent that the old DS record can be deleted. The drawbacks of this scheme are that during the "new DS" phase the parent cannot verify the match between the DS2 RR and DNSKEY2 using the DNS -- as DNSKEY2 is not yet published. Besides, we introduce a "security lame" key (see Section 4.4.3). Finally, the child-parent interaction consists of two steps. The "double signature" method only needs one interaction. 4.2.4. Automated Key Rollovers As keys must be renewed periodically, there is some motivation to automate the rollover process. Consider the following: o ZSK rollovers are easy to automate as only the child zone is involved. o A KSK rollover needs interaction between parent and child. Data exchange is needed to provide the new keys to the parent; consequently, this data must be authenticated and integrity must be guaranteed in order to avoid attacks on the rollover. 4.3. Planning for Emergency Key Rollover This section deals with preparation for a possible key compromise. Our advice is to have a documented procedure ready for when a key compromise is suspected or confirmed. When the private material of one of your keys is compromised it can be used for as long as a valid trust chain exists. A trust chain remains intact for o as long as a signature over the compromised key in the trust chain is valid, o as long as a parental DS RR (and signature) points to the compromised key, o as long as the key is anchored in a resolver and is used as a starting point for validation (this is generally the hardest to update). While a trust chain to your compromised key exists, your namespace is vulnerable to abuse by anyone who has obtained illegitimate possession of the key. Zone operators have to make a trade-off if the abuse of the compromised key is worse than having data in caches that cannot be validated. If the zone operator chooses to break the trust chain to the compromised key, data in caches signed with this key cannot be validated. However, if the zone administrator chooses to take the path of a regular rollover, the malicious key holder can spoof data so that it appears to be valid. 4.3.1. KSK Compromise A zone containing a DNSKEY RRSet with a compromised KSK is vulnerable as long as the compromised KSK is configured as trust anchor or a parental DS points to it. A compromised KSK can be used to sign the key set of an attacker's zone. That zone could be used to poison the DNS. Therefore, when the KSK has been compromised, the trust anchor or the parental DS should be replaced as soon as possible. It is local policy whether to break the trust chain during the emergency rollover. The trust chain would be broken when the compromised KSK is removed from the child's zone while the parent still has a DS pointing to the compromised KSK (the assumption is that there is only one DS at the parent. If there are multiple DSes this does not apply -- however the chain of trust of this particular key is broken). Note that an attacker's zone still uses the compromised KSK and the presence of a parental DS would cause the data in this zone to appear as valid. Removing the compromised key would cause the attacker's zone to appear as valid and the child's zone as Bogus. Therefore, we advise not to remove the KSK before the parent has a DS to a new KSK in place. 22.214.171.124. Keeping the Chain of Trust Intact If we follow this advice, the timing of the replacement of the KSK is somewhat critical. The goal is to remove the compromised KSK as soon as the new DS RR is available at the parent. And also make sure that the signature made with a new KSK over the key set with the compromised KSK in it expires just after the new DS appears at the parent, thus removing the old cruft in one swoop. The procedure is as follows: 1. Introduce a new KSK into the key set, keep the compromised KSK in the key set. 2. Sign the key set, with a short validity period. The validity period should expire shortly after the DS is expected to appear in the parent and the old DSes have expired from caches. 3. Upload the DS for this new key to the parent. 4. Follow the procedure of the regular KSK rollover: Wait for the DS to appear in the authoritative servers and then wait as long as the TTL of the old DS RRs. If necessary re-sign the DNSKEY RRSet and modify/extend the expiration time. 5. Remove the compromised DNSKEY RR from the zone and re-sign the key set using your "normal" validity interval. An additional danger of a key compromise is that the compromised key could be used to facilitate a legitimate DNSKEY/DS rollover and/or nameserver changes at the parent. When that happens, the domain may be in dispute. An authenticated out-of-band and secure notify mechanism to contact a parent is needed in this case. Note that this is only a problem when the DNSKEY and or DS records are used for authentication at the parent. 188.8.131.52. Breaking the Chain of Trust There are two methods to break the chain of trust. The first method causes the child zone to appear 'Bogus' to validating resolvers. The other causes the child zone to appear 'insecure'. These are described below. In the method that causes the child zone to appear 'Bogus' to validating resolvers, the child zone replaces the current KSK with a new one and re-signs the key set. Next it sends the DS of the new key to the parent. Only after the parent has placed the new DS in the zone is the child's chain of trust repaired. An alternative method of breaking the chain of trust is by removing the DS RRs from the parent zone altogether. As a result, the child zone would become insecure. 4.3.2. ZSK Compromise Primarily because there is no parental interaction required when a ZSK is compromised, the situation is less severe than with a KSK compromise. The zone must still be re-signed with a new ZSK as soon as possible. As this is a local operation and requires no communication between the parent and child, this can be achieved fairly quickly. However, one has to take into account that just as with a normal rollover the immediate disappearance of the old compromised key may lead to verification problems. Also note that as long as the RRSIG over the compromised ZSK is not expired the zone may be still at risk. 4.3.3. Compromises of Keys Anchored in Resolvers A key can also be pre-configured in resolvers. For instance, if DNSSEC is successfully deployed the root key may be pre-configured in most security aware resolvers. If trust-anchor keys are compromised, the resolvers using these keys should be notified of this fact. Zone administrators may consider setting up a mailing list to communicate the fact that a SEP key is about to be rolled over. This communication will of course need to be authenticated, e.g., by using digital signatures. End-users faced with the task of updating an anchored key should always validate the new key. New keys should be authenticated out- of-band, for example, through the use of an announcement website that is secured using secure sockets (TLS) [21]. 4.4. Parental Policies 4.4.1. Initial Key Exchanges and Parental Policies Considerations The initial key exchange is always subject to the policies set by the parent. When designing a key exchange policy one should take into account that the authentication and authorization mechanisms used during a key exchange should be as strong as the authentication and authorization mechanisms used for the exchange of delegation information between parent and child. That is, there is no implicit need in DNSSEC to make the authentication process stronger than it was in DNS. Using the DNS itself as the source for the actual DNSKEY material, with an out-of-band check on the validity of the DNSKEY, has the benefit that it reduces the chances of user error. A DNSKEY query tool can make use of the SEP bit [3] to select the proper key from a DNSSEC key set, thereby reducing the chance that the wrong DNSKEY is sent. It can validate the self-signature over a key; thereby verifying the ownership of the private key material. Fetching the DNSKEY from the DNS ensures that the chain of trust remains intact once the parent publishes the DS RR indicating the child is secure. Note: the out-of-band verification is still needed when the key material is fetched via the DNS. The parent can never be sure whether or not the DNSKEY RRs have been spoofed. 4.4.2. Storing Keys or Hashes? When designing a registry system one should consider which of the DNSKEYs and/or the corresponding DSes to store. Since a child zone might wish to have a DS published using a message digest algorithm not yet understood by the registry, the registry can't count on being able to generate the DS record from a raw DNSKEY. Thus, we recommend that registry systems at least support storing DS records. It may also be useful to store DNSKEYs, since having them may help during troubleshooting and, as long as the child's chosen message digest is supported, the overhead of generating DS records from them is minimal. Having an out-of-band mechanism, such as a registry directory (e.g., Whois), to find out which keys are used to generate DS Resource Records for specific owners and/or zones may also help with troubleshooting. The storage considerations also relate to the design of the customer interface and the method by which data is transferred between registrant and registry; Will the child zone administrator be able to upload DS RRs with unknown hash algorithms or does the interface only allow DNSKEYs? In the registry-registrar model, one can use the DNSSEC extensions to the Extensible Provisioning Protocol (EPP) [15], which allows transfer of DS RRs and optionally DNSKEY RRs. 4.4.3. Security Lameness Security lameness is defined as what happens when a parent has a DS RR pointing to a non-existing DNSKEY RR. When this happens, the child's zone may be marked "Bogus" by verifying DNS clients. As part of a comprehensive delegation check, the parent could, at key exchange time, verify that the child's key is actually configured in the DNS. However, if a parent does not understand the hashing algorithm used by child, the parental checks are limited to only comparing the key id. Child zones should be very careful in removing DNSKEY material, specifically SEP keys, for which a DS RR exists. Once a zone is "security lame", a fix (e.g., removing a DS RR) will take time to propagate through the DNS. 4.4.4. DS Signature Validity Period Since the DS can be replayed as long as it has a valid signature, a short signature validity period over the DS minimizes the time a child is vulnerable in the case of a compromise of the child's KSK(s). A signature validity period that is too short introduces the possibility that a zone is marked "Bogus" in case of a configuration error in the signer. There may not be enough time to fix the problems before signatures expire. Something as mundane as operator unavailability during weekends shows the need for DS signature validity periods longer than 2 days. We recommend an absolute minimum for a DS signature validity period of a few days. The maximum signature validity period of the DS record depends on how long child zones are willing to be vulnerable after a key compromise. On the other hand, shortening the DS signature validity interval increases the operational risk for the parent. Therefore, the parent may have policy to use a signature validity interval that is considerably longer than the child would hope for. A compromise between the operational constraints of the parent and minimizing damage for the child may result in a DS signature validity period somewhere between a week and months. In addition to the signature validity period, which sets a lower bound on the number of times the zone owner will need to sign the zone data and which sets an upper bound to the time a child is vulnerable after key compromise, there is the TTL value on the DS RRs. Shortening the TTL means that the authoritative servers will see more queries. But on the other hand, a short TTL lowers the persistence of DS RRSets in caches thereby increasing the speed with which updated DS RRSets propagate through the DNS. 5. Security Considerations DNSSEC adds data integrity to the DNS. This document tries to assess the operational considerations to maintain a stable and secure DNSSEC service. Not taking into account the 'data propagation' properties in the DNS will cause validation failures and may make secured zones unavailable to security-aware resolvers. 6. Acknowledgments Most of the ideas in this document were the result of collective efforts during workshops, discussions, and tryouts. At the risk of forgetting individuals who were the original contributors of the ideas, we would like to acknowledge people who were actively involved in the compilation of this document. In random order: Rip Loomis, Olafur Gudmundsson, Wesley Griffin, Michael Richardson, Scott Rose, Rick van Rein, Tim McGinnis, Gilles Guette Olivier Courtay, Sam Weiler, Jelte Jansen, Niall O'Reilly, Holger Zuleger, Ed Lewis, Hilarie Orman, Marcos Sanz, and Peter Koch. Some material in this document has been copied from RFC 2541 [12]. Mike StJohns designed the key exchange between parent and child mentioned in the last paragraph of Section 4.2.2 Section 4.2.4 was supplied by G. Guette and O. Courtay. Emma Bretherick, Adrian Bedford, and Lindy Foster corrected many of the spelling and style issues. Kolkman and Gieben take the blame for introducing all miscakes (sic). While working on this document, Kolkman was employed by the RIPE NCC and Gieben was employed by NLnet Labs. 7. References 7.1. Normative References [1] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [2] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [3] Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name System KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag", RFC 3757, May 2004. [4] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. [5] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005. [6] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005. 7.2. Informative References [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [8] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, August 1996. [9] Vixie, P., "A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)", RFC 1996, August 1996. [10] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000. [11] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, March 1998. [12] Eastlake, D., "DNS Security Operational Considerations", RFC 2541, March 1999. [13] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, April 2004. [14] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. [15] Hollenbeck, S., "Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)", RFC 4310, December 2005. [16] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key Sizes", The Journal of Cryptology 14 (255-293), 2001. [17] Schneier, B., "Applied Cryptography: Protocols, Algorithms, and Source Code in C", ISBN (hardcover) 0-471-12845-7, ISBN (paperback) 0-471-59756-2, Published by John Wiley & Sons Inc., 1996. [18] Rose, S., "NIST DNSSEC workshop notes", June 2001. [19] Jansen, J., "Use of RSA/SHA-256 DNSKEY and RRSIG Resource Records in DNSSEC", Work in Progress, January 2006. [20] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)", RFC 4509, May 2006. [21] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, April 2006. Appendix A. Terminology In this document, there is some jargon used that is defined in other documents. In most cases, we have not copied the text from the documents defining the terms but have given a more elaborate explanation of the meaning. Note that these explanations should not be seen as authoritative. Anchored key: A DNSKEY configured in resolvers around the globe. This key is hard to update, hence the term anchored. Bogus: Also see Section 5 of [4]. An RRSet in DNSSEC is marked "Bogus" when a signature of an RRSet does not validate against a DNSKEY. Key Signing Key or KSK: A Key Signing Key (KSK) is a key that is used exclusively for signing the apex key set. The fact that a key is a KSK is only relevant to the signing tool. Key size: The term 'key size' can be substituted by 'modulus size' throughout the document. It is mathematically more correct to use modulus size, but as this is a document directed at operators we feel more at ease with the term key size. Private and public keys: DNSSEC secures the DNS through the use of public key cryptography. Public key cryptography is based on the existence of two (mathematically related) keys, a public key and a private key. The public keys are published in the DNS by use of the DNSKEY Resource Record (DNSKEY RR). Private keys should remain private. Key rollover: A key rollover (also called key supercession in some environments) is the act of replacing one key pair with another at the end of a key effectivity period. Secure Entry Point (SEP) key: A KSK that has a parental DS record pointing to it or is configured as a trust anchor. Although not required by the protocol, we recommend that the SEP flag [3] is set on these keys. Self-signature: This only applies to signatures over DNSKEYs; a signature made with DNSKEY x, over DNSKEY x is called a self- signature. Note: without further information, self-signatures convey no trust. They are useful to check the authenticity of the DNSKEY, i.e., they can be used as a hash. Singing the zone file: The term used for the event where an administrator joyfully signs its zone file while producing melodic sound patterns. Signer: The system that has access to the private key material and signs the Resource Record sets in a zone. A signer may be configured to sign only parts of the zone, e.g., only those RRSets for which existing signatures are about to expire. Zone Signing Key (ZSK): A key that is used for signing all data in a zone. The fact that a key is a ZSK is only relevant to the signing tool. Zone administrator: The 'role' that is responsible for signing a zone and publishing it on the primary authoritative server. Appendix B. Zone Signing Key Rollover How-To Using the pre-published signature scheme and the most conservative method to assure oneself that data does not live in caches, here follows the "how-to". Step 0: The preparation: Create two keys and publish both in your key set. Mark one of the keys "active" and the other "published". Use the "active" key for signing your zone data. Store the private part of the "published" key, preferably off-line. The protocol does not provide for attributes to mark a key as active or published. This is something you have to do on your own, through the use of a notebook or key management tool. Step 1: Determine expiration: At the beginning of the rollover make a note of the highest expiration time of signatures in your zone file created with the current key marked as active. Wait until the expiration time marked in Step 1 has passed. Step 2: Then start using the key that was marked "published" to sign your data (i.e., mark it "active"). Stop using the key that was marked "active"; mark it "rolled". Step 3: It is safe to engage in a new rollover (Step 1) after at least one signature validity period. Appendix C. Typographic Conventions The following typographic conventions are used in this document: Key notation: A key is denoted by DNSKEYx, where x is a number or an identifier, x could be thought of as the key id. RRSet notations: RRs are only denoted by the type. All other information -- owner, class, rdata, and TTL--is left out. Thus: "example.com 3600 IN A 192.0.2.1" is reduced to "A". RRSets are a list of RRs. A example of this would be "A1, A2", specifying the RRSet containing two "A" records. This could again be abbreviated to just "A". Signature notation: Signatures are denoted as RRSIGx(RRSet), which means that RRSet is signed with DNSKEYx. Zone representation: Using the above notation we have simplified the representation of a signed zone by leaving out all unnecessary details such as the names and by representing all data by "SOAx" SOA representation: SOAs are represented as SOAx, where x is the serial number. Using this notation the following signed zone: example.net. 86400 IN SOA ns.example.net. bert.example.net. ( 2006022100 ; serial 86400 ; refresh ( 24 hours) 7200 ; retry ( 2 hours) 3600000 ; expire (1000 hours) 28800 ) ; minimum ( 8 hours) 86400 RRSIG SOA 5 2 86400 20130522213204 ( 20130422213204 14 example.net. cmL62SI6iAX46xGNQAdQ... ) 86400 NS a.iana-servers.net. 86400 NS b.iana-servers.net. 86400 RRSIG NS 5 2 86400 20130507213204 ( 20130407213204 14 example.net. SO5epiJei19AjXoUpFnQ ... ) 86400 DNSKEY 256 3 5 ( EtRB9MP5/AvOuVO0I8XDxy0... ) ; id = 14 86400 DNSKEY 257 3 5 ( gsPW/Yy19GzYIY+Gnr8HABU... ) ; id = 15 86400 RRSIG DNSKEY 5 2 86400 20130522213204 ( 20130422213204 14 example.net. J4zCe8QX4tXVGjV4e1r9... ) 86400 RRSIG DNSKEY 5 2 86400 20130522213204 ( 20130422213204 15 example.net. keVDCOpsSeDReyV6O... ) 86400 RRSIG NSEC 5 2 86400 20130507213204 ( 20130407213204 14 example.net. obj3HEp1GjnmhRjX... ) a.example.net. 86400 IN TXT "A label" 86400 RRSIG TXT 5 3 86400 20130507213204 ( 20130407213204 14 example.net. IkDMlRdYLmXH7QJnuF3v... ) 86400 NSEC b.example.com. TXT RRSIG NSEC 86400 RRSIG NSEC 5 3 86400 20130507213204 ( 20130407213204 14 example.net. bZMjoZ3bHjnEz0nIsPMM... ) ... is reduced to the following representation: SOA2006022100 RRSIG14(SOA2006022100) DNSKEY14 DNSKEY15 RRSIG14(KEY) RRSIG15(KEY) The rest of the zone data has the same signature as the SOA record, i.e., an RRSIG created with DNSKEY 14. Authors' Addresses Olaf M. Kolkman NLnet Labs Kruislaan 419 Amsterdam 1098 VA The Netherlands EMail: email@example.com URI: http://www.nlnetlabs.nl R. (Miek) Gieben EMail: firstname.lastname@example.com Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at email@example.com. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).EID 792 (Verified) is as follows: Section: 188.8.131.52 Original Text: Making sure that the "new DNSKEY" phase lasts until the signature expiration time of the data in initial version of the zone is recommended. Corrected Text: Making sure that the "new DNSKEY" phase lasts until the signature | expiration time of the data in the initial version of the zone is recommended.Notes:
missing article
from pending


text:
By Allen Best
Along Highway 160 in southwestern Colorado, the movement of deer and elk mark the changing seasons. In winter, they browse amid the plateaus, canyons and prairies south of the highway. Come May, the herds cross the highway, following the receding snow line northward into the lofty San Juan Mountains. Many don't make it.
Each day, the highway carries 20,000 to 30,000 vehicles between Durango, a resort and college town, and the burgeoning bedroom community of Bayfield, 15 miles to the east. Vehicle collisions with wildlife occur frequently, nearly always killing the animals and sometimes people. In the bloodiest one-mile strip, wildlife collisions account for 70 percent of all accidents, compared to 20 percent in other highway segments of the region. "The average costs associated with a deer-vehicle collision are about $6,600. This includes property damage and also costs associated with the occasional human injury and human fatality," says Marcel Huisjer, a research ecologist with the Western Transportation Institute in Bozeman, Montana. "The costs for the average elk- or moose-vehicle collision are higher at $17,500 and $30,800 respectively." Nationwide, wildlife collisions cost $8 billion a year and kill about 200 people—and countless wild animals.
"Wildlife needs to move around—sometimes hundreds of miles in a year—to find food, shelter and mates," says Trisha White, director of Defenders of Wildlife's Habitat and Highways Campaign. "When we build highways through their habitat, we shouldn't be surprised when cars and animals collide."
Highway engineers and wildlife biologists have puzzled for decades about how to keep deer hooves and car hoods apart. Recently, the Colorado Department of Transportation has turned to technology previously used at prisons, military bases and airports to detect intruders in unauthorized areas. The technology—specialized cables—can detect the electromagnetic fields given off by any living creature the size of a cat or larger. Now on Highway 160, when a large animal moves across the cable buried about nine inches beneath the ground, it triggers 12 warning signs in the one-mile corridor, alerting motorists that there's a large animal within 30 feet of the pavement.
Research collected since the cable was installed in October 2008 suggests the warnings have slowed drivers and made them more alert. That's the goal. "We are hoping to reduce accidents, but we also want to see if we can change driver behavior," says Mike McVaugh, a traffic and safety engineer with the Colorado Department of Transportation.
In other states and in Canada, wildlife crossings and fencing have been shown to reduce wildlife-vehicle collisions by at least 80 percent. Fences along highways that funnel animals to highway underpasses have proved highly effective. The price tag for such projects can be in the millions of dollars, however. That cost is justified if a road section had at least 5.1 deer-vehicle collisions per mile before the mitigation measures were put in place, says Huijser.
Elsewhere in Colorado, Defenders persuaded state officials to build two wildlife underpasses southwest of Denver using federal stimulus money. More are planned. These strategically placed underpasses and fencing will allow deer, elk, bears, mountain lions, imperiled Canada lynx and other animals to travel safely under the highway to find the food, mates and quality habitat they need to survive.
"By making smart investments in wildlife crossings now, we will save millions of dollars each year, boost our local economies by creating jobs and, most importantly, save lives," says White.
As the effects of climate change become more challenging, it will become even more important for species that are being driven to higher elevations to be able to travel safely through the landscape.
And if the new surveillance technology works on Colorado's Highway 160, there could be a new tool to help critters safely get to the other side of the road while keeping people on their merry way.
Only select articles from Defenders are available online. To receive 4 issues annually of the full award-winning magazine, become a member of Defenders of Wildlife!

subset: commoncrawl


text:
Thursday, October 25, 2012
melancholia strikes
Part I. THE DIAGNOSIS
I am having a hard time adjusting. I did it to myself.
At the farm, each day unfolds as a massive unstructured expanse in front of me. I watch from the window, it's probably 7:30 am. I have so much to do and nothing to do. I've created this time and space for myself to be better and now I sit in the middle of our unfinished house waiting for something to happen. But there are few external forces here. Telephones don't ring, and people don't stop by. There are no meetings where I'm nodding and saying yes. Yes, yes yes! Oh the bobble head I used to be! The days of hustling. Do I miss them? It doesn't matter because we can't go back.
The quiet in my mind becomes wildly uncomfortable. I call my astrologer. She tells me to confront the dragons in the basement.
Part II. AVOIDING CONFRONTING THE DRAGONS IN THE BASEMENT
In an effort to distract myself I ordered a small box of roses last week and had Fallon ship them to the farm. This would be the external force! A catalyst to propel me into a mode of productivity where I could face the mounting list of farm tasks that hover around me. Where I could escape Enya on repeat.
One time when I was really struggling with depression and anxiety I saw a homeopathist. She asked me a number of questions about what moments made me feel the happiest. It was a difficult question for me because at the time I was working in the art world and nothing was happy for me there. But now it is simple to answer - I am happiest when I am alone with flowers.
The activity of making flowers just for my own enjoyment is very critical to my work, I don't know if I've ever talked about it here. In my brain it feels like I am making a symphony. I am myself and I feel close to freedom. It feels like a ringing or striking a chord. A surge: it is sharp and clear and focused.
I felt a little better, and then I got to escape to the city.
Part III. THE OTHER SIDE
Another box of roses are due to arrive any minute, the last box of the year. I'm back in the city now, sitting up in my office, thinking about Worlds End....how tenuous it feels; my suspended reality. Last night I forgot how to hail a cab and experienced another wallop of anxiety on 3rd Avenue. Obviously what I am trying to tell you is that I'm stuck between two worlds. I am smiling when I am writing now. There must be an appropriate 80's anthem for this moment.
Anyway, the roses. The rains came to Petaluma Sunday or Monday and we are to receive what was snipped right before they blew in. I like to imagine these roses somewhere dark in their wax tissuey shrouds...stacked on the back of a fed ex truck, bouncing through the streets of Brooklyn. Sealed in their box, neither dead nor alive.
It's 11:53am now. Where is fedex anyway?
33 comments:
- Dana said...
You should start a commune. Seriously. I'd move up there.
- October 25, 2012 at 9:12 AM
- Meg said...
insanely beautiful as always...enjoy those roses whenever they get there, and i hope the melancholy subsides. something about fall and melancholy seem to suit each other though, especially through your lens.
the new world you've created is pretty damn enchanting! - October 25, 2012 at 9:29 AM
- abby said...
i second that commune idea! also your photographs are simply stunning, capturing the mood of the post so precisely everytime! i could see that first or tenth one in all it melancholic beauty poster size.
- October 25, 2012 at 10:10 AM
- Mihaeko said...
I'm so surprised at the timing of this post. That struggle, I'm new to it myself spending time at a farm in VT for extended work getaways, living in Brooklyn. I suspect there's a deep level of stress related to living in the city that takes a long time to shake, even if it's good stress. The constant input. I know the countryside nourishes me, I feel I belong there but it can also bring on a feeling of eerie emptiness that is hard to reconcile and I too have been at a loss for how to respond when I find myself not doing anything...
Bon courage. - October 25, 2012 at 10:13 AM
- bigBANG studio said...
in the studio, painting, undisturbed.
in the desert, hiking, with the dogs.
on the island in maine, reading, with P.
is when i'm happiest. also, i am clearing my throat at this moment and piping up that there *is* a little bit of joy in the art world because i say so, because i insist on it, because i inhabit it and i am *into* joy, happiness. otherwise i might as well hurl myself out this window. (delusion is an important part of happiness, maybe?)
here's to courage and a sense of continuing wonder, and to world's end, and the city, and all of us women with a foot in both worlds.
xo. - October 25, 2012 at 11:28 AM
- Sarah Ryhanen said...
lily; i edited my words - you are right (winky emoticon)
- October 25, 2012 at 12:43 PM
- Jessica said...
Your photographs kill me every time. Another serious talent you have there.
Any time I have too much of something or of everything I get idled with confusion and fear then I do nothing. Still working on a solution for that.
Also, I find that doing flowers for myself not only keeps me in check but reminds me why I fell in to it. Kind of like how people say that folks in long term relationships should try to date / court their partner. It keeps things interesting. - October 25, 2012 at 1:06 PM
- Shelley said...
Not a solution to the conundrum but an idea.www.oldsheepmeadowsnursery.com/
- October 25, 2012 at 2:10 PM
- Erin said...
killer post! love the little window into your world.
- October 25, 2012 at 3:44 PM
- bigBANG studio said...
- October 25, 2012 at 4:54 PM
- Liz said...
me too about the little window comment. always, always look forward to your posts and your snaps.
- October 25, 2012 at 5:52 PM
- Katie said...
i'm happiest when i'm walking winslow in the park in the morning, he is sniffing and i am thinking about nothing.
miss you, miss nea xooxo - October 25, 2012 at 6:36 PM
- margaret said...
this is my favorite blog. EVER.
- October 25, 2012 at 8:26 PM
- Margaret Kelley said...
The idea of composing a symphony wih flowers is very interesting. As someone who works with both classical music and flora on a daily, nay regular basis, I think you've hit the nail on the head. You're layering, building, adding color, dimension, texture, line, negative space. Resting, but continuing to produce.
Sarah, you're a 21st century floral composer! - October 25, 2012 at 8:37 PM
- Unknown said...
The descriptive bit about the roses in their wax paper in the Fed Ex truck was just so lovely.
- October 25, 2012 at 9:21 PM
- amygoround said...
What I've learned from melancholy/depression: One, when we choose to express and talk about it to people, we almost always play it down from, and lighter than, how intense it really is. Two, when we express and talk about it, we feel better. So maybe when we talk about it as less intense and lighter than it really is, we are anticipating how much lighter and less intense it will feel after we've talked about it. On a lighter note, I like Betty Davis Eyes as an 80's anthem in times like these.
- October 25, 2012 at 10:35 PM
- Unknown said...
I feel the same peace and focus when I am working with flowers, that I don't get anywhere else. Follow that :)
- October 26, 2012 at 4:06 AM
- edi gardner said...
It reminds me of Anais Nin but prettier pictures.
I think you are experiencing ownership. And that changes everything :-)). Huge Hug - October 26, 2012 at 6:48 AM
- LPC said...
And I have always found your melancholy flowers to be your most beautiful. You're a profoundly talented person. Many people feel anxious now and then, few are so talented as you. Just in case that's helpful, since I like you very much here in the Interether.
- October 26, 2012 at 5:27 PM
- IAMTHELAB said...
Just amazing. I could get lost in those images.
- October 27, 2012 at 1:44 AM
- Carola said...
I now how u feel. We moved from the city to a more country-beachy place and some days are just like that. Time seems to stop in front of me.
kisses from the vegetable garden
Carola - October 27, 2012 at 4:36 PM
- count buckula said...
you should call jen
- October 27, 2012 at 7:42 PM
- Country Flora@Hyderabad said...
All over world beautiful flowers!
- October 29, 2012 at 4:15 AM
- Melbourne florist said...
I like this blog very much !! Melbourne florist
- October 29, 2012 at 5:10 AM
- Allisunny S. said...
I know you'll find your farm feet and internal forces...transition is such a confusing stretch.
Allison - October 31, 2012 at 5:40 AM
- Volare said...
Hello Saipua ladies. Sorry this is not about the post, but I was just hoping your business fared well through the storm. Wishing you the best (if it is not already that way)!
- October 31, 2012 at 7:48 AM
- Sally May Mills said...
I smiled and nodded in recognition at your dilemma. I followed my values of freedom and simplicity to create what many may see as an idyllic lifestyle. A house on a tropical beach, no schedules, no demands, no work, and no stress. There isn't need for a calendar, a shopping list or an inbox. We don't have a postal service, local newspaper or tv. We're barefoot and child free. Yet I allowed myself to be plagued by feelings of guilt, lack of purpose and uselessness for many years. Overwhelmed by the great ocean of time. I tried creating fake "schedules" to bring order into my day and have something "worthwhile" to show for my waking hours. I carried with me the expectations of the western society and family; of what I thought I should be doing, which in my mind was never enough. I was measuring my days by someone else's yardstick, rather than being true to my intention. My mind was sullied by our society's obsession with busyness and the false sense of importance it commands. I suffered from under-stimulation because I let myself believe that doing fun things all day was frivolous and indulgent. Eventually i learned to be more at peace with simply being, and try (not always successfully) to ignore what other's think about my life. I let go of goals and expectations, preferring instead to focus on the present, for it is only here that true happiness exists. It requires ongoing awareness of my thoughts, letting go of unhelpful ones, and believing that I have enough, I do enough, I am enough. It doesn't mean I don't still fall into spirals of uncertainty, but it is an a journey I am grateful for. Moving between this world and the pace of Aussie society is still a big struggle, and I'm due back there in a few weeks...
Your photos, flowers and words have been a source of beauty, inspiration and stimulation on my island home. Stay with the vision. Blameless, at ease and in peace. - November 4, 2012 at 12:07 AM
oh my god...your photos are always perfect, gorgeous.... <3
Fàtima - November 6, 2012 at 4:56 AM
- MCC said...
That second photograph. You're the Mozart of flowers.
- November 7, 2012 at 5:42 AM
- Tine (matimuk) said...
I find really wonderful images here..
- November 8, 2012 at 8:44 AM
- florist online said...
Meloncholia strikes is shown on the post here. Read all about it
- December 6, 2012 at 4:25 AM
- Van Nuys said...
Hi, I was simply checking out this blog and I really admire the premise of the article and this is really informative. I will for sure refer my friends the same. Thanks
- December 8, 2012 at 7:39 AM
It is your colourful blog that brings me a lot of knowledge about living.
| Toko Baju Online
| Reseller Baju
- June 27, 2013 at 5:22 AM


text:
IVY -flat top, prehung,w/screen, front entry single wrought iron door- 38x81 Right Hand
- Size: 38"x81"
- Door Opening: Right in swing
- Color: Black
- Glass: Frosted Tempered Glass
- Screen Included
- Handle: 2 Custom Included
Pickup available at 15545 Cabrito Road
Usually ready in 2-4 days
Product information
Need To Custom Order?
Most of our in-stock doors are available as they are. Any changes can be made to order for a lead time of 3-4 months. If you need assistance with customizing the design, size, or color options, please do not hesitate to get in touch with us at (818)-779-0222. Additionally, you can also contact us via email or by clicking the button below.
What payment methods can I use?
We provide a variety of payment options from well-known providers such as Mastercard, Visa, and American Express. Additionally, we offer a convenient financing cart option where customers can choose Affirm at checkout.
What carriers do you use for shipping
In order to ensure the most optimal shipping service for your specific location, we partner with a trusted third-party agent who specializes in connecting us with the best LTL freight companies available.
How secure are your packaging
The wooden crates ensured the flawless delivery of our exquisite doors to their destination
What is the process to order a custom door?
In order to initiate the order, a 50% deposit is necessary. Once the payment has been made, our team will generate CAD drawings to ensure that the design, size, and configurations align with your requirements. The final payment will be collected prior to shipping.
What is your turn around time for custom door
The duration for completion depends on the magnitude of the project. In the case of custom orders, our lead time averages at 3-4 months.
What is your return policy
Please visit our Policy Page for more information. See Return Policy
Do you have warranty on your products
We guarantee the quality of our products with a warranty. Get peace of mind with a 10-year warranty for manufacturing defects and a 5-year warranty for hardware.
To learn more you can check out our warranty page here: Warranty
Where are your doors made?
The production of all our iron doors takes place at our partnered factory in China. Moreover, local manufacturing is an option for Railings and Gates.


text:
If U.S. military forces in Iraq and Afghanistan were trusted more by the locals, would they be safer? A Longwood University psychology professor thinks so, and she is trying to help the military's counterinsurgency efforts through a project to build trust between strangers from different cultures.
Dr. Sarai Blincoe has been helping coordinate a grant-funded project in conjunction with the Naval Research Laboratory that will test a "social psychological model of trust" in a survey of people in Jordan and Lebanon. The "experimental poll" of 600 people in each country will test the theory that engaging in sacrificial acts generates far more trust than self-beneficial or mutually beneficial acts—which can be used by the military in counterinsurgency. One of the project's funders is the Air Force Office of Scientific Research. Depending on continued funding, the polling will be expanded to countries in northern Africa and the Pacific Rim.
"A major aspect of counterinsurgency is building trust with local populations, which has been challenging as evidenced by our actions in Iraq and Afghanistan," said Blincoe, assistant professor of psychology. "Our approach involves risks, but we think it will have bigger payoffs."
Jordanian and Lebanese adults will be randomly assigned to read one of nine different versions of a story in which an American diplomat, an American working for a nongovernmental organization, or a local employee of the Jordanian/Lebanese government proposes to his supervisor a project that would benefit his community. The boss' reaction varies, though in each version the employee ends up doing the project, with varying results.
"As the factors in the story change, we will get to see how that affects trust," said Blincoe. "In some versions, both the employee and the community benefit—for example, the employee could get a raise or a promotion—but in others, the employee is taking a risk, such as getting fired. The key question is: Will trust build more when it's a sacrifice as opposed to a mutual benefit? We predict trust will be greater when it's a sacrifice instead of a mutual benefit."
It is hoped that the data will be collected during the summer. Then it will be analyzed, after which she and her collaborators will publish their findings and present them at conferences.
Blincoe began working during summer 2012 on the project, "Generating Trust in the Counterinsurgency Context," at the invitation of Lt. David Combs, a Navy researcher at the Naval Research Laboratory in Washington, D.C., who had previously done research on trust in the political setting. They met in graduate school at the University of Kentucky, where both earned a Ph.D. in experimental psychology.
"The Navy is interested in how the social sciences can inform military strategy and tactics, and all branches of the military are doing something something," said Blincoe. "Most are funding research into culture. The Army recently hired anthropologists for what it calls 'cultural terrain' teams—anthropologists who go along on their missions and say 'Look, you're interpreting that flag as a threat, but it represents something about their culture or country.'
"The military is starting to think more about this because the type of war we're fighting has changed from conventional—my tanks versus your tanks— to insurgencies, so we need a different approach. The enemy is not on a battlefield—they're in the town, among the people, blending in. The military is realizing it has to learn about the local people and get them on their side. There are other models of trust in the social sciences, but we are tailoring this to the unique counterinsurgency environment."
An example of taking risks in the name of building trust can be found in the military's decision to move its forward-operating bases in Iraq and Afghanistan closer to the local community, Blincoe said. "Troops used to march out in the morning from a very secure base to the nearby town or city, then return to their base in the evening. But they found that the local people didn't trust them or help them, so they moved their bases closer to, and integrated with, the towns and cities, which has improved the safety of both the military and the locals. They took a risk, but it was beneficial—because the people supported it."


text:
Tactus Gives Touchscreen Users Something To Touch
by Jason Inofuentes on January 9, 2013 2:09 PM EST- Posted in
- Trade Shows
- Touchscreen
- Tactus
One of the hardest leaps to make in entering this modern era of mobile phones was the idea of using a touchscreen keyboard. Losing our beloved keys was anathema to Blackberry and Treo users. But what if you could get a little of that back? Tactus has been exploring that idea almost since the iPhone's first announcement. By combining a small pump and an array of microfluidic channels and chambers on a plastic panel, they can bring topograph to otherwise flat touch screens. The keys raise on demand when the keyboard is called, and will disappear when the keyboard is no longer needed. The technology is still very much a work in progress. The demo device they showed off has a single portrait keyboard configuration, and while raising takes a quick second, evacuating the chambers takes considerably longer. Dr. Craig Ciesla, founder and CEO of Tactus , says reliability concerns have largely been dealt with and they're well on their way to bringing the technology to phone sized devices, as well as refining their larger offerings. The technology is still in its earliest days, but we're excited to see where it gets.
Comments Locked
5 Comments
View All Comments
Inteli - Wednesday, January 9, 2013 - link
Not that I have a real issue with touch keyboards, this is very very cool. I won't personally get a new tablet for quite a while, I'll think much more strongly about it when they figure out a way for touchscreen keyboards to have travel and tactile feedback. So Tactus, if you're reading this, then get working on travel on those little domes of yours. -
DuckieHo - Thursday, January 10, 2013 - link
Is a key stroke registered just on contact or does the user have to actually press down on a bubble? -
JasonInofuentes - Monday, January 21, 2013 - link
So there are varying levels of sensitivity associated with the firmness of the buttons, as set in the demo the buttons triggered with a very light touch, more like a bumpy capacitive touch screen. It's unclear what effect firming or softening the action of the keys would have on triggering an input. -
speculatrix - Sunday, January 20, 2013 - link
Topology is definitely not the right word.
Topography somewhat better. -
JasonInofuentes - Monday, January 21, 2013 - link
Good call.


text:
Need help?
Your cart is empty
Use this bar to show information about your cookie policy.
1 product
Showing 1 - 1 of 1 product
Express Shipping Options Available
We offer the following express shipping options: EVRI 1-2 Day Delivery & Royal Mail Tracked 24 Hour Delivery.
We Offer Free Shipping
Free 1-2 Day Evri Shipping when you spend £50 or more!
Top-notch support
If you need to contact our customer service team please fill in our contact form and someone will get back to you within 2 working days.
Secure payments
We offer a range of payment options to suit everyone, including: Debit/Credit Card, Apple Pay, PayPal, Clearpay and Klarna.


text:
IMPAwards has found a very scary looking German poster for Mikael Håfström's Escape Plan.
The film follows a structural engineer who is wrongly convicted of a crime, and is locked up in a prison of his own design, and plots his escape.
Sylvester Stallone is teaming up with Arnold Schwarzenegger for this one, with Jim Caviezel, Curtis "50 Cent" Jackson, Vinnie Jones, Vincent D'Onofrio, and Amy Ryan also starring.
Escape Plan is out on October 18th.
Escape Plan follows Ray Breslin (Stallone) who is the world's foremost authority on structural security. He's analyzed every high security prison and has gained a vast array of survival skills. But all Ray's ingenuity and knowledge are about to be put to work in the most challenging test he's ever faced: escaping from the master prison of his own design.
Schwarzenegger, in the role of Church, plays a complex inmate with multiple shades of grey. He's the guy who fights to keep the prisoners from losing their humanity in their darkest hour as they struggle together to stay alive.


text: There's a feeling you get when you go fishing. You get on the boat and the only thing between you and the fish is water. Each time you cast, the sound of nature drowns out the noise, you feel a rush of anticipation - it's all about that tug at the end of the line - so set the hook! Get an Owner hook and clear the deck.


text:
Photograph of smiling Charlotte taken by Duchess of Cambridge released on Princess' sixth birthday
A photograph of Princess Charlotte looking happy and relaxed in a floral summer dress has been released to mark her sixth birthday on Sunday.
Kensington Palace said the photograph was taken this weekend in Norfolk.
Hide AdAdvertisement
Hide AdThe photo's publication comes after the release of a video of Charlotte with her brothers George, seven, and Louis, three, and their parents to mark the Duke and Duchess of Cambridge's 10th wedding anniversary on Thursday.
It showed the family enjoying time outdoors at their Norfolk residence Anmer Hall and on sand dunes at a nearby beach.
Charlotte was dressed for cooler weather in the video which showed her playing and toasting a marshmallow on a camp fire.
The new photo was taken in warmer weather with the smiling princess pictured outdoors while wearing a dark blue short sleeved dress with a pink floral design.
Hide AdAdvertisement
Hide AdThe dress is £59 design from British children's clothing brand Rachel Riley.
Amateur photographer Kate
The new image was not shared on the Cambridges' social media accounts after William said they were joining the sporting world for a four-day social media blackout to show that online abuse is not acceptable.
The relaxed look is a contrast from the photos which marked Charlotte's fifth birthday.
In 2020, she was pictured volunteering with her brothers and their parents William and Kate by helping to load a van with food and delivering meals for those in need in Norfolk.
Hide AdAdvertisement
Hide AdThe birthday girl's full title is Her Royal Highness Princess Charlotte Elizabeth Diana of Cambridge.
She was born at the private maternity Lindo Wing of St Mary's Hospital in Paddington, central London, at 8.34am on May 2 2015, weighing 8lb 3oz.
Kate is a keen amateur photographer and patron of the Royal Photographic Society and her pictures have regularly been released to mark her children's birthdays.