// BUG: Limited timestamp due to Windows bug: https://connect.microsoft.com/VisualStudio/feedback/details/559198/net-4-datetime-tolocaltime-is-sometimes-wrong
// BUG: Limited timestamp due to Windows bug: https://connect.microsoft.com/VisualStudio/feedback/details/559198/net-4-datetime-tolocaltime-is-sometimes-wrong
/// Exists in order to allow a security-aware resolver to disable signature validation
/// in a security-aware name server's processing of a particular query.
///
/// The name server side must copy the setting of the CD bit from a query to the corresponding response.
///
/// The name server side of a security-aware recursive name server must pass the state of the CD bit to the resolver side
/// along with the rest of an initiating query,
/// so that the resolver side will know whether it is required to verify the response data it returns to the name server side.
/// If the CD bit is set, it indicates that the originating resolver is willing to perform whatever authentication its local policy requires.
/// Thus, the resolver side of the recursive name server need not perform authentication on the RRsets in the response.
/// When the CD bit is set, the recursive name server should, if possible, return the requested data to the originating resolver,
/// even if the recursive name server's local authentication policy would reject the records in question.
/// That is, by setting the CD bit, the originating resolver has indicated that it takes responsibility for performing its own authentication,
/// and the recursive name server should not interfere.
///
/// If the resolver side implements a BAD cache and the name server side receives a query that matches an entry in the resolver side's BAD cache,
/// the name server side's response depends on the state of the CD bit in the original query.
/// If the CD bit is set, the name server side should return the data from the BAD cache;
/// if the CD bit is not set, the name server side must return RCODE 2 (server failure).
///
/// The intent of the above rule is to provide the raw data to clients that are capable of performing their own signature verification checks
/// while protecting clients that depend on the resolver side of a security-aware recursive name server to perform such checks.
/// Several of the possible reasons why signature validation might fail involve conditions
/// that may not apply equally to the recursive name server and the client that invoked it.
/// For example, the recursive name server's clock may be set incorrectly, or the client may have knowledge of a relevant island of security
/// that the recursive name server does not share.
/// In such cases, "protecting" a client that is capable of performing its own signature validation from ever seeing the "bad" data does not help the client.
/// Ignored if the type field indicates "no key" and the following description assumes that type field to be non-zero.
/// Keys may be associated with zones, entities, or users for experimental, trial, or optional use, in which case this bit will be one.
/// If this bit is a zero, it means that the use or availability of security based on the key is "mandatory".
/// Thus, if this bit is off for a zone key, the zone should be assumed secured by SIG RRs and any responses indicating the zone is not secured should be considered bogus.
/// If this bit is a one for a host or end entity, it might sometimes operate in a secure mode and at other times operate without security.
/// The experimental bit, like all other aspects of the KEY RR, is only effective if the KEY RR is appropriately signed by a SIG RR.
/// The experimental bit must be zero for safe secure operation and should only be a one for a minimal transition period.
/// </summary>
publicboolExperimental{get;privateset;}
/// <summary>
/// Indicates that this is a key associated with a "user" or "account" at an end entity, usually a host.
/// The coding of the owner name is that used for the responsible individual mailbox in the SOA and RP RRs:
/// The owner name is the user name as the name of a node under the entity name.
/// For example, "j.random_user" on host.subdomain.domain could have a public key associated through a KEY RR
/// with name j\.random_user.host.subdomain.domain and the user bit a one.
/// It could be used in an security protocol where authentication of a user was desired.
/// This key might be useful in IP or other security for a user level service such a telnet, ftp, rlogin, etc.
/// </summary>
publicboolUserAssociated{get;privateset;}
/// <summary>
/// Indicates that this key is valid for use in conjunction with that security standard.
/// This key could be used in connection with secured communication on behalf of an end entity or user whose name is the owner name of the KEY RR
/// if the entity or user bits are on.
/// The presence of a KEY resource with the IPSEC and entity bits on and experimental and no-key bits off is an assertion that the host speaks IPSEC.
/// </summary>
publicboolIpSec{get;privateset;}
/// <summary>
/// Indicates that this key is valid for use in conjunction with MIME security multiparts.
/// This key could be used in connection with secured communication on behalf of an end entity or user
/// whose name is the owner name of the KEY RR if the entity or user bits are on.