Common use of DNSSEC Clause in Contracts

DNSSEC. Registry Operator shall sign its TLD zone files implementing Domain Name System Security Extensions (“DNSSEC”). For the absence of doubt, Registry Operator shall sign the zone file of <TLD> and zone files used for in-bailiwick glue for the TLD’s DNS servers. During the Term, Registry Operator shall comply with RFCs 4033, 4034, 4035, 4509 and their successors, and follow the best practices described in RFC 6781 and its successors. If Registry Operator implements Hashed Authenticated Denial of Existence for DNS Security Extensions, it shall comply with RFC 5155 and its successors. Registry Operator shall accept public-key material from child domain names in a secure manner according to industry best practices. Registry shall also publish in its website the DNSSEC Practice Statements (DPS) describing critical security controls and procedures for key material storage, access and usage for its own keys and secure acceptance of registrants’ public-key material. Registry Operator shall publish its DPS following the format described in RFC 6841. DNSSEC validation must be active and use the IANA DNS Root Key Signing Key set (available at xxxxx://xxx.xxxx.xxx/dnssec/files) as a trust anchor for Registry Operator’s Registry Services making use of data obtained via DNS responses.

Appears in 44 contracts

Samples: Registry Agreement, Registry Agreement, Registry Agreement

AutoNDA by SimpleDocs

DNSSEC. Registry Operator shall sign its TLD zone files implementing Domain Name System Security Extensions (“DNSSEC”). For the absence of doubt, Registry Operator shall sign the zone file of <TLD> and zone files used for in-bailiwick in‐bailiwick glue for the TLD’s DNS servers. During the Term, Registry Operator shall comply with RFCs 4033, 4034, 4035, 4509 and their successors, and follow the best practices described in RFC 6781 and its successors. If Registry Operator implements Hashed Authenticated Denial of Existence for DNS Security Extensions, it shall comply with RFC 5155 and its successors. Registry Operator shall accept public-key public‐key material from child domain names in a secure manner according to industry best practices. Registry shall also publish in its website the DNSSEC Practice Statements (DPS) describing critical security controls and procedures for key material storage, access and usage for its own keys and secure acceptance of registrants’ public-key public‐key material. Registry Operator shall publish its DPS following the format described in RFC 6841. DNSSEC validation must be active and use the IANA DNS Root Key Signing Key set (available at xxxxx://xxx.xxxx.xxx/dnssec/files) as a trust anchor for Registry Operator’s Registry Services making use of data obtained via DNS responses.

Appears in 12 contracts

Samples: Registry Agreement, Registry Agreement, Registry Agreement

DNSSEC. Registry Operator shall sign its TLD zone files implementing Domain Name System Security Extensions (“DNSSEC”). For the absence of doubt, Registry Operator shall sign the zone file of <TLD> and zone files used for in-in- bailiwick glue for the TLD’s DNS servers. During the Term, Registry Operator shall comply with RFCs 4033, 4034, 4035, 4509 and their successors, and follow the best practices described in RFC 6781 and its successors. If Registry Operator implements Hashed Authenticated Denial of Existence for DNS Security Extensions, it shall comply with RFC 5155 and its successors. Registry Operator shall accept public-key material from child domain names in a secure manner according to industry best practices. Registry shall also publish in its website the DNSSEC Practice Statements (DPS) describing critical security controls and procedures for key material storage, access and usage for its own keys and secure acceptance of registrants’ public-key material. Registry Operator shall publish its DPS following the format described in RFC 6841. DNSSEC validation must be active and use the IANA DNS Root Key Signing Key set (available at xxxxx://xxx.xxxx.xxx/dnssec/files) as a trust anchor for Registry Operator’s Registry Services making use of data obtained via DNS responses.

Appears in 6 contracts

Samples: Aero TLD Sponsorship Registry Agreement, Coop Sponsored TLD Registry Agreement, Museum Registry Agreement

AutoNDA by SimpleDocs

DNSSEC. Registry Operator shall sign its TLD zone files implementing Domain Name System Security Extensions (“DNSSEC”). For the absence of doubt, Registry Operator shall sign the zone file of <TLD> and zone files used for in-bailiwick glue for the TLD’s DNS servers. During the Term, Registry Operator shall comply with RFCs 4033, 4034, 4035, 4509 and their successors, and follow the best practices described in RFC 6781 46416781 and its successors. If Registry Operator implements Hashed Authenticated Denial of Existence for DNS Security Extensions, it shall comply with RFC 5155 and its successors. Registry Operator shall accept public-key material from child domain names in a secure manner according to industry best practices. Registry shall also publish in its website the DNSSEC Practice Statements (DPS) describing critical security controls and procedures for key material storage, access and usage for its own keys and secure acceptance of registrants’ public-key material. Registry Operator shall publish its DPS following the format described in RFC 6841. DNSSEC validation must be active and use the IANA DNS Root Key Signing Key set (available at xxxxx://xxx.xxxx.xxx/dnssec/files) as a trust anchor for Registry Operator’s Registry Services making use of data obtained via DNS responses.

Appears in 4 contracts

Samples: Registry Agreement, Registry Agreement, Registry Agreement

Time is Money Join Law Insider Premium to draft better contracts faster.