add dnssecOps.xfrACL

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

inc/suites.yaml.in

@@ -244,6 +244,8 @@ DNSSECOperations:
     - dnssecOps.tsigKey
   Errors:
     - DNSSEC_OPS_XFR_FAILED
+  Resources:
+    - dnssecOps.xfrACL
 
 MinimumRPMs:
   Order: 9

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<https://www.icann.org/en/registry-agreements/base-agreement>.\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"
 }

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: