From 8d8e7680098662495d00a0d201be98955e1bfb0a Mon Sep 17 00:00:00 2001 From: Gavin Brown Date: Thu, 11 Jan 2024 13:51:02 +0000 Subject: [PATCH] add dnssecOps.xfrACL --- inc/resources.yaml | 13 +++++++++++++ inc/suites.yaml.in | 2 ++ rst-test-specs.html | 27 +++++++++++++++------------ rst-test-specs.json | 9 ++++++++- rst-test-specs.yaml | 17 ++++++++++++++++- 5 files changed, 54 insertions(+), 14 deletions(-) diff --git a/inc/resources.yaml b/inc/resources.yaml index b637939..6726a83 100644 --- a/inc/resources.yaml +++ b/inc/resources.yaml @@ -4,34 +4,40 @@ rde.encryptionKey: key that **MUST** be used to encrypt the escrow deposit file may be found at this URL. URL: https://rst.icann.org/v2/resources/rde.encryptionKey.asc + epp.clientCertificate: Description: | RFC 5734 requires servers to perform authentication of clients by means of a client certificate. Operators **MUST** configure their systems to permit the test client to connect using the certificate found at this URL. URL: https://rst.icann.org/v2/resources/epp.clientCertificate.pem + epp.clientCSR: Description: | For servers that operate a private CA, this CSR may be used to issue a client certificate. This certificate must then be provided in the `epp.clientCertificate` input parameter. + epp.clientACL: Description: | A list of IPv4 and IPv6 address(es) from which client connections to the operator's EPP server will be made. The list is a plain text file with each IP address on a separate line. URL: https://rst.icann.org/v2/resources/epp.clientACL.txt + integration.rdeSFTPPublicKey: Description: | The SSH public key that will be used to authenticate connections to the operator's SFTP server. URL: https://rst.icann.org/v2/resources/integration.rdeSFTPPublicKey.pem + integration.rdeSFTPACL: Description: | A list of IPv4 and IPv6 address(es) from which client connections to the operator's SFTP server will be made. The list is a plain text file with each IP address on a separate line. URL: https://rst.icann.org/v2/resources/integration.rdeSFTPACL.txt + epp.tlsCertificateStore: Description: | A PEM-formatted file containing the CA certificates trusted by Mozilla. @@ -40,3 +46,10 @@ epp.tlsCertificateStore: EPP servers **MUST** use a certificate that has a chain of trust to one of the CAs present in this file. URL: https://rst.icann.org/v2/resources/epp.tlsCertificateStore.pem + +dnssecOps.xfrACL: + Description: | + A list of IPv4 and IPv6 address(es) from which zone file transfers to + primary DNS servers will be made. The list is a plain text file with + each IP address on a separate line. + URL: https://rst.icann.org/v2/resources/dnssecOps.xfrACL.txt diff --git a/inc/suites.yaml.in b/inc/suites.yaml.in index fdbfbb4..3aa94c0 100644 --- a/inc/suites.yaml.in +++ b/inc/suites.yaml.in @@ -244,6 +244,8 @@ DNSSECOperations: - dnssecOps.tsigKey Errors: - DNSSEC_OPS_XFR_FAILED + Resources: + - dnssecOps.xfrACL MinimumRPMs: Order: 9 diff --git a/rst-test-specs.html b/rst-test-specs.html index 91f2fc2..8c90826 100644 --- a/rst-test-specs.html +++ b/rst-test-specs.html @@ -168,7 +168,7 @@ -

Registry System Testing - Test Specifications

Version 3.0.253

+

Registry System Testing - Test Specifications

Version 3.0.254

Last Updated: 2024-01-11

GDS Technical Services, Internet Corporation for Assigned Names and Numbers (ICANN)

2. Preamble

This file describes each test plan, suite and case in the @@ -7890,7 +7890,7 @@

Pass/fail criteria

DNSSECRSPEvaluationTest

3.9.3. Test suites

This plan uses the following test suites:

  1. DNS Security Extensions (DNSSEC)
  2. DNSSEC Operations

3.9.4. Resources

The following resources may be required to prepare for this test plan:

-
  • None specified.

3.9.5. Errors

This test plan may produce the following errors:

+

3.9.5. Errors

This test plan may produce the following errors:

3.9.6. Input parameters

This plan requires the following input parameters:

3.9.7. Required files

  • None specified.

3.9.8. RST-API example

POST /test/987654/inputs HTTP/1.1
 Content-Type: application/json
@@ -10937,7 +10937,7 @@ 
Pass/fail criteria

 
  1. dnssecOps01-ZSKRollover - ZSK rollover
  2. dnssecOps02-KSKRollover - KSK rollover
  3. dnssecOps03-AlgorithmRollover - algorithm rollover

4.8.3. Test plans

This suite is used by the following test plans:

  1. DNSSEC RSP Evaluation Test

4.8.4. Resources

The following resources may be required to prepare for this test plan:

-
  • None specified.

4.8.5. Errors

This test suite may produce the following errors:

+

4.8.5. Errors

This test suite may produce the following errors:

4.8.6. Input parameters

The test cases used by this suite require the following input parameters:

  1. dnssecOps.algorithmRolloverZone (string)
  2. dnssecOps.csk (boolean)
  3. dnssecOps.kskRolloverZone (string)
  4. dnssecOps.nameservers (object)
  5. dnssecOps.primaryServer (string)
  6. dnssecOps.tsigKey (object)
  7. dnssecOps.zskRolloverZone (string)

4.8.7. Sequence diagram

 @@ -11156,31 +11156,34 @@

Pass/fail criteria

-

5. Resources

5.1. epp.clientACL

5.1.1. Description

A list of IPv4 and IPv6 address(es) from which client connections to +

5. Resources

5.1. dnssecOps.xfrACL

5.1.1. Description

A list of IPv4 and IPv6 address(es) from which zone file transfers to +primary DNS servers will be made. The list is a plain text file with +each IP address on a separate line.

+

5.1.2. URL

5.2. epp.clientACL

5.2.1. Description

A list of IPv4 and IPv6 address(es) from which client connections to the operator’s EPP server will be made. The list is a plain text file with each IP address on a separate line.

-

5.1.2. URL

5.2. epp.clientCSR

5.2.1. Description

For servers that operate a private CA, this CSR may be used to issue +

5.2.2. URL

5.3. epp.clientCSR

5.3.1. Description

For servers that operate a private CA, this CSR may be used to issue a client certificate. This certificate must then be provided in the epp.clientCertificate input parameter.

-

5.2.2. URL

5.3. epp.clientCertificate

5.3.1. Description

RFC 5734 requires servers to perform authentication of clients by +

5.3.2. URL

5.4. epp.clientCertificate

5.4.1. Description

RFC 5734 requires servers to perform authentication of clients by means of a client certificate. Operators MUST configure their systems to permit the test client to connect using the certificate found at this URL.

-

5.3.2. URL

5.4. epp.tlsCertificateStore

5.4.1. Description

A PEM-formatted file containing the CA certificates trusted by +

5.4.2. URL

5.5. epp.tlsCertificateStore

5.5.1. Description

A PEM-formatted file containing the CA certificates trusted by Mozilla. For more information, see https://curl.se/docs/caextract.html.

EPP servers MUST use a certificate that has a chain of trust to one of the CAs present in this file.

-

5.4.2. URL

5.5. integration.rdeSFTPACL

5.5.1. Description

A list of IPv4 and IPv6 address(es) from which client connections to +

5.5.2. URL

5.6. integration.rdeSFTPACL

5.6.1. Description

A list of IPv4 and IPv6 address(es) from which client connections to the operator’s SFTP server will be made. The list is a plain text file with each IP address on a separate line.

-

5.5.2. URL

5.6. integration.rdeSFTPPublicKey

5.6.1. Description

The SSH public key that will be used to authenticate connections to +

5.6.2. URL

5.7. integration.rdeSFTPPublicKey

5.7.1. Description

The SSH public key that will be used to authenticate connections to the operator’s SFTP server.

-

5.6.2. URL

5.7. rde.encryptionKey

5.7.1. Description

RDE deposit files MUST be encrypted using OpenPGP +

5.7.2. URL

5.8. rde.encryptionKey

5.8.1. Description

RDE deposit files MUST be encrypted using OpenPGP (RFC 4880). The PGP key that MUST be used to encrypt the escrow deposit file may be found at this URL.

-

5.7.2. URL

6. Test Cases

6.1. dns-address01 - Name server address must be globally routable

6.1.1. Maturity Level

  • BETA: complete but likely to require further changes

6.1.2. Description

This test case comes from version v2023.1.4 of Zonemaster. For more +

5.8.2. URL

6. Test Cases

6.1. dns-address01 - Name server address must be globally routable

6.1.1. Maturity Level

  • BETA: complete but likely to require further changes

6.1.2. Description

This test case comes from version v2023.1.4 of Zonemaster. For more information, see https://github.com/zonemaster/zonemaster/blob/v2023.1.4/docs/public/specifications/tests/Address-TP/address01.md.

diff --git a/rst-test-specs.json b/rst-test-specs.json index 83b5892..eb140ae 100644 --- a/rst-test-specs.json +++ b/rst-test-specs.json @@ -2456,6 +2456,10 @@ "Preamble" : "This file describes each test [plan](#test-plans), [suite](#test-suites) and\n[case](#test-cases) in the RST system, as well as the\n[input parameters](#input-parameters) required for each, relevant\n[resources](#resources), any inter-case dependencies, and the\n[errors](#errors) that might occur during testing.\n\nThe key words \"MUST\", \"MUST NOT\", \"REQUIRED\", \"SHALL\", \"SHALL NOT\", \"SHOULD\",\n\"SHOULD NOT\", \"RECOMMENDED\", \"NOT RECOMMENDED\", \"MAY\", and \"OPTIONAL\" in this\ndocument are to be interpreted as described in [RFC\n2119](https://www.rfc-editor.org/rfc/rfc2119.html) when, and only when, they\nappear in all capitals, as shown here.\n\n# 2.1. Test plans\n\nAn individual *Test Plan* addresses a particular scenario (for example, RSP\nevaluation or Pre-Delegation Testing). Each plan consists of one or more *test\nsuites*, which in turn include one or more *test cases*.\n\n## 2.1.1. Test plan types\n\nThere are two types of test plan described in this document:\n\n* **Business as usual** plans, which are used as part of the lifecycle of a\ngTLD (Pre-Delegion Test, RSP/DNS RSP change Test, IDN Test, SRS Gateway\nTest)\n* **RSP evaluation** plans, which are used as part of the RSP evaluation\nprogram.\n\n# 2.2. Test suites\n\nA *Test Suite* is a collection of *test cases* with a common theme or subject\nmatter, for example, Authoritative DNS or Registry Data Escrow.\n\n# 2.3. Test cases\n\nA *Test Case* describes a process for determining the conformance or\nacceptability of a certain element of the system.\n\nA test case consists of a *test procedure* which accepts zero or more **input\nparameters**, and generates one or more **test results**.\n\n## 2.3.1. Input parameters\n\nAll test cases require some information about the subject of the test, for\nexample, service hostnames, credentials, and functional parameters. These\n*input parameters* may be shared across multiple test cases.\n\n## 2.3.2. Test environments\n\nEach test plan indicates whether the test is to be carried out in the\nproduction environment, or whether a test, staging or OT&E environment may be\nused. In general, test plans which are designed for \"business as usual\" use\nduring the lifecycle of a TLD **MUST** be carried out in the production\nregistry infrastructure, while RSP evaluation tests **MAY** be carried out in\ntest, staging or OT&E environments.\n\n## 2.3.3. Test results\n\nTest cases will generate one or more *test results*. Test results indicate the\noutcome of the test and other relevant information.\n\n## 2.3.4. General pass/fail criteria\n\nIn general, for a test to pass, **all** the test cases specified in the test\nsuite(s) for the test plan **MUST** pass: if *any* fail, then the test as a\nwhole will fail.\n\nA test case will fail if it produces one or more [errors](#errors) with the\n`ERROR` or `CRITICAL` severities.\n\n## 2.3.5. Error severity levels\n\n1. `INFO` - an informational message.\n1. `NOTICE` - a normal but significant condition.\n2. `WARNING` - an issue which does not prevent the test from *passing*, but\n which may benefit from further investigation.\n1. `ERROR` - an issue which prevents the test from *passing*, but does not\n prevent the test from *continuing*. A test may produce multiple `ERROR`\n results.\n2. `CRITICAL` - an issue which prevents the test from continuing any\n further. A test will only produce a single `CRITICAL` result and it\n will always be the last result in the log.\n\n## 2.3.6. Common errors\n\nFor each test case, various errors and critical errors are defined which will\nbe used to signal why that the case might have failed.\n\nIn addition to these, there are a number of errors which any test case may\nproduce, which are:\n\n* [TBA]\n\n# 2.4. Key acronyms and terms\n\nRST\n: Registry System Testing. This system.\n\nPDT\n: Pre-Delegation Test. A test carried out prior to the delegation of a new TLD\ninto the DNS root zone.\n\nRSP\n: Registry Service Provider. A specialist provider of critical registry\nservices.\n\nDNS\n: Domain Name System. The internet's system of globally unique identifiers.\n\nTLD\n: Top-level domain. The highest level of the DNS namespace hierarchy.\n\ngTLD\n: generic top-level domain.\n\nDNSSEC\n: DNS Security Extensions. DNSSEC is described in [BCP\n237](https://www.rfc-editor.org/info/bcp237).\n\nEPP\n: Extensible Provisioning Protocol. The protocol used by registrars to create\nand manage domain name registrations in an SRS. EPP is defined in [STD\n69](https://www.rfc-editor.org/info/std69).\n\nSRS\n: Shared Registry System. A TLD registry in which registrations are managed\nby one or more registrars, using EPP.\n\nRDDS\n: Registration Data Directory Services. A service to provide access to\ndata about domain registrations to third parties.\n\nRDAP\n: Registration Data Access Protocol. The protocol used to deliver the RDDS.\nRDAP is defined in [STD 95](https://www.rfc-editor.org/info/std95).\n\nRDE\n: Registry Data Escrow. A system whereby the registration data stored in a\nShared Registry System is backed up to a trusted third party. RDE is defined\nin [RFC 8909](https://www.rfc-editor.org/info/rfc8909) and [RFC\n9022](https://www.rfc-editor.org/info/rfc9022).\n\nIDN\n: Internationalized Domain Name. A domain name that contains characters not in\nthe ASCII character set. The technical specification for IDNs may be found in\n[RFC 5890](https://www.rfc-editor.org/info/rfc5890). All gTLDs must comply\nwith ICANN's [IDN\nGuidelines](https://www.icann.org/resources/pages/implementation-guidelines-2012-02-25-en).\n\nLGR\n: Label Generation Ruleset. The rules by which IDNs are validated. LGRs are\ndescribed in [RFC 7940](https://www.rfc-editor.org/info/rfc7940).\n\nRO\n: Registry Operator. The entity to which ICANN has granted the right to\noperate a gTLD.\n\nRA\n: Registry Agreement. The contract between a Registry Operator and ICANN. The\nbase Registry Agreement may be reviewed at\n.\n\nKSK\n: Key Signing Key. A cryptographic key which acts as the Secure Entry Point\nfor a DNS zone, and which signs a DNS zone's ZSKs. A digest of this key is\npublished in the parent zone (ie. the root zone for a TLD).\n\nZSK\n: Zone Signing Key. A cryptographic key which signs a DNS zone's resource\nrecords.\n\nCSK\n: Combined Signing Key. A cryptographic key used as **both** a KSK and a ZSK.\n\nRPMs\n: Rights Protection Mechanisms, intended to discourage or prevent registration\nof domain names that violate or abuse another party’s legal rights. These\n**MUST** include (but are not limited to): (1) Sunrise Periods, and (2)\nTrademark Claims Periods (see [Specification 7 of the Registry\nAgreement](https://itp.cdn.icann.org/en/files/registry-agreements/base-registry-agreement-30-04-2023-en.html#specification7)).\n\nTMCH\n: Trademark Clearinghouse. The system established by ICANN to maintain a\ndatabase of validated and registered trademarks which is used to enforce\nRights Protection Mechanisms (RPMs) in gTLDs. The functional specifications of\nthe TMCH are defined in [RFC 9361](https://www.rfc-editor.org/info/rfc9361).\n\nSLA\n: Service Level Agreement. The registry performance specifications laid out in\n[Specification 10 of the Registry\nAgreement](https://itp.cdn.icann.org/en/files/registry-agreements/base-registry-agreement-30-04-2023-en.html#specification10).\n\nRRI\n: Registration Reporting Interfaces. The interfaces provided by ICANN to\ncontracted parties including Registry Operators to fulfill and monitor their\napplicable reporting requirements, including per-registrar transaction\nreports; registry functions activity reports; data escrow deposits reports and\ndata escrow deposits notifications. For registry operators, the relevant\ninterfaces are defined in [draft-lozano-icann-registry-interfaces](https://datatracker.ietf.org/doc/html/draft-lozano-icann-registry-interfaces).\n", "RST-Test-Plan-Schema-Version" : "1.6.1", "Resources" : { + "dnssecOps.xfrACL" : { + "Description" : "A list of IPv4 and IPv6 address(es) from which zone file transfers to\nprimary DNS servers will be made. The list is a plain text file with\neach IP address on a separate line.\n", + "URL" : "https://rst.icann.org/v2/resources/dnssecOps.xfrACL.txt" + }, "epp.clientACL" : { "Description" : "A list of IPv4 and IPv6 address(es) from which client connections to the\noperator's EPP server will be made. The list is a plain text file with\neach IP address on a separate line.\n", "URL" : "https://rst.icann.org/v2/resources/epp.clientACL.txt" @@ -4259,6 +4263,9 @@ ], "Name" : "DNSSEC Operations", "Order" : "8", + "Resources" : [ + "dnssecOps.xfrACL" + ], "Test-Cases" : "^dnssecOps" }, "MinimumRPMs" : { @@ -4444,5 +4451,5 @@ "Test-Cases" : "^srsgw-" } }, - "Version" : "3.0.253" + "Version" : "3.0.254" } diff --git a/rst-test-specs.yaml b/rst-test-specs.yaml index 01aac80..547cdda 100644 --- a/rst-test-specs.yaml +++ b/rst-test-specs.yaml @@ -1,6 +1,6 @@ --- RST-Test-Plan-Schema-Version: 1.6.1 -Version: 3.0.253 +Version: 3.0.254 Last-Updated: 2024-01-11 Contact: Name: GDS Technical Services @@ -682,6 +682,8 @@ Test-Suites: - dnssecOps.tsigKey Errors: - DNSSEC_OPS_XFR_FAILED + Resources: + - dnssecOps.xfrACL MinimumRPMs: Order: 9 @@ -726,34 +728,40 @@ Resources: key that **MUST** be used to encrypt the escrow deposit file may be found at this URL. URL: https://rst.icann.org/v2/resources/rde.encryptionKey.asc + epp.clientCertificate: Description: | RFC 5734 requires servers to perform authentication of clients by means of a client certificate. Operators **MUST** configure their systems to permit the test client to connect using the certificate found at this URL. URL: https://rst.icann.org/v2/resources/epp.clientCertificate.pem + epp.clientCSR: Description: | For servers that operate a private CA, this CSR may be used to issue a client certificate. This certificate must then be provided in the `epp.clientCertificate` input parameter. + epp.clientACL: Description: | A list of IPv4 and IPv6 address(es) from which client connections to the operator's EPP server will be made. The list is a plain text file with each IP address on a separate line. URL: https://rst.icann.org/v2/resources/epp.clientACL.txt + integration.rdeSFTPPublicKey: Description: | The SSH public key that will be used to authenticate connections to the operator's SFTP server. URL: https://rst.icann.org/v2/resources/integration.rdeSFTPPublicKey.pem + integration.rdeSFTPACL: Description: | A list of IPv4 and IPv6 address(es) from which client connections to the operator's SFTP server will be made. The list is a plain text file with each IP address on a separate line. URL: https://rst.icann.org/v2/resources/integration.rdeSFTPACL.txt + epp.tlsCertificateStore: Description: | A PEM-formatted file containing the CA certificates trusted by Mozilla. @@ -762,6 +770,13 @@ Resources: EPP servers **MUST** use a certificate that has a chain of trust to one of the CAs present in this file. URL: https://rst.icann.org/v2/resources/epp.tlsCertificateStore.pem + + dnssecOps.xfrACL: + Description: | + A list of IPv4 and IPv6 address(es) from which zone file transfers to + primary DNS servers will be made. The list is a plain text file with + each IP address on a separate line. + URL: https://rst.icann.org/v2/resources/dnssecOps.xfrACL.txt Test-Cases: dns-address01: