Registry System Testing - Test Specifications

Version 3.1.2024137

Last Updated: 2024-05-16

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

2. Change Log

2.1. Thursday, May 16, 2024

  1. This is the first release since the end of the Public Comment period, but does not include any changes made as a result of that proceeding. These will come in a future release.

  2. The specification has been updated to include data providers which are associated with test cases.

  3. Clarified that the epp-05 test case will be skipped if the server uses host attributes.

  4. Clarified that the epp-06 test case will be skipped if the general.registryDataModel input parameter is minimum.

  5. Updated the wording of epp-08 to clarify that both <info> and <update> commands will be used.

  6. Updated epp-04 to clarify that the epp.registeredNames input parameter will be used in this test case.

  7. Added idn-05 which checks that the EPP server rejects <create> commands for pure ASCII domains in TLDs that are IDN-only.

  8. Added idn-06 which checks that the EPP server rejects <create> commands for domains that do not comply with the requirements of IDNA2008.

  9. Updated idn-01 to include <check> commands for valid and invalid labels.

  10. Input parameters now have a boolean Required parameter indicating whether they are required or optional. Where the description of the input parameter says the value can be empty, it now says it can be omitted.

  11. If a port is specified in an RDAP Base URL, it MUST be 443.

2.2. Tuesday, March 26, 2024

  1. This is the final release of the test specifications before the start of the Public Comment. No changes to the specification will be published until after the Public Comment process has been completed.

  2. Since the Registration Data Policy allows for different registry data models to apply to different registrar accounts (depending on whether or not there is an appropriate legal basis, and data processing agreement is in place), the general.minimalPublicDataSet input parameter has been replaced with general.registryDataModel, which is an enum. To support this, the epp.clid01DataModel and epp.clid02DataModel input parameters have been added, so that different registry data models can be specified for each registrar account.

  3. The algorithm mnemonics that can be specified in the dnssecOps.tsigKey input parameter have been restricted to those that are (a) applicable for DNS and (b) secure.

  4. Error messages extracted from Zonemaster now include the tag descriptions from Zonemaster::Engine.

  5. In minimumRPMs-03, the maximum time period between when the trademark claim notice acknowledgement and the submission of the domain <create> command has been increased from 48 hours to one year. The maturity of this test has been changed to BETA.

  6. Case maturity metrics: ALPHA 0% (-1%), BETA 0% (-50%), GAMMA 100% (+50%).

2.3. Wednesday, March 20, 2024

  1. clarified the elements that will be tested in epp-07.

  2. added Configuration section to the YAML file which holds internal test system configuration parameters.

  3. Case maturity metrics: ALPHA <1% (no change), BETA 50% (no change), GAMMA 50% (no change)

2.4. Wednesday, March 13, 2024

  1. Added a number of new errors to epp-07.

  2. In rde-07, clarify that a domain with the pendingDelete status can have an <exDate> element that is before the watermark.

  3. Case maturity metrics: ALPHA <1% (no change), BETA 50% (no change), GAMMA 50% (no change)

2.5. Wednesday, February 28, 2024

  1. Added the EPP_GREETING_MISSING_EN_LANG error to epp-02. The circumstances under which the EPP_GREETING_RECOMMENDED_EXTENSION_MISSING warning will be produced have been clarified.

  2. Various changes to input parameter schema to address issues with OpenAPI code generators not being able to support various JSON Schema features.

  3. The dnssecOps.primaryServer input parameter has been changed to an array to allow for multiple servers to be specified.

  4. Documented the test sequence.

  5. In order to simplify the specifications and avoid confusion, inter-case dependencies have been removed from the HTML representation.

  6. Added the DNS_INCONSISTENT_RESPONSES to all test cases in the DNS and DNSSEC suites.

  7. Upgraded the ZM_RNAME_MISUSED_AT_SIGN and ZM_DIFFERENT_SOURCE_IP errors to ERROR.

  8. Case maturity metrics: ALPHA <1% (no change), BETA 50% (no change), GAMMA 50% (no change)

2.6. Wednesday, February 21, 2024

  1. The ZM_NAMESERVER_IP_PRIVATE_NETWORK error now has CRITICAL severity.

  2. The suites that use an Input Parameter are now listed, in addition to any test cases.

  3. All cases in the Minimum RPMs suite are now at BETA maturity, except for minimumRPMs-03, which may change due to anticipated changes to the Trademark Claims policy.

  4. All cases in the DNSSEC Operations suite are now at BETA maturity.

  5. Clarified wording of the DNSSEC Operations test cases and added configuration guidance for applicants.

  6. Any DNS query or XFR that fails during the DNSSEC Operations suite is now an error.

  7. Added the epp.tlsCertificateStore resource to rdap-91.

  8. Added new test plans that will only be available in OT&E, to allow testing of specific test suites.

  9. Added the OTE-Only property to test plan objects indicating the above, and bumped the schema version accordingly.

  10. All error messages are now documented.

  11. Case maturity metrics: ALPHA <1% (-5%), BETA 50% (+7%), GAMMA 50% (+0%)

2.7. Wednesday, February 14, 2024

  1. Links to references and notes about upgraded message severities in Zonemaster cases have been fixed.

  2. the epp.greeting input parameter is now a file upload.

  3. added schemas to all input parameters that didn’t have them.

  4. Case maturity metrics: ALPHA 7% (+2%), BETA 43% (-14%), GAMMA 50% (+12%)

2.8. Wednesday, February 7, 2024

  1. Zonemaster cases are now generated directly from Zonemaster::Engine, so now include all possible error messages.

  2. Rather than placing “common” errors at the suite level, each case now lists all the errors it may emit. In the HTML output, the cases that may emit an error are listed for each error.

  3. Began providing descriptions of errors, and adjusting their severity levels accordingly.

  4. Protocol-related errors are now standardised, so for example, the SRSGW and IDN cases use the same errors as the EPP cases, for EPP-related errors.

  5. The way that the specification version is calculated has changed to accommodate the new release process (now that the repository has multiple branches, counting commits can result in two files having the same version).

  6. Case maturity metrics: ALPHA 5% (-2%), BETA 57% (-17%), GAMMA 38% (+19%)

2.9. Wednesday, January 31, 2024

  1. Added this ChangeLog.

  2. Add content of NS records to the list of names checked in dns-zz-idna2008-compliance.

  3. Add dnssec-93 test case.

  4. Remove the dnssec-12, dnssec-15, dnssec-16, dnssec-17 and dnssec-18 test cases.

  5. The ZM_ALGORITHM_NOT_RECOMMENDED error raised by dnssec-05 is now an ERROR.

  6. The maturity of all cases in the EPP suite has been raised to BETA.

  7. Added additional error codes to epp-16.

  8. Added check for transferPeriod RGP status to epp-19.

  9. Add epp-25 test case.

  10. Case maturity metrics: ALPHA 7% , BETA 74%, GAMMA 19%

3. Preamble

This file describes each test plan, suite and case in the RST service, as well as the input parameters required for each; relevant resources; data providers; and the errors that may occur during testing.

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119 when, and only when, they appear in all capitals, as shown here.

2.1. Test plans

An individual Test Plan addresses a particular scenario (for example, RSP evaluation or Pre-Delegation Testing). Each plan consists of one or more test suites, which in turn include one or more test cases.

2.1.1. Test plan types

There are two types of test plan described in this document:

  • “Business as usual” plans, which are used as part of the lifecycle of a gTLD (e.g., Pre-Delegation Test, RSP/DNS RSP change Test, IDN Test, SRS Gateway Test);

  • RSP evaluation plans, which are used as part of the RSP evaluation program.

2.2. Test suites

A Test Suite is a collection of test cases with a common theme or subject matter, for example, Authoritative DNS or Registry Data Escrow.

2.3. Test cases

A Test Case describes a process for determining the conformance or acceptability of a certain element of the system.

A test case consists of a test procedure that accepts zero or more input parameters, and generates one or more test results.

2.3.1. Input parameters

All test cases require some information about the subject of the test, for example, service hostnames, credentials, and functional parameters. These input parameters may be shared across multiple test cases.

2.3.2. Data providers

Some test cases involve performing multiple operations (such as creating objects) using slightly different input values each time, in order to test the behaviour of a system and its ability to validate inputs. To simplify implementation and provide clarity for test subjects, data providers are used to enumerate all the possible permutations of input values. A data provider consists of sets of input values, plus the expected outcome, and the error code that should be raised if the outcome does not match the expected outcome.

2.3.3. Test environments

Each test plan indicates whether the test is to be carried out in the production environment, or whether a test, staging or Operational Testing and Evaluation (OT&E) environment may be used. In general, test plans which are designed for “business as usual” use during the lifecycle of a TLD MUST be carried out in the production registry infrastructure, while RSP evaluation tests MAY be carried out in test, staging or OT&E environments.

2.3.4. Test results

Test cases will generate one or more test results. Test results indicate the outcome of the test and other relevant information.

2.3.5. General pass/fail criteria

In general, for a test to pass, all the test cases specified in the test suite(s) for the test plan MUST pass: if any fail, then the test as a whole will fail.

A test case will fail if it produces one or more errors with the ERROR or CRITICAL severities.

2.3.6. Error severity levels

The supported severity levels are a subset of the values defined in RFC 5424.

  1. WARNING - an issue which does not prevent the test from passing, but which may benefit from further investigation.
  2. ERROR - an issue which prevents the test case from passing, but does not prevent the test case from continuing. A test case may produce multiple ERROR results.
  3. CRITICAL - an issue which prevents the test case from continuing any further. A test case will only produce a single CRITICAL result and it will always be the last result in the log.

2.4. Test procedures

Where possible, test cases will reuse existing connections and any objects created as part of previous test cases, to reduce the resources required to perform service testing. However, it is anticipated that registry services will see a moderate volume of connections from test systems, and a moderate number of objects may be created as part of the test. The level of resource consumption is anticipated to be significantly lower than that experienced by a live production system, so in “business as usual” scenarios, where production systems are being tested, no impact to those systems is expected.

Where a test is being carried out using test, staging or OT&E environments, then those systems should be provisioned with sufficient capacity to allow testing to be carried out without interruption. Any existing OT&E environment supporting registrar integration testing and onboarding is likely to be sufficiently robust to support Registry System Testing with no further additional capacity requirements.

2.5. Test sequence

The test system will generate a linear test sequence based on the test suite(s) and test case(s) used by the specified test plan. The test cases will be sorted in canonical alphanumeric order and executed in that order.

If a test case produces any ERROR or CRITICAL messages, the test run will stop at that point.

Future versions may optimize the test sequence using knowledge of intercase dependencies to allow certain parts of the sequence to be run in parallel.

2.6. Key acronyms and terms

RST
Registry System Testing. This system.
PDT
Pre-Delegation Test. A test carried out prior to the delegation of a new TLD into the DNS root zone.
RSP
Registry Service Provider. A specialist provider of critical registry services.
DNS
Domain Name System. The Internet’s system of globally unique identifiers.
TLD
Top-level domain. The highest level of the DNS namespace hierarchy.
gTLD
generic top-level domain.
DNSSEC
DNS Security Extensions. DNSSEC is described in BCP 237.
EPP
Extensible Provisioning Protocol. The protocol used by registrars to create and manage domain name registrations in an SRS. EPP is defined in STD 69.
SRS
Shared Registry System. A TLD registry in which registrations are managed by one or more registrars, using EPP.
RDDS
Registration Data Directory Services. A service to provide access to data about domain registrations to third parties.
RDAP
Registration Data Access Protocol. The protocol used to deliver the RDDS. RDAP is defined in STD 95.
RDE
Registry Data Escrow. A system whereby the registration data stored in a Shared Registry System is backed up to a trusted third party. RDE is defined in RFC 8909 and RFC 9022.
IDN
Internationalized Domain Name. A domain name that contains characters not in the ASCII character set. The technical specification for IDNs may be found in RFC 5890. All gTLDs must comply with ICANN’s IDN Guidelines.
LGR
Label Generation Ruleset. The rules by which IDNs are validated. LGRs are described in RFC 7940.
RO
Registry Operator. The entity to which ICANN has granted the right to operate a gTLD.
RA
Registry Agreement. The contract between a Registry Operator and ICANN. The base Registry Agreement may be reviewed at https://www.icann.org/en/registry-agreements/base-agreement.
KSK
Key Signing Key. A cryptographic key that serves as the Secure Entry Point for a DNS zone, and which signs a DNS zone’s ZSKs. A digest of this key is published in the parent zone (ie. the root zone for a TLD).
ZSK
Zone Signing Key. A cryptographic key that signs a DNS zone’s resource records.
CSK
Combined Signing Key. A cryptographic key used as both a KSK and a ZSK.
RPMs
Rights Protection Mechanisms, intended to discourage or prevent registration of domain names that violate or abuse another party’s legal rights. These MUST include (but are not limited to): (1) Sunrise Periods, and (2) Trademark Claims Periods (see Specification 7 of the Registry Agreement).
TMCH
Trademark Clearinghouse. The system used by ICANN to maintain a database of validated and registered trademarks which is used to enforce Rights Protection Mechanisms (RPMs) in gTLDs. The functional specifications of the TMCH are defined in RFC 9361.
SLA
Service Level Agreement. The registry performance specifications laid out in Specification 10 of the Registry Agreement.
RRI
Registration Reporting Interfaces. The interfaces provided by ICANN to contracted parties including Registry Operators to fulfill and monitor their applicable reporting requirements, including per-registrar transaction reports; registry functions activity reports; data escrow deposits reports and data escrow deposits notifications. For registry operators, the relevant interfaces are defined in draft-lozano-icann-registry-interfaces.

4. Test Plans

4.1. Pre-Delegation Test

4.1.1. Description

The purpose of the Pre-Delegation Test is to verify that the applicant has met its commitment to establish registry operations in accordance with the technical and operational criteria described in the gTLD Applicant Guidebook (AGB). Each applicant will be required to complete PDT as a prerequisite to delegation into the root zone.

The Pre-Delegation Test covers all critical registry services and IDNs, and therefore uses all standard test suites.

Note on test environment: this is a “business as usual” test, designed to test a soon-to-be or already delegated TLD. Therefore, all input parameters provided MUST relate to the production registry environment.

Pass/fail criteria

As with all other test plans, for this test to pass, all the listed test cases MUST pass: if any fail, then the test as a whole will fail.

4.1.2. Plan ID

The following Test Plan ID may be used with the RST API:

StandardPreDelegationTest

4.1.3. Test suites

This plan uses the following test suites:

  1. Authoritative DNS Service
  2. DNS Security Extensions (DNSSEC)
  3. Registration Data Access Protocol (RDAP)
  4. Extensible Provisioning Protocol (EPP)
  5. Registry Data Escrow (RDE)
  6. Internationalized Domain Names (IDN)
  7. Standard Integration Test

4.1.4. Resources

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

4.1.5. Errors

This test plan may produce the following errors:

4.1.6. Input parameters

This plan requires the following input parameters:

4.1.7. Required files

4.1.8. RST-API example

POST /test/987654/inputs HTTP/1.1
Content-Type: application/json
Content-Length: 2591

{
   "dns.nameservers" : [
      {
         "name" : "ns1.example.com",
         "v4Addrs" : [
            "192.0.2.1"
         ],
         "v6Addrs" : [
            "2001:DB8::53:1"
         ]
      },
      {
         "name" : "ns2.example.net",
         "v4Addrs" : [
            "192.0.2.2"
         ],
         "v6Addrs" : [
            "2001:DB8::53:2"
         ]
      }
   ],
   "dnssec.dsRecords" : [
      {
         "dsRecords" : [
            {
               "alg" : 8,
               "digest" : "E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D",
               "digestType" : 2,
               "keyTag" : 12345
            }
         ],
         "name" : "example"
      }
   ],
   "epp.clid01" : "clid-01",
   "epp.clid01DataModel" : "minimum",
   "epp.clid02" : "clid-02",
   "epp.clid02DataModel" : "minimum",
   "epp.greeting" : "greeting.xml",
   "epp.hostModel" : "objects",
   "epp.hostName" : "epp.rsp.tech",
   "epp.pwd01" : "foo2bar",
   "epp.pwd02" : "foo3bar",
   "epp.registeredContacts" : [
      "abc123",
      "def321"
   ],
   "epp.registeredNames" : [
      "example.example1",
      "example.example2"
   ],
   "epp.registeredNameservers" : [
      "ns1.example.com",
      "ns2.example.org"
   ],
   "epp.requiredContactTypes" : [
      "admin"
   ],
   "epp.restoreReportRequired" : false,
   "epp.secDNSInterfaces" : "dsData",
   "epp.serverIssuedClientCertificate01" : "rst_test_client_cert.pem",
   "epp.serverIssuedClientCertificate02" : "rst_test_client_cert.pem",
   "general.registryDataModel" : "minimum",
   "integration.rdeSFTPDirectory" : "/path/to/deposits",
   "integration.rdeSFTPHostname" : "sftp.rsp.tech",
   "integration.rdeSFTPUsername" : "icann",
   "integration.rriACL" : {
      "v4Addrs" : [
         "192.0.2.1",
         "192.0.2.2"
      ],
      "v6Addrs" : [
         "2001:DB8::22:1",
         "2001:DB8::22:2"
      ]
   },
   "rdap.baseURLs" : [
      {
         "baseURL" : "https://rdap.example.com/example/",
         "tld" : "example"
      }
   ],
   "rdap.testDomains" : [
      "example.com",
      "example.net"
   ],
   "rdap.testEntities" : [
      {
         "handle" : 9995,
         "tld" : "example"
      }
   ],
   "rdap.testNameservers" : [
      {
         "nameserver" : "ns1.example.com",
         "tld" : "example1"
      },
      {
         "nameserver" : "ns1.example.com",
         "tld" : "example2"
      }
   ],
   "rde.depositFile" : "example_20231004_FULL_S1_R0.ryde",
   "rde.publicKey" : "rsp-rde-signing-key.asc",
   "rde.signatureFile" : "example_20231004_FULL_S1_R0.sig"
}

4.2. RSP Change Test

4.2.1. Description

A Registry Operator may apply to ICANN to change a Material Subcontracting Arrangement (MSA) and appoint a new Registry Services Provider. Before this change can be approved, the new RSP MUST complete Registry System Testing to ensure their systems comply with the technical and operational requirements of the Registry Agreement.

The RSP Change Test covers all critical registry services and IDNs, and therefore uses all test standard suites.

Note on test environment: this is a “business as usual” test, designed to test a soon-to-be or already delegated TLD. Therefore, all input parameters provided MUST relate to the production registry environment.

Pass/fail criteria

As with all other test plans, for this test to pass, all the listed test cases MUST pass: if any fail, then the test as a whole will fail.

4.2.2. Plan ID

The following Test Plan ID may be used with the RST API:

StandardRSPChangeTest

4.2.3. Test suites

This plan uses the following test suites:

  1. Authoritative DNS Service
  2. DNS Security Extensions (DNSSEC)
  3. Registration Data Access Protocol (RDAP)
  4. Extensible Provisioning Protocol (EPP)
  5. Registry Data Escrow (RDE)
  6. Internationalized Domain Names (IDN)
  7. Standard Integration Test

4.2.4. Resources

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

4.2.5. Errors

This test plan may produce the following errors:

4.2.6. Input parameters

This plan requires the following input parameters:

4.2.7. Required files

4.2.8. RST-API example

POST /test/987654/inputs HTTP/1.1
Content-Type: application/json
Content-Length: 2591

{
   "dns.nameservers" : [
      {
         "name" : "ns1.example.com",
         "v4Addrs" : [
            "192.0.2.1"
         ],
         "v6Addrs" : [
            "2001:DB8::53:1"
         ]
      },
      {
         "name" : "ns2.example.net",
         "v4Addrs" : [
            "192.0.2.2"
         ],
         "v6Addrs" : [
            "2001:DB8::53:2"
         ]
      }
   ],
   "dnssec.dsRecords" : [
      {
         "dsRecords" : [
            {
               "alg" : 8,
               "digest" : "E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D",
               "digestType" : 2,
               "keyTag" : 12345
            }
         ],
         "name" : "example"
      }
   ],
   "epp.clid01" : "clid-01",
   "epp.clid01DataModel" : "minimum",
   "epp.clid02" : "clid-02",
   "epp.clid02DataModel" : "minimum",
   "epp.greeting" : "greeting.xml",
   "epp.hostModel" : "objects",
   "epp.hostName" : "epp.rsp.tech",
   "epp.pwd01" : "foo2bar",
   "epp.pwd02" : "foo3bar",
   "epp.registeredContacts" : [
      "abc123",
      "def321"
   ],
   "epp.registeredNames" : [
      "example.example1",
      "example.example2"
   ],
   "epp.registeredNameservers" : [
      "ns1.example.com",
      "ns2.example.org"
   ],
   "epp.requiredContactTypes" : [
      "admin"
   ],
   "epp.restoreReportRequired" : false,
   "epp.secDNSInterfaces" : "dsData",
   "epp.serverIssuedClientCertificate01" : "rst_test_client_cert.pem",
   "epp.serverIssuedClientCertificate02" : "rst_test_client_cert.pem",
   "general.registryDataModel" : "minimum",
   "integration.rdeSFTPDirectory" : "/path/to/deposits",
   "integration.rdeSFTPHostname" : "sftp.rsp.tech",
   "integration.rdeSFTPUsername" : "icann",
   "integration.rriACL" : {
      "v4Addrs" : [
         "192.0.2.1",
         "192.0.2.2"
      ],
      "v6Addrs" : [
         "2001:DB8::22:1",
         "2001:DB8::22:2"
      ]
   },
   "rdap.baseURLs" : [
      {
         "baseURL" : "https://rdap.example.com/example/",
         "tld" : "example"
      }
   ],
   "rdap.testDomains" : [
      "example.com",
      "example.net"
   ],
   "rdap.testEntities" : [
      {
         "handle" : 9995,
         "tld" : "example"
      }
   ],
   "rdap.testNameservers" : [
      {
         "nameserver" : "ns1.example.com",
         "tld" : "example1"
      },
      {
         "nameserver" : "ns1.example.com",
         "tld" : "example2"
      }
   ],
   "rde.depositFile" : "example_20231004_FULL_S1_R0.ryde",
   "rde.publicKey" : "rsp-rde-signing-key.asc",
   "rde.signatureFile" : "example_20231004_FULL_S1_R0.sig"
}

4.3. DNS RSP Change Test

4.3.1. Description

A Registry Operator may apply to ICANN to change a Material Subcontracting Arrangement (MSA) and appoint a new provider of authoritative DNS services instead of or in addition to any existing provider(s).

Before this change can be approved, the new DNS provider MUST complete testing to ensure their systems comply with the technical and operational requirements of the Registry Agreement.

The DNS RSP Change Test uses the DNS test suite only.

Note on test environment: this is a “business as usual” test, designed to test a soon-to-be or already delegated TLD. Therefore, all input parameters provided MUST relate to the production registry environment.

Pass/fail criteria

As with all other test plans, for this test to pass, all the listed test cases MUST pass: if any fail, then the test as a whole will fail.

4.3.2. Plan ID

The following Test Plan ID may be used with the RST API:

DNSRSPChangeTest

4.3.3. Test suites

This plan uses the following test suites:

  1. Authoritative DNS Service
  2. DNS Security Extensions (DNSSEC)

4.3.4. Resources

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

  • None specified.

4.3.5. Errors

This test plan may produce the following errors:

4.3.6. Input parameters

This plan requires the following input parameters:

4.3.7. Required files

  • None specified.

4.3.8. RST-API example

POST /test/987654/inputs HTTP/1.1
Content-Type: application/json
Content-Length: 711

{
   "dns.nameservers" : [
      {
         "name" : "ns1.example.com",
         "v4Addrs" : [
            "192.0.2.1"
         ],
         "v6Addrs" : [
            "2001:DB8::53:1"
         ]
      },
      {
         "name" : "ns2.example.net",
         "v4Addrs" : [
            "192.0.2.2"
         ],
         "v6Addrs" : [
            "2001:DB8::53:2"
         ]
      }
   ],
   "dnssec.dsRecords" : [
      {
         "dsRecords" : [
            {
               "alg" : 8,
               "digest" : "E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D",
               "digestType" : 2,
               "keyTag" : 12345
            }
         ],
         "name" : "example"
      }
   ]
}

4.4. Standard IDN Test

4.4.1. Description

A Registry Operator may apply to ICANN to amend its Registry Agreement to offer new scripts and/or languages for Internationalized Domain Names.

The purpose of an IDN RST test is to verify that the Registry Operator’s registry system handles IDN registrations in accordance with the submitted policy statements and IDN tables.

The IDN Test uses the IDN test suite only.

Note on test environment: this is a “business as usual” test, designed to test a soon-to-be or already delegated TLD. Therefore, all input parameters provided MUST relate to the production registry environment.

Pass/fail criteria

As with all other test plans, for this test to pass, all the listed test cases MUST pass: if any fail, then the test as a whole will fail.

4.4.2. Plan ID

The following Test Plan ID may be used with the RST API:

StandardIDNTest

4.4.3. Test suites

This plan uses the following test suites:

  1. Internationalized Domain Names (IDN)

4.4.4. Resources

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

4.4.5. Errors

This test plan may produce the following errors:

4.4.6. Input parameters

This plan requires the following input parameters:

4.4.7. Required files

4.4.8. RST-API example

POST /test/987654/inputs HTTP/1.1
Content-Type: application/json
Content-Length: 501

{
   "epp.clid01" : "clid-01",
   "epp.clid01DataModel" : "minimum",
   "epp.clid02" : "clid-02",
   "epp.clid02DataModel" : "minimum",
   "epp.hostModel" : "objects",
   "epp.hostName" : "epp.rsp.tech",
   "epp.pwd01" : "foo2bar",
   "epp.pwd02" : "foo3bar",
   "epp.requiredContactTypes" : [
      "admin"
   ],
   "epp.serverIssuedClientCertificate01" : "rst_test_client_cert.pem",
   "epp.serverIssuedClientCertificate02" : "rst_test_client_cert.pem",
   "general.registryDataModel" : "minimum"
}

4.5. IDN Test (RSP Evaluation)

4.5.1. Description

This test plan is identical to the Standard IDN Test, but is intended solely for use in the RSP evaluation program.

One key difference between this plan and the Standard IDN Test is that the TLD string(s) that will be used will not be real (delegated or applied-for) TLDs but test TLDs that will be determined by ICANN. Test subjects will be required to configure their systems to support these TLDs prior to the start of the test run.

Note on test environment: this is a “business as usual” test, designed to test a soon-to-be or already delegated TLD. Therefore, all input parameters provided MUST relate to the production registry environment.

Pass/fail criteria

As with all other test plans, for this test to pass, all the listed test cases MUST pass: if any fail, then the test as a whole will fail.

4.5.2. Plan ID

The following Test Plan ID may be used with the RST API:

RSPEvaluationIDNTest

4.5.3. Test suites

This plan uses the following test suites:

  1. Internationalized Domain Names (IDN)

4.5.4. Resources

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

4.5.5. Errors

This test plan may produce the following errors:

4.5.6. Input parameters

This plan requires the following input parameters:

4.5.7. Required files

4.5.8. RST-API example

POST /test/987654/inputs HTTP/1.1
Content-Type: application/json
Content-Length: 501

{
   "epp.clid01" : "clid-01",
   "epp.clid01DataModel" : "minimum",
   "epp.clid02" : "clid-02",
   "epp.clid02DataModel" : "minimum",
   "epp.hostModel" : "objects",
   "epp.hostName" : "epp.rsp.tech",
   "epp.pwd01" : "foo2bar",
   "epp.pwd02" : "foo3bar",
   "epp.requiredContactTypes" : [
      "admin"
   ],
   "epp.serverIssuedClientCertificate01" : "rst_test_client_cert.pem",
   "epp.serverIssuedClientCertificate02" : "rst_test_client_cert.pem",
   "general.registryDataModel" : "minimum"
}

4.6. SRS Gateway Test

4.6.1. Description

An SRS Gateway service is a Shared Registry System implementation that acts as a proxy between a subset of Registrars and the Registry. It uses a local cache to speed up EPP query commands, but forwards all EPP transform commands to the primary registry system. TLD registries need to deploy a proxy setup in order to operate in certain markets worldwide.

The purpose of an SRS Gateway Test is to verify that the Registry Operator’s proxy setup operates in accordance with the technical and operational criteria for EPP systems described in the gTLD Applicant Guidebook (AGB). Furthermore, it MUST keep its own database synchronized with that of the TLD registry.

The SRS Gateway Test Change Test uses the SRS gateway test suite only.

Note on test environment: this is a “business as usual” test, designed to test a soon-to-be or already delegated TLD. Therefore, all input parameters provided MUST relate to the production registry environment.

Pass/fail criteria

As with all other test plans, for this test to pass, all the listed test cases MUST pass: if any fail, then the test as a whole will fail.

4.6.2. Plan ID

The following Test Plan ID may be used with the RST API:

SRSGatewayTest

4.6.3. Test suites

This plan uses the following test suites:

  1. SRS Gateway

4.6.4. Resources

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

4.6.5. Errors

This test plan may produce the following errors:

4.6.6. Input parameters

This plan requires the following input parameters:

4.6.7. Required files

4.6.8. RST-API example

POST /test/987654/inputs HTTP/1.1
Content-Type: application/json
Content-Length: 1055

{
   "epp.clid01" : "clid-01",
   "epp.clid01DataModel" : "minimum",
   "epp.clid02" : "clid-02",
   "epp.clid02DataModel" : "minimum",
   "epp.hostModel" : "objects",
   "epp.hostName" : "epp.rsp.tech",
   "epp.pwd01" : "foo2bar",
   "epp.pwd02" : "foo3bar",
   "epp.requiredContactTypes" : [
      "admin"
   ],
   "epp.serverIssuedClientCertificate01" : "rst_test_client_cert.pem",
   "epp.serverIssuedClientCertificate02" : "rst_test_client_cert.pem",
   "general.registryDataModel" : "minimum",
   "rdap.baseURLs" : [
      {
         "baseURL" : "https://rdap.example.com/example/",
         "tld" : "example"
      }
   ],
   "srsgw.eppClid01" : "clid-01",
   "srsgw.eppClid02" : "clid-02",
   "srsgw.eppHostName" : "epp.rsp.tech",
   "srsgw.eppPwd01" : "foo2bar",
   "srsgw.eppPwd02" : "foo3bar",
   "srsgw.rdapBaseURLs" : [
      {
         "baseURL" : "https://rdap.example.com/example/",
         "tld" : "example"
      }
   ],
   "srsgw.serverIssuedClientCertificate01" : "cert.pem",
   "srsgw.serverIssuedClientCertificate02" : "cert.pem"
}

4.7. Main RSP Evaluation Test

4.7.1. Description

The Main RSP is responsible for the creation and maintenance of domain name registrations in a Shared Registration System (SRS). This encompasses the lifecycle of a domain name registration using domain registrars and protocols such as the Extensible Provisioning Protocol (EPP) and adherence to policies regarding the use and transparency domain name registrations through reporting, the Registration Data Access Protocol (RDAP), and other mechanisms.

Unlike the “business as usual” test plans (e.g. The Pre-Delegation Test) the TLD string(s) that will be used will not be real (delegated or applied-for) TLDs but test TLDs that will be determined by ICANN. Test subjects will be required to configure their systems to support these TLDs prior to the start of the test run.

Note on test environment: this test is designed to be used as part of the RSP evaluation program. Therefore, input parameters MAY be provided the relate to a test, staging or OT&E environment.

Pass/fail criteria

As with all other test plans, for this test to pass, all the listed test cases MUST pass: if any fail, then the test as a whole will fail.

4.7.2. Plan ID

The following Test Plan ID may be used with the RST API:

MainRSPEvaluationTest

4.7.3. Test suites

This plan uses the following test suites:

  1. Registration Data Access Protocol (RDAP)
  2. Extensible Provisioning Protocol (EPP)
  3. Registry Data Escrow (RDE)
  4. Minimum Rights Protection Mechanisms (RPMs)

4.7.4. Resources

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

4.7.5. Errors

This test plan may produce the following errors:

4.7.6. Input parameters

This plan requires the following input parameters:

4.7.7. Required files

4.7.8. RST-API example

POST /test/987654/inputs HTTP/1.1
Content-Type: application/json
Content-Length: 1691

{
   "epp.clid01" : "clid-01",
   "epp.clid01DataModel" : "minimum",
   "epp.clid02" : "clid-02",
   "epp.clid02DataModel" : "minimum",
   "epp.greeting" : "greeting.xml",
   "epp.hostModel" : "objects",
   "epp.hostName" : "epp.rsp.tech",
   "epp.pwd01" : "foo2bar",
   "epp.pwd02" : "foo3bar",
   "epp.registeredContacts" : [
      "abc123",
      "def321"
   ],
   "epp.registeredNames" : [
      "example.example1",
      "example.example2"
   ],
   "epp.registeredNameservers" : [
      "ns1.example.com",
      "ns2.example.org"
   ],
   "epp.requiredContactTypes" : [
      "admin"
   ],
   "epp.restoreReportRequired" : false,
   "epp.secDNSInterfaces" : "dsData",
   "epp.serverIssuedClientCertificate01" : "rst_test_client_cert.pem",
   "epp.serverIssuedClientCertificate02" : "rst_test_client_cert.pem",
   "general.registryDataModel" : "minimum",
   "minimumRPMS.claimsTLD" : "tmclaims.rsp.tech",
   "minimumRPMS.sunriseModels" : "start-date",
   "minimumRPMS.sunriseTLD" : "tmclaims.rsp.tech",
   "rdap.baseURLs" : [
      {
         "baseURL" : "https://rdap.example.com/example/",
         "tld" : "example"
      }
   ],
   "rdap.testDomains" : [
      "example.com",
      "example.net"
   ],
   "rdap.testEntities" : [
      {
         "handle" : 9995,
         "tld" : "example"
      }
   ],
   "rdap.testNameservers" : [
      {
         "nameserver" : "ns1.example.com",
         "tld" : "example1"
      },
      {
         "nameserver" : "ns1.example.com",
         "tld" : "example2"
      }
   ],
   "rde.depositFile" : "example_20231004_FULL_S1_R0.ryde",
   "rde.publicKey" : "rsp-rde-signing-key.asc",
   "rde.signatureFile" : "example_20231004_FULL_S1_R0.sig"
}

4.8. DNS RSP Evaluation Test

4.8.1. Description

DNS RSPs provide primary or secondary authoritative DNS services. Therefore, this test plan only covers the DNS area.

RSPs wishing to offer DNSSEC services in addition to authoritative DNS will also be evaluated using the DNSSEC RSP Evaluation Test.

Unlike the “business as usual” test plans (e.g. The Pre-Delegation Test) the TLD string(s) that will be used will not be real (delegated or applied-for) TLDs but test TLDs that will be determined by ICANN. Test subjects will be required to configure their systems to support these TLDs prior to the start of the test run.

Note on test environment: this test is designed to be used as part of the RSP evaluation program. Therefore, input parameters MAY be provided the relate to a test, staging or OT&E environment.

Pass/fail criteria

As with all other test plans, for this test to pass, all the listed test cases MUST pass: if any fail, then the test as a whole will fail.

4.8.2. Plan ID

The following Test Plan ID may be used with the RST API:

DNSRSPEvaluationTest

4.8.3. Test suites

This plan uses the following test suites:

  1. Authoritative DNS Service

4.8.4. Resources

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

  • None specified.

4.8.5. Errors

This test plan may produce the following errors:

4.8.6. Input parameters

This plan requires the following input parameters:

4.8.7. Required files

  • None specified.

4.8.8. RST-API example

POST /test/987654/inputs HTTP/1.1
Content-Type: application/json
Content-Length: 385

{
   "dns.nameservers" : [
      {
         "name" : "ns1.example.com",
         "v4Addrs" : [
            "192.0.2.1"
         ],
         "v6Addrs" : [
            "2001:DB8::53:1"
         ]
      },
      {
         "name" : "ns2.example.net",
         "v4Addrs" : [
            "192.0.2.2"
         ],
         "v6Addrs" : [
            "2001:DB8::53:2"
         ]
      }
   ]
}

4.9. DNSSEC RSP Evaluation Test

4.9.1. Description

DNSSEC RSPs provide signing of TLD zone files as a service. They do not provide primary or secondary authoritative DNS services.

RSPs wishing to offer authoritative DNS services in addition to authoritative DNS will also be evaluated using the DNS RSP Evaluation Test.

Unlike the “business as usual” test plans (e.g. The Pre-Delegation Test) the TLD string(s) that will be used will not be real (delegated or applied-for) TLDs but test TLDs that will be determined by ICANN. Test subjects will be required to configure their systems to support these TLDs prior to the start of the test run.

Note on test environment: this test is designed to be used as part of the RSP evaluation program. Therefore, input parameters MAY be provided the relate to a test, staging or OT&E environment.

As with all other test plans, for this test to pass, all the listed test cases MUST pass: if any fail, then the test as a whole will fail.

4.9.2. Plan ID

The following Test Plan ID may be used with the RST API:

DNSSECRSPEvaluationTest

4.9.3. Test suites

This plan uses the following test suites:

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

4.9.4. Resources

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

4.9.5. Errors

This test plan may produce the following errors:

4.9.6. Input parameters

This plan requires the following input parameters:

4.9.7. Required files

  • None specified.

4.9.8. RST-API example

POST /test/987654/inputs HTTP/1.1
Content-Type: application/json
Content-Length: 1583

{
   "dns.nameservers" : [
      {
         "name" : "ns1.example.com",
         "v4Addrs" : [
            "192.0.2.1"
         ],
         "v6Addrs" : [
            "2001:DB8::53:1"
         ]
      },
      {
         "name" : "ns2.example.net",
         "v4Addrs" : [
            "192.0.2.2"
         ],
         "v6Addrs" : [
            "2001:DB8::53:2"
         ]
      }
   ],
   "dnssec.dsRecords" : [
      {
         "dsRecords" : [
            {
               "alg" : 8,
               "digest" : "E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D",
               "digestType" : 2,
               "keyTag" : 12345
            }
         ],
         "name" : "example"
      }
   ],
   "dnssecOps.algorithmRolloverZone" : "example.com",
   "dnssecOps.csk" : false,
   "dnssecOps.kskRolloverZone" : "example.com",
   "dnssecOps.nameservers" : [
      {
         "name" : "ns1.example.com",
         "v4addrs" : [
            "192.0.2.1"
         ],
         "v6addrs" : [
            "2001:DB8::53:1"
         ]
      },
      {
         "name" : "ns2.example.net",
         "v4addrs" : [
            "192.0.2.2"
         ],
         "v6addrs" : [
            "2001:DB8::53:2"
         ]
      }
   ],
   "dnssecOps.primaryServers" : {
      "v4Addrs" : [
         "192.0.2.1"
      ],
      "v6Addrs" : [
         "2001:DB8::53:2"
      ]
   },
   "dnssecOps.tsigKey" : {
      "algorithm" : "hmac-sha256",
      "name" : "rst-tsig-01",
      "secret" : "cSevMti9Wj6P2i4SsK4bHRnzUKT8k/FGOUoPLZ7kYm8="
   },
   "dnssecOps.zskRolloverZone" : "example.com"
}

4.10. SRS Gateway RSP Evaluation Test

4.10.1. Description

SRS Gateway RSPs provide a proxy between a subset of Registrars and the Registry. It uses a local cache to speed up EPP query commands, but forwards all EPP transform commands to the primary registry system. TLD registries need to deploy a proxy setup in order to operate in certain markets worldwide.

The SRS Gateway test suite requires access to a primary registry system that is logically independent of the SRS Gateway system, and details of the primary registry system are required as input parameters.

RSPs wishing to offer SRS gateway services MUST identify such a primary registry system, which MUST be independent of the SRS gateway system, and MAY be operated by a third party.

Unlike the “business as usual” test plans (e.g. The Pre-Delegation Test) the TLD string(s) that will be used will not be real (delegated or applied-for) TLDs but test TLDs that will be determined by ICANN. Test subjects will be required to configure their systems to support these TLDs prior to the start of the test run.

Note on test environment: this test is designed to be used as part of the RSP evaluation program. Therefore, input parameters MAY be provided the relate to a test, staging or OT&E environment.

Pass/fail criteria

As with all other test plans, for this test to pass, all the listed test cases MUST pass: if any fail, then the test as a whole will fail.

4.10.2. Plan ID

The following Test Plan ID may be used with the RST API:

SRSGatewayRSPTest

4.10.3. Test suites

This plan uses the following test suites:

  1. SRS Gateway

4.10.4. Resources

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

4.10.5. Errors

This test plan may produce the following errors:

4.10.6. Input parameters

This plan requires the following input parameters:

4.10.7. Required files

4.10.8. RST-API example

POST /test/987654/inputs HTTP/1.1
Content-Type: application/json
Content-Length: 1055

{
   "epp.clid01" : "clid-01",
   "epp.clid01DataModel" : "minimum",
   "epp.clid02" : "clid-02",
   "epp.clid02DataModel" : "minimum",
   "epp.hostModel" : "objects",
   "epp.hostName" : "epp.rsp.tech",
   "epp.pwd01" : "foo2bar",
   "epp.pwd02" : "foo3bar",
   "epp.requiredContactTypes" : [
      "admin"
   ],
   "epp.serverIssuedClientCertificate01" : "rst_test_client_cert.pem",
   "epp.serverIssuedClientCertificate02" : "rst_test_client_cert.pem",
   "general.registryDataModel" : "minimum",
   "rdap.baseURLs" : [
      {
         "baseURL" : "https://rdap.example.com/example/",
         "tld" : "example"
      }
   ],
   "srsgw.eppClid01" : "clid-01",
   "srsgw.eppClid02" : "clid-02",
   "srsgw.eppHostName" : "epp.rsp.tech",
   "srsgw.eppPwd01" : "foo2bar",
   "srsgw.eppPwd02" : "foo3bar",
   "srsgw.rdapBaseURLs" : [
      {
         "baseURL" : "https://rdap.example.com/example/",
         "tld" : "example"
      }
   ],
   "srsgw.serverIssuedClientCertificate01" : "cert.pem",
   "srsgw.serverIssuedClientCertificate02" : "cert.pem"
}

4.11. StandardDNS (OT&E only)

4.11.1. Description

Note: this plan is only available in the OT&E environment.

This test plan allows an RSP to request testing of a single test suite, specifically the StandardDNS suite.

4.11.2. Plan ID

The following Test Plan ID may be used with the RST API:

StandardDNSOnly

4.11.3. Test suites

This plan uses the following test suites:

  1. Authoritative DNS Service

4.11.4. Resources

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

  • None specified.

4.11.5. Errors

This test plan may produce the following errors:

4.11.6. Input parameters

This plan requires the following input parameters:

4.11.7. Required files

  • None specified.

4.11.8. RST-API example

POST /test/987654/inputs HTTP/1.1
Content-Type: application/json
Content-Length: 385

{
   "dns.nameservers" : [
      {
         "name" : "ns1.example.com",
         "v4Addrs" : [
            "192.0.2.1"
         ],
         "v6Addrs" : [
            "2001:DB8::53:1"
         ]
      },
      {
         "name" : "ns2.example.net",
         "v4Addrs" : [
            "192.0.2.2"
         ],
         "v6Addrs" : [
            "2001:DB8::53:2"
         ]
      }
   ]
}

4.12. StandardDNSSEC (OT&E only)

4.12.1. Description

Note: this plan is only available in the OT&E environment.

This test plan allows an RSP to request testing of a single test suite, specifically the StandardDNSSEC suite.

4.12.2. Plan ID

The following Test Plan ID may be used with the RST API:

StandardDNSSECOnly

4.12.3. Test suites

This plan uses the following test suites:

  1. DNS Security Extensions (DNSSEC)

4.12.4. Resources

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

  • None specified.

4.12.5. Errors

This test plan may produce the following errors:

4.12.6. Input parameters

This plan requires the following input parameters:

4.12.7. Required files

  • None specified.

4.12.8. RST-API example

POST /test/987654/inputs HTTP/1.1
Content-Type: application/json
Content-Length: 711

{
   "dns.nameservers" : [
      {
         "name" : "ns1.example.com",
         "v4Addrs" : [
            "192.0.2.1"
         ],
         "v6Addrs" : [
            "2001:DB8::53:1"
         ]
      },
      {
         "name" : "ns2.example.net",
         "v4Addrs" : [
            "192.0.2.2"
         ],
         "v6Addrs" : [
            "2001:DB8::53:2"
         ]
      }
   ],
   "dnssec.dsRecords" : [
      {
         "dsRecords" : [
            {
               "alg" : 8,
               "digest" : "E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D",
               "digestType" : 2,
               "keyTag" : 12345
            }
         ],
         "name" : "example"
      }
   ]
}

4.13. StandardRDAP (OT&E only)

4.13.1. Description

Note: this plan is only available in the OT&E environment.

This test plan allows an RSP to request testing of a single test suite, specifically the StandardRDAP suite.

4.13.2. Plan ID

The following Test Plan ID may be used with the RST API:

StandardRDAPOnly

4.13.3. Test suites

This plan uses the following test suites:

  1. Registration Data Access Protocol (RDAP)

4.13.4. Resources

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

4.13.5. Errors

This test plan may produce the following errors:

4.13.6. Input parameters

This plan requires the following input parameters:

4.13.7. Required files

  • None specified.

4.13.8. RST-API example

POST /test/987654/inputs HTTP/1.1
Content-Type: application/json
Content-Length: 519

{
   "rdap.baseURLs" : [
      {
         "baseURL" : "https://rdap.example.com/example/",
         "tld" : "example"
      }
   ],
   "rdap.testDomains" : [
      "example.com",
      "example.net"
   ],
   "rdap.testEntities" : [
      {
         "handle" : 9995,
         "tld" : "example"
      }
   ],
   "rdap.testNameservers" : [
      {
         "nameserver" : "ns1.example.com",
         "tld" : "example1"
      },
      {
         "nameserver" : "ns1.example.com",
         "tld" : "example2"
      }
   ]
}

4.14. StandardEPP (OT&E only)

4.14.1. Description

Note: this plan is only available in the OT&E environment.

This test plan allows an RSP to request testing of a single test suite, specifically the StandardEPP suite.

4.14.2. Plan ID

The following Test Plan ID may be used with the RST API:

StandardEPPOnly

4.14.3. Test suites

This plan uses the following test suites:

  1. Extensible Provisioning Protocol (EPP)

4.14.4. Resources

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

4.14.5. Errors

This test plan may produce the following errors:

4.14.6. Input parameters

This plan requires the following input parameters:

4.14.7. Required files

4.14.8. RST-API example

POST /test/987654/inputs HTTP/1.1
Content-Type: application/json
Content-Length: 860

{
   "epp.clid01" : "clid-01",
   "epp.clid01DataModel" : "minimum",
   "epp.clid02" : "clid-02",
   "epp.clid02DataModel" : "minimum",
   "epp.greeting" : "greeting.xml",
   "epp.hostModel" : "objects",
   "epp.hostName" : "epp.rsp.tech",
   "epp.pwd01" : "foo2bar",
   "epp.pwd02" : "foo3bar",
   "epp.registeredContacts" : [
      "abc123",
      "def321"
   ],
   "epp.registeredNames" : [
      "example.example1",
      "example.example2"
   ],
   "epp.registeredNameservers" : [
      "ns1.example.com",
      "ns2.example.org"
   ],
   "epp.requiredContactTypes" : [
      "admin"
   ],
   "epp.restoreReportRequired" : false,
   "epp.secDNSInterfaces" : "dsData",
   "epp.serverIssuedClientCertificate01" : "rst_test_client_cert.pem",
   "epp.serverIssuedClientCertificate02" : "rst_test_client_cert.pem",
   "general.registryDataModel" : "minimum"
}

4.15. StandardRDE (OT&E only)

4.15.1. Description

Note: this plan is only available in the OT&E environment.

This test plan allows an RSP to request testing of a single test suite, specifically the StandardRDE suite.

4.15.2. Plan ID

The following Test Plan ID may be used with the RST API:

StandardRDEOnly

4.15.3. Test suites

This plan uses the following test suites:

  1. Registry Data Escrow (RDE)

4.15.4. Resources

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

4.15.5. Errors

This test plan may produce the following errors:

4.15.6. Input parameters

This plan requires the following input parameters:

4.15.7. Required files

4.15.8. RST-API example

POST /test/987654/inputs HTTP/1.1
Content-Type: application/json
Content-Length: 206

{
   "epp.greeting" : "greeting.xml",
   "rde.depositFile" : "example_20231004_FULL_S1_R0.ryde",
   "rde.publicKey" : "rsp-rde-signing-key.asc",
   "rde.signatureFile" : "example_20231004_FULL_S1_R0.sig"
}

4.16. StandardSRSGateway (OT&E only)

4.16.1. Description

Note: this plan is only available in the OT&E environment.

This test plan allows an RSP to request testing of a single test suite, specifically the StandardSRSGateway suite.

4.16.2. Plan ID

The following Test Plan ID may be used with the RST API:

StandardSRSGatewayOnly

4.16.3. Test suites

This plan uses the following test suites:

  1. SRS Gateway

4.16.4. Resources

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

4.16.5. Errors

This test plan may produce the following errors:

4.16.6. Input parameters

This plan requires the following input parameters:

4.16.7. Required files

4.16.8. RST-API example

POST /test/987654/inputs HTTP/1.1
Content-Type: application/json
Content-Length: 1055

{
   "epp.clid01" : "clid-01",
   "epp.clid01DataModel" : "minimum",
   "epp.clid02" : "clid-02",
   "epp.clid02DataModel" : "minimum",
   "epp.hostModel" : "objects",
   "epp.hostName" : "epp.rsp.tech",
   "epp.pwd01" : "foo2bar",
   "epp.pwd02" : "foo3bar",
   "epp.requiredContactTypes" : [
      "admin"
   ],
   "epp.serverIssuedClientCertificate01" : "rst_test_client_cert.pem",
   "epp.serverIssuedClientCertificate02" : "rst_test_client_cert.pem",
   "general.registryDataModel" : "minimum",
   "rdap.baseURLs" : [
      {
         "baseURL" : "https://rdap.example.com/example/",
         "tld" : "example"
      }
   ],
   "srsgw.eppClid01" : "clid-01",
   "srsgw.eppClid02" : "clid-02",
   "srsgw.eppHostName" : "epp.rsp.tech",
   "srsgw.eppPwd01" : "foo2bar",
   "srsgw.eppPwd02" : "foo3bar",
   "srsgw.rdapBaseURLs" : [
      {
         "baseURL" : "https://rdap.example.com/example/",
         "tld" : "example"
      }
   ],
   "srsgw.serverIssuedClientCertificate01" : "cert.pem",
   "srsgw.serverIssuedClientCertificate02" : "cert.pem"
}

4.17. MinimumRPMs (OT&E only)

4.17.1. Description

Note: this plan is only available in the OT&E environment.

This test plan allows an RSP to request testing of a single test suite, specifically the MinimumRPMs suite.

4.17.2. Plan ID

The following Test Plan ID may be used with the RST API:

MinimumRPMsOnly

4.17.3. Test suites

This plan uses the following test suites:

  1. Minimum Rights Protection Mechanisms (RPMs)

4.17.4. Resources

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

4.17.5. Errors

This test plan may produce the following errors:

4.17.6. Input parameters

This plan requires the following input parameters:

4.17.7. Required files

4.17.8. RST-API example

POST /test/987654/inputs HTTP/1.1
Content-Type: application/json
Content-Length: 649

{
   "epp.clid01" : "clid-01",
   "epp.clid01DataModel" : "minimum",
   "epp.clid02" : "clid-02",
   "epp.clid02DataModel" : "minimum",
   "epp.hostModel" : "objects",
   "epp.hostName" : "epp.rsp.tech",
   "epp.pwd01" : "foo2bar",
   "epp.pwd02" : "foo3bar",
   "epp.requiredContactTypes" : [
      "admin"
   ],
   "epp.serverIssuedClientCertificate01" : "rst_test_client_cert.pem",
   "epp.serverIssuedClientCertificate02" : "rst_test_client_cert.pem",
   "general.registryDataModel" : "minimum",
   "minimumRPMS.claimsTLD" : "tmclaims.rsp.tech",
   "minimumRPMS.sunriseModels" : "start-date",
   "minimumRPMS.sunriseTLD" : "tmclaims.rsp.tech"
}

5. Test Suites

5.1. Authoritative DNS Service

5.1.1. Description

The DNS test suite validates the authoritative DNS services for the TLD or RSP.

The DNS test suite is derived from the test plans in version v2023.1.4 of Zonemaster. Test case IDs from this document can be mapped to the Zonemaster test IDs by removing the dns- prefix.

Since Zonemaster is designed to perform testing of domain names anywhere in the DNS hierarchy, not all Zonemaster tests are applicable for TLDs and may not be listed in the test suites in this document.

Testing of Anycast networks using multiple vantage points

In order to test anycast networks without requiring RSPs to provide the unicast adresses of their nodes, tests carried out over the network will be performed from multiple vantage points. All vantage points MUST receive the same response in order for the tests to pass.

Pass/fail criteria

As with all other test suites, for this test suite to pass all the listed test cases MUST pass: if any fail, then the suite as a whole will fail.

Unless stated otherwise, the pass/fail criteria for the test cases in this suite are the same as those defined in the Zonemaster documentation: that is, if Zonemaster reports that a test case has an ERROR or CRITICAL result, then the corresponding test case in this suite will fail. INFO, NOTICE and WARNING results will not result in a failed test case. Error codes in this suite are prefixed with ZM_ which map onto the message tags used by Zonemaster.

5.1.2. Test cases

This suite uses the following test cases:

  1. dns-address01 - Name server address must be globally routable
  2. dns-address02 - Reverse DNS entry exists for name server IP address
  3. dns-address03 - Reverse DNS entry matches name server name
  4. dns-connectivity01 - UDP connectivity to name servers
  5. dns-connectivity02 - TCP connectivity to name servers
  6. dns-connectivity03 - AS Diversity
  7. dns-consistency02 - SOA RNAME consistency
  8. dns-consistency03 - SOA timers consistency
  9. dns-consistency04 - Name server NS consistency
  10. dns-consistency05 - Consistency between glue and authoritative data
  11. dns-consistency06 - SOA MNAME consistency
  12. dns-delegation01 - Minimum number of name servers
  13. dns-delegation02 - Name servers must have distinct IP addresses
  14. dns-delegation03 - No truncation of referrals
  15. dns-delegation04 - Name server is authoritative
  16. dns-delegation05 - Name server must not point at CNAME alias
  17. dns-delegation07 - Parent glue name records present in child
  18. dns-nameserver01 - A name server should not be a recursor
  19. dns-nameserver02 - Test of EDNS0 support
  20. dns-nameserver04 - Same source address
  21. dns-nameserver05 - Behaviour against AAAA query
  22. dns-nameserver06 - NS can be resolved
  23. dns-nameserver08 - Testing QNAME case insensitivity
  24. dns-nameserver09 - Testing QNAME case sensitivity
  25. dns-nameserver10 - Test for undefined EDNS version
  26. dns-nameserver11 - Test for unknown EDNS OPTION-CODE
  27. dns-nameserver12 - Test for unknown EDNS flags
  28. dns-nameserver13 - Test for truncated response on EDNS query
  29. dns-syntax05 - Misuse of '@' character in the SOA RNAME field
  30. dns-syntax06 - No illegal characters in the SOA RNAME field
  31. dns-syntax07 - No illegal characters in the SOA MNAME field
  32. dns-zone07 - SOA master is not an alias
  33. dns-zone10 - No multiple SOA records
  34. dns-zz-idna2008-compliance - IDNA2008 compliance check

5.1.3. Test plans

This suite is used by the following test plans:

  1. Pre-Delegation Test
  2. RSP Change Test
  3. DNS RSP Change Test
  4. DNS RSP Evaluation Test
  5. StandardDNS

5.1.4. Resources

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

  • None specified.

5.1.5. Errors

This test suite may produce the following errors:

5.1.6. Input parameters

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

  1. dns.nameservers (input)

5.2. DNS Security Extensions (DNSSEC)

5.2.1. Description

The DNSSEC test suite validates the DNSSEC signing service for the TLD or RSP.

The DNSSEC test suite is derived from the test plans in version v2023.1.4 of Zonemaster. Test case IDs from this document can be mapped to the Zonemaster test IDs by removing the hyphen-minus.

Since Zonemaster is designed to perform testing of domain names anywhere in the DNS hierarchy, not all Zonemaster tests are applicable for TLDs and may not be listed in the test suites in this document.

Pass/fail criteria

As with all other test suites, for this test suite to pass all the listed test cases MUST pass: if any fail, then the suite as a whole will fail.

Unless stated otherwise, the pass/fail criteria for the test cases in this suite are the same as those defined in the Zonemaster documentation: that is, if Zonemaster reports that a test case has an ERROR or CRITICAL result, then the corresponding test case in this suite will fail. INFO, NOTICE and WARNING results will not result in a failed test case. Error codes in this suite are prefixed with ZM_ which map onto the message tags used by Zonemaster.

5.2.2. Test cases

This suite uses the following test cases:

  1. dnssec-01 - Legal values for the DS hash digest algorithm
  2. dnssec-02 - DS must match a valid DNSKEY in the child zone
  3. dnssec-03 - Check for too many NSEC3 iterations
  4. dnssec-04 - Check for too short or too long RRSIG lifetimes
  5. dnssec-05 - Check for invalid DNSKEY algorithms
  6. dnssec-06 - Verify DNSSEC additional processing
  7. dnssec-08 - Valid RRSIG for DNSKEY
  8. dnssec-09 - RRSIG(SOA) must be valid and created by a valid DNSKEY
  9. dnssec-10 - Zone contains NSEC or NSEC3 records
  10. dnssec-13 - All DNSKEY algorithms used to sign the zone
  11. dnssec-14 - Check for valid RSA DNSKEY key size
  12. dnssec-91 - Permitted signing algorithms
  13. dnssec-92 - Permitted DS record hash algorithm(s)
  14. dnssec-93 - NSEC3 iterations check

5.2.3. Test plans

This suite is used by the following test plans:

  1. Pre-Delegation Test
  2. RSP Change Test
  3. DNS RSP Change Test
  4. DNSSEC RSP Evaluation Test
  5. StandardDNSSEC

5.2.4. Resources

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

  • None specified.

5.2.5. Errors

This test suite may produce the following errors:

5.2.6. Input parameters

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

  1. dns.nameservers (input)
  2. dnssec.dsRecords (input)

5.3. Registration Data Access Protocol (RDAP)

5.3.1. Description

The RDAP test suite validates the RDAP service of the TLD or RSP.

The RDAP test suite is derived from the test specification of the RDAP Conformance Tool. As with the DNS and DNSSEC tests, the test IDs can be mapped to the test IDs in this document by removing the rdap-NN- prefix.

Pass/fail criteria

As with all other test suites, for this test suite to pass all the listed test cases MUST pass: if any fail, then the suite as a whole will fail.

5.3.2. Test cases

This suite uses the following test cases:

  1. rdap-01-ipv4Validation - IPv4 address validation
  2. rdap-02-ipv6Validation - IPv6 address validation
  3. rdap-03-domainNameValidation - Domain Name validation
  4. rdap-04-webUriValidation - Web URI validation
  5. rdap-05-domainCaseFoldingValidation - Domain label case folding validation
  6. rdap-06-stdRdapConformanceValidation - RDAP Conformance validation
  7. rdap-07-stdRdapLinksValidation - Links validation
  8. rdap-08-stdRdapNoticesRemarksValidation - Notices and Remarks Validation
  9. rdap-09-stdRdapLanguageIdentifierValidation - Language Identifier Validation
  10. rdap-10-stdRdapEventsValidation - Events Validation
  11. rdap-11-stdRdapStatusValidation - Status validation
  12. rdap-12-stdRdapPort43WhoisServerValidation - Port 43 WHOIS Server
  13. rdap-13-stdRdapPublicIdsValidation - Public IDs validation
  14. rdap-14-stdRdapAsEventActorValidation - asEventActor Validation
  15. rdap-15-stdRdapIpAddressesValidation - IP Addresses Validation
  16. rdap-16-stdRdapVariantsValidation - Variants validation
  17. rdap-17-stdRdapUnicodeNameValidation - Unicode name
  18. rdap-18-stdRdapLdhNameValidation - LDH name
  19. rdap-19-stdRdapRolesValidation - Roles validation
  20. rdap-20-stdRdapEntitiesValidation - Entities validation
  21. rdap-21-stdRdapSecureDnsValidation - Secure DNS validation
  22. rdap-22-stdRdapErrorResponseBodyValidation - Error Response Body
  23. rdap-23-stdRdapDomainLookupValidation - Domain Lookup Validation
  24. rdap-24-stdRdapEntityLookupValidation - Entity lookup validation
  25. rdap-25-stdRdapNameserverLookupValidation - Nameserver lookup validation
  26. rdap-26-stdRdapHelpValidation - Help validation
  27. rdap-27-stdRdapNameserversSearchValidation - Nameservers search validation
  28. rdap-91 - TLS version conformance check
  29. rdap-92 - Service port consistency check

5.3.3. Test plans

This suite is used by the following test plans:

  1. Pre-Delegation Test
  2. RSP Change Test
  3. Main RSP Evaluation Test
  4. StandardRDAP

5.3.4. Resources

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

5.3.5. Errors

This test suite may produce the following errors:

5.3.6. Input parameters

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

  1. rdap.baseURLs (input)
  2. rdap.testDomains (input)
  3. rdap.testEntities (input)
  4. rdap.testNameservers (input)

5.4. Extensible Provisioning Protocol (EPP)

5.4.1. Description

The EPP test suite validates the EPP service of the TLD or RSP. It verifies that the EPP server properly implements the query and transform commands specified for domain names (and optionally host and contact objects) and the mandatory extensions.

Pass/fail criteria

As with all other test suites, for this test suite to pass all the listed test cases MUST pass: if any fail, then the suite as a whole will fail.

5.4.2. Test cases

This suite uses the following test cases:

  1. epp-01 - Service connectivity test
  2. epp-02 - Protocol conformance test
  3. epp-03 - Authentication test
  4. epp-04 - Domain <check> command test
  5. epp-05 - Host <check> command test (if applicable)
  6. epp-06 - Contact <check> command test (if applicable for the registry type)
  7. epp-07 - Contact <create> command test (if applicable for the registry type)
  8. epp-08 - Contact object access control (if applicable)
  9. epp-09 - Contact <update> command test (if applicable for the registry type)
  10. epp-10 - Contact <delete> command test (if applicable for the registry type)
  11. epp-11 - Host <create> command test (if applicable)
  12. epp-12 - Host object access control (if applicable)
  13. epp-13 - Host <update> command test (if applicable)
  14. epp-14 - Domain <create> command test
  15. epp-15 - Registry object integrity test
  16. epp-16 - Domain <update> command test
  17. epp-17 - Service Port consistency test
  18. epp-18 - Domain <renew> command test
  19. epp-19 - Domain <transfer> command test
  20. epp-20 - Domain <transfer> rejection test
  21. epp-21 - Domain <delete> command test
  22. epp-22 - Domain restore test
  23. epp-23 - Host rename test (if applicable)
  24. epp-24 - Host <delete> command test (if applicable)

5.4.3. Test plans

This suite is used by the following test plans:

  1. Pre-Delegation Test
  2. RSP Change Test
  3. Main RSP Evaluation Test
  4. StandardEPP

5.4.4. Resources

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

5.4.5. Errors

This test suite may produce the following errors:

5.4.6. Input parameters

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

  1. epp.clid01 (input)
  2. epp.clid01DataModel (input)
  3. epp.clid02 (input)
  4. epp.clid02DataModel (input)
  5. epp.greeting (file)
  6. epp.hostModel (input)
  7. epp.hostName (input)
  8. epp.pwd01 (input)
  9. epp.pwd02 (input)
  10. epp.registeredContacts (input)
  11. epp.registeredNames (input)
  12. epp.registeredNameservers (input)
  13. epp.requiredContactTypes (input)
  14. epp.restoreReportRequired (input)
  15. epp.secDNSInterfaces (input)
  16. epp.serverIssuedClientCertificate01 (file)
  17. epp.serverIssuedClientCertificate02 (file)
  18. general.registryDataModel (input)

5.5. Registry Data Escrow (RDE)

5.5.1. Description

The RDE test suite validates Registry Data Escrow deposits generated for the TLD or RSP. These deposits MUST comply with the specifications in the Registry Agreement and with RFC 8909 and RFC 9022.

Pass/fail criteria

As with all other test suites, for this test suite to pass all the listed test cases MUST pass: if any fail, then the suite as a whole will fail.

5.5.2. Test cases

This suite uses the following test cases:

  1. rde-01 - validate deposit filename format
  2. rde-02 - validate signature over deposit file
  3. rde-03 - decrypt deposit file(s)
  4. rde-04 - validate XML/CSV
  5. rde-05 - validate object types
  6. rde-06 - validate object counts
  7. rde-07 - validate domain objects
  8. rde-08 - validate host objects (if applicable)
  9. rde-09 - validate contact objects (if applicable)
  10. rde-10 - validate registrar objects
  11. rde-11 - validate IDN table objects (if applicable)
  12. rde-12 - validate NNDN objects
  13. rde-13 - validate EPP parameters object
  14. rde-14 - validate policy object (if applicable)

5.5.3. Test plans

This suite is used by the following test plans:

  1. Pre-Delegation Test
  2. RSP Change Test
  3. Main RSP Evaluation Test
  4. StandardRDE

5.5.4. Resources

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

5.5.5. Errors

This test suite may produce the following errors:

5.5.6. Input parameters

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

  1. epp.greeting (file)
  2. rde.depositFile (file)
  3. rde.publicKey (file)
  4. rde.signatureFile (file)

5.6. Internationalized Domain Names (IDN)

5.6.1. Description

The RDE test suite validates the IDN table(s) for a TLD or RSP, including compliance with specifications for variant labels at the top- or second- level, and conformance with the IDN Guidelines.

Pass/fail criteria

As with all other test suites, for this test suite to pass all the listed test cases MUST pass: if any fail, then the suite as a whole will fail.

5.6.2. Test cases

This suite uses the following test cases:

  1. idn-01 - Label validation test
  2. idn-02 - Level 1 variant handling test
  3. idn-03 - Level 2 variant handling test
  4. idn-04 - Level 3 variant handling test
  5. idn-05 - ASCII domains in IDN-only TLD test
  6. idn-06 - IDNA2008 conformance test

5.6.3. Test plans

This suite is used by the following test plans:

  1. Pre-Delegation Test
  2. RSP Change Test
  3. Standard IDN Test
  4. IDN Test (RSP Evaluation)

5.6.4. Resources

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

5.6.5. Errors

This test suite may produce the following errors:

5.6.6. Input parameters

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

  1. epp.clid01 (input)
  2. epp.clid01DataModel (input)
  3. epp.clid02 (input)
  4. epp.clid02DataModel (input)
  5. epp.hostModel (input)
  6. epp.hostName (input)
  7. epp.pwd01 (input)
  8. epp.pwd02 (input)
  9. epp.requiredContactTypes (input)
  10. epp.serverIssuedClientCertificate01 (file)
  11. epp.serverIssuedClientCertificate02 (file)
  12. general.registryDataModel (input)

5.7. SRS Gateway

5.7.1. Description

The SRS Gateway test suite validates the conformance of the Gateway registry infrastructure of a TLD or RSP, and the synchronisation between primary and gateway systems.

Pass/fail criteria

As with all other test suites, for this test suite to pass all the listed test cases MUST pass: if any fail, then the suite as a whole will fail.

5.7.2. Test cases

This suite uses the following test cases:

  1. srsgw-01 - IPv4 and IPv6 connectivity
  2. srsgw-02 - Host <create> synchronization (if applicable)
  3. srsgw-03 - Contact <create> synchronization (if applicable)
  4. srsgw-04 - Domain <create> synchronization
  5. srsgw-05 - Domain <renew> synchronisation
  6. srsgw-06 - Domain <transfer> synchronisation
  7. srsgw-07 - Domain <transfer> approval synchronisation
  8. srsgw-08 - Domain <delete> synchronisation
  9. srsgw-09 - Host <update> synchronization (if applicable)
  10. srsgw-10 - Host <delete> synchronization (if applicable)
  11. srsgw-11 - Contact <update> synchronization (if applicable)
  12. srsgw-12 - Contact <delete> synchronization (if applicable)
  13. srsgw-13 - Domain RDAP synchronization
  14. srsgw-14 - Nameserver RDAP synchronization
  15. srsgw-15 - Registrar RDAP synchronization

5.7.3. Test plans

This suite is used by the following test plans:

  1. SRS Gateway Test
  2. SRS Gateway RSP Evaluation Test
  3. StandardSRSGateway

5.7.4. Resources

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

5.7.5. Errors

This test suite may produce the following errors:

5.7.6. Input parameters

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

  1. epp.clid01 (input)
  2. epp.clid01DataModel (input)
  3. epp.clid02 (input)
  4. epp.clid02DataModel (input)
  5. epp.hostModel (input)
  6. epp.hostName (input)
  7. epp.pwd01 (input)
  8. epp.pwd02 (input)
  9. epp.requiredContactTypes (input)
  10. epp.serverIssuedClientCertificate01 (file)
  11. epp.serverIssuedClientCertificate02 (file)
  12. general.registryDataModel (input)
  13. rdap.baseURLs (input)
  14. srsgw.eppClid01 (input)
  15. srsgw.eppClid02 (input)
  16. srsgw.eppHostName (input)
  17. srsgw.eppPwd01 (input)
  18. srsgw.eppPwd02 (input)
  19. srsgw.rdapBaseURLs (input)
  20. srsgw.serverIssuedClientCertificate01 (input)
  21. srsgw.serverIssuedClientCertificate02 (file)

5.8. DNSSEC Operations

5.8.1. Description

This test suite verifies the ability of an RSP to carry out standard DNSSEC operational procedures while maintaining a chain of trust to the parent zone.

Pass/fail criteria

As with all other test suites, for this test suite to pass all the listed test cases MUST pass: if any fail, then the suite as a whole will fail.

5.8.2. Test cases

This suite uses the following test cases:

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

5.8.3. Test plans

This suite is used by the following test plans:

  1. DNSSEC RSP Evaluation Test

5.8.4. Resources

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

5.8.5. Errors

This test suite may produce the following errors:

5.8.6. Input parameters

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

  1. dnssecOps.algorithmRolloverZone (input)
  2. dnssecOps.csk (input)
  3. dnssecOps.kskRolloverZone (input)
  4. dnssecOps.nameservers (input)
  5. dnssecOps.primaryServers (input)
  6. dnssecOps.tsigKey (input)
  7. dnssecOps.zskRolloverZone (input)

5.9. Minimum Rights Protection Mechanisms (RPMs)

5.9.1. Description

This test suite verifies an RSP’s support for the minimum Rights Protection Mechanisms (RPMs), and the Launch Extension (RFC 8334).

Pass/fail criteria

As with all other test suites, for this test suite to pass all the listed test cases MUST pass: if any fail, then the suite as a whole will fail.

5.9.2. Test cases

This suite uses the following test cases:

  1. minimumRPMs-01 - Claims <check> command test
  2. minimumRPMs-02 - Sunrise domain/launch application <create> command test
  3. minimumRPMs-03 - Trademark claims domain <create> command test

5.9.3. Test plans

This suite is used by the following test plans:

  1. Main RSP Evaluation Test
  2. MinimumRPMs

5.9.4. Resources

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

5.9.5. Errors

This test suite may produce the following errors:

5.9.6. Input parameters

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

  1. epp.clid01 (input)
  2. epp.clid01DataModel (input)
  3. epp.clid02 (input)
  4. epp.clid02DataModel (input)
  5. epp.hostModel (input)
  6. epp.hostName (input)
  7. epp.pwd01 (input)
  8. epp.pwd02 (input)
  9. epp.requiredContactTypes (input)
  10. epp.serverIssuedClientCertificate01 (file)
  11. epp.serverIssuedClientCertificate02 (file)
  12. general.registryDataModel (input)
  13. minimumRPMS.claimsTLD (input)
  14. minimumRPMS.sunriseModels (input)
  15. minimumRPMS.sunriseTLD (input)

5.10. Standard Integration Test

5.10.1. Description

This test suite verifies that the critical registry services of the TLD are properly integrated and functioning within the requirements of the Service Level Agreement.

Pass/fail criteria

As with all other test suites, for this test suite to pass all the listed test cases MUST pass: if any fail, then the suite as a whole will fail.

5.10.2. Test cases

This suite uses the following test cases:

  1. integration-01 - EPP -> RDAP Integration Test
  2. integration-02 - EPP -> DNS Integration Test
  3. integration-03 - EPP -> RDE Integration Test

5.10.3. Test plans

This suite is used by the following test plans:

  1. Pre-Delegation Test
  2. RSP Change Test

5.10.4. Resources

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

5.10.5. Errors

This test suite may produce the following errors:

5.10.6. Input parameters

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

  1. dns.nameservers (input)
  2. epp.clid01 (input)
  3. epp.hostModel (input)
  4. epp.hostName (input)
  5. epp.pwd01 (input)
  6. epp.requiredContactTypes (input)
  7. epp.serverIssuedClientCertificate01 (file)
  8. general.registryDataModel (input)
  9. integration.rdeSFTPDirectory (input)
  10. integration.rdeSFTPHostname (input)
  11. integration.rdeSFTPUsername (input)
  12. integration.rriACL (input)
  13. rdap.baseURLs (input)

6. Resources

6.1. dnssecOps.xfrACL

6.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.

6.1.2. URL

6.2. epp.clientACL

6.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.

6.2.2. URL

6.3. epp.clientCSR

6.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.

6.3.2. URL

6.4. epp.clientCertificate

6.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.

6.4.2. URL

6.5. epp.tlsCertificateStore

6.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.

6.5.2. URL

6.6. integration.rdeSFTPACL

6.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.

6.6.2. URL

6.7. integration.rdeSFTPPublicKey

6.7.1. Description

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

6.7.2. URL

6.8. rde.encryptionKey

6.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.

6.8.2. URL

6.9. tmch.testCRL

6.9.1. Description

A Certificate Revocation List (CRL) that identifies revoked TMCH certificates.

6.9.2. URL

6.10. tmch.testCert

6.10.1. Description

The x509 certificate that is the trust anchor for the test TMCH system. This certificate can be used to validate the digital signatures on SMD files.

6.10.2. URL

6.11. tmch.testDNL

6.11.1. Description

A file containing the list of labels subject to Trademark Claims in the TMCH test environment.

6.11.2. URL

6.12. tmch.testSMDRL

6.12.1. Description

A CSV file containing a list of revoked SMDs.

6.12.2. URL

6.13. tmch.testSURL

6.13.1. Description

A file containing the list of labels for which SMDs have been produced in the TMCH test environment.

6.13.2. URL

7. Test Cases

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

7.1.1. Maturity Level

7.1.2. Description

Note: the severity levels of one or more error codes for this test case have been changed from the default.

This test case comes from version v2023.1.4 of Zonemaster. For more information, please refer to the documentation for this test case.

Objective

In order for the domain and its resources to be accessible, authoritative name servers must have addresses in the routable public addressing space.

IANA is responsible for global coordination of the IP addressing system. Aside its address allocation activities, it maintains reserved address ranges for special uses. These ranges can be categorized into three types : Special purpose IPv4 addresses, Special purpose IPv6 addresses and Multicast reserved addresses.

7.1.3. Errors

This test case may produce the following errors:

7.1.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.1.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.1.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.1.7. Test suites

This test case is used in the following test suite(s):

7.2. dns-address02 - Reverse DNS entry exists for name server IP address

7.2.1. Maturity Level

7.2.2. Description

This test case comes from version v2023.1.4 of Zonemaster. For more information, please refer to the documentation for this test case.

Objective

Some anti-spam techniques use reverse DNS lookup to allow incoming traffic. In order to prevent name servers to be blocked or blacklisted, DNS administrators should publish PTR records associated to name server addresses.

[technical reference to be found]

7.2.3. Errors

This test case may produce the following errors:

7.2.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.2.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.2.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.2.7. Test suites

This test case is used in the following test suite(s):

7.3. dns-address03 - Reverse DNS entry matches name server name

7.3.1. Maturity Level

7.3.2. Description

This test case comes from version v2023.1.4 of Zonemaster. For more information, please refer to the documentation for this test case.

Objective

Some anti-spam techniques use reverse DNS lookup to allow incoming traffic. In order to prevent name servers to be blocked or blacklisted, DNS administrators should publish PTR records associated with the name server addresses.

Moreover, as mentioned in paragraph 2.1 of RFC 1912 when a PTR record exists, it must match the host name.

7.3.3. Errors

This test case may produce the following errors:

7.3.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.3.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.3.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.3.7. Test suites

This test case is used in the following test suite(s):

7.4. dns-connectivity01 - UDP connectivity to name servers

7.4.1. Maturity Level

7.4.2. Description

Note: the severity levels of one or more error codes for this test case have been changed from the default.

This test case comes from version v2023.1.4 of Zonemaster. For more information, please refer to the documentation for this test case.

Objective

UDP is the fundamental protocol to reach a general purpose name server hosting a zone, “DNS servers MUST be able to service UDP […]” (RFC 1123, section 6.1.3.2, page 75), also restated in RFC 7766, section 5.

This Test Case will verify if the name servers of Child Zone are reachable over UDP. The name servers tested are both those in the delegation of Child Zone and those in the NS records in the Child Zone itself.

Most Zonemaster Test Cases will query the name servers in the delegation or the name servers appointed by the NS records in the zone for the NS or SOA record, or both. It is crucial that problems are reported, but instead of letting several Test Cases report the same problems found, most Test Cases assume that this test case is run. Only this Test Case will report problems found in the following areas over UDP:

  • Name Server not responding to a query without EDNS.
  • Name Server not including SOA record of Child Zone in the answer section in the response on a SOA query for Child Zone.
  • Name Server not including NS record of Child Zone in the answer section in the response on an NS query for Child Zone.
  • Name Server not setting the AA flag in a response with SOA or NS in answer section.
  • Name Server responding with unexpected RCODE Name (any except “NoError”) on query for SOA or NS for Child Zone.

In addition, this test case will output a message if transport over IPv4 or IPv6 has been disabled.

7.4.3. Errors

This test case may produce the following errors:

7.4.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.4.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.4.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.4.7. Test suites

This test case is used in the following test suite(s):

7.5. dns-connectivity02 - TCP connectivity to name servers

7.5.1. Maturity Level

7.5.2. Description

Note: the severity levels of one or more error codes for this test case have been changed from the default.

This test case comes from version v2023.1.4 of Zonemaster. For more information, please refer to the documentation for this test case.

Objective

TCP is a protocol to reach a general purpose name server hosting a zone, “All general-purpose DNS implementations MUST support […] TCP transport” (RFC 7766, section 5).

This Test Case will verify if the name servers of Child Zone are reachable over TCP. The name servers tested are both those in the delegation of Child Zone and those in the NS records in the Child Zone itself.

This Test Case will mimic the tests done by Connectivity01, but over TCP instead:

  • Name Server responding to a query.
  • Name Server including SOA record of Child Zone in the answer section in the response on a SOA query for Child Zone.
  • Name Server including NS record of Child Zone in the answer section in the response on an NS query for Child Zone.
  • Name Server setting the AA flag in a response with SOA or NS in answer section.
  • Name Server responding with expected RCODE Name (“NoError”) on query for SOA or NS for Child Zone.

7.5.3. Errors

This test case may produce the following errors:

7.5.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.5.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.5.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.5.7. Test suites

This test case is used in the following test suite(s):

7.6. dns-connectivity03 - AS Diversity

7.6.1. Maturity Level

7.6.2. Description

Note: the severity levels of one or more error codes for this test case have been changed from the default.

This test case comes from version v2023.1.4 of Zonemaster. For more information, please refer to the documentation for this test case.

Objective

The objective in this test is to verify that all IP addresses of the domain’s authoritative name servers are announced from different ASNs (autonomous system number). See RFC 1930 and Wikipedia for an explanation of AS (autonomous system).

This test is done separately on IPv4 and IPv6, and both must match the criterion.

RFC 2182, section 3.1, clearly specifies that distinct authoritative name servers for a child domain should be placed in different topological and geographical locations. The objective is to minimise the likelihood of a single failure disabling all of them.

7.6.3. Errors

This test case may produce the following errors:

7.6.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.6.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.6.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.6.7. Test suites

This test case is used in the following test suite(s):

7.7. dns-consistency02 - SOA RNAME consistency

7.7.1. Maturity Level

7.7.2. Description

Note: the severity levels of one or more error codes for this test case have been changed from the default.

This test case comes from version v2023.1.4 of Zonemaster. For more information, please refer to the documentation for this test case.

Objective

All authoritative name servers must serve the same SOA record for the tested domain (section 4.2.1 of RFC 1034). As per section 3.3.13 of RFC 1035, the RNAME field in the SOA RDATA refers to the administrative contact. An inconsistency in the administrative contact for the domain might result in operational failures being reported to different persons.

The objective of this test is to verify that the administrative contact is consistent between different authoritative name servers.

7.7.3. Errors

This test case may produce the following errors:

7.7.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.7.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.7.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.7.7. Test suites

This test case is used in the following test suite(s):

7.8. dns-consistency03 - SOA timers consistency

7.8.1. Maturity Level

7.8.2. Description

Note: the severity levels of one or more error codes for this test case have been changed from the default.

This test case comes from version v2023.1.4 of Zonemaster. For more information, please refer to the documentation for this test case.

Objective

All SOA record timer fields must be consistent across all authoritative name servers. An inconsistency in these fields might result in operational inconsistencies for the designated zone.

There are other test cases that provide consistency tests for the other SOA fields:

7.8.3. Errors

This test case may produce the following errors:

7.8.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.8.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.8.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.8.7. Test suites

This test case is used in the following test suite(s):

7.9. dns-consistency04 - Name server NS consistency

7.9.1. Maturity Level

7.9.2. Description

Note: the severity levels of one or more error codes for this test case have been changed from the default.

This test case comes from version v2023.1.4 of Zonemaster. For more information, please refer to the documentation for this test case.

Objective

All authoritative name servers must serve the same NS record set for the tested domain, child zone (RFC 1034, section 4.2.2). Any inconsistencies in NS records described in RFC 1035, section 3.3.11, might result in operational failures.

The objective of this test is to verify that the NS records are consistent between all authoritative name servers of the child zone.

Two NS RR sets are considered to be equal if both sets have the same number of NS records, and for each NS record in one of the sets there is exactly one NS record with identical owner name, class, TTL and RDATA in the other NS set.

7.9.3. Errors

This test case may produce the following errors:

7.9.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.9.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.9.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.9.7. Test suites

This test case is used in the following test suite(s):

7.10. dns-consistency05 - Consistency between glue and authoritative data

7.10.1. Maturity Level

7.10.2. Description

Note: the severity levels of one or more error codes for this test case have been changed from the default.

This test case comes from version v2023.1.4 of Zonemaster. For more information, please refer to the documentation for this test case.

Objective

For name servers that have IP addresses listed as glue, the IP addresses must match the authoritative A and AAAA records for that host. This is an IANA name server requirement.

The objective of this test is to verify that the glue records in the delegation are consistent with authoritative data.

7.10.3. Errors

This test case may produce the following errors:

7.10.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.10.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.10.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.10.7. Test suites

This test case is used in the following test suite(s):

7.11. dns-consistency06 - SOA MNAME consistency

7.11.1. Maturity Level

7.11.2. Description

Note: the severity levels of one or more error codes for this test case have been changed from the default.

This test case comes from version v2023.1.4 of Zonemaster. For more information, please refer to the documentation for this test case.

Objective

All authoritative name servers must serve the same SOA record (section 4.2.1) of RFC 1034 for the tested domain. As per section 3.3.13 of RFC 1035 the MNAME field in the SOA RDATA refers to the name of “the name server that was the original or primary source of data for this zone”. Inconsistency in MNAME of the domain might result in operational failures for applications that uses MNAME.

7.11.3. Errors

This test case may produce the following errors:

7.11.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.11.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.11.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.11.7. Test suites

This test case is used in the following test suite(s):

7.12. dns-delegation01 - Minimum number of name servers

7.12.1. Maturity Level

7.12.2. Description

Note: the severity levels of one or more error codes for this test case have been changed from the default.

This test case comes from version v2023.1.4 of Zonemaster. For more information, please refer to the documentation for this test case.

Objective

Section 4.1 of RFC 1034 specifies that there must be a minimum of two name servers for a domain. This test is done to verify this condition.

The RFC (RFC 1034) predates IPv6. Since IPv4 and IPv6 work as separate networks, this test case has been extended to test for two name servers that resolve into IPv4 addresses and IPv6 addresses respectively.

Both RFC 3901 (section 3) and RFC 4472 (section 1.3) states that a domain (zone) should be available over IPv4 for the time being. Therefore, it is by the default level in this test case considered to be more problematic not being available over IPv4 than not being available over IPv6.

7.12.3. Errors

This test case may produce the following errors:

7.12.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.12.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.12.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.12.7. Test suites

This test case is used in the following test suite(s):

7.13. dns-delegation02 - Name servers must have distinct IP addresses

7.13.1. Maturity Level

7.13.2. Description

This test case comes from version v2023.1.4 of Zonemaster. For more information, please refer to the documentation for this test case.

Objective

If the domain’s name servers use several different names, they can all be using the same IP address. This may be due to a configuration error, or a workaround for a certain policy restriction. This test case checks that the name servers used do not reuse the same IP addresses.

Section 4.1 of RFC 1034 says at least two name servers must be used for a delegation.

7.13.3. Errors

This test case may produce the following errors:

7.13.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.13.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.13.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.13.7. Test suites

This test case is used in the following test suite(s):

7.14. dns-delegation03 - No truncation of referrals

7.14.1. Maturity Level

7.14.2. Description

Note: the severity levels of one or more error codes for this test case have been changed from the default.

This test case comes from version v2023.1.4 of Zonemaster. For more information, please refer to the documentation for this test case.

Objective

The Domain Name System defaults to using UDP for queries and answers with a DNS payload limit of 512 octets (bytes). Larger replies cause an initial truncation indication leading to a subsequent handling via TCP with substantially higher overhead. EDNS0 is used to allow for larger UDP responses thus reducing the need for use of TCP.

But IANA still maintains that referrals from the parent zone name servers must fit into a non-EDNS0 UDP DNS packet.

7.14.3. Errors

This test case may produce the following errors:

7.14.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.14.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.14.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.14.7. Test suites

This test case is used in the following test suite(s):

7.15. dns-delegation04 - Name server is authoritative

7.15.1. Maturity Level

7.15.2. Description

This test case comes from version v2023.1.4 of Zonemaster. For more information, please refer to the documentation for this test case.

Objective

Subsection 6.1 of RFC 2181 specifies that the nameservers must answer authoritatively for the domain. Answers to queries to the name servers for the designated zone must have the “AA” bit set.

7.15.3. Errors

This test case may produce the following errors:

7.15.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.15.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.15.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.15.7. Test suites

This test case is used in the following test suite(s):

7.16. dns-delegation05 - Name server must not point at CNAME alias

7.16.1. Maturity Level

7.16.2. Description

Note: the severity levels of one or more error codes for this test case have been changed from the default.

This test case comes from version v2023.1.4 of Zonemaster. For more information, please refer to the documentation for this test case.

Objective

Name servers for a zone are defined in NS records. An NS record points at a name, i.e. the RDATA for an NS record is a domain name. That name is the name of the name server. RFC 2181, section 10.3, states that the name of the name server must not itself point at a CNAME.

The objective of this test is to verify that name servers of the tested domain (zone) do not point at CNAME records.

7.16.3. Errors

This test case may produce the following errors:

7.16.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.16.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.16.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.16.7. Test suites

This test case is used in the following test suite(s):

7.17. dns-delegation07 - Parent glue name records present in child

7.17.1. Maturity Level

7.17.2. Description

This test case comes from version v2023.1.4 of Zonemaster. For more information, please refer to the documentation for this test case.

Objective

If the list of name servers for a domain obtained from its parent are not found in its its child zone, then it leads to an inconsistency (section 2.3 of RIPE-114)

7.17.3. Errors

This test case may produce the following errors:

7.17.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.17.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.17.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.17.7. Test suites

This test case is used in the following test suite(s):

7.18. dns-nameserver01 - A name server should not be a recursor

7.18.1. Maturity Level

7.18.2. Description

Note: the severity levels of one or more error codes for this test case have been changed from the default.

This test case comes from version v2023.1.4 of Zonemaster. For more information, please refer to the documentation for this test case.

Objective

To ensure consistency in DNS, an authoritative name server should not be configured to do recursive lookups. Also, open recursive resolvers are considered bad internet practice due to their capability of assisting in large scale DDoS attacks. The introduction to RFC 5358 elaborates on mixing recursor and authoritative functionality, and the issue is further elaborated by D.J. Bernstein.

Section 2.5 of RFC 2870 have very specific requirement on disabling recursion functionality on root name servers.

7.18.3. Errors

This test case may produce the following errors:

7.18.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.18.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.18.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.18.7. Test suites

This test case is used in the following test suite(s):

7.19. dns-nameserver02 - Test of EDNS0 support

7.19.1. Maturity Level

7.19.2. Description

Note: the severity levels of one or more error codes for this test case have been changed from the default.

This test case comes from version v2023.1.4 of Zonemaster. For more information, please refer to the documentation for this test case.

Objective

EDNS(0) is a mechanism to announce capabilities of a DNS implementation, and is now basically required by any new functionality in DNS such as DNSSEC. EDNS(0) is standardized in RFC 6891.

This test case checks that all name servers has the capability to do EDNS(0) or if not, correctly replies to queries containing EDNS (OPT record).

Servers not supporting EDNS(0) must return FORMERR (RFC 6891, section 7):

Responders that choose not to implement the protocol extensions defined in this document MUST respond with a return code (RCODE) of FORMERR to messages containing an OPT record in the additional section and MUST NOT include an OPT record in the response.

Servers supporting EDNS(0) must reply with EDNS(0) (RFC 6891, section 6.1.1):

If an OPT record is present in a received request, compliant responders MUST include an OPT record in their respective responses.

To eliminating the risk of falsely classifying the server as not supporting EDNS due e.g. firewall issues, the UDP buffer size is set to 512 bytes (octets).

7.19.3. Errors

This test case may produce the following errors:

7.19.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.19.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.19.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.19.7. Test suites

This test case is used in the following test suite(s):

7.20. dns-nameserver04 - Same source address

7.20.1. Maturity Level

7.20.2. Description

Note: the severity levels of one or more error codes for this test case have been changed from the default.

This test case comes from version v2023.1.4 of Zonemaster. For more information, please refer to the documentation for this test case.

Objective

Responses from the authoritative name servers must contain same source IP address as the destination IP address of the initial query. This has been clarified in section 4 of RFC 2181.

7.20.3. Errors

This test case may produce the following errors:

7.20.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.20.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.20.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.20.7. Test suites

This test case is used in the following test suite(s):

7.21. dns-nameserver05 - Behaviour against AAAA query

7.21.1. Maturity Level

7.21.2. Description

Note: the severity levels of one or more error codes for this test case have been changed from the default.

This test case comes from version v2023.1.4 of Zonemaster. For more information, please refer to the documentation for this test case.

Objective

Older implementations of authoritative name servers have shown different misbehaviours trying to answer queries for AAAA records, as described in RFC 4074. This test case is intended to find out if the name server authoritative for the domain shows any of these behaviours.

7.21.3. Errors

This test case may produce the following errors:

7.21.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.21.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.21.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.21.7. Test suites

This test case is used in the following test suite(s):

7.22. dns-nameserver06 - NS can be resolved

7.22.1. Maturity Level

7.22.2. Description

This test case comes from version v2023.1.4 of Zonemaster. For more information, please refer to the documentation for this test case.

Objective

All name servers names listed for a delegation must be resolvable in DNS. If they are not resolvable using DNS this is a sign of misconfiguration, and raises the risk of unreachability for the domain. It could also lower the performance for any resolver trying to resolve the name.

The objective of this test is to resolve the domain using all the listed name servers used in the delegation. More information about resolver behavior is in section 7 of RFC 1035.

7.22.3. Errors

This test case may produce the following errors:

7.22.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.22.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.22.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.22.7. Test suites

This test case is used in the following test suite(s):

7.23. dns-nameserver08 - Testing QNAME case insensitivity

7.23.1. Maturity Level

7.23.2. Description

This test case comes from version v2023.1.4 of Zonemaster. For more information, please refer to the documentation for this test case.

Objective

The DNS standards require that nameservers treat names with case insensitivity. That is, the names example.com and EXAMPLE.COM should resolve to the same IP address. However, in the response, most nameservers echo back the name as it appeared in the request, preserving the original case.

Therefore, another way to add entropy to requests is to randomly vary the case of letters in domain names queried. This technique, also known as “0x20” because bit 0x20 is used to set the case of of US-ASCII letters, was first proposed in the IETF internet draft Use of Bit 0x20 in DNS Labels to Improve Transaction Identity. With this technique, the nameserver response must match not only the query name, but the case of every letter in the name string; for example, wWw.eXaMpLe.CoM or WwW.ExamPLe.COm. This may add little or no entropy to queries for the top-level and root domains, but it’s effective for most hostnames.

7.23.3. Errors

This test case may produce the following errors:

7.23.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.23.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.23.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.23.7. Test suites

This test case is used in the following test suite(s):

7.24. dns-nameserver09 - Testing QNAME case sensitivity

7.24.1. Maturity Level

7.24.2. Description

This test case comes from version v2023.1.4 of Zonemaster. For more information, please refer to the documentation for this test case.

Objective

There has been cases where the nameservers respond with complete case-sensitivity (in violation of the DNS standards): that is, they match the exact case of the name in the response; but return different results for equivalent names with different cases in the request (typically NXDOMAIN).

7.24.3. Errors

This test case may produce the following errors:

7.24.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.24.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.24.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.24.7. Test suites

This test case is used in the following test suite(s):

7.25. dns-nameserver10 - Test for undefined EDNS version

7.25.1. Maturity Level

7.25.2. Description

Note: the severity levels of one or more error codes for this test case have been changed from the default.

This test case comes from version v2023.1.4 of Zonemaster. For more information, please refer to the documentation for this test case.

Objective

EDNS (RFC 6891) is a mechanism to announce capabilities of a DNS implementation, and is required by new functionality in DNS such as DNSSEC (RFC 4033, section 3).

RFC 6891, section 6.1.3, states that if a nameserver has implemented EDNS but has not implemented the version level of the request, then it MUST respond with RCODE “BADVERS”. Only version “0” has been defined for EDNS.

Note that RCODE “BADVERS” is an extended RCODE which is calculated from the combination of the normal RCODE field in the DNS package header (RFC 1035, section 4.1.1) and the OPT record EXTENDED-RCODE field (RFC 6891, section 6.1.3). Also see IANA RCODE Registry.

7.25.3. Errors

This test case may produce the following errors:

7.25.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.25.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.25.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.25.7. Test suites

This test case is used in the following test suite(s):

7.26. dns-nameserver11 - Test for unknown EDNS OPTION-CODE

7.26.1. Maturity Level

7.26.2. Description

Note: the severity levels of one or more error codes for this test case have been changed from the default.

This test case comes from version v2023.1.4 of Zonemaster. For more information, please refer to the documentation for this test case.

Objective

EDNS is a mechanism to announce capabilities of a DNS implementation, and is now basically required by any new functionality in DNS such as DNSSEC (RFC 6891).

RFC 6891, section 6.1.2, states that any OPTION-CODE values not understood by a responder or requestor MUST be ignored. Unknown OPTION-CODE values must be processed as though the OPTION-CODE was not even there.

In this test case, we will query with an unknown EDNS OPTION-CODE and expect that the OPTION-CODE is not present in the response for the query.

7.26.3. Errors

This test case may produce the following errors:

7.26.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.26.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.26.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.26.7. Test suites

This test case is used in the following test suite(s):

7.27. dns-nameserver12 - Test for unknown EDNS flags

7.27.1. Maturity Level

7.27.2. Description

Note: the severity levels of one or more error codes for this test case have been changed from the default.

This test case comes from version v2023.1.4 of Zonemaster. For more information, please refer to the documentation for this test case.

Objective

EDNS is a mechanism to announce capabilities of a dns implementation, and is now basically required by any new functionality in dns such as DNSSEC (RFC 6891).

RFC 6891, section 6.1.4, states that “Z” flag bits must be set to zero by senders and ignored by receiver.

IANA lists the flags in the EDNS Header Flags assignment list.

In this test case, the query will have an unknown EDNS flag set, i.e. one of the Z flag bits set to “1”, and it is expected that all “Z” bits to be clear in the response (set to “0”).

7.27.3. Errors

This test case may produce the following errors:

7.27.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.27.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.27.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.27.7. Test suites

This test case is used in the following test suite(s):

7.28. dns-nameserver13 - Test for truncated response on EDNS query

7.28.1. Maturity Level

7.28.2. Description

Note: the severity levels of one or more error codes for this test case have been changed from the default.

This test case comes from version v2023.1.4 of Zonemaster. For more information, please refer to the documentation for this test case.

Objective

EDNS is a mechanism to announce capabilities of a DNS implementation, and is now basically required by any new functionality in DNS such as DNSSEC (RFC 6891).

RFC 6891, section 7 states that an OPT record must be included in a truncated response, if the query includes an OPT pseudo record.

This Test Case will try to verify that if the response to a query with an OPT record is truncated, then the response will contain an OPT record.

To trigger a truncated response, the OPT pseudo record ‘DO’ bit is set and the buffer size is limited to 512 bytes. If the zone is not signed with DNSSEC, the response will probably not be truncated anyway.

7.28.3. Errors

This test case may produce the following errors:

7.28.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.28.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.28.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.28.7. Test suites

This test case is used in the following test suite(s):

7.29. dns-syntax05 - Misuse of '@' character in the SOA RNAME field

7.29.1. Maturity Level

7.29.2. Description

Note: the severity levels of one or more error codes for this test case have been changed from the default.

This test case comes from version v2023.1.4 of Zonemaster. For more information, please refer to the documentation for this test case.

Objective

The SOA RNAME field does not allow the ‘@’ characters to be used for describing a mailbox. The first dot (‘.’) is thus translated into the ‘@’ character. This is a common mistake. The rules are defined in RFC 1035.

7.29.3. Errors

This test case may produce the following errors:

7.29.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.29.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.29.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.29.7. Test suites

This test case is used in the following test suite(s):

7.30. dns-syntax06 - No illegal characters in the SOA RNAME field

7.30.1. Maturity Level

7.30.2. Description

Note: the severity levels of one or more error codes for this test case have been changed from the default.

This test case comes from version v2023.1.4 of Zonemaster. For more information, please refer to the documentation for this test case.

Objective

The SOA RNAME field is a mailbox address. The SOA RNAME field is defined in RFC 1035, section 3.3.13 and in RFC 1912, section 2.2. The RNAME field should follow the rules of an e-mail address also defined in RFC 5322, section 3.4.1.

7.30.3. Errors

This test case may produce the following errors:

7.30.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.30.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.30.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.30.7. Test suites

This test case is used in the following test suite(s):

7.31. dns-syntax07 - No illegal characters in the SOA MNAME field

7.31.1. Maturity Level

7.31.2. Description

Note: the severity levels of one or more error codes for this test case have been changed from the default.

This test case comes from version v2023.1.4 of Zonemaster. For more information, please refer to the documentation for this test case.

Objective

The SOA MNAME field is a hostname. Hostnames are valid according to the rules defined in RFC 952, in section 2.1 in RFC 1123, section 11 in RFC 2182 and section 2 and 5 in RFC 3696. Newer RFCs may override some rules defined in earlier documents.

7.31.3. Errors

This test case may produce the following errors:

7.31.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.31.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.31.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.31.7. Test suites

This test case is used in the following test suite(s):

7.32. dns-zone07 - SOA master is not an alias

7.32.1. Maturity Level

7.32.2. Description

Note: the severity levels of one or more error codes for this test case have been changed from the default.

This test case comes from version v2023.1.4 of Zonemaster. For more information, please refer to the documentation for this test case.

Objective

Any NS type record should not be a CNAME. The SOA MNAME should in this respect not be a CNAME.

Quote from 2.4 in RFC 1912:

Having NS records pointing to a CNAME is bad and may conflict badly with current BIND servers.

The SOA MNAME field is described in section 3.3.13 in RFC 1035.

The RIPE-203 recommendation for the minimum value 2 days, but the negative caching is now the norm. DNSCheck has a recommended value of between 300 seconds (5 minutes) and 86400 seconds (1 day).

7.32.3. Errors

This test case may produce the following errors:

7.32.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.32.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.32.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.32.7. Test suites

This test case is used in the following test suite(s):

7.33. dns-zone10 - No multiple SOA records

7.33.1. Maturity Level

7.33.2. Description

Note: the severity levels of one or more error codes for this test case have been changed from the default.

This test case comes from version v2023.1.4 of Zonemaster. For more information, please refer to the documentation for this test case.

Objective

The SOA record is crucial for the DNS zone and “exactly one SOA RR should be present at the top of the zone” (RFC 1035, section 5.2). This test case will verify that the zone of the domain to be tested return exactly one SOA record.

7.33.3. Errors

This test case may produce the following errors:

7.33.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.33.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.33.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.33.7. Test suites

This test case is used in the following test suite(s):

7.34. dns-zz-idna2008-compliance - IDNA2008 compliance check

7.34.1. Maturity Level

7.34.2. Description

In addition to the other tests case in this suite, which come from Zonemaster, this test case exists to confirm that all DNS host names which appear in resource records at the TLD apex conform to the IDNA2008 specifications, described in RFC 5980.

The names that appear in the MNAME and RNAME fields of the TLD SOA record, and in the apex NS records, MUST be comprised solely of (a) NR-LDH labels (see Section 2.3.2.2 of RFC 5980) or (b) IDN labels that conform to the requirements of IDNA2008.

7.34.3. Errors

This test case may produce the following errors:

7.34.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.34.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.34.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.34.7. Test suites

This test case is used in the following test suite(s):

7.35. dnssec-01 - Legal values for the DS hash digest algorithm

7.35.1. Maturity Level

7.35.2. Description

Note: the severity levels of one or more error codes for this test case have been changed from the default.

This test case comes from version v2023.1.4 of Zonemaster. For more information, please refer to the documentation for this test case.

Objective

The list of allowed Digest Algorithms in a DS record published by the parent is specified by RFC 8624, section 3.3, and is published in the IANA registry of DS RR Type Digest Algorithms. No DS Digest Algorithm values, other than those specified in the RFC and allocated by IANA, should be used in public DNS.

If RFC 8624 and the IANA registry disagree on the same DS digest algorithm, the RFC takes precedence until the registry has a been updated with a reference to the RFC.

The table of algorithms below is for reference only and is copied from IANA registry. It is here to make it easier to read the steps when symbolic names are given. This is only an excerpt from the table. The full table is available at the IANA registry.

Algorithm number Algorithm (or description)
0 (Reserved)
1 SHA-1
2 SHA-256
3 GOST R 34.11-94
4 SHA-384
5-255 (Unassigned)

This test case will verify that the Zonemaster implementation has support for the DS digest algorithm of the DS record found, and if not output a message tag. If the support is missing other test cases will not be able to verify that DS record.

7.35.3. Errors

This test case may produce the following errors:

7.35.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.35.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.35.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.35.7. Test suites

This test case is used in the following test suite(s):

7.36. dnssec-02 - DS must match a valid DNSKEY in the child zone

7.36.1. Maturity Level

7.36.2. Description

Note: the severity levels of one or more error codes for this test case have been changed from the default.

Note: References to “Key Signing Keys” in the description below also refer to Combined Signing Keys, if used.

This test case comes from version v2023.1.4 of Zonemaster. For more information, please refer to the documentation for this test case.

Objective

DNS delegations from a parent to a child are secured with DNSSEC by publishing one or several Delegation Signer (DS) records in the parent zone, along with the NS records for the delegation.

For the secure delegation to work, at least one DS record must match a DNSKEY record in the child zone (RFC 4035, section 5). Each DS record should match a DNSKEY record in the child zone. More than one DS may match the same DNSKEY. The DNSKEY that the DS record refer to must be used to sign the DNSKEY RRset in the child zone (RFC 4035, section 5).

The DNSKEY record that the DS record refer to must have bit 7 (“Zone Key flag”) set in the DNSKEY RR Flags (RFC 4034, section 5.2).

Bit 15 (“Secure Entry Point flag”) on a DNSKEY record signals that it is meant to be a KSK and pointed out by a DS record. It is noted if the DNSKEY record that the DS points at does not have that flag set (RFC 4034, section 2.1.1).

7.36.3. Errors

This test case may produce the following errors:

7.36.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.36.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.36.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.36.7. Test suites

This test case is used in the following test suite(s):

7.37. dnssec-03 - Check for too many NSEC3 iterations

7.37.1. Maturity Level

7.37.2. Description

Note: while failure conditions defined in this test case are weaker than those defined in dnssec-93, as of Zonemaster::Engine v5.0.0, this test case emits the ZM_DS03_NO_DNSSEC_SUPPORT error, which is required to ensure that the TLD zone is properly signed with DNSSEC.

This test case comes from version v2023.1.4 of Zonemaster. For more information, please refer to the documentation for this test case.

Objective

For an authoritative name server an increased number of NSEC3 iterations have a negative impact on performance.

Section 10.3 in RFC 5155 sets a maximum number of iterations depending on the DNSSEC key size - regardless of which algorithm is used.

A zone owner MUST NOT use a value higher than shown in the table below for iterations for the given key size. A resolver MAY treat a response with a higher value as insecure, after the validator has verified that the signature over the NSEC3 RR is correct.

Key Size Iterations
1024 150
2048 500
4096 2,500

Section 5.3.2 in RFC 6781 describes the consequences for an authoritative name server in more detail, and references the NSEC Hash Performance study from NLNet Labs.

Choosing a value of 100 iterations is deemed to be a sufficiently costly, yet not excessive, value: In the worst-case scenario, the performance of name servers would be halved, regardless of key size.

7.37.3. Errors

This test case may produce the following errors:

7.37.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.37.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.37.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.37.7. Test suites

This test case is used in the following test suite(s):

7.38. dnssec-04 - Check for too short or too long RRSIG lifetimes

7.38.1. Maturity Level

7.38.2. Description

This test case comes from version v2023.1.4 of Zonemaster. For more information, please refer to the documentation for this test case.

Objective

Having RRSIG signature lifetimes last for too long opens up for DNS replay attacks. Having too short RRSIG signature lifetimes is likely to have a major operational impact if the master name server is down for that long.

There is no clear recommendation of the exact validity periods to use with DNSSEC. Shorter validity than 12 hours until expiration will give a serious operational problem just in case of temporary network problems, and longer than 180 days will create wide open holes for replay attacks.

The considerations are described in RFC6781.

7.38.3. Errors

This test case may produce the following errors:

7.38.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.38.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.38.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.38.7. Test suites

This test case is used in the following test suite(s):

7.39. dnssec-05 - Check for invalid DNSKEY algorithms

7.39.1. Maturity Level

7.39.2. Description

Note: the severity levels of one or more error codes for this test case have been changed from the default.

This test case comes from version v2023.1.4 of Zonemaster. For more information, please refer to the documentation for this test case.

Objective

A domain name (zone) should only use DNSKEY algorithms that are specified by RFC 8624, section 3.1 and the IANA registry of DNSSEC Algorithm Numbers to be used for DNSSEC signing. A public domain name (zone) should not use private algorithms.

If RFC 8624 and IANA registry disagree on the same algorithm, the RFC takes precedence until the registry has a been updated with a reference to the RFC.

The table of algorithms below is for reference only and is copied from IANA registry. It is here to make it easier to read the steps when symbolic names are given. This is only an excerpt from the table. The full table is available at IANA registry.

Algorithm number Algorithm (or description)
0 (Delete DS)
1 RSA/MD5
2 Diffie-Hellman
3 DSA/SHA1
4 (Reserved)
5 RSA/SHA-1
6 DSA-NSEC3-SHA1
7 RSASHA1-NSEC3-SHA1
8 RSA/SHA-256
9 (Reserved)
10 RSA/SHA-512
11 (Reserved)
12 GOST R 34.10-2001
13 ECDSA Curve P-256 with SHA-256
14 ECDSA Curve P-384 with SHA-384
15 Ed25519
16 Ed448
17-122 (Unassigned)
123-251 (Reserved)
252 (Indirect Keys)
253 (Private algorithm)
254 (Private algorithm OID)
255 (Reserved)

7.39.3. Errors

This test case may produce the following errors:

7.39.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.39.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.39.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.39.7. Test suites

This test case is used in the following test suite(s):

7.40. dnssec-06 - Verify DNSSEC additional processing

7.40.1. Maturity Level

7.40.2. Description

This test case comes from version v2023.1.4 of Zonemaster. For more information, please refer to the documentation for this test case.

Objective

In order for an authoritative name server to be DNSSEC compliant, it must serve DNSSEC signatures (RRSIG) as additional data in a DNS answer. This additional processing is described in section 3.1 of RFC 4035.

7.40.3. Errors

This test case may produce the following errors:

7.40.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.40.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.40.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.40.7. Test suites

This test case is used in the following test suite(s):

7.41. dnssec-08 - Valid RRSIG for DNSKEY

7.41.1. Maturity Level

7.41.2. Description

This test case comes from version v2023.1.4 of Zonemaster. For more information, please refer to the documentation for this test case.

Objective

A DNSSEC signed zone should have a DNSKEY RRset in the zone apex (RFC 4035, section 2.1) and that RRset should be signed by a key that matches one of the records in the DNSKEY RRset (RFC 4035, section 2.2).

This test case will verify if the Child Zone meets that requirement.

7.41.3. Errors

This test case may produce the following errors:

7.41.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.41.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.41.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.41.7. Test suites

This test case is used in the following test suite(s):

7.42. dnssec-09 - RRSIG(SOA) must be valid and created by a valid DNSKEY

7.42.1. Maturity Level

7.42.2. Description

This test case comes from version v2023.1.4 of Zonemaster. For more information, please refer to the documentation for this test case.

Objective

If the zone is signed, the SOA RR should be signed with a valid RRSIG using a DNSKEY from the DNSKEY RR set. This is described in RFC 4035, section 2.2.

This test case will verify if the Child Zone meets that requirement.

7.42.3. Errors

This test case may produce the following errors:

7.42.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.42.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.42.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.42.7. Test suites

This test case is used in the following test suite(s):

7.43. dnssec-10 - Zone contains NSEC or NSEC3 records

7.43.1. Maturity Level

7.43.2. Description

This test case comes from version v2023.1.4 of Zonemaster. For more information, please refer to the documentation for this test case.

Objective

When DNSSEC is enabled, NSEC or NSEC3 records provide a secure denial of existence for records not present in the zone. This test case verifies that correct NSEC or NSEC3 records with valid signatures are returned for a query for an non-existent name.

Furthermore, it is verified that the name servers for the zone are consistent about NSEC and NSEC3, i.e. either all servers should use NSEC or all servers should use NSEC3. It is never permitted to serve both NSEC and NSEC3 for the same zone.

The use of the NSEC RR type is described in RFC 4035, section 3.1.3, and the description of the NSEC RR itself is in RFC 4034, section 4.

The description of the NSEC3 RR is in RFC 5155, section 3, and its use in the DNS response is described in RFC 5155, section 7.2.

7.43.3. Errors

This test case may produce the following errors:

7.43.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.43.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.43.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.43.7. Test suites

This test case is used in the following test suite(s):

7.44. dnssec-13 - All DNSKEY algorithms used to sign the zone

7.44.1. Maturity Level

7.44.2. Description

Note: the severity levels of one or more error codes for this test case have been changed from the default.

This test case comes from version v2023.1.4 of Zonemaster. For more information, please refer to the documentation for this test case.

Objective

From RFC 6840, section 5.11:

The DS RRset and DNSKEY RRset are used to signal which algorithms are used to sign a zone. […] The zone MUST also be signed with each algorithm (though not each key) present in the DNSKEY RRset. […]

To verify that the whole zone is signed with all algorithms require access to the complete zone, which is generally not possible for public zones. This test case is limited to three RRsets that must be present in a signed zone, the SOA RRset, the NS RRset and the DNSKEY RRset.

This test case will verify that for each DNSKEY algorithm, there is a RRSIG of that algorithm for the three selected RRsets.

7.44.3. Errors

This test case may produce the following errors:

7.44.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.44.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.44.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.44.7. Test suites

This test case is used in the following test suite(s):

7.45. dnssec-14 - Check for valid RSA DNSKEY key size

7.45.1. Maturity Level

7.45.2. Description

Note: the severity levels of one or more error codes for this test case have been changed from the default.

This test case comes from version v2023.1.4 of Zonemaster. For more information, please refer to the documentation for this test case.

Objective

The DNSKEYs based on RSA have different minimum and maximum key sizes, which must be followed. This test case will validate the keys size of such keys. RSA based algorithms that are deprecated or else not suitable for DNSKEY (RFC 8624 and IANA registry) are just ignored. See test case DNSSEC05 for test of algorithm.

The table 1 below specify the maximum and minimum key size, respectively. Algorithm number can be found in IANA registry.

Table 1: Minimum and maximum RSA key sizes in bits

Algorithm Min size Max size Reference
5 512 4096 RFC 3110
7 512 4096 RFC 5155
8 512 4096 RFC 5702
10 1024 4096 RFC 5702

It is also recommended that an RSA based algorithm has a key length of at least 2048 bit as stated in NIST SP 800-57 Part 1 Rev. 4, table 2 on page 53 in section 5.6.1 and table 4 on page 55 in section 5.6.2.

This test case verifies that RSA DNSKEYs follows the stated key lengths from the RFCs and also the NIST recommended shortest key length.

7.45.3. Errors

This test case may produce the following errors:

7.45.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.45.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.45.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.45.7. Test suites

This test case is used in the following test suite(s):

7.46. dnssec-91 - Permitted signing algorithms

7.46.1. Maturity Level

7.46.2. Description

In addition to the requirements outlined in dnssec-05, this test imposes an additional requirement on the signing algorithms used to sign zones.

Specifically, the algorithm number MUST NOT be lower than 8.

7.46.3. Errors

This test case may produce the following errors:

7.46.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.46.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.46.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.46.7. Test suites

This test case is used in the following test suite(s):

7.47. dnssec-92 - Permitted DS record hash algorithm(s)

7.47.1. Maturity Level

7.47.2. Description

The DS record(s) submitted in the dnssec.dsRecords input parameter will be validated. Algorithm 1 (SHA-1) MUST NOT be used.

7.47.3. Errors

This test case may produce the following errors:

7.47.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.47.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.47.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.47.7. Test suites

This test case is used in the following test suite(s):

7.48. dnssec-93 - NSEC3 iterations check

7.48.1. Maturity Level

7.48.2. Description

RFC 9276 defines best practice relating to the use of NSEC3 for Authenticated Denial of Existence. This test case verifies that the zone’s NSEC3 configuration complies with this best practice.

If the zone does not use NSEC3, then this test will be skipped.

The NSEC3PARAM record will be checked to ensure that:

  • the value of the iterations field of the NSEC3 record is zero;
  • the value of the salt field of the NSEC3 record is empty (represented as a - in the presentation format).

7.48.3. Errors

This test case may produce the following errors:

7.48.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.48.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.48.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.48.7. Test suites

This test case is used in the following test suite(s):

7.49. dnssecOps01-ZSKRollover - ZSK rollover

7.49.1. Maturity Level

7.49.2. Description

This test case verifies the RSP’s ability to perform a ZSK rollover (as described in Section 4.1.1 of RFC 6781.

If the value of the dnssecOps.csk input parameter is true, then this test will be skipped.

The system will monitor the zone specified in the dnssec.zskRolloverZone input parameter. The domain may be present anywhere in the global DNS hierarchy (that is, it does not need to be a TLD), but MUST have a secure chain of trust up to the root zone, so that it can be validated using the root zone trust anchor.

The zone MUST contain at least 10,000 delegations, where a delegation is considered to be one or more NS records with owner names that are below the zone’s origin. If NSEC3 is used for secure denial of existence, the opt-out flag MUST NOT be set (that is, an RRSIG record should be present for all NS rrsets, irrespective of whether a corresponding DS record is published).

Monitoring will be carried out using SOA queries sent to multiple validating DNS resolvers, and by validating the result of a zone transfer from the server(s) specified in the dnssecOps.primaryServers input parameter.

During the test period (currently defined as 48 hours) the operator MUST successfully carry out a ZSK rollover for the domain, where the Zone Signing Key is replaced, without disrupting the chain of trust.

The original ZSK MUST additionally be unpublished (removed from the zone) before the end of the test period.

To simplify testing, applicants may wish to provision the zone such that it is configured with short TTLs and a short ZSK lifetime, so that a ZSK rollover is guaranteed to occur within the 48 test period.

7.49.3. Errors

This test case may produce the following errors:

7.49.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

7.49.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.49.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.49.7. Test suites

This test case is used in the following test suite(s):

7.50. dnssecOps02-KSKRollover - KSK rollover

7.50.1. Maturity Level

7.50.2. Description

This test case verifies the RSP’s ability to perform a CSK/KSK rollover (as described in Sections 4.1.2 and 4.13 of RFC 6781.

The system will monitor the zone specified in the dnssec.kskRolloverZone input parameter. The domain may be present anywhere in the global DNS hierarchy (that is, it does not need to be a TLD), but MUST have a secure chain of trust up to the root zone, so that it can be validated using the root zone trust anchor.

The zone MUST contain at least 10,000 delegations, where a delegation is considered to be one or more NS records with owner names that are below the zone’s origin. If NSEC3 is used for secure denial of existence, the opt-out flag MUST NOT be set (that is, an RRSIG record should be present for all NS rrsets, irrespective of whether a corresponding DS record is published).

Monitoring will be carried out using SOA queries sent to multiple validating DNS resolvers, and by validating the result of a zone transfer from the server(s) specified in the dnssecOps.primaryServers input parameter.

During the test period (currently defined as 48 hours) the operator MUST successfully carry out a KSK rollover for the domain, where the Key Signing Key is replaced, and the DS record in the parent zone is updated, without disrupting the chain of trust.

The DS record for the original KSK MUST additionally be removed from the parent zone before the end of the test period.

To simplify testing, applicants may wish to use a subdomain of an existing DNSSEC-signed zone under their control, so that completion of the test is not dependent on interaction with a third party.

7.50.3. Errors

This test case may produce the following errors:

7.50.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

7.50.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.50.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.50.7. Test suites

This test case is used in the following test suite(s):

7.51. dnssecOps03-AlgorithmRollover - algorithm rollover

7.51.1. Maturity Level

7.51.2. Description

This test case verifies the RSP’s ability to perform an algorithm rollover (as described in Section 4.1.4 of RFC 6781.

The system will monitor the zone specified in the dnssec.algorithmRolloverZone input parameter. The domain may be present anywhere in the global DNS hierarchy (that is, it does not need to be a TLD), but MUST have a secure chain of trust up to the root zone, so that it can be validated using the root zone trust anchor.

The zone MUST contain at least 10,000 delegations, where a delegation is considered to be one or more NS records with owner names that are below the zone’s origin. If NSEC3 is used for secure denial of existence, the opt-out flag MUST NOT be set (that is, an RRSIG record should be present for all NS rrsets, irrespective of whether a corresponding DS record is published).

Monitoring will be carried out using SOA queries sent to multiple validating DNS resolvers, and by validating the result of a zone transfer from the server(s) specified in the dnssecOps.primaryServesr input parameter.

During the test period (currently defined as 48 hours) the operator MUST successfully carry out an algorithm rollover for the domain (including an update to the DS record in the parent zone), where the algorithm used to secure the domain is changed, without disrupting the chain of trust.

The DS record for the original KSK MUST additionally be removed from the parent zone before the end of the test period.

Note that the specific algorithms being rolled to and from are not significant (although they MUST be present in the IANA registry and comply with all other requirements specified in the DNSSEC test suite); it is not required that the new algorithm be more “secure” than the original algorithm; only that they are different. So for example, a rollover from algorithm 13 (ECDSAP256SHA256) to algorithm 8 (RSASHA256) will be accepted as well as a rollover from RSASHA256 to ECDSAP256SHA256.

To simplify testing, applicants may wish to use a subdomain of an existing DNSSEC-signed zone under their control, so that completion of the test is not dependent on interaction with a third party.

7.51.3. Errors

This test case may produce the following errors:

7.51.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

7.51.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.51.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.51.7. Test suites

This test case is used in the following test suite(s):

7.52. epp-01 - Service connectivity test

7.52.1. Maturity Level

7.52.2. Description

This test confirms that the EPP service is reachable from the probe servers.

  1. At least one A record MUST be published in the DNS for the EPP hostname, to allow IPv4-only hosts to connect to the EPP service.
  2. At least one AAAA record SHOULD be published in the DNS for the EPP hostname, to allow IPv6-only hosts to connect to the EPP service.
  3. EPP is associated with TCP port 700. All IPv4/IPv6 addresses published in the DNS for the EPP hostname MUST accept TCP connections on this port. Since the EPP specification requires IP-based access control, the RSP MUST configure their firewall to allow access from the IP addresses listed in the epp.clientACL resource.
  4. EPP uses TLS to secure the channel between client and server. All service ports MUST support TLSv1.2 and optionally any subsequent protocol published by the IETF.
  5. TLSv1.1 and all previous versions have known security issues and MUST NOT be supported by any service ports.
  6. To ensure that the connection can be trusted, all service ports MUST present a certificate issued by a trusted CA, such as those supported by major browsers.
  7. All TLS certificates MUST NOT have expired, and MUST be presented wth any required intermediate certificates.
  8. The EPP server name MUST match at least one subjectAltName field in all presented certificates (either exact match or wildcard).
  9. Service ports MUST use at least one of the ciphers recommended in RFC 9325 (or any successor document).

7.52.3. Errors

This test case may produce the following errors:

7.52.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.52.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.52.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

7.52.7. Test suites

This test case is used in the following test suite(s):

7.53. epp-02 - Protocol conformance test

7.53.1. Maturity Level

7.53.2. Description

Once a connection is established, all service ports MUST send a valid <greeting> frame to the client.

  1. The <svID> element in the <greeting> MUST identify the EPP server.
  2. The <svDate> element in the <greeting> MUST specify a time within 30 seconds of the current date and time as received from the NTP network.
  3. There MUST be exactly one <version> element in the and it MUST contain exactly 1.0.
  4. All <lang> element(s) in the <greeting> MUST contain valid language codes. At least en MUST be included.
  5. All <objURI> element(s) in the <greeting> MUST contain XML namespace URIs that are appropriate. The only mandatory URI that MUST be present is the domain namespace URI. The host and contact namespace URIs may be required depending on the epp.hostModel and general.registryDataModel parameters.
  6. All <extURI> element(s) in the <greeting> MUST contain XML namespace URIs that have been registered in the IANA registry, and that the mandatory extensions are also included.
  7. <extURI> elements containing the following XML namespaces MUST be present in the <greeting>:
    • urn:ietf:params:xml:ns:secDNS-1.1
    • urn:ietf:params:xml:ns:launch-1.0
    • urn:ietf:params:xml:ns:rgp-1.0
  8. With the exception of the <svDate> element, all values in the <greeting> MUST match those found in the epp.greeting input parameter.

This test case will produce the EPP_GREETING_RECOMMENDED_EXTENSION_MISSING warning if any of the following XML namespace URIs are not included in the <svcExtension> element:

  • urn:ietf:params:xml:ns:epp:secure-authinfo-transfer-1.0
  • urn:ietf:params:xml:ns:epp:unhandled-namespaces-1.0
  • urn:ietf:params:xml:schema:epp:loginSec-1.0

7.53.3. Errors

This test case may produce the following errors:

7.53.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

7.53.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.53.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.53.7. Test suites

This test case is used in the following test suite(s):

7.54. epp-03 - Authentication test

7.54.1. Maturity Level

7.54.2. Description

This test case validates the server’s implementation of client authentication. The client will submit a series of <login> commands to confirm that:

  • the server rejects a <login> command with a (randomly generated) non- existent client ID;
  • the server rejects a <login> command with a valid client ID, but an invalid password;
  • the server rejects a <login> command with a valid client ID and password but an incorrect client certificate;
  • the server accepts a <login> command with a valid client ID, password and client certificate;

The client will use the object and extension XML namespaces from the server’s <greeting> as part of the <login> command.

If the server supports the Login Security Extension (see RFC 8807) then this will be used by the client.

7.54.3. Errors

This test case may produce the following errors:

7.54.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.54.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.54.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.54.7. Test suites

This test case is used in the following test suite(s):

7.55. epp-04 - Domain <check> command test

7.55.1. Maturity Level

7.55.2. Description

The client will perform a series of <check> commands and will validate the avail attribute of the <domain:name> elements in the server response, as follows:

  • syntactically invalid domain name: avail attribute MUST be 0 or false.
  • valid but registered domain name: avail attribute MUST be 0 or false. The names provided in the epp.registeredNames input parameter will be used to test this.
  • syntactically valid, unregistered domain name: avail attribute MUST be 1 or true. The domain name will be generated using random characters.

A “syntactically valid” domain name is one that complies with the format specified in RFC 1123. This test case does not consider IDN names.

Checks will be carried out for all TLDs in the TLD set whose idnOnly property is false. If a TLD’s idnOnly property is true then that TLD will be skipped (the functionality of the <check> command for these TLDs will be checked in the idn-01 test case).

7.55.3. Errors

This test case may produce the following errors:

7.55.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.55.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.55.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.55.7. Test suites

This test case is used in the following test suite(s):

7.56. epp-05 - Host <check> command test (if applicable)

7.56.1. Maturity Level

7.56.2. Description

If the EPP server supports host objects, this test will perform a series of <check> commands and will validate the avail attribute of the <host:name> elements in the server response, as follows:

  • syntactically invalid hostname: avail attribute MUST be 0 or false.
  • valid but registered hostname: avail attribute MUST be 0 or false.
  • syntactically valid and unregistered hostname: avail attribute MUST be 1 or true. The hostname will be generated using random characters.

A “syntactically valid” hostname is one that complies with the format specified in RFC 1123 (this test case does not consider IDN names).

If the epp.hostModel input parameter is attributes, this test will be skipped.

7.56.3. Errors

This test case may produce the following errors:

7.56.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

7.56.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.56.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.56.7. Test suites

This test case is used in the following test suite(s):

7.57. epp-06 - Contact <check> command test (if applicable for the registry type)

7.57.1. Maturity Level

7.57.2. Description

If the EPP server supports contact objects, this test will perform a series of <check> commands and will validate the avail attribute of the <contact:id> elements in the server response, as follows:

  • syntactically invalid ID: avail attribute MUST be 0 or false.
  • valid but registered ID: avail attribute MUST be 0 or false.
  • valid and unregistered ID: avail attribute MUST be 1 or true. The ID will be generated using random characters.

If the general.registryDataModel input parameter is minimum, this test will be skipped.

7.57.3. Errors

This test case may produce the following errors:

7.57.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

7.57.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.57.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.57.7. Test suites

This test case is used in the following test suite(s):

7.58. epp-07 - Contact <create> command test (if applicable for the registry type)

7.58.1. Maturity Level

7.58.2. Description

This test attempts to create a number of contact objects, and validates the server’s response. For example, the test will expect that the server will reject a command that creates an object with missing or invalid properties, but will accept a command to create an object with valid properties. Property values will be randomly generated but will contain realistic values. No personal information will be transmitted as part of this test.

If the general.registryDataModel input parameter is minimum, this test will be skipped. Otherwise, this client will select the appropriate registrar credentials based on the values of the epp.clid01DataModel and epp.clid02DataModel input parameters.

The test will confirm that the server checks and validates the values of the following elements against the XML schema provided in RFC 5733:

  • <contact:id>

  • <contact:postalInfo> element(s)

  • <contact:name> element

  • <contact:org> element

  • <contact:street> element

  • <contact:city> element

  • <contact:cc> element

  • <contact:voice>

  • <contact:email>

  • The server MUST NOT accept a <contact:id> element that contains a value that is not a valid clIDType value;

  • The server MUST NOT accept a <contact:postalInfo> element that contains a type attribute that is neither int nor loc;

  • The server MUST NOT accept a <contact:cc> element that contains a value that is not a valid ISO 3166-1 alpha-2 code;

  • The server MUST NOT accept a <contact:voice> element that contains a value that does not conform to the format described in Section 2.5 of RFC 5733;

  • The server MUST NOT accept a <contact:email> element that contains a value that does not conform to the format specified in RFC 5322.

Once objects have been created, the client will then perform <info> commands to verify that the server has correctly stored the provided values.

7.58.3. Errors

This test case may produce the following errors:

7.58.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.58.5. Data providers

This test case uses the following data providers(s):

7.58.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.58.7. Test suites

This test case is used in the following test suite(s):

7.59. epp-08 - Contact object access control (if applicable)

7.59.1. Maturity Level

7.59.2. Description

This test will confirm that EPP clients are unable to perform <info> and <update> commands on objects that they do not sponsor.

If the general.registryDataModel input parameter is minimum, this test will be skipped.

The client will connect using a set of alternate credentials and will submit <info> and <update> commands on the contact objects created in epp-07. The server MUST respond with a 2201 “authorization error” response.

7.59.3. Errors

This test case may produce the following errors:

7.59.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.59.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.59.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.59.7. Test suites

This test case is used in the following test suite(s):

7.60. epp-09 - Contact <update> command test (if applicable for the registry type)

7.60.1. Maturity Level

7.60.2. Description

This test will perform <update> commands on the objects created during epp-07 and will confirm that the server correctly rejects invalid commands (which would specify invalid property values) and accepts valid commands.

If the general.registryDataModel input parameter is minimum, this test will be skipped. Otherwise, this client will select the appropriate registrar credentials based on the values of the epp.clid01DataModel and epp.clid02DataModel input parameters.

The test will confirm that the server checks and validates <update> commands which transform the values of the following elements:

  • <contact:status>
  • <contact:postalInfo> elements (both int and loc)
    • <contact:name>
    • <contact:org>
    • <contact:addr> elements
      • <contact:street> element(s)
      • <contact:city> element
      • <contact:sp> element
      • <contact:pc> element
      • <contact:cc> element
  • <contact:voice>
  • <contact:email>

Once objects have been updated, the client will then perform <info> commands to verify that the server has correctly stored the provided values.

7.60.3. Errors

This test case may produce the following errors:

7.60.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.60.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.60.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.60.7. Test suites

This test case is used in the following test suite(s):

7.61. epp-10 - Contact <delete> command test (if applicable for the registry type)

7.61.1. Maturity Level

7.61.2. Description

This test will perform <delete> commands on the objects created during epp-24 and will confirm that the server accepts the <delete> command with a 1xxx response code.

If the general.registryDataModel input parameter is minimum, this test will be skipped.

Once the <delete> commands have been submitted, the client will perform <info> commands to confirm that the objects have actually been removed from the repository. If the response to the previous <delete> command was 1001, this step will be skipped.

7.61.3. Errors

This test case may produce the following errors:

7.61.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.61.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.61.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.61.7. Test suites

This test case is used in the following test suite(s):

7.62. epp-11 - Host <create> command test (if applicable)

7.62.1. Maturity Level

7.62.2. Description

This test attempts to create a number of host objects, and validates the server’s response. For example, the test will expect that the server will reject a command that creates an object with missing or invalid properties, but will accept a command to create an object with valid properties. Property values will be randomly generated but will contain realistic values. No personal information will be transmitted as part of this test.

If the epp.hostModel input parameter is attributes, this test will be skipped.

The test will confirm that the server checks and validates the values of the following elements:

  • <host:name> (both in- and out-of-bailiwick, for each TLD in the TLD set)
  • <host:status>
  • <host:addr> elements (both IPv4 and IPv6)

If the epp.hostModel input parameter is attributes, this test will be skipped.

The client will then perform <info> commands on the objects successfully created to confirm that the server has correctly stored the provided values.

7.62.3. Errors

This test case may produce the following errors:

7.62.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.62.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.62.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.62.7. Test suites

This test case is used in the following test suite(s):

7.63. epp-12 - Host object access control (if applicable)

7.63.1. Maturity Level

7.63.2. Description

This test will confirm that EPP clients are unable to perform <info> commands on objects that they do not sponsor.

If the epp.hostModel input parameter is attributes, this test will be skipped.

The client will connect using a set of alternate credentials and will submit <update> commands on the contact objects created in epp-11. The server MUST respond with a 2201 “authorization error” response.

7.63.3. Errors

This test case may produce the following errors:

7.63.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.63.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.63.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.63.7. Test suites

This test case is used in the following test suite(s):

7.64. epp-13 - Host <update> command test (if applicable)

7.64.1. Maturity Level

7.64.2. Description

This test will perform <update> commands on the objects created during epp-11 and will confirm that the server correctly rejects invalid commands (which would specify invalid property values) and accepts valid commands.

If the epp.hostModel input parameter is attributes, this test will be skipped.

The test will confirm that the server checks and validates <update> commands which transform the values of the following elements:

  • <host:status>
  • <host:addr> elements (both IPv4 and IPv6)

Note: the server’s ability to support host renames is checked in a later test.

The client will then perform <info> commands on the objects successfully updated to confirm that the server has correctly stored the updated values.

7.64.3. Errors

This test case may produce the following errors:

7.64.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.64.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.64.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.64.7. Test suites

This test case is used in the following test suite(s):

7.65. epp-14 - Domain <create> command test

7.65.1. Maturity Level

7.65.2. Description

This test performs a series domain <create> commands, using pseudo- random syntactically valid ASCII domain names under each TLD in the TLD set. Depending on the value of the general.registryDataModel and epp.requiredContactTypes input parameters, one or more contact objects will be created (using pseudo-random contact information) beforehand and used as the registrant (and other) contacts. If the epp.hostModel parameter is objects, then two host objects with syntactically valid pseudo-random names will be created and used as the nameservers (otherwise the names will be provided as attributes).

The client will perform several <create> commands, each of which will test certain aspects of the server’s processing of those commands, for example:

  • to confirm that the server does not accept invalid values for object properties (such as domain name, registration period, registant ID, nameservers, and DS record parameters). Examples:
    • invalid domain
    • invalid period (1-10 years)
    • invalid host attributes (if applicable)
    • host attributes with subordinate names and missing glue (if applicable)
    • invalid DS/keyData record parameters (keyTag, algorithm, digest type, and malformed digest)
  • to confirm that the server does not accept commands which reference non-existent host/contact objects (if applicable)
  • to confirm that the server rejects a <create> command which specifies a registrant contact (where the general.registryDataModel input parameter is minimum or per-registrar)
  • to confirm that the server rejects a <create> command which does not specify a registrant contact (where the general.registryDataModel input parameter is maximum or per-registrar)
  • to confirm that the server rejects a <create> command containing host objects when the epp.hostModel parameter is attributes
  • to confirm that the server rejects a <create> command containing host attributes when the epp.hostModel parameter is objects
  • to confirm that the the server which implements RFC 9154 accepts a <create> command without an authInfo command.

Both registrar IDs (those specified in the epp.clid01 and epp.clid02 input parameters) will be used to create domains. If the value of the epp.registryDataModel input parameter is per-registrar, then the epp.clid01DataModel and epp.clid02DataModel input parameters will be taken into consideration when determining whether contact objects are needed to successfully create a domain name.

Once the <create> commands have been processed, the client will then perform <info> commands to confirm that:

  • the <roid> element is valid and contains a repository ID registered with IANA;
  • the <crDate> and <exDate> elements are present and valid;
  • the <crID> and <clID> elements match the client ID used to create the domain.
  • DNSSEC information provided in the <create> command is present and correct.

7.65.3. Errors

This test case may produce the following errors:

7.65.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

7.65.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.65.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.65.7. Test suites

This test case is used in the following test suite(s):

7.66. epp-15 - Registry object integrity test

7.66.1. Maturity Level

7.66.2. Description

This test confirms that the EPP server will refuse a request to delete a linked object.

If the epp.hostModel input parameter is attributes, and the general.registryDataModel input parameter is minimum, then this test will be skipped. Otherwise, this client will select the appropriate registrar credentials based on the values of the epp.clid01DataModel and epp.clid02DataModel input parameters.

The client will submit <delete> commands for any contact and host objects created during epp-14. The server MUST respond with a 2305 “Object association prohibits operation” error.

7.66.3. Errors

This test case may produce the following errors:

7.66.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.66.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.66.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.66.7. Test suites

This test case is used in the following test suite(s):

7.67. epp-16 - Domain <update> command test

7.67.1. Maturity Level

7.67.2. Description

This test will confirm that the client is able to perform an <update> command on the domain names created in epp-14, including:

  • adding and removing client-assigned status codes
  • adding and removing nameservers (whether objects or attributes)
  • changing registrant object (if applicable)
  • adding and remove DNSSEC information

The client will also confirm that it cannot perform an <update> command on a domain sponsored by another registrar, and that the server responds with a 2201 authorization error.

Once the <update> commands have been processed, the client will then perform <info> commands to confirm that the changes have been correctly stored by the server.

7.67.3. Errors

This test case may produce the following errors:

7.67.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.67.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.67.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.67.7. Test suites

This test case is used in the following test suite(s):

7.68. epp-17 - Service Port consistency test

7.68.1. Maturity Level

7.68.2. Description

This test confirms that all EPP service ports respond with consistent object information.

The client will establish seperate connections to each EPP service port (defined as an IP address and TCP port) and perform <info> commands on the objects created in epp-14. In all cases, the server MUST respond with a 1000 response and the content of the <infData> element MUST be identical on all service ports.

7.68.3. Errors

This test case may produce the following errors:

7.68.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.68.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.68.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.68.7. Test suites

This test case is used in the following test suite(s):

7.69. epp-18 - Domain <renew> command test

7.69.1. Maturity Level

7.69.2. Description

This test will confirm that the client is able to renew domain names. The client will submit a number of <renew> commands for the domains created in epp-14.

  • Following a succesful <renew> command, the expiry date of the domain MUST have been increased by the period specified by the client;
  • The domain MUST have an RGP status of renewPeriod;
  • The server MUST reject a <renew> command if it would result in the expiry date being more than 10 years into the future.

The client will issue the <renew> commands and then perform <info> commands to ensure that the expiry date and RGP status of the domain are set correctly.

7.69.3. Errors

This test case may produce the following errors:

7.69.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.69.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.69.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.69.7. Test suites

This test case is used in the following test suite(s):

7.70. epp-19 - Domain <transfer> command test

7.70.1. Maturity Level

7.70.2. Description

This test will confirm that the client is able to initiate a domain transfer.

The client will perform an <update> command to set the authInfo code for the test domain (taken from the set created in epp-14) to a randomly-determined value. If the server implements RFC 9154, it MUST reject the <update> command if the authInfo code is insufficently secure.

Then, using a second set of credentials, the client will connect to the EPP server and authenticate, submit <transfer> commands, and validate the responses.

This test will confirm that:

  • the server rejects a <transfer> command with an invalid authInfo code
  • the server rejects a command which would extend the domain’s validity period more than 10 years into the future
  • the server accepts a <transfer> command with a valid authInfo code and period.

The client will use an <info> command to ensure that the pendingTransfer status code is added to the domain after a successul transfer request.

Once the transfer request has been accepted, the sponsoring client will wait for a message to be received on the server’s message queue, and will then approve the transfer. This message MUST be received within 120 seconds of the transfer request.

Once the gaining registrar has also received a message on the queue, the client will use an <info> command to confirm that:

  • the domain is now under the sponsorship of the gaining registrar;
  • the authInfo code has been reset by the server (if the server supports RFC 9154);
  • the domain has the transferPeriod RGP status.

This message MUST be received within 120 seconds of the transfer approval.

7.70.3. Errors

This test case may produce the following errors:

7.70.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.70.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.70.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.70.7. Test suites

This test case is used in the following test suite(s):

7.71. epp-20 - Domain <transfer> rejection test

7.71.1. Maturity Level

7.71.2. Description

This test confirms that the server behaves correctly if the sponsoring registrar of a domain rejects a transfer request.

The test procedure matches that of epp-19, but the transfer request will be rejected rather than approved. An <info> command will be used to confirm that the domain name remains under the sponsorship of the original registrar.

7.71.3. Errors

This test case may produce the following errors:

7.71.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.71.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.71.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.71.7. Test suites

This test case is used in the following test suite(s):

7.72. epp-21 - Domain <delete> command test

7.72.1. Maturity Level

7.72.2. Description

This test will perform <delete> commands on the objects created during epp-14 and will confirm that the server accepts the <delete> command with a 1xxx response code.

Once the <delete> commands have been processed, the client will perform <info> commands on the deleted to object to confirm that:

  • if the server responded to the <delete> command with a 1000 response, then the domain no longer exists
  • if the server responded to the <delete> command with a 1001 response, then the domain has the pendingDelete status and the redemptionPeriod RGP status.

7.72.3. Errors

This test case may produce the following errors:

7.72.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.72.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.72.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.72.7. Test suites

This test case is used in the following test suite(s):

7.73. epp-22 - Domain restore test

7.73.1. Maturity Level

7.73.2. Description

This test will perform RGP restore operations on the objects deleted during epp-21, in order to confirm the correct operation of the server’s implementation of RFC 3915.

Once the restore request has been procssed, the client will perform <info> commands on the deleted to object to confirm that the domain no longer has the pendingDelete status and RGP status.

7.73.3. Errors

This test case may produce the following errors:

7.73.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

7.73.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.73.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.73.7. Test suites

This test case is used in the following test suite(s):

7.74. epp-23 - Host rename test (if applicable)

7.74.1. Maturity Level

7.74.2. Description

This tests verifies the server’s support for host rename operations.

If the epp.hostModel input parameter is attributes, this test will be skipped.

The client will perform <update> commands on the objects created during epp-11 and will confirm that the server correctly accepts or rejects the commands, for example:

  • an <update> command which specifies a syntatically invalid host name is rejected;
  • an <update> command which places the object out-of-bailiwick is accepted;
  • an <update> command which places the object within a non-existent domain is rejected;
  • an <update> command which places the object within a domain sponsored by another registrar is rejected. The domain name(s) provided in the epp.registeredNames parameter will be used for this test.
  • an <update> command which places the object within a domain sponsored by the test client is accepted. A domain created during the epp-14 test case will be used as the new parent domain.

The client will then perform <info> commands on the objects successfully updated, to confirm that the server has correctly stored the updated values.

7.74.3. Errors

This test case may produce the following errors:

7.74.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.74.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.74.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.74.7. Test suites

This test case is used in the following test suite(s):

7.75. epp-24 - Host <delete> command test (if applicable)

7.75.1. Maturity Level

7.75.2. Description

This test will perform <delete> commands on the objects created during epp-11 and will confirm that the server accepts the <delete> command with a 1xxx response code.

If the epp.hostModel input parameter is attributes, this test will be skipped.

Once the <delete> commands have been submitted, if a 1000 response was received from the server, the client will perform <check> and <info> commands to confirm that the objects have been deleted.

7.75.3. Errors

This test case may produce the following errors:

7.75.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.75.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.75.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.75.7. Test suites

This test case is used in the following test suite(s):

7.76. idn-01 - Label validation test

7.76.1. Maturity Level

7.76.2. Description

This test confirms that the EPP server correctly accepts or rejects domain <create> commands for valid and invalid IDN labels, respectively.

If there are no IDN tables supported under any of the TLDs associated with the test, then this test will be skipped.

For each supported IDN table, the test client will perform a series of <check> and <create> commands using a pre-defined catalogue of test labels. If required, the client will create any contact object(s) needed.

The avail attribute of <domain:name> elements in the response to the <check> commands MUST be 0 or false for invalid labels, and 1 or true for valid labels.

The server MUST reject all <create> commands for invalid labels and MUST accept all <create> commands for valid labels.

7.76.3. Errors

This test case may produce the following errors:

7.76.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.76.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.76.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.76.7. Test suites

This test case is used in the following test suite(s):

7.77. idn-02 - Level 1 variant handling test

7.77.1. Maturity Level

7.77.2. Description

This test confirms the EPP server’s conformance with the Level 1 variant support (no support for variant activation, all variants are blocked).

If there are no IDN tables for which Level 1 support is claimed, this test will be skipped.

For each supported IDN table, the test client will perform a series of <create> commands using a pre-defined catalogue of test labels. If required, the client will create any contact object(s) needed.

The client will then submit <create> commands for one or more labels that are variants of the names created in the first step. The server MUST reject these commands.

7.77.3. Errors

This test case may produce the following errors:

7.77.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.77.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.77.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.77.7. Test suites

This test case is used in the following test suite(s):

7.78. idn-03 - Level 2 variant handling test

7.78.1. Maturity Level

7.78.2. Description

This test confirms the EPP server’s conformance with the Level 2 variant support (variants are supported within the same TLD).

If there are no IDN tables for which Level 2 support is claimed, this test will be skipped.

For each supported IDN table, the test client will perform a series of <create> commands using a pre-defined catalogue of test labels. If required, the client will create any contact object(s) needed.

The client will then submit <create> commands for one or more labels that are variants of the names created in the first step. Some of these commands will be made using the same registrar account as the first step, while some will be made using alternate credentials. If the value of the general.registryDataModel input parameter is maximum or per-registrar, then some commands will also use a different registrant contact.

The server MUST reject <create> commands where the (a) registrar is different from that of the primary label or (b) the registrant (if applicable) is different.

7.78.3. Errors

This test case may produce the following errors:

7.78.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.78.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.78.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.78.7. Test suites

This test case is used in the following test suite(s):

7.79. idn-04 - Level 3 variant handling test

7.79.1. Maturity Level

7.79.2. Description

This test confirms the EPP server’s conformance with the Level 3 variant support (variants are supported within variant TLD(s)).

If there are no IDN tables for which Level 3 support is claimed, this test will be skipped.

For each supported IDN table, the test client will perform a series of <create> commands using a pre-defined catalogue of test labels. If required, the client will create any contact object(s) needed.

The client will then submit <create> commands for one or more labels that are variants (at both second- and top-level) of the names created in the first step. Some of these commands will be made using the same registrar account as the first step, while some will be made using alternate credentials. If the value of the general.registryDataModel input parameter is maximum or per-registrar, then some commands will also use a different registrant contact.

The server MUST reject <create> commands where the (a) registrar is different from that of the primary label or (b) the registrant (if applicable) is different.

7.79.3. Errors

This test case may produce the following errors:

7.79.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.79.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.79.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.79.7. Test suites

This test case is used in the following test suite(s):

7.80. idn-05 - ASCII domains in IDN-only TLD test

7.80.1. Maturity Level

7.80.2. Description

This test confirms that the EPP server rejects EPP <create> commands for a domain under a TLD that is configured to be “IDN only” (that is, pure ASCII domains are not permitted).

If all TLDs in the test have idnOnly properties that are false, this test will be skipped.

For those TLDs for which the idnOnly property is true, an EPP <create> command will be sent to the EPP server for a domain name that is syntactically valid, comprised only of characters from the LDH ASCII range, and not already registered.

The EPP server MUST reject the command.

7.80.3. Errors

This test case may produce the following errors:

7.80.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.80.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.80.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.80.7. Test suites

This test case is used in the following test suite(s):

7.81. idn-06 - IDNA2008 conformance test

7.81.1. Maturity Level

7.81.2. Description

This test confirms that the EPP server rejects EPP <create> commands for domains that do not conform to the requirements of IDNA2008 (but which may be valid in IDNA2003).

EPP <create> commands will be sent to the server for a variety of pre-generated test labels. The server MUST reject all these commands.

7.81.3. Errors

This test case may produce the following errors:

7.81.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.81.5. Data providers

This test case uses the following data providers(s):

7.81.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.81.7. Test suites

This test case is used in the following test suite(s):

7.82. integration-01 - EPP -> RDAP Integration Test

7.82.1. Maturity Level

7.82.2. Description

This test confirms that the EPP and RDAP systems are properly integrated, that is, that transform commands performed on objects in the EPP system are reflected in the RDAP system within the Service Level Requirement of the SLA.

The test system will connect to the EPP server and create domain and (if applicable) host and contact objects using the same methodology as epp-14 epp-11. It will then perform RDAP queries for those objects.

The RDAP server MUST provide a 200 response for every object created within 1 hour of the object’s <crDate> element.

7.82.3. Errors

This test case may produce the following errors:

7.82.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

7.82.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.82.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.82.7. Test suites

This test case is used in the following test suite(s):

7.83. integration-02 - EPP -> DNS Integration Test

7.83.1. Maturity Level

7.83.2. Description

This test confirms that the EPP and DNS systems are properly integrated, that is, that transform commands performed on objects in the EPP system are reflected in the RDAP system within the Service Level Requirement of the SLA.

The test system will perform DNS queries to confirm that the DNS servers provide responses for the domain names created in integration-01. All DNS servers MUST provide the correct DNS response for all domains within 1 hour of the domains’s <crDate> element.

7.83.3. Errors

This test case may produce the following errors:

7.83.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

7.83.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.83.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.83.7. Test suites

This test case is used in the following test suite(s):

7.84. integration-03 - EPP -> RDE Integration Test

7.84.1. Maturity Level

7.84.2. Description

This test confirms that the EPP and RDE systems are properly integrated, that is, that objects created in the EPP system are reflected in a valid RDE deposit file within the Service Level Requirement of the SLA.

The test system will periodically connect to the SFTP server specified by the integration.rdeSFTPHostname input parameter, using the username specified in the integration.rdeSFTPUsername input parameter and the SSH key in the integration.rdeSFTPPublicKey resource, and look for .ryde files in the directory specified by the integration.rdeSFTPDirectory input parameter. Note that operators MUST ensure that the IP addresses listed in the integration.rdeSFTPACL resource have been added to the Access Control List for the SFTP server (if any).

All objects created in the integration-01 test case MUST be found within a valid RDE deposit file (that is, the deposit passes all the tests in the RDE test suite) within 24 hours of each object’s <crDate> element.

Furthermore, for each deposit found in the directory, the corresponding RDE report (as described in Section 2.1 of draft-lozano-icann-registry-interfaces) MUST be recieved on the test RRI environment before 23:59:59 UTC on the date specified in the Watermark element of the deposit file.

To facilitate submission of RDE reports, the RRI test environment will be configured to accept submissions for the TLDs associated with the test from clients using the same TLSA DNS hostnames that are configured for the test.

7.84.3. Errors

This test case may produce the following errors:

7.84.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

7.84.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.84.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

7.84.7. Test suites

This test case is used in the following test suite(s):

7.85. minimumRPMs-01 - Claims <check> command test

7.85.1. Maturity Level

7.85.2. Description

This test is used to confirm the conformance of the EPP server’s implementation of the Claims Check Form, as described in Section 3.1.1 of RFC 8334.

For this test, the applicant must configure their system using the test TMCH data files found in the following resources:

  • tmch.testCert
  • tmch.testCRL
  • tmch.testDNL
  • tmch.testSMDRL
  • tmch.testSURL

The client will connect to the EPP server using the provided credentials and will then perform a series of <check> commands, using the Launch extension to specify a value of claims for the type attribute of the <launch:check> element and the <launch:phase> element. It will then confirm that the server returns an appropriate response:

  • a <check> response for a domain that is present on the DNL contains the correct <launch:claimKey> element;
  • a <check> response for a domain that is NOT present on the DNL does not contain a <launch:claimKey> element.

7.85.3. Errors

This test case may produce the following errors:

7.85.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.85.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.85.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.85.7. Test suites

This test case is used in the following test suite(s):

7.86. minimumRPMs-02 - Sunrise domain/launch application <create> command test

7.86.1. Maturity Level

7.86.2. Description

This test is used to confirm the conformance of the EPP server’s implementation of the Sunrise Create Form, as described in Section 3.3.1 of RFC 8334.

For this test, the applicant must configure their system using the test TMCH data files found in the following resources:

  • tmch.testCert
  • tmch.testCRL
  • tmch.testDNL
  • tmch.testSMDRL
  • tmch.testSURL

The client will connect to the EPP server and will submit <create> commands, using domain names and SMD files present in the TMCH test environment.

If the server supports Start Date sunrises, the fully-qualified domain name will be constructed using a label from the SMD file and the minimumRPMS.sunriseTLD input parameter. If the domain is not already present in the registry, the Server MUST respond with a 1000 or 1001 result code, however, if the client receives a 2302 “object exists” result code, it will retry with a different domain name, until a 1000 or 1001 response is received.

If the server supports End Date sunrises, the fully-qualified domain name will be constructed using a label from the SMD file and the minimumRPMS.sunriseTLD input parameter. The Server MUST respond with a 1000 or 1001 result code, and create a launch application.

Once the <create> commands have been processed, the client will then perform <info> commands to confirm that the domains or launch applications have been created and that the submitted object properties have been correctly stored.

The client will also confirm that the server rejects attempts to:

  1. create a domain using an expired SMD;
  2. create a domain using a revoked SMD;
  3. create a domain using an SMD signed by a revoked certificate.
  4. create a domain using an SMD for a different domain.

7.86.3. Errors

This test case may produce the following errors:

7.86.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.86.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.86.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.86.7. Test suites

This test case is used in the following test suite(s):

7.87. minimumRPMs-03 - Trademark claims domain <create> command test

7.87.1. Maturity Level

7.87.2. Description

This test is used to confirm the conformance of the EPP server’s implementation of the Claims Create Form, as described in Section 3.3.2 of RFC 8334.

For this test, the applicant must configure their system using the test TMCH data files found in the following resources:

  • tmch.testCert
  • tmch.testCRL
  • tmch.testDNL
  • tmch.testSMDRL
  • tmch.testSURL

The client will connect to the EPP server and will submit <create> commands, using domain names present in the TMCH test environment.

The domain name will be constructed using a label from the DNL, and the minimumRPMS.claimsTLD input parameter. The client will perform a Trademark Claims <check> command beforehand to obtain the claim key, and will then synthesise a trademark claims acknowledgement. The server MUST respond with a 1000 or 1001 response.

Once the <create> commands have been processed, the client will then perform <info> commands to confirm that the domains have been created and that the submitted object properties have been correctly stored.

The client will also confirm that the server rejects attempts to:

  1. create a domain using an invalid claim key;
  2. create a domain using an expired claim key;
  3. create a domain using an acceptance datetime more than 12 months in the past.

7.87.3. Errors

This test case may produce the following errors:

7.87.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.87.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.87.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.87.7. Test suites

This test case is used in the following test suite(s):

7.88. rdap-01-ipv4Validation - IPv4 address validation

7.88.1. Maturity Level

7.88.2. Description

This test case comes from the RDAP Conformance Tool. For more information, see https://github.com/icann/rdap-conformance-tool/blob/master/doc/RDAPConformanceToolSpecifications.pdf.

7.88.3. Errors

This test case may produce the following errors:

7.88.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.88.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.88.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.88.7. Test suites

This test case is used in the following test suite(s):

7.89. rdap-02-ipv6Validation - IPv6 address validation

7.89.1. Maturity Level

7.89.2. Description

This test case comes from the RDAP Conformance Tool. For more information, see https://github.com/icann/rdap-conformance-tool/blob/master/doc/RDAPConformanceToolSpecifications.pdf.

7.89.3. Errors

This test case may produce the following errors:

7.89.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.89.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.89.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.89.7. Test suites

This test case is used in the following test suite(s):

7.90. rdap-03-domainNameValidation - Domain Name validation

7.90.1. Maturity Level

7.90.2. Description

This test case comes from the RDAP Conformance Tool. For more information, see https://github.com/icann/rdap-conformance-tool/blob/master/doc/RDAPConformanceToolSpecifications.pdf.

7.90.3. Errors

This test case may produce the following errors:

7.90.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.90.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.90.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.90.7. Test suites

This test case is used in the following test suite(s):

7.91. rdap-04-webUriValidation - Web URI validation

7.91.1. Maturity Level

7.91.2. Description

This test case comes from the RDAP Conformance Tool. For more information, see https://github.com/icann/rdap-conformance-tool/blob/master/doc/RDAPConformanceToolSpecifications.pdf.

7.91.3. Errors

This test case may produce the following errors:

7.91.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.91.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.91.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.91.7. Test suites

This test case is used in the following test suite(s):

7.92. rdap-05-domainCaseFoldingValidation - Domain label case folding validation

7.92.1. Maturity Level

7.92.2. Description

This test case comes from the RDAP Conformance Tool. For more information, see https://github.com/icann/rdap-conformance-tool/blob/master/doc/RDAPConformanceToolSpecifications.pdf.

7.92.3. Errors

This test case may produce the following errors:

7.92.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.92.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.92.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.92.7. Test suites

This test case is used in the following test suite(s):

7.93. rdap-06-stdRdapConformanceValidation - RDAP Conformance validation

7.93.1. Maturity Level

7.93.2. Description

This test case comes from the RDAP Conformance Tool. For more information, see https://github.com/icann/rdap-conformance-tool/blob/master/doc/RDAPConformanceToolSpecifications.pdf.

7.93.3. Errors

This test case may produce the following errors:

7.93.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.93.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.93.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.93.7. Test suites

This test case is used in the following test suite(s):

7.94. rdap-07-stdRdapLinksValidation - Links validation

7.94.1. Maturity Level

7.94.2. Description

This test case comes from the RDAP Conformance Tool. For more information, see https://github.com/icann/rdap-conformance-tool/blob/master/doc/RDAPConformanceToolSpecifications.pdf.

7.94.3. Errors

This test case may produce the following errors:

7.94.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.94.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.94.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.94.7. Test suites

This test case is used in the following test suite(s):

7.95. rdap-08-stdRdapNoticesRemarksValidation - Notices and Remarks Validation

7.95.1. Maturity Level

7.95.2. Description

This test case comes from the RDAP Conformance Tool. For more information, see https://github.com/icann/rdap-conformance-tool/blob/master/doc/RDAPConformanceToolSpecifications.pdf.

7.95.3. Errors

This test case may produce the following errors:

7.95.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.95.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.95.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.95.7. Test suites

This test case is used in the following test suite(s):

7.96. rdap-09-stdRdapLanguageIdentifierValidation - Language Identifier Validation

7.96.1. Maturity Level

7.96.2. Description

This test case comes from the RDAP Conformance Tool. For more information, see https://github.com/icann/rdap-conformance-tool/blob/master/doc/RDAPConformanceToolSpecifications.pdf.

7.96.3. Errors

This test case may produce the following errors:

7.96.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.96.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.96.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.96.7. Test suites

This test case is used in the following test suite(s):

7.97. rdap-10-stdRdapEventsValidation - Events Validation

7.97.1. Maturity Level

7.97.2. Description

This test case comes from the RDAP Conformance Tool. For more information, see https://github.com/icann/rdap-conformance-tool/blob/master/doc/RDAPConformanceToolSpecifications.pdf.

7.97.3. Errors

This test case may produce the following errors:

7.97.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.97.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.97.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.97.7. Test suites

This test case is used in the following test suite(s):

7.98. rdap-11-stdRdapStatusValidation - Status validation

7.98.1. Maturity Level

7.98.2. Description

This test case comes from the RDAP Conformance Tool. For more information, see https://github.com/icann/rdap-conformance-tool/blob/master/doc/RDAPConformanceToolSpecifications.pdf.

7.98.3. Errors

This test case may produce the following errors:

7.98.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.98.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.98.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.98.7. Test suites

This test case is used in the following test suite(s):

7.99. rdap-12-stdRdapPort43WhoisServerValidation - Port 43 WHOIS Server

7.99.1. Maturity Level

7.99.2. Description

This test case comes from the RDAP Conformance Tool. For more information, see https://github.com/icann/rdap-conformance-tool/blob/master/doc/RDAPConformanceToolSpecifications.pdf.

7.99.3. Errors

This test case may produce the following errors:

7.99.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.99.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.99.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.99.7. Test suites

This test case is used in the following test suite(s):

7.100. rdap-13-stdRdapPublicIdsValidation - Public IDs validation

7.100.1. Maturity Level

7.100.2. Description

This test case comes from the RDAP Conformance Tool. For more information, see https://github.com/icann/rdap-conformance-tool/blob/master/doc/RDAPConformanceToolSpecifications.pdf.

7.100.3. Errors

This test case may produce the following errors:

7.100.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.100.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.100.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.100.7. Test suites

This test case is used in the following test suite(s):

7.101. rdap-14-stdRdapAsEventActorValidation - asEventActor Validation

7.101.1. Maturity Level

7.101.2. Description

This test case comes from the RDAP Conformance Tool. For more information, see https://github.com/icann/rdap-conformance-tool/blob/master/doc/RDAPConformanceToolSpecifications.pdf.

7.101.3. Errors

This test case may produce the following errors:

7.101.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.101.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.101.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.101.7. Test suites

This test case is used in the following test suite(s):

7.102. rdap-15-stdRdapIpAddressesValidation - IP Addresses Validation

7.102.1. Maturity Level

7.102.2. Description

This test case comes from the RDAP Conformance Tool. For more information, see https://github.com/icann/rdap-conformance-tool/blob/master/doc/RDAPConformanceToolSpecifications.pdf.

7.102.3. Errors

This test case may produce the following errors:

7.102.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.102.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.102.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.102.7. Test suites

This test case is used in the following test suite(s):

7.103. rdap-16-stdRdapVariantsValidation - Variants validation

7.103.1. Maturity Level

7.103.2. Description

This test case comes from the RDAP Conformance Tool. For more information, see https://github.com/icann/rdap-conformance-tool/blob/master/doc/RDAPConformanceToolSpecifications.pdf.

7.103.3. Errors

This test case may produce the following errors:

7.103.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.103.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.103.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.103.7. Test suites

This test case is used in the following test suite(s):

7.104. rdap-17-stdRdapUnicodeNameValidation - Unicode name

7.104.1. Maturity Level

7.104.2. Description

This test case comes from the RDAP Conformance Tool. For more information, see https://github.com/icann/rdap-conformance-tool/blob/master/doc/RDAPConformanceToolSpecifications.pdf.

7.104.3. Errors

This test case may produce the following errors:

7.104.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.104.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.104.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.104.7. Test suites

This test case is used in the following test suite(s):

7.105. rdap-18-stdRdapLdhNameValidation - LDH name

7.105.1. Maturity Level

7.105.2. Description

This test case comes from the RDAP Conformance Tool. For more information, see https://github.com/icann/rdap-conformance-tool/blob/master/doc/RDAPConformanceToolSpecifications.pdf.

7.105.3. Errors

This test case may produce the following errors:

7.105.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.105.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.105.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.105.7. Test suites

This test case is used in the following test suite(s):

7.106. rdap-19-stdRdapRolesValidation - Roles validation

7.106.1. Maturity Level

7.106.2. Description

This test case comes from the RDAP Conformance Tool. For more information, see https://github.com/icann/rdap-conformance-tool/blob/master/doc/RDAPConformanceToolSpecifications.pdf.

7.106.3. Errors

This test case may produce the following errors:

7.106.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.106.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.106.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.106.7. Test suites

This test case is used in the following test suite(s):

7.107. rdap-20-stdRdapEntitiesValidation - Entities validation

7.107.1. Maturity Level

7.107.2. Description

This test case comes from the RDAP Conformance Tool. For more information, see https://github.com/icann/rdap-conformance-tool/blob/master/doc/RDAPConformanceToolSpecifications.pdf.

7.107.3. Errors

This test case may produce the following errors:

7.107.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.107.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.107.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.107.7. Test suites

This test case is used in the following test suite(s):

7.108. rdap-21-stdRdapSecureDnsValidation - Secure DNS validation

7.108.1. Maturity Level

7.108.2. Description

This test case comes from the RDAP Conformance Tool. For more information, see https://github.com/icann/rdap-conformance-tool/blob/master/doc/RDAPConformanceToolSpecifications.pdf.

7.108.3. Errors

This test case may produce the following errors:

7.108.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.108.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.108.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.108.7. Test suites

This test case is used in the following test suite(s):

7.109. rdap-22-stdRdapErrorResponseBodyValidation - Error Response Body

7.109.1. Maturity Level

7.109.2. Description

This test case comes from the RDAP Conformance Tool. For more information, see https://github.com/icann/rdap-conformance-tool/blob/master/doc/RDAPConformanceToolSpecifications.pdf.

7.109.3. Errors

This test case may produce the following errors:

7.109.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.109.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.109.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.109.7. Test suites

This test case is used in the following test suite(s):

7.110. rdap-23-stdRdapDomainLookupValidation - Domain Lookup Validation

7.110.1. Maturity Level

7.110.2. Description

This test case comes from the RDAP Conformance Tool. For more information, see https://github.com/icann/rdap-conformance-tool/blob/master/doc/RDAPConformanceToolSpecifications.pdf.

7.110.3. Errors

This test case may produce the following errors:

7.110.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.110.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.110.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.110.7. Test suites

This test case is used in the following test suite(s):

7.111. rdap-24-stdRdapEntityLookupValidation - Entity lookup validation

7.111.1. Maturity Level

7.111.2. Description

This test case comes from the RDAP Conformance Tool. For more information, see https://github.com/icann/rdap-conformance-tool/blob/master/doc/RDAPConformanceToolSpecifications.pdf.

7.111.3. Errors

This test case may produce the following errors:

7.111.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.111.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.111.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.111.7. Test suites

This test case is used in the following test suite(s):

7.112. rdap-25-stdRdapNameserverLookupValidation - Nameserver lookup validation

7.112.1. Maturity Level

7.112.2. Description

This test case comes from the RDAP Conformance Tool. For more information, see https://github.com/icann/rdap-conformance-tool/blob/master/doc/RDAPConformanceToolSpecifications.pdf.

7.112.3. Errors

This test case may produce the following errors:

7.112.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.112.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.112.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.112.7. Test suites

This test case is used in the following test suite(s):

7.113. rdap-26-stdRdapHelpValidation - Help validation

7.113.1. Maturity Level

7.113.2. Description

This test case comes from the RDAP Conformance Tool. For more information, see https://github.com/icann/rdap-conformance-tool/blob/master/doc/RDAPConformanceToolSpecifications.pdf.

7.113.3. Errors

This test case may produce the following errors:

7.113.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.113.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.113.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.113.7. Test suites

This test case is used in the following test suite(s):

7.114. rdap-27-stdRdapNameserversSearchValidation - Nameservers search validation

7.114.1. Maturity Level

7.114.2. Description

This test case comes from the RDAP Conformance Tool. For more information, see https://github.com/icann/rdap-conformance-tool/blob/master/doc/RDAPConformanceToolSpecifications.pdf.

7.114.3. Errors

This test case may produce the following errors:

7.114.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.114.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.114.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.114.7. Test suites

This test case is used in the following test suite(s):

7.115. rdap-91 - TLS version conformance check

7.115.1. Maturity Level

7.115.2. Description

NOTE: this test case is a placeholder for a test case that will eventually be added to the RDAP Conformance Tool.

This test case verifies that the RDAP server properly implements a secure TLS configuration.

  1. All service ports MUST support TLSv1.2 and optionally any subsequent protocol published by the IETF.
  2. TLSv1.1 and all previous versions have known security issues and MUST NOT be supported by any service ports.
  3. To ensure that the connection can be trusted, all service ports MUST present a certificate issued by a trusted CA, such as those supported by major browsers (see the epp.tlsCertificateStore resource).
  4. All TLS certificates MUST NOT have expired, and MUST be presented wth any required intermediate certificates.
  5. The RDAP server name MUST match at least one subjectAltName field in all presented certificates (either exact match or wildcard).
  6. Service ports MUST use at least one of the ciphers recommended in RFC 9325 (or any successor document).

7.115.3. Errors

This test case may produce the following errors:

7.115.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.115.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.115.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

7.115.7. Test suites

This test case is used in the following test suite(s):

7.116. rdap-92 - Service port consistency check

7.116.1. Maturity Level

7.116.2. Description

NOTE: this test case is a placeholder for a test case that will eventually be added to the RDAP Conformance Tool.

This test confirms that all RDAP service ports return identical responses.

Since applicants must provide an RDAP service over both IPv4 and IPv6, at least two service ports will be checked.

The client will establish separate connections to each RDAP service port (defined as an IP address and TCP port, where at least one IPv4 address/port pair and IPv6 address/port pair are expected) and perform RDAP queries on the objects specified in the rdap.testDomains, rdap.testEntities, and rdap.testNameservers input parameters.

The responses returned by each service port MUST, with the exception of the last update of RDAP database event, be consistent, once the JSON body has been parsed and canonicalised.

7.116.3. Errors

This test case may produce the following errors:

7.116.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.116.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.116.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.116.7. Test suites

This test case is used in the following test suite(s):

7.117. rde-01 - validate deposit filename format

7.117.1. Maturity Level

7.117.2. Description

  • The deposit filename MUST conform to the format specified in the RA.
  • The type of the deposit MUST be FULL.
  • The TLD in the filename MUST be present in the list of TLDs associated with the test.

7.117.3. Errors

This test case may produce the following errors:

7.117.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.117.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.117.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.117.7. Test suites

This test case is used in the following test suite(s):

7.118. rde-02 - validate signature over deposit file

7.118.1. Maturity Level

7.118.2. Description

The PGP signature MUST be valid for the deposit file and the RSP’s key.

7.118.3. Errors

This test case may produce the following errors:

7.118.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

7.118.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.118.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.118.7. Test suites

This test case is used in the following test suite(s):

7.119. rde-03 - decrypt deposit file(s)

7.119.1. Maturity Level

7.119.2. Description

It MUST be possible to decrypt the deposit file using the RST key. The PGP public key for which the deposit MUST be encrypted may be found in the URL specified by the rde.encryptionKey resource.

7.119.3. Errors

This test case may produce the following errors:

7.119.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.119.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.119.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

7.119.7. Test suites

This test case is used in the following test suite(s):

7.120. rde-04 - validate XML/CSV

7.120.1. Maturity Level

7.120.2. Description

  • XML deposit files MUST be well-formed and validate against the XML schema.
  • CSV files MUST conform to RFC 4180.
  • Deposits MUST NOT contain a mix of XML and CSV files for the deposit contents.

7.120.3. Errors

This test case may produce the following errors:

7.120.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.120.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.120.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.120.7. Test suites

This test case is used in the following test suite(s):

7.121. rde-05 - validate object types

7.121.1. Maturity Level

7.121.2. Description

The header object MUST reference the correct object XML namespace URIs.

The correct URIs are determined by the general.registryDataModel and epp.hostModel input parameters.

  • if the general.registryDataModel input parameter is maximum or per-registrar, then the contact URI MUST be present. If the value is true, then it MUST NOT be present.

  • if the epp.hostModel input parameter is ‘objects’, then the host URI MUST be present. If the value is attributes, then it MUST NOT be present.

All expected URIs MUST be present in the header, and the header MUST NOT contain any unexpected URIs.

7.121.3. Errors

This test case may produce the following errors:

7.121.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.121.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.121.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.121.7. Test suites

This test case is used in the following test suite(s):

7.122. rde-06 - validate object counts

7.122.1. Maturity Level

7.122.2. Description

The number of each type of object MUST match the number of objects actually present in the deposit file.

7.122.3. Errors

This test case may produce the following errors:

7.122.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.122.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.122.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.122.7. Test suites

This test case is used in the following test suite(s):

7.123. rde-07 - validate domain objects

7.123.1. Maturity Level

7.123.2. Description

Domain objects (whether CSV or XML) MUST have the required object properties, and the values of those object properties MUST be well-formed.

The required properties are:

  • <domain:name>
  • <domain:roid> (which MUST have a repository ID registered with IANA)
  • at least one <domain:status> element
  • <domain:registrant> (if general.registryDataModel is maximum)
  • <domain:clID> (sponsoring registrar ID)
  • <domain:crDate> (creation date), which MUST be before the timestamp in the deposit’s ’<watermark> element.
  • <domain:exDate> (expiry date), which MUST be after the timestamp in the deposit’s ’<watermark> element, unless the domain has the pendingDelete status.

Contact, host and registrar objects (including optional objects such as admin and tech contacts) which are referenced in domain objects MUST be present in the deposit.

7.123.3. Errors

This test case may produce the following errors:

7.123.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.123.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.123.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.123.7. Test suites

This test case is used in the following test suite(s):

7.124. rde-08 - validate host objects (if applicable)

7.124.1. Maturity Level

7.124.2. Description

Host objects (whether CSV or XML) MUST have the required object properties, and the values of those object properties MUST be well-formed.

The required properties are:

  • <host:name>
  • <host:roid> (which MUST have a repository ID registered with IANA)
  • at least one <domain:status> element
  • one or more <addr> elements (if the host name is subordinate to the TLD)
  • <host:clID> (sponsoring registrar ID)

If the applicant uses the host attribute model, then this test will be skipped.

Registrar objects which are referenced in host objects MUST be present in the deposit.

7.124.3. Errors

This test case may produce the following errors:

7.124.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.124.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.124.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.124.7. Test suites

This test case is used in the following test suite(s):

7.125. rde-09 - validate contact objects (if applicable)

7.125.1. Maturity Level

7.125.2. Description

Contact objects (whether CSV or XML) MUST have the required object properties, and the values of those object properties MUST be well-formed.

If the value of the general.registryDataModel input parameter is minimum, then this test will be skipped.

  • The value of the <contact:id> element MUST be unique in the deposit
  • The value of the <contact:roid> MUST have a repository ID registered with IANA
  • The object MUST NOT have two <rdeContact:postalInfo> elements with the same type attribute
  • The value of the <contact:cc> element MUST contain a value on the ISO-3166-alpha-2 list
  • The value of the <contact:email> element MUST be a valid mailbox

Registrar objects which are referenced in contact objects MUST be present in the deposit.

7.125.3. Errors

This test case may produce the following errors:

7.125.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.125.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.125.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.125.7. Test suites

This test case is used in the following test suite(s):

7.126. rde-10 - validate registrar objects

7.126.1. Maturity Level

7.126.2. Description

Registrar objects (whether CSV or XML) MUST have the required object properties, and the values of those object properties MUST be well-formed.

The required properties are:

  • <rdeRegistrar:id>
  • <rdeRegistrar:name>
  • <rdeRegistrar:gurid> (IANA ID)

7.126.3. Errors

This test case may produce the following errors:

7.126.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.126.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.126.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.126.7. Test suites

This test case is used in the following test suite(s):

7.127. rde-11 - validate IDN table objects (if applicable)

7.127.1. Maturity Level

7.127.2. Description

IDN table objects (whether CSV or XML) MUST have the required object properties, and the values of those object properties MUST be well-formed.

All IDN table objects present in the deposit MUST correspond to IDN tables approved for the TLD, and all approved tables MUST have a corresponding object in the deposit.

7.127.3. Errors

This test case may produce the following errors:

7.127.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.127.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.127.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.127.7. Test suites

This test case is used in the following test suite(s):

7.128. rde-12 - validate NNDN objects

7.128.1. Maturity Level

7.128.2. Description

NNDN table objects (whether CSV or XML) MUST have the required object properties, and the values of those object properties MUST be well-formed.

The aName property of NNDN objects MUST NOT match the name property of a domain object.

7.128.3. Errors

This test case may produce the following errors:

7.128.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.128.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.128.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.128.7. Test suites

This test case is used in the following test suite(s):

7.129. rde-13 - validate EPP parameters object

7.129.1. Maturity Level

7.129.2. Description

The EPP Parameters object MUST match the <greeting> element provided as an input parameter.

A test case in the EPP Test Suite will confirm that this also matches what is returned when a client connects to the EPP server.

7.129.3. Errors

This test case may produce the following errors:

7.129.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

7.129.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.129.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.129.7. Test suites

This test case is used in the following test suite(s):

7.130. rde-14 - validate policy object (if applicable)

7.130.1. Maturity Level

7.130.2. Description

The object policies included in the <rdePolicy:policy> object MUST conform to the Registration Data Policy and the applicable data model.

  • If the general.registryDataModel input parameter is minimum, then contact objects MUST NOT be present in the deposit.
  • If the epp.hostModel input parameter is attributes, then host objects MUST NOT be present in the deposit.

7.130.3. Errors

This test case may produce the following errors:

7.130.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.130.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.130.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.130.7. Test suites

This test case is used in the following test suite(s):

7.131. srsgw-01 - IPv4 and IPv6 connectivity

7.131.1. Maturity Level

7.131.2. Description

This test confirms that the SRS Gateway EPP system is reachable over IPv4 and IPv6.

The SRS Gateway EPP server host name will be resolved to obtain its IPv4 and IPv6 addresses. The client will then attempt to connect to TCP port 700 on these addresses and log in using the provided credentials.

7.131.3. Errors

This test case may produce the following errors:

7.131.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.131.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.131.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.131.7. Test suites

This test case is used in the following test suite(s):

7.132. srsgw-02 - Host <create> synchronization (if applicable)

7.132.1. Maturity Level

7.132.2. Description

This test confirms that host objects created in the SRS Gateway EPP system are correctly synchronized with the primary registry system.

If the value of the epp.hostModel input parameter is attributes, then this test will be skipped.

The client will connect to the SRS Gateway EPP system, authenticate, and submit a <create> command for a pseudo-randomly generated host name. IP address information will be provided if required. The server MUST respond with a 1000 or 1001 response. The client will then perform an <info> command and will capture the response.

It will then connect to the primary EPP system, authenticate, and perform an <info> command for the object created in the first step. If the server responds with a 2303 response, it will wait for 30 seconds and retry. The server MUST respond to the first or second <info> command with a 1000 response.

The two <info> responses will then be compared and MUST be identical.

7.132.3. Errors

This test case may produce the following errors:

7.132.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.132.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.132.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.132.7. Test suites

This test case is used in the following test suite(s):

7.133. srsgw-03 - Contact <create> synchronization (if applicable)

7.133.1. Maturity Level

7.133.2. Description

This test confirms that contact objects created in the SRS Gateway EPP system are correctly synchronized with the primary registry system.

If the general.registryDataModel input parameter is minimum, this test will be skipped. Otherwise, this client will select the appropriate registrar credentials based on the values of the epp.clid01DataModel and epp.clid02DataModel input parameters.

The client will connect to the SRS Gateway EPP system, authenticate, and submit a <create> command for a pseudo-randomly generated contact object. The client will then perform an <info> command and will capture the response.

It will then connect to the primary EPP system, authenticate, and perform an <info> command for the object created in the first step. If the server responds with a 2303 response, it will wait for 30 seconds and retry. The server MUST respond to the first or second <info> command with a 1000 response.

The two <info> responses will then be compared and MUST be identical.

7.133.3. Errors

This test case may produce the following errors:

7.133.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.133.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.133.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.133.7. Test suites

This test case is used in the following test suite(s):

7.134. srsgw-04 - Domain <create> synchronization

7.134.1. Maturity Level

7.134.2. Description

This test confirms that domain objects created in the SRS Gateway EPP system are correctly synchronized with the primary registry system.

The client will connect to the SRS Gateway EPP system, authenticate, and submit <create> commands for a pseudo-randomly generated domain names. Contact and nameserver objects created in srsgw-02 and srsgw-03 will be used if required. The server MUST respond with 1000 or 1001 responses. The client will then perform <info> commands and will capture the responses.

It will then connect to the primary EPP system, authenticate, and perform <info> commands for the domains created in the first step. If the server responds with a 2303 response, it will wait for 30 seconds and retry. The server MUST respond to the first or second <info> command with a 1000 response.

The pairs of <info> responses will then be compared and MUST be identical.

7.134.3. Errors

This test case may produce the following errors:

7.134.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.134.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.134.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.134.7. Test suites

This test case is used in the following test suite(s):

7.135. srsgw-05 - Domain <renew> synchronisation

7.135.1. Maturity Level

7.135.2. Description

This test confirms that the expiry dates of domain objects renewed in the SRS Gateway EPP system are correctly synchronized with the primary registry system.

The client will connect to the SRS Gateway EPP system, authenticate, and submit a <renew> command for the domain created in srsgw-04. The server MUST respond with a 1000 or 1001 response. The client will then perform an <info> command and will capture the response.

It will then connect to the primary EPP system, authenticate, and perform an <info> command for the domain renewed in the first step. The server MUST respond with a 1000 response.

The <exDate> element of the two <info> responses will then be compared and MUST be identical.

7.135.3. Errors

This test case may produce the following errors:

7.135.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.135.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.135.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.135.7. Test suites

This test case is used in the following test suite(s):

7.136. srsgw-06 - Domain <transfer> synchronisation

7.136.1. Maturity Level

7.136.2. Description

This test confirms that transfer requests submitted in the SRS Gateway EPP system are correctly synchronized with the primary registry system.

The client will connect to the SRS Gateway EPP system, authenticate, and perform an <update> command to specify an authInfo code for the domain created in srsgw-04. The server MUST respond with a 1000 or 1001 response.

It will then reconnect to the SRS Gateway EPP system using the credentials of a second registrar account and submit a <transfer op="request"> command using the authInfo command set for the domain in the first step. The server MUST respond with a 1000 or 1001 response.

It will then connect to the primary EPP system, authenticate, and perform an <info> command for the domain. The server MUST respond with a 1000 response.

  • if the response to the original <transfer op="request"> command was 1000, then the <clID> element MUST contain the value of the srsgw.eppClid01 input parameter.
  • if the response to the <transfer op="request"> command was 1001, then the domain MUST have the pendingTransfer status.

7.136.3. Errors

This test case may produce the following errors:

7.136.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.136.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.136.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.136.7. Test suites

This test case is used in the following test suite(s):

7.137. srsgw-07 - Domain <transfer> approval synchronisation

7.137.1. Maturity Level

7.137.2. Description

This test confirms that transfer request approvals submitted in the SRS Gateway EPP system are correctly synchronized with the primary registry system.

If the response to the <transfer op="request"> command performed in srsgw-07 was 1000, then this test will be skipped.

The client will connect to the SRS Gateway EPP system, authenticate, and perform an <transfer op="approve"> command for the domain for which a transfer was requested in srsgw-04. The server MUST respond with a 1000 or 1001 response.

It will then connect to the primary EPP system, authenticate, and perform an <info> command for the domain. The server MUST respond with a 1000 response. The <domain:clID> element MUST contain the value of the srsgw.eppClid01 input parameter.

7.137.3. Errors

This test case may produce the following errors:

7.137.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.137.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.137.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.137.7. Test suites

This test case is used in the following test suite(s):

7.138. srsgw-08 - Domain <delete> synchronisation

7.138.1. Maturity Level

7.138.2. Description

This test confirms that domain objects deleted in the SRS Gateway EPP system are correctly synchronized with the primary registry system.

The client will connect to the SRS Gateway EPP system, authenticate using the credentials provided in epp.clid02 and epp.pwd02, and submit a <delete> command for the domain transferred in srsgw-07. The server MUST respond with a 1001 response.

It will then connect to the primary EPP system, authenticate, and perform an <info> command for the domain renewed in the first step.

The domain object MUST have the pendingDelete status and have an RGP status of pendingDeleteRestorable.

7.138.3. Errors

This test case may produce the following errors:

7.138.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.138.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.138.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.138.7. Test suites

This test case is used in the following test suite(s):

7.139. srsgw-09 - Host <update> synchronization (if applicable)

7.139.1. Maturity Level

7.139.2. Description

This test confirms that host objects updated in the SRS Gateway EPP system are correctly synchronized with the primary registry system.

If the value of the epp.hostModel input parameter is attributes, then this test will be skipped.

The test client will connect to the SRS Gateway EPP server and perform <update> commands on the objects created in srsgw-02, specifically to add and remove status codes and IP addresses. It will then perform <info> commands on those objects.

The client will then connect to the primary registry EPP server and perform <info> commands for those objects.

The two sets of <info> responses MUST be identical.

7.139.3. Errors

This test case may produce the following errors:

7.139.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.139.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.139.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.139.7. Test suites

This test case is used in the following test suite(s):

7.140. srsgw-10 - Host <delete> synchronization (if applicable)

7.140.1. Maturity Level

7.140.2. Description

This test confirms that host objects deleted in the SRS Gateway EPP system are correctly synchronized with the primary registry system.

If the value of the epp.hostModel input parameter is attributes, then this test will be skipped.

The test client will connect to the SRS Gateway EPP server and perform <delete> commands on objects created in srsgw-02. The server MUST respond with a 1000 response.

The client will then connect to the primary registry EPP server and perform <info> commands for those objects. The server MUST respond with a 2303 “object does not exist” response.

7.140.3. Errors

This test case may produce the following errors:

7.140.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.140.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.140.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.140.7. Test suites

This test case is used in the following test suite(s):

7.141. srsgw-11 - Contact <update> synchronization (if applicable)

7.141.1. Maturity Level

7.141.2. Description

This test confirms that contact objects updated in the SRS Gateway EPP system are correctly synchronized with the primary registry system.

If the general.registryDataModel input parameter is minimum, this test will be skipped. Otherwise, this client will select the appropriate registrar credentials based on the values of the epp.clid01DataModel and epp.clid02DataModel input parameters.

The test client will connect to the SRS Gateway EPP server and perform <update> commands on the objects created in srsgw-03. It will then perform <info> commands on those objects.

The client will then connect to the primary registry EPP server and perform <info> commands for those objects.

The two sets of <info> responses MUST be identical.

7.141.3. Errors

This test case may produce the following errors:

7.141.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.141.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.141.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.141.7. Test suites

This test case is used in the following test suite(s):

7.142. srsgw-12 - Contact <delete> synchronization (if applicable)

7.142.1. Maturity Level

7.142.2. Description

This test confirms that contact objects delete in the SRS Gateway EPP system are correctly synchronized with the primary registry system.

If the general.registryDataModel input parameter is minimum, this test will be skipped. Otherwise, this client will select the appropriate registrar credentials based on the values of the epp.clid01DataModel and epp.clid02DataModel input parameters.

The test client will connect to the SRS Gateway EPP server and perform <delete> commands on objects created in srsgw-03. The server MUST respond with a 1000 response.

The client will then connect to the primary registry EPP server and perform <info> commands for those objects. The server MUST respond with a 2303 “object does not exist” response.

7.142.3. Errors

This test case may produce the following errors:

7.142.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.142.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.142.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.142.7. Test suites

This test case is used in the following test suite(s):

7.143. srsgw-13 - Domain RDAP synchronization

7.143.1. Maturity Level

7.143.2. Description

This test confirms that the SRS Gateway’s RDAP service provides responses to domain lookups that match those of the primary registry RDAP server.

The test system will perform RDAP queries for some of the objects created in srsgw-04 against both the primary registry RDAP server and the SRS Gateway RDAP server. After canonicalisation, the responses from each server MUST be identical.

7.143.3. Errors

This test case may produce the following errors:

7.143.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.143.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.143.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.143.7. Test suites

This test case is used in the following test suite(s):

7.144. srsgw-14 - Nameserver RDAP synchronization

7.144.1. Maturity Level

7.144.2. Description

This test confirms that the SRS Gateway’s RDAP service provides responses to domain lookups that match those of the primary registry RDAP server.

If the value of the epp.hostModel input parameter is attributes, then this test will be skipped.

The test system will perform RDAP queries for some of the objects created in srsgw-02 against both the primary registry RDAP server and the SRS Gateway RDAP server. After canonicalisation, the JSON responses from each server MUST be identical.

7.144.3. Errors

This test case may produce the following errors:

7.144.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.144.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.144.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.144.7. Test suites

This test case is used in the following test suite(s):

7.145. srsgw-15 - Registrar RDAP synchronization

7.145.1. Maturity Level

7.145.2. Description

This test confirms that the SRS Gateway’s RDAP service provides responses to registrar (entity) lookups that match those of the primary registry RDAP server.

The test system will perform RDAP queries for some of the objects created in srsgw-04 against the primary registry RDAP server in order to obtain the handle property of the entity with the registrar role. It will then construct two URLs using this value and the values of the rdap.baseURLs and srsgw.rdapBaseURLs input parameters. It will then retrieve those URLs.

After canonicalisation, the JSON responses from each server MUST be identical.

7.145.3. Errors

This test case may produce the following errors:

7.145.4. Input parameters

This test case requires the following input parameters, in addition to those defined in the test suite:

  • None specified.

7.145.5. Data providers

This test case uses the following data providers(s):

  • None specified.

7.145.6. Resources

The following resources may be required to prepare for this test case, in addition to those defined in the test suite:

  • None specified.

7.145.7. Test suites

This test case is used in the following test suite(s):

8. Input Parameters

8.1. dns.nameservers

8.1.1. Description

The set of nameservers that will be authoritative for the zones used in the DNSSEC operations test suite.

8.1.2. Required

This input parameter is REQUIRED.

8.1.3. Example

{
   "dns.nameservers" : [
      {
         "name" : "ns1.example.com",
         "v4Addrs" : [
            "192.0.2.1"
         ],
         "v6Addrs" : [
            "2001:DB8::53:1"
         ]
      },
      {
         "name" : "ns2.example.net",
         "v4Addrs" : [
            "192.0.2.2"
         ],
         "v6Addrs" : [
            "2001:DB8::53:2"
         ]
      }
   ]
}

8.1.4. Schema

items:
  properties:
    name:
      description: The fully-qualified nameserver name.
      format: hostname
      type: string
    v4Addrs:
      description: The IPv4 address(es) for the nameserver.
      items:
        format: ipv4
        type: string
      minItems: 1
      type: array
    v6Addrs:
      description: The IPv6 address(es) for the nameserver.
      items:
        format: ipv6
        type: string
      minItems: 1
      type: array
  required:
  - name
  - addrs
  type: object
minItems: 1
type: array

8.1.5. Test cases

This input parameter is used in the following test cases:

8.1.6. Test suites

This input parameter is also used in the following test suites:

8.2. dnssec.dsRecords

8.2.1. Description

The DS record(s) that may be used to validate the DNSSEC signature for the TLD(s). This input parameter is an object where the object properties are the TLD names and the values are arrays of objects representing DS records.

There MUST be an entry for every TLD in the TLD set and there MUST be at least one DS record for each TLD.

8.2.2. Required

This input parameter is REQUIRED.

8.2.3. Example

{
   "dnssec.dsRecords" : [
      {
         "dsRecords" : [
            {
               "alg" : 8,
               "digest" : "E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D",
               "digestType" : 2,
               "keyTag" : 12345
            }
         ],
         "name" : "example"
      }
   ]
}

8.2.4. Schema

items:
  properties:
    dsRecords:
      description: the DS record(s)
      items:
        properties:
          alg:
            format: uint16
            type: integer
          digest:
            pattern: ^[0-9A-Fa-f]+$
            type: string
          digestType:
            format: uint16
            type: integer
          keyTag:
            format: uint16
            type: integer
        required:
        - keyTag
        - alg
        - digestType
        - digest
        type: object
      minItems: 1
      type: array
    name:
      description: the zone name
      format: hostname
      type: string
  required:
  - name
  - dsRecords
  type: object
minItems: 1
type: array

8.2.5. Test cases

This input parameter is used in the following test cases:

  • None specified.

8.2.6. Test suites

This input parameter is also used in the following test suites:

8.3. dnssecOps.algorithmRolloverZone

8.3.1. Description

The domain name which will be monitored for the occurrence of an algorithm rollover.

8.3.2. Required

This input parameter is REQUIRED.

8.3.3. Example

{
   "dnssecOps.algorithmRolloverZone" : "example.com"
}

8.3.4. Schema

format: hostname
type: string

8.3.5. Test cases

This input parameter is used in the following test cases:

8.3.6. Test suites

This input parameter is also used in the following test suites:

  • None specified.

8.4. dnssecOps.csk

8.4.1. Description

A boolean indicating whether the RSP uses a Combined Signing Key (CSK, also referred to as a “Single Type Signing Scheme”) instead of a split KSK/ZSK configuration.

8.4.2. Required

This input parameter is REQUIRED.

8.4.3. Example

{
   "dnssecOps.csk" : false
}

8.4.4. Schema

type: boolean

8.4.5. Test cases

This input parameter is used in the following test cases:

8.4.6. Test suites

This input parameter is also used in the following test suites:

  • None specified.

8.5. dnssecOps.kskRolloverZone

8.5.1. Description

The domain name which will be monitored for the occurrence of a KSK rollover.

8.5.2. Required

This input parameter is REQUIRED.

8.5.3. Example

{
   "dnssecOps.kskRolloverZone" : "example.com"
}

8.5.4. Schema

format: hostname
type: string

8.5.5. Test cases

This input parameter is used in the following test cases:

8.5.6. Test suites

This input parameter is also used in the following test suites:

  • None specified.

8.6. dnssecOps.nameservers

8.6.1. Description

The set of nameservers that will be authoritative for the zones used in the DNSSEC operations test suite.

8.6.2. Required

This input parameter is REQUIRED.

8.6.3. Example

{
   "dnssecOps.nameservers" : [
      {
         "name" : "ns1.example.com",
         "v4addrs" : [
            "192.0.2.1"
         ],
         "v6addrs" : [
            "2001:DB8::53:1"
         ]
      },
      {
         "name" : "ns2.example.net",
         "v4addrs" : [
            "192.0.2.2"
         ],
         "v6addrs" : [
            "2001:DB8::53:2"
         ]
      }
   ]
}

8.6.4. Schema

items:
  properties:
    name:
      description: The fully-qualified nameserver name.
      format: hostname
      type: string
    v4Addrs:
      description: The IPv4 address(es) for the nameserver.
      items:
        format: ipv4
        type: string
      minItems: 1
      type: array
    v6Addrs:
      description: The IPv6 address(es) for the nameserver.
      items:
        format: ipv6
        type: string
      minItems: 1
      type: array
  required:
  - name
  - addrs
  type: object
minItems: 1
type: array

8.6.5. Test cases

This input parameter is used in the following test cases:

  • None specified.

8.6.6. Test suites

This input parameter is also used in the following test suites:

8.7. dnssecOps.primaryServers

8.7.1. Description

The primary nameserver(s) from which zones can be transferred.

8.7.2. Required

This input parameter is REQUIRED.

8.7.3. Example

{
   "dnssecOps.primaryServers" : {
      "v4Addrs" : [
         "192.0.2.1"
      ],
      "v6Addrs" : [
         "2001:DB8::53:2"
      ]
   }
}

8.7.4. Schema

properties:
  v4Addrs:
    description: The IPv4 address(es) for the primary server(s).
    items:
      format: ipv4
      type: string
    minItems: 1
    type: array
  v6Addrs:
    description: The IPv6 address(es) for the primary server(s).
    items:
      format: ipv6
      type: string
    minItems: 1
    type: array
required:
- v4Addrs
- v6Addrs
type: object

8.7.5. Test cases

This input parameter is used in the following test cases:

  • None specified.

8.7.6. Test suites

This input parameter is also used in the following test suites:

8.8. dnssecOps.tsigKey

8.8.1. Description

The TSIG key which should be used to perform zone transfers.

8.8.2. Required

This input parameter is REQUIRED.

8.8.3. Example

{
   "dnssecOps.tsigKey" : {
      "algorithm" : "hmac-sha256",
      "name" : "rst-tsig-01",
      "secret" : "cSevMti9Wj6P2i4SsK4bHRnzUKT8k/FGOUoPLZ7kYm8="
   }
}

8.8.4. Schema

properties:
  algorithm:
    description: |
      The TSIG algorithm. The mnemonics are a subset of those published in
      the IANA registry at
      <https://www.iana.org/assignments/tsig-algorithm-names/tsig-algorithm-names.xhtml>.
    enum:
    - hmac-sha256
    - hmac-sha384
    - hmac-sha512
    type: string
  name:
    description: The TSIG name.
    format: hostname
    type: string
  secret:
    description: The TSIG secret.
    type: string
type: object

8.8.5. Test cases

This input parameter is used in the following test cases:

  • None specified.

8.8.6. Test suites

This input parameter is also used in the following test suites:

8.9. dnssecOps.zskRolloverZone

8.9.1. Description

The domain name which will be monitored for the occurrence of a ZSK rollover.

8.9.2. Required

This input parameter is REQUIRED.

8.9.3. Example

{
   "dnssecOps.zskRolloverZone" : "example.com"
}

8.9.4. Schema

format: hostname
type: string

8.9.5. Test cases

This input parameter is used in the following test cases:

8.9.6. Test suites

This input parameter is also used in the following test suites:

  • None specified.

8.10. epp.clid01

8.10.1. Description

the username used to log in to the EPP server.

8.10.2. Required

This input parameter is REQUIRED.

8.10.3. Example

{
   "epp.clid01" : "clid-01"
}

8.10.4. Schema

maxLength: 16
minLength: 3
type: string

8.10.5. Test cases

This input parameter is used in the following test cases:

8.10.6. Test suites

This input parameter is also used in the following test suites:

8.11. epp.clid01DataModel

8.11.1. Description

the data model configured for this registrar. This may be omitted and will in any case be ignored unless the value of the general.registryDataModel input parameter is per-registrar.

  • A value of minimum means that this registrar does not need to specify a registrant object when creating a domain name.
  • A value of maximum means that this registrar MUST specify a registrant object when creating a domain name.

If the value of the general.registryDataModel input parameter is per-registrar, then the value of this input parameter MUST be different from the value of the epp.clid02DataModel input parameter.

8.11.2. Required

This input parameter is REQUIRED.

8.11.3. Example

{
   "epp.clid01DataModel" : "minimum"
}

8.11.4. Schema

enum:
- minimum
- maximum
type: string

8.11.5. Test cases

This input parameter is used in the following test cases:

  • None specified.

8.11.6. Test suites

This input parameter is also used in the following test suites:

8.12. epp.clid02

8.12.1. Description

the username used for transfer tests.

8.12.2. Required

This input parameter is REQUIRED.

8.12.3. Example

{
   "epp.clid02" : "clid-02"
}

8.12.4. Schema

maxLength: 16
minLength: 3
type: string

8.12.5. Test cases

This input parameter is used in the following test cases:

  • None specified.

8.12.6. Test suites

This input parameter is also used in the following test suites:

8.13. epp.clid02DataModel

8.13.1. Description

the data model configured for this registrar. This may be omitted and will in any case be ignored unless the value of the general.registryDataModel input parameter is per-registrar.

  • A value of minimum means that this registrar does not need to specify a registrant object when creating a domain name.
  • A value of maximum means that this registrar MUST specify a registrant object when creating a domain name.

If the value of the general.registryDataModel input parameter is per-registrar, then the value of this input parameter MUST be different from the value of the epp.clid01DataModel input parameter.

8.13.2. Required

This input parameter is REQUIRED.

8.13.3. Example

{
   "epp.clid02DataModel" : "minimum"
}

8.13.4. Schema

enum:
- minimum
- maximum
type: string

8.13.5. Test cases

This input parameter is used in the following test cases:

  • None specified.

8.13.6. Test suites

This input parameter is also used in the following test suites:

8.14. epp.greeting

8.14.1. Description

an XML instance which contains a copy of the server’s <greeting>.

8.14.2. Required

This input parameter is REQUIRED.

8.14.3. Example

{
   "epp.greeting" : "greeting.xml"
}

8.14.4. Schema

type: string

8.14.5. Test cases

This input parameter is used in the following test cases:

8.14.6. Test suites

This input parameter is also used in the following test suites:

  • None specified.

8.15. epp.hostModel

8.15.1. Description

The host model supported by the EPP server. The possible values for this parameter are: * objects * attributes

8.15.2. Required

This input parameter is REQUIRED.

8.15.3. Example

{
   "epp.hostModel" : "objects"
}

8.15.4. Schema

enum:
- objects
- attributes
type: string

8.15.5. Test cases

This input parameter is used in the following test cases:

8.15.6. Test suites

This input parameter is also used in the following test suites:

8.16. epp.hostName

8.16.1. Description

The fully-qualified domain name of the EPP server.

The server name MUST comply with the requirements for valid hostnames described in RFC 1123, section 2.1. Additionally, all IDN labels in the server name MUST comply with IDNA2008.

8.16.2. Required

This input parameter is REQUIRED.

8.16.3. Example

{
   "epp.hostName" : "epp.rsp.tech"
}

8.16.4. Schema

format: hostname
type: string

8.16.5. Test cases

This input parameter is used in the following test cases:

8.16.6. Test suites

This input parameter is also used in the following test suites:

8.17. epp.pwd01

8.17.1. Description

the password used to log in to the EPP server.

8.17.2. Required

This input parameter is REQUIRED.

8.17.3. Example

{
   "epp.pwd01" : "foo2bar"
}

8.17.4. Schema

type: string

8.17.5. Test cases

This input parameter is used in the following test cases:

8.17.6. Test suites

This input parameter is also used in the following test suites:

8.18. epp.pwd02

8.18.1. Description

the password used for transfer tests.

8.18.2. Required

This input parameter is REQUIRED.

8.18.3. Example

{
   "epp.pwd02" : "foo3bar"
}

8.18.4. Schema

type: string

8.18.5. Test cases

This input parameter is used in the following test cases:

  • None specified.

8.18.6. Test suites

This input parameter is also used in the following test suites:

8.19. epp.registeredContacts

8.19.1. Description

An array of contact IDs that exist in the EPP server and which are therefore unavailable for registration.

If the value of general.registryDataModel is maximum, or per-registrar, then this array MUST contain one member for each TLD in the TLD set. However, if it is minimum, the array MUST be empty.

8.19.2. Required

This input parameter is REQUIRED.

8.19.3. Example

{
   "epp.registeredContacts" : [
      "abc123",
      "def321"
   ]
}

8.19.4. Schema

items:
  type: string
type: array

8.19.5. Test cases

This input parameter is used in the following test cases:

8.19.6. Test suites

This input parameter is also used in the following test suites:

  • None specified.

8.20. epp.registeredNames

8.20.1. Description

An array of domain names that exist in the EPP server and which are therefore unavailable for registration. The domains MUST NOT be under the sponsorship of the epp.clid01 or epp.clid02 registrars. The array MUST contain one member for each TLD in the TLD set.

8.20.2. Required

This input parameter is REQUIRED.

8.20.3. Example

{
   "epp.registeredNames" : [
      "example.example1",
      "example.example2"
   ]
}

8.20.4. Schema

items:
  format: hostname
  type: string
type: array

8.20.5. Test cases

This input parameter is used in the following test cases:

  • None specified.

8.20.6. Test suites

This input parameter is also used in the following test suites:

8.21. epp.registeredNameservers

8.21.1. Description

An array of host objects that exist in the EPP server and which are therefore unavailable for registration.

If the value of epp.hostModel is objects, this array MUST contain one member for each TLD in the TLD set. However, if it is attributes, the array MUST be empty.

8.21.2. Required

This input parameter is REQUIRED.

8.21.3. Example

{
   "epp.registeredNameservers" : [
      "ns1.example.com",
      "ns2.example.org"
   ]
}

8.21.4. Schema

items:
  format: hostname
  type: string
type: array

8.21.5. Test cases

This input parameter is used in the following test cases:

8.21.6. Test suites

This input parameter is also used in the following test suites:

  • None specified.

8.22. epp.requiredContactTypes

8.22.1. Description

An array containing the values of the type attribute of <contact> element(s) that are required to successfully create a domain name. If the value of general.registryDataModel is minimum, this array MUST be empty.

8.22.2. Required

This input parameter is REQUIRED.

8.22.3. Example

{
   "epp.requiredContactTypes" : [
      "admin"
   ]
}

8.22.4. Schema

items:
  enum:
  - admin
  - tech
  - billing
  type: string
type: array

8.22.5. Test cases

This input parameter is used in the following test cases:

8.22.6. Test suites

This input parameter is also used in the following test suites:

8.23. epp.restoreReportRequired

8.23.1. Description

Whether the server requires submission of a restore report when a client attempts to restore a domain.

8.23.2. Required

This input parameter is REQUIRED.

8.23.3. Example

{
   "epp.restoreReportRequired" : false
}

8.23.4. Schema

type: boolean

8.23.5. Test cases

This input parameter is used in the following test cases:

8.23.6. Test suites

This input parameter is also used in the following test suites:

  • None specified.

8.24. epp.secDNSInterfaces

8.24.1. Description

Which of the interfaces defined in Section 4 of RFC 5910 the server supports (either dsData or keyData).

8.24.2. Required

This input parameter is REQUIRED.

8.24.3. Example

{
   "epp.secDNSInterfaces" : "dsData"
}

8.24.4. Schema

enum:
- dsData
- keyData
type: string

8.24.5. Test cases

This input parameter is used in the following test cases:

8.24.6. Test suites

This input parameter is also used in the following test suites:

  • None specified.

8.25. epp.serverIssuedClientCertificate01

8.25.1. Description

If the EPP server uses a private CA to issue client certificates, then a certificate generated using the CSR provided in the epp.clientCSR resource may be provided using this parameter. This certificate will only be used in conjunction with the epp.clid01 and epp.pwd01 credentials. If the server will accept ICANN’s own client certificate, this parameter SHOULD be empty.

8.25.2. Required

This input parameter is NOT required.

8.25.3. Example

{
   "epp.serverIssuedClientCertificate01" : "rst_test_client_cert.pem"
}

8.25.4. Schema

type: string

8.25.5. Test cases

This input parameter is used in the following test cases:

8.25.6. Test suites

This input parameter is also used in the following test suites:

8.26. epp.serverIssuedClientCertificate02

8.26.1. Description

If the EPP server uses a private CA to issue client certificates, then a certificate generated using the CSR provided in the epp.clientCSR resource may be provided using this parameter. This certificate will only be used in conjunction with the epp.clid02 and epp.pwd02 credentials. If the server will accept ICANN’s own client certificate, this parameter SHOULD be omitted.

8.26.2. Required

This input parameter is NOT required.

8.26.3. Example

{
   "epp.serverIssuedClientCertificate02" : "rst_test_client_cert.pem"
}

8.26.4. Schema

type: string

8.26.5. Test cases

This input parameter is used in the following test cases:

  • None specified.

8.26.6. Test suites

This input parameter is also used in the following test suites:

8.27. general.registryDataModel

8.27.1. Description

This input parameter describes the data model(s) supported by the registry, determined in accordance with Section 7 of the Registration Data Policy. The possible values are:

  • minimum: the registry does not collect registrant contact information from registrars. This policy applies to all registrars.
  • maximum: the registry requires the transmission of registrant contact information from registrars for all registrations. This policy applies to all registrars.
  • per-registrar: the registry may or may not require transmission of registrant contact information, depending on whether there is an appropriate legal basis, and a data processing agreement is in place between the registry operator and the registrar. Therefore, the data model is determined per-registrar rather than globally.

If the value of this parameter is per-registrar, then one of the registrar accounts specified by the epp.clid01 and epp.clid02 input parameters MUST be configured to use the minimum data model, and one MUST be configured to use the maximum data model. The epp.clid01DataModel and epp.clid02DataModel input parameters are used to identify the data model configured for each account.

8.27.2. Required

This input parameter is REQUIRED.

8.27.3. Example

{
   "general.registryDataModel" : "minimum"
}

8.27.4. Schema

enum:
- minimum
- maximum
- per-registrar
type: string

8.27.5. Test cases

This input parameter is used in the following test cases:

8.27.6. Test suites

This input parameter is also used in the following test suites:

8.28. integration.rdeSFTPDirectory

8.28.1. Description

The directory on the SFTP server where deposit files may be found.

8.28.2. Required

This input parameter is REQUIRED.

8.28.3. Example

{
   "integration.rdeSFTPDirectory" : "/path/to/deposits"
}

8.28.4. Schema

type: string

8.28.5. Test cases

This input parameter is used in the following test cases:

8.28.6. Test suites

This input parameter is also used in the following test suites:

  • None specified.

8.29. integration.rdeSFTPHostname

8.29.1. Description

The hostname of the operator’s SFTP server.

8.29.2. Required

This input parameter is REQUIRED.

8.29.3. Example

{
   "integration.rdeSFTPHostname" : "sftp.rsp.tech"
}

8.29.4. Schema

format: hostname
type: string

8.29.5. Test cases

This input parameter is used in the following test cases:

8.29.6. Test suites

This input parameter is also used in the following test suites:

  • None specified.

8.30. integration.rdeSFTPUsername

8.30.1. Description

The username that can be used to connect to the SFTP server.

8.30.2. Required

This input parameter is REQUIRED.

8.30.3. Example

{
   "integration.rdeSFTPUsername" : "icann"
}

8.30.4. Schema

type: string

8.30.5. Test cases

This input parameter is used in the following test cases:

8.30.6. Test suites

This input parameter is also used in the following test suites:

  • None specified.

8.31. integration.rriACL

8.31.1. Description

An object representing the IP addresses from which requests to the RRI will be sent.

8.31.2. Required

This input parameter is REQUIRED.

8.31.3. Example

{
   "integration.rriACL" : {
      "v4Addrs" : [
         "192.0.2.1",
         "192.0.2.2"
      ],
      "v6Addrs" : [
         "2001:DB8::22:1",
         "2001:DB8::22:2"
      ]
   }
}

8.31.4. Schema

properties:
  v4Addrs:
    items:
      format: ipv4
      type: string
    minItems: 1
    type: array
  v6Addrs:
    items:
      format: ipv6
      type: string
    type: array
required:
- v4Addrs
- v6Addrs
type: object

8.31.5. Test cases

This input parameter is used in the following test cases:

8.31.6. Test suites

This input parameter is also used in the following test suites:

  • None specified.

8.32. minimumRPMS.claimsTLD

8.32.1. Description

A TLD, or other registry-class zone, which has been configured to be in perpetual trademark claims.

8.32.2. Required

This input parameter is REQUIRED.

8.32.3. Example

{
   "minimumRPMS.claimsTLD" : "tmclaims.rsp.tech"
}

8.32.4. Schema

format: hostname
type: string

8.32.5. Test cases

This input parameter is used in the following test cases:

  • None specified.

8.32.6. Test suites

This input parameter is also used in the following test suites:

8.33. minimumRPMS.sunriseModels

8.33.1. Description

The sunrise models supported by the EPP server. The possible values for this parameter are: * start-date * end-date * both

8.33.2. Required

This input parameter is REQUIRED.

8.33.3. Example

{
   "minimumRPMS.sunriseModels" : "start-date"
}

8.33.4. Schema

enum:
- start-date
- end-date
- both
type: string

8.33.5. Test cases

This input parameter is used in the following test cases:

  • None specified.

8.33.6. Test suites

This input parameter is also used in the following test suites:

8.34. minimumRPMS.sunriseTLD

8.34.1. Description

A TLD, or other registry-class zone, which has been configured to be in perpetual sunrise.

8.34.2. Required

This input parameter is REQUIRED.

8.34.3. Example

{
   "minimumRPMS.sunriseTLD" : "tmclaims.rsp.tech"
}

8.34.4. Schema

format: hostname
type: string

8.34.5. Test cases

This input parameter is used in the following test cases:

  • None specified.

8.34.6. Test suites

This input parameter is also used in the following test suites:

8.35. rdap.baseURLs

8.35.1. Description

The RDAP base URL(s) for the TLD(s).

The host name component of each URL MUST comply with the requirements for valid hostnames described in RFC 1123, section 2.1. Additionally, all IDN labels in the host name MUST comply with IDNA2008.

8.35.2. Required

This input parameter is REQUIRED.

8.35.3. Example

{
   "rdap.baseURLs" : [
      {
         "baseURL" : "https://rdap.example.com/example/",
         "tld" : "example"
      }
   ]
}

8.35.4. Schema

items:
  properties:
    baseURL:
      description: |
        The RDAP Base URL. The URL **MUST** have trailing slash (`/`). If
        specified, the port **MUST** be 443.
      format: url
      type: string
    tld:
      description: The TLD or equivalent registry-class domain name.
      format: hostname
      type: string
  required:
  - tld
  - baseURL
  type: object
minItems: 1
type: array

8.35.5. Test cases

This input parameter is used in the following test cases:

8.35.6. Test suites

This input parameter is also used in the following test suites:

8.36. rdap.testDomains

8.36.1. Description

The domain(s) that will be queried to validate domain responses. This input parameter is an array of domain names, which MUST include at least one domain name for each TLD being tested.

8.36.2. Required

This input parameter is REQUIRED.

8.36.3. Example

{
   "rdap.testDomains" : [
      "example.com",
      "example.net"
   ]
}

8.36.4. Schema

items:
  format: hostname
  type: string
minItems: 1
type: array

8.36.5. Test cases

This input parameter is used in the following test cases:

  • None specified.

8.36.6. Test suites

This input parameter is also used in the following test suites:

8.37. rdap.testEntities

8.37.1. Description

The entities(s) that will be queried to validate entity responses. This input parameter is an array of objects. At least one entity MUST be provided for each TLD being tested.

8.37.2. Required

This input parameter is REQUIRED.

8.37.3. Example

{
   "rdap.testEntities" : [
      {
         "handle" : 9995,
         "tld" : "example"
      }
   ]
}

8.37.4. Schema

items:
  properties:
    handle:
      description: the entity handle.
      type: string
    tld:
      description: The TLD.
      format: hostname
      type: string
  required:
  - tld
  - handle
  type: object
minItems: 1
type: array

8.37.5. Test cases

This input parameter is used in the following test cases:

  • None specified.

8.37.6. Test suites

This input parameter is also used in the following test suites:

8.38. rdap.testNameservers

8.38.1. Description

The nameservers(s) that will be queried to validate nameserver responses. This input parameter is an array of objects. At least one nameserver MUST be provided for each TLD being tested.

8.38.2. Required

This input parameter is REQUIRED.

8.38.3. Example

{
   "rdap.testNameservers" : [
      {
         "nameserver" : "ns1.example.com",
         "tld" : "example1"
      },
      {
         "nameserver" : "ns1.example.com",
         "tld" : "example2"
      }
   ]
}

8.38.4. Schema

items:
  properties:
    nameserver:
      description: The nameserver name.
      format: hostname
      type: string
    tld:
      description: The TLD.
      format: hostname
      type: string
  required:
  - tld
  - nameserver
  type: object
minItems: 1
type: array

8.38.5. Test cases

This input parameter is used in the following test cases:

  • None specified.

8.38.6. Test suites

This input parameter is also used in the following test suites:

8.39. rde.depositFile

8.39.1. Description

an RDE deposit file. The TLD to which the deposit relates MUST match one of the TLDs that are associated with the test object.

8.39.2. Required

This input parameter is REQUIRED.

8.39.3. Example

{
   "rde.depositFile" : "example_20231004_FULL_S1_R0.ryde"
}

8.39.4. Schema

type: string

8.39.5. Test cases

This input parameter is used in the following test cases:

  • None specified.

8.39.6. Test suites

This input parameter is also used in the following test suites:

8.40. rde.publicKey

8.40.1. Description

a PGP public key block

8.40.2. Required

This input parameter is REQUIRED.

8.40.3. Example

{
   "rde.publicKey" : "rsp-rde-signing-key.asc"
}

8.40.4. Schema

type: string

8.40.5. Test cases

This input parameter is used in the following test cases:

8.40.6. Test suites

This input parameter is also used in the following test suites:

  • None specified.

8.41. rde.signatureFile

8.41.1. Description

an ASCII-armoured OpenPGP signature covering the deposit file

8.41.2. Required

This input parameter is REQUIRED.

8.41.3. Example

{
   "rde.signatureFile" : "example_20231004_FULL_S1_R0.sig"
}

8.41.4. Schema

type: string

8.41.5. Test cases

This input parameter is used in the following test cases:

8.41.6. Test suites

This input parameter is also used in the following test suites:

  • None specified.

8.42. srsgw.eppClid01

8.42.1. Description

the username used to log in to the SRS Gateway EPP server.

8.42.2. Required

This input parameter is REQUIRED.

8.42.3. Example

{
   "srsgw.eppClid01" : "clid-01"
}

8.42.4. Schema

minLength: 3
type: string

8.42.5. Test cases

This input parameter is used in the following test cases:

  • None specified.

8.42.6. Test suites

This input parameter is also used in the following test suites:

8.43. srsgw.eppClid02

8.43.1. Description

the username used for transfer tests.

8.43.2. Required

This input parameter is REQUIRED.

8.43.3. Example

{
   "srsgw.eppClid02" : "clid-02"
}

8.43.4. Schema

type: string

8.43.5. Test cases

This input parameter is used in the following test cases:

  • None specified.

8.43.6. Test suites

This input parameter is also used in the following test suites:

8.44. srsgw.eppHostName

8.44.1. Description

the fully-qualified domain name of the SRS Gateway EPP server.

8.44.2. Required

This input parameter is REQUIRED.

8.44.3. Example

{
   "srsgw.eppHostName" : "epp.rsp.tech"
}

8.44.4. Schema

format: hostname
type: string

8.44.5. Test cases

This input parameter is used in the following test cases:

  • None specified.

8.44.6. Test suites

This input parameter is also used in the following test suites:

8.45. srsgw.eppPwd01

8.45.1. Description

the password used to log in to the SRS Gateway EPP server.

8.45.2. Required

This input parameter is REQUIRED.

8.45.3. Example

{
   "srsgw.eppPwd01" : "foo2bar"
}

8.45.4. Schema

type: string

8.45.5. Test cases

This input parameter is used in the following test cases:

  • None specified.

8.45.6. Test suites

This input parameter is also used in the following test suites:

8.46. srsgw.eppPwd02

8.46.1. Description

the password used for transfer tests.

8.46.2. Required

This input parameter is REQUIRED.

8.46.3. Example

{
   "srsgw.eppPwd02" : "foo3bar"
}

8.46.4. Schema

type: string

8.46.5. Test cases

This input parameter is used in the following test cases:

  • None specified.

8.46.6. Test suites

This input parameter is also used in the following test suites:

8.47. srsgw.rdapBaseURLs

8.47.1. Description

The RDAP base URL(s) for the TLD(s).

The host name component of each URL MUST comply with the requirements for valid hostnames described in RFC 1123, section 2.1. Additionally, all IDN labels in the host name MUST comply with IDNA2008.

8.47.2. Required

This input parameter is REQUIRED.

8.47.3. Example

{
   "srsgw.rdapBaseURLs" : [
      {
         "baseURL" : "https://rdap.example.com/example/",
         "tld" : "example"
      }
   ]
}

8.47.4. Schema

items:
  properties:
    baseURL:
      description: |
        The RDAP Base URL. The URL **MUST** have trailing slash (`/`).
      format: url
      type: string
    tld:
      description: The TLD or equivalent registry-class domain name.
      format: hostname
      type: string
  required:
  - tld
  - baseURL
  type: object
minItems: 1
type: array

8.47.5. Test cases

This input parameter is used in the following test cases:

  • None specified.

8.47.6. Test suites

This input parameter is also used in the following test suites:

8.48. srsgw.serverIssuedClientCertificate01

8.48.1. Description

If the EPP server uses a private CA to issue client certificates, then a certificate generated using the CSR provided in the epp.clientCSR may be provided using this parameter. This certificate will only be used in conjunction with the srsgw.eppClid01 and srsgw.eppPwd01 credentials. If the server will accept ICANN’s own client certificate, this parameter SHOULD be omitted.

8.48.2. Required

This input parameter is REQUIRED.

8.48.3. Example

{
   "srsgw.serverIssuedClientCertificate01" : "cert.pem"
}

8.48.4. Schema

type: string

8.48.5. Test cases

This input parameter is used in the following test cases:

  • None specified.

8.48.6. Test suites

This input parameter is also used in the following test suites:

8.49. srsgw.serverIssuedClientCertificate02

8.49.1. Description

If the EPP server uses a private CA to issue client certificates, then a certificate generated using the CSR provided in the epp.clientCSR may be provided using this parameter. This certificate will only be used in conjunction with the srsgw.eppClid02 and srsgw.eppPwd02 credentials. If the server will accept ICANN’s own client certificate, this parameter SHOULD be omitted.

8.49.2. Required

This input parameter is REQUIRED.

8.49.3. Example

{
   "srsgw.serverIssuedClientCertificate02" : "cert.pem"
}

8.49.4. Schema

type: string

8.49.5. Test cases

This input parameter is used in the following test cases:

  • None specified.

8.49.6. Test suites

This input parameter is also used in the following test suites:

9. Errors

9.1. DNSSEC_DNS_QUERY_ERROR

9.1.1. Severity

9.1.2. Description

An error occurred while performing DNS query(s).

9.1.3. Test cases

This error may be produced by the following test cases:

9.2. DNSSEC_INVALID_DIGEST_ALGORITHM

9.2.1. Severity

9.2.2. Description

An invalid algorithm is used in the provided DS record(s).

9.2.3. Test cases

This error may be produced by the following test cases:

9.3. DNSSEC_INVALID_SIGNING_ALGORITHM

9.3.1. Severity

9.3.2. Description

An invalid algorithm is used to sign the zone.

9.3.3. Test cases

This error may be produced by the following test cases:

9.4. DNSSEC_NSEC3_ITERATIONS_IS_NOT_ZERO

9.4.1. Severity

9.4.2. Description

The iterations field of the NSEC3PARAM record is not zero.

9.4.3. Test cases

This error may be produced by the following test cases:

9.5. DNSSEC_NSEC3_SALT_IS_NOT_EMPTY

9.5.1. Severity

9.5.2. Description

The salt field of the NSEC3PARAM record is not zero (represented as a - in the presentation format).

9.5.3. Test cases

This error may be produced by the following test cases:

9.6. DNSSEC_OPS_ALGORITHM_ROLLOVER_CHAIN_OF_TRUST_BROKEN

9.6.1. Severity

9.6.2. Description

The Chain-of-Trust from the root trust anchor was broken during the algorith rollover.

9.6.3. Test cases

This error may be produced by the following test cases:

9.7. DNSSEC_OPS_ALGORITHM_ROLLOVER_NOT_COMPLETED

9.7.1. Severity

9.7.2. Description

The algorith rollover was not completed within the test period.

9.7.3. Test cases

This error may be produced by the following test cases:

9.8. DNSSEC_OPS_DNS_QUERY_FAILED_TOO_MANY_TIMES

9.8.1. Severity

9.8.2. Description

There was an error performing a DNS query.

9.8.3. Test cases

This error may be produced by the following test cases:

9.9. DNSSEC_OPS_INVALID_ALGORITHM

9.9.1. Severity

9.9.2. Description

The zone was rolled to an invalid algorithm. Please see the details of dnssec-91 for more information.

9.9.3. Test cases

This error may be produced by the following test cases:

9.10. DNSSEC_OPS_KSK_ROLLOVER_CHAIN_OF_TRUST_BROKEN

9.10.1. Severity

9.10.2. Description

The Chain-of-Trust from the root trust anchor was broken during the KSK rollover.

9.10.3. Test cases

This error may be produced by the following test cases:

9.11. DNSSEC_OPS_KSK_ROLLOVER_NOT_COMPLETED

9.11.1. Severity

9.11.2. Description

The KSK rollover was not completed within the test period.

9.11.3. Test cases

This error may be produced by the following test cases:

9.12. DNSSEC_OPS_XFR_FAILED_TOO_MANY_TIMES

9.12.1. Severity

9.12.2. Description

There was an error performing a zone transfer.

9.12.3. Test cases

This error may be produced by the following test cases:

9.13. DNSSEC_OPS_ZONE_IS_INVALID

9.13.1. Severity

9.13.2. Description

The zone file returned by a zone transfer request was invalid. This may be because: 1. it was not properly signed, or 2. it contained an insufficient number of resource records.

9.13.3. Test cases

This error may be produced by the following test cases:

9.14. DNSSEC_OPS_ZSK_ROLLOVER_CHAIN_OF_TRUST_BROKEN

9.14.1. Severity

9.14.2. Description

The Chain-of-Trust from the root trust anchor was broken during the ZSK rollover.

9.14.3. Test cases

This error may be produced by the following test cases:

9.15. DNSSEC_OPS_ZSK_ROLLOVER_NOT_COMPLETED

9.15.1. Severity

9.15.2. Description

The ZSK rollover was not completed within the test period.

9.15.3. Test cases

This error may be produced by the following test cases:

9.16. DNS_IDNA2008_INVALID_MNAME

9.16.1. Severity

9.16.2. Description

The mname field of the SOA record contains one or more labels that are not compliant with IDNA2008.

9.16.3. Test cases

This error may be produced by the following test cases:

9.17. DNS_IDNA2008_INVALID_NS_NSDNAME

9.17.1. Severity

9.17.2. Description

One or more NS records at the zone apex contains one or more labels that are not compliant with IDNA2008.

9.17.3. Test cases

This error may be produced by the following test cases:

9.18. DNS_IDNA2008_INVALID_RNAME

9.18.1. Severity

9.18.2. Description

The rname field of the SOA record contains one or more labels that are not compliant with IDNA2008.

9.18.3. Test cases

This error may be produced by the following test cases:

9.19. DNS_IDNA2008_QUERY_FAILED

9.19.1. Severity

9.19.2. Description

The SOA query failed.

9.19.3. Test cases

This error may be produced by the following test cases:

9.20. DNS_INCONSISTENT_RESPONSES

9.20.1. Severity

9.20.2. Description

One or more responses to DNS queries sent to the subject DNS servers were not consistent across all vantage points.

9.20.3. Test cases

This error may be produced by the following test cases:

9.21. EPP_CONTACT_CHECK_INVALID_CONTACT_ID_INCORRECT_AVAIL

9.21.1. Severity

9.21.2. Description

The server responded to a <check> command with an unexpected value in one or more of the avail attributes.

9.21.3. Test cases

This error may be produced by the following test cases:

9.22. EPP_CONTACT_CHECK_REGISTERED_CONTACT_ID_INCORRECT_AVAIL

9.22.1. Severity

9.22.2. Description

The server responded to a <check> command with an unexpected value in one or more of the avail attributes.

9.22.3. Test cases

This error may be produced by the following test cases:

9.23. EPP_CONTACT_CHECK_VALID_CONTACT_ID_INCORRECT_AVAIL

9.23.1. Severity

9.23.2. Description

The server responded to a <check> command with an unexpected value in one or more of the avail attributes.

9.23.3. Test cases

This error may be produced by the following test cases:

9.24. EPP_CONTACT_CREATE_INFO_RESPONSE_MISSING_OR_INCORRECT_CC

9.24.1. Severity

9.24.2. Description

Following a successful contact <create> command, a subsequent <info> response for the created object contained an incorrect or missing <cc> element.

9.24.3. Test cases

This error may be produced by the following test cases:

9.25. EPP_CONTACT_CREATE_INFO_RESPONSE_MISSING_OR_INCORRECT_CITY

9.25.1. Severity

9.25.2. Description

Following a successful contact <create> command, a subsequent <info> response for the created object contained an incorrect or missing <city> element.

9.25.3. Test cases

This error may be produced by the following test cases:

9.26. EPP_CONTACT_CREATE_INFO_RESPONSE_MISSING_OR_INCORRECT_EMAIL

9.26.1. Severity

9.26.2. Description

Following a successful contact <create> command, a subsequent <info> response for the created object contained an incorrect or missing <email> element.

9.26.3. Test cases

This error may be produced by the following test cases:

9.27. EPP_CONTACT_CREATE_INFO_RESPONSE_MISSING_OR_INCORRECT_ID

9.27.1. Severity

9.27.2. Description

Following a successful contact <create> command, a subsequent <info> response for the created object contained an incorrect or missing <id> element.

9.27.3. Test cases

This error may be produced by the following test cases:

9.28. EPP_CONTACT_CREATE_INFO_RESPONSE_MISSING_OR_INCORRECT_NAME

9.28.1. Severity

9.28.2. Description

Following a successful contact <create> command, a subsequent <info> response for the created object contained an incorrect or missing <name> element.

9.28.3. Test cases

This error may be produced by the following test cases:

9.29. EPP_CONTACT_CREATE_INFO_RESPONSE_MISSING_OR_INCORRECT_ORG

9.29.1. Severity

9.29.2. Description

Following a successful contact <create> command, a subsequent <info> response for the created object contained an incorrect or missing <org> element.

9.29.3. Test cases

This error may be produced by the following test cases:

9.30. EPP_CONTACT_CREATE_INFO_RESPONSE_MISSING_OR_INCORRECT_PC

9.30.1. Severity

9.30.2. Description

Following a successful contact <create> command, a subsequent <info> response for the created object contained an incorrect or missing <pc> element.

9.30.3. Test cases

This error may be produced by the following test cases:

9.31. EPP_CONTACT_CREATE_INFO_RESPONSE_MISSING_OR_INCORRECT_POSTALINFO_TYPE

9.31.1. Severity

9.31.2. Description

Following a successful contact <create> command, a subsequent <info> response for the created object contained a <postalInfo> element with an incorrect or missing type attribute.

9.31.3. Test cases

This error may be produced by the following test cases:

9.32. EPP_CONTACT_CREATE_INFO_RESPONSE_MISSING_OR_INCORRECT_SP

9.32.1. Severity

9.32.2. Description

Following a successful contact <create> command, a subsequent <info> response for the created object contained an incorrect or missing <sp> element.

9.32.3. Test cases

This error may be produced by the following test cases:

9.33. EPP_CONTACT_CREATE_INFO_RESPONSE_MISSING_OR_INCORRECT_STREET

9.33.1. Severity

9.33.2. Description

Following a successful contact <create> command, a subsequent <info> response for the created object contained an incorrect or missing <status> element.

9.33.3. Test cases

This error may be produced by the following test cases:

9.34. EPP_CONTACT_CREATE_INFO_RESPONSE_MISSING_OR_INCORRECT_VOICE

9.34.1. Severity

9.34.2. Description

Following a successful contact <create> command, a subsequent <info> response for the created object contained an incorrect or missing <voice> element.

9.34.3. Test cases

This error may be produced by the following test cases:

9.35. EPP_CONTACT_CREATE_INFO_RESPONSE_NOT_1000

9.35.1. Severity

9.35.2. Description

Following a successful contact <create> command, a subsequent <info> response for the created object did not result in a response with the 1000 result code.

9.35.3. Test cases

This error may be produced by the following test cases:

9.36. EPP_CONTACT_CREATE_SERVER_ACCEPTS_EMPTY_CC

9.36.1. Severity

9.36.2. Description

The server incorrectly accepted an empty value for the <cc> element in a contact <create> command.

9.36.3. Test cases

This error may be produced by the following test cases:

9.37. EPP_CONTACT_CREATE_SERVER_ACCEPTS_EMPTY_CITY

9.37.1. Severity

9.37.2. Description

The server incorrectly accepted an empty value for the <name> element in a contact <create> command.

9.37.3. Test cases

This error may be produced by the following test cases:

9.38. EPP_CONTACT_CREATE_SERVER_ACCEPTS_EMPTY_EMAIL

9.38.1. Severity

9.38.2. Description

The server incorrectly accepted an empty value for the <email> element in a contact <create> command.

9.38.3. Test cases

This error may be produced by the following test cases:

9.39. EPP_CONTACT_CREATE_SERVER_ACCEPTS_EMPTY_NAME

9.39.1. Severity

9.39.2. Description

The server incorrectly accepted an empty value for the <name> element in a contact <create> command.

9.39.3. Test cases

This error may be produced by the following test cases:

9.40. EPP_CONTACT_CREATE_SERVER_ACCEPTS_EMPTY_STREET

9.40.1. Severity

9.40.2. Description

The server incorrectly accepted an empty value for the <street> element in a contact <create> command.

9.40.3. Test cases

This error may be produced by the following test cases:

9.41. EPP_CONTACT_CREATE_SERVER_ACCEPTS_EMPTY_VOICE

9.41.1. Severity

9.41.2. Description

The server incorrectly accepted an empty value for the <voice> element in a contact <create> command.

9.41.3. Test cases

This error may be produced by the following test cases:

9.42. EPP_CONTACT_CREATE_SERVER_ACCEPTS_INVALID_CC

9.42.1. Severity

9.42.2. Description

The server incorrectly accepted an invalid value for the <cc> element in a contact <create> command.

9.42.3. Test cases

This error may be produced by the following test cases:

9.43. EPP_CONTACT_CREATE_SERVER_ACCEPTS_INVALID_CITY

9.43.1. Severity

9.43.2. Description

The server incorrectly accepted an empty value for the <city> element in a contact <create> command.

9.43.3. Test cases

This error may be produced by the following test cases:

9.44. EPP_CONTACT_CREATE_SERVER_ACCEPTS_INVALID_EMAIL

9.44.1. Severity

9.44.2. Description

The server incorrectly accepted an invalid value for the <email> element in a contact <create> command.

9.44.3. Test cases

This error may be produced by the following test cases:

9.45. EPP_CONTACT_CREATE_SERVER_ACCEPTS_INVALID_ID

9.45.1. Severity

9.45.2. Description

The server incorrectly accepted an invalid value for the <id> element in a contact <create> command.

9.45.3. Test cases

This error may be produced by the following test cases:

9.46. EPP_CONTACT_CREATE_SERVER_ACCEPTS_INVALID_NAME

9.46.1. Severity

9.46.2. Description

The server incorrectly accepted an invalid value for the <name> element in a contact <create> command.

9.46.3. Test cases

This error may be produced by the following test cases:

9.47. EPP_CONTACT_CREATE_SERVER_ACCEPTS_INVALID_ORG

9.47.1. Severity

9.47.2. Description

The server incorrectly accepted an invalid value for the <org> element in a contact <create> command.

9.47.3. Test cases

This error may be produced by the following test cases:

9.48. EPP_CONTACT_CREATE_SERVER_ACCEPTS_INVALID_POSTALINFO_TYPE

9.48.1. Severity

9.48.2. Description

The server incorrectly accepted an invalid value for the type attribute of the <postalInfo> element in a contact <create> command.

9.48.3. Test cases

This error may be produced by the following test cases:

9.49. EPP_CONTACT_CREATE_SERVER_ACCEPTS_INVALID_STREET

9.49.1. Severity

9.49.2. Description

The server incorrectly accepted an invalid value for the <street> element in a contact <create> command.

9.49.3. Test cases

This error may be produced by the following test cases:

9.50. EPP_CONTACT_CREATE_SERVER_ACCEPTS_INVALID_VOICE

9.50.1. Severity

9.50.2. Description

The server incorrectly accepted an invalid value for the <voice> element in a contact <create> command.

9.50.3. Test cases

This error may be produced by the following test cases:

9.51. EPP_CONTACT_DELETE_OBJECT_STILL_EXISTS

9.51.1. Severity

9.51.2. Description

Following a successful contact <delete> command, a subsequent <info> response for the deleted object did not result in a response with the 2303 (“Object does not exist”) result code.

9.51.3. Test cases

This error may be produced by the following test cases:

9.52. EPP_CONTACT_DELETE_RESPONSE_NOT_1000_OR_1001

9.52.1. Severity

9.52.2. Description

The server did not response to a contact <delete> command with a 1xxx result code.

9.52.3. Test cases

This error may be produced by the following test cases:

9.53. EPP_CONTACT_INFO_RESPONSE_NOT_2201

9.53.1. Severity

9.53.2. Description

The server did not response to a contact <info> command on a contact object not under the sponsorship of the connected client with a 2201 result code.

9.53.3. Test cases

This error may be produced by the following test cases:

9.54. EPP_CONTACT_UPDATE_INFO_RESPONSE_MISSING_OR_INCORRECT_CC

9.54.1. Severity

9.54.2. Description

Following a successful contact <update> command, a subsequent <info> response for the created object contained an incorrect or missing <cc> element.

9.54.3. Test cases

This error may be produced by the following test cases:

9.55. EPP_CONTACT_UPDATE_INFO_RESPONSE_MISSING_OR_INCORRECT_CITY

9.55.1. Severity

9.55.2. Description

Following a successful contact <update> command, a subsequent <info> response for the created object contained an incorrect or missing <city> element.

9.55.3. Test cases

This error may be produced by the following test cases:

9.56. EPP_CONTACT_UPDATE_INFO_RESPONSE_MISSING_OR_INCORRECT_EMAIL

9.56.1. Severity

9.56.2. Description

Following a successful contact <update> command, a subsequent <info> response for the created object contained an incorrect or missing <email> element.

9.56.3. Test cases

This error may be produced by the following test cases:

9.57. EPP_CONTACT_UPDATE_INFO_RESPONSE_MISSING_OR_INCORRECT_ID

9.57.1. Severity

9.57.2. Description

Following a successful contact <update> command, a subsequent <info> response for the created object contained an incorrect or missing <id> element.

9.57.3. Test cases

This error may be produced by the following test cases:

9.58. EPP_CONTACT_UPDATE_INFO_RESPONSE_MISSING_OR_INCORRECT_NAME

9.58.1. Severity

9.58.2. Description

Following a successful contact <update> command, a subsequent <info> response for the created object contained an incorrect or missing <name> element.

9.58.3. Test cases

This error may be produced by the following test cases:

9.59. EPP_CONTACT_UPDATE_INFO_RESPONSE_MISSING_OR_INCORRECT_ORG

9.59.1. Severity

9.59.2. Description

Following a successful contact <update> command, a subsequent <info> response for the created object contained an incorrect or missing <org> element.

9.59.3. Test cases

This error may be produced by the following test cases:

9.60. EPP_CONTACT_UPDATE_INFO_RESPONSE_MISSING_OR_INCORRECT_PC

9.60.1. Severity

9.60.2. Description

Following a successful contact <update> command, a subsequent <info> response for the created object contained an incorrect or missing <pc> element.

9.60.3. Test cases

This error may be produced by the following test cases:

9.61. EPP_CONTACT_UPDATE_INFO_RESPONSE_MISSING_OR_INCORRECT_POSTALINFO_TYPE

9.61.1. Severity

9.61.2. Description

Following a successful contact <update> command, a subsequent <info> response for the created object contained a <postalInfo> element with an incorrect or missing value for the type attribute.

9.61.3. Test cases

This error may be produced by the following test cases:

9.62. EPP_CONTACT_UPDATE_INFO_RESPONSE_MISSING_OR_INCORRECT_SP

9.62.1. Severity

9.62.2. Description

Following a successful contact <update> command, a subsequent <info> response for the created object contained an incorrect or missing <sp> element.

9.62.3. Test cases

This error may be produced by the following test cases:

9.63. EPP_CONTACT_UPDATE_INFO_RESPONSE_MISSING_OR_INCORRECT_STATUS

9.63.1. Severity

9.63.2. Description

Following a successful contact <update> command, a subsequent <info> response for the created object contained a <status> element with an incorrect or missing value for the s attribute.

9.63.3. Test cases

This error may be produced by the following test cases:

9.64. EPP_CONTACT_UPDATE_INFO_RESPONSE_MISSING_OR_INCORRECT_STREET

9.64.1. Severity

9.64.2. Description

Following a successful contact <update> command, a subsequent <info> response for the created object contained an incorrect or missing <street> element.

9.64.3. Test cases

This error may be produced by the following test cases:

9.65. EPP_CONTACT_UPDATE_INFO_RESPONSE_MISSING_OR_INCORRECT_VOICE

9.65.1. Severity

9.65.2. Description

Following a successful contact <update> command, a subsequent <info> response for the created object contained an incorrect or missing <voice> element.

9.65.3. Test cases

This error may be produced by the following test cases:

9.66. EPP_CONTACT_UPDATE_INFO_RESPONSE_NOT_1000

9.66.1. Severity

9.66.2. Description

Following a successful contact <update> command, a subsequent <info> response for the created object did not result in a response with the 1000 result code.

9.66.3. Test cases

This error may be produced by the following test cases:

9.67. EPP_CONTACT_UPDATE_RESPONSE_NOT_2201

9.67.1. Severity

9.67.2. Description

The server did not response to a contact <update> command on a contact object not under the sponsorship of the connected client with a 2201 result code.

9.67.3. Test cases

This error may be produced by the following test cases:

9.68. EPP_CONTACT_UPDATE_SERVER_ACCEPTS_INVALID_CC

9.68.1. Severity

9.68.2. Description

The server incorrectly accepted an invalid value for the <cc> element in a contact <update> command.

9.68.3. Test cases

This error may be produced by the following test cases:

9.69. EPP_CONTACT_UPDATE_SERVER_ACCEPTS_INVALID_CITY

9.69.1. Severity

9.69.2. Description

The server incorrectly accepted an invalid value for the <city> element in a contact <update> command.

9.69.3. Test cases

This error may be produced by the following test cases:

9.70. EPP_CONTACT_UPDATE_SERVER_ACCEPTS_INVALID_EMAIL

9.70.1. Severity

9.70.2. Description

The server incorrectly accepted an invalid value for the <email> element in a contact <update> command.

9.70.3. Test cases

This error may be produced by the following test cases:

9.71. EPP_CONTACT_UPDATE_SERVER_ACCEPTS_INVALID_ORG

9.71.1. Severity

9.71.2. Description

The server incorrectly accepted an invalid value for the <org> element in a contact <update> command.

9.71.3. Test cases

This error may be produced by the following test cases:

9.72. EPP_CONTACT_UPDATE_SERVER_ACCEPTS_INVALID_PC

9.72.1. Severity

9.72.2. Description

The server incorrectly accepted an invalid value for the <pc> element in a contact <update> command.

9.72.3. Test cases

This error may be produced by the following test cases:

9.73. EPP_CONTACT_UPDATE_SERVER_ACCEPTS_INVALID_POSTALINFO_TYPE

9.73.1. Severity

9.73.2. Description

The server incorrectly accepted an invalid value for the type attribute of a <postalInfo> element in a contact <update> command.

9.73.3. Test cases

This error may be produced by the following test cases:

9.74. EPP_CONTACT_UPDATE_SERVER_ACCEPTS_INVALID_SP

9.74.1. Severity

9.74.2. Description

The server incorrectly accepted an invalid value for the <sp> element in a contact <update> command.

9.74.3. Test cases

This error may be produced by the following test cases:

9.75. EPP_CONTACT_UPDATE_SERVER_ACCEPTS_INVALID_STATUS

9.75.1. Severity

9.75.2. Description

The server incorrectly accepted an invalid status code in a contact <update> command.

9.75.3. Test cases

This error may be produced by the following test cases:

9.76. EPP_CONTACT_UPDATE_SERVER_ACCEPTS_INVALID_STREET

9.76.1. Severity

9.76.2. Description

The server incorrectly accepted an invalid value for the <street> element in a contact <update> command.

9.76.3. Test cases

This error may be produced by the following test cases:

9.77. EPP_CONTACT_UPDATE_SERVER_ACCEPTS_INVALID_VOICE

9.77.1. Severity

9.77.2. Description

The server incorrectly accepted an invalid value for the <voice> element in a contact <update> command.

9.77.3. Test cases

This error may be produced by the following test cases:

9.78. EPP_DNS_RESOLUTION_ERROR

9.78.1. Severity

9.78.2. Description

There was an error while performing a DNS query for the EPP server hostname.

9.78.3. Test cases

This error may be produced by the following test cases:

9.79. EPP_DOMAIN_CHECK_INVALID_DOMAIN_INCORRECT_AVAIL

9.79.1. Severity

9.79.2. Description

The server responded to a <check> command with an unexpected value in one or more of the avail attributes.

9.79.3. Test cases

This error may be produced by the following test cases:

9.80. EPP_DOMAIN_CHECK_REGISTERED_DOMAIN_INCORRECT_AVAIL

9.80.1. Severity

9.80.2. Description

The server responded to a <check> command with an unexpected value in one or more of the avail attributes.

9.80.3. Test cases

This error may be produced by the following test cases:

9.81. EPP_DOMAIN_CHECK_VALID_DOMAIN_INCORRECT_AVAIL

9.81.1. Severity

9.81.2. Description

The server responded to a <check> command with an unexpected value in one or more of the avail attributes.

9.81.3. Test cases

This error may be produced by the following test cases:

9.82. EPP_DOMAIN_CREATE_INFO_RESPONSE_INVALID_ROID

9.82.1. Severity

9.82.2. Description

Following a successful domain <create> command, a subsequent <info> response for the created object contained an invalid value in the <roid> element, or which has a suffix not present in the IANA registry.

9.82.3. Test cases

This error may be produced by the following test cases:

9.83. EPP_DOMAIN_CREATE_INFO_RESPONSE_MISSING_OBJECT_PROPERTIES

9.83.1. Severity

9.83.2. Description

Following a successful domain <create> command, a subsequent <info> response for the created object did not include one or more elements from the <create> command.

9.83.3. Test cases

This error may be produced by the following test cases:

9.84. EPP_DOMAIN_CREATE_SERVER_ACCEPTS_AUTHINFO

9.84.1. Severity

9.84.2. Description

The server accepts a domain <create> command with a <pw> element with an invalid value.

9.84.3. Test cases

This error may be produced by the following test cases:

9.85. EPP_DOMAIN_CREATE_SERVER_ACCEPTS_HOST_ATTRIBUTES_WITHOUT_GLUE

9.85.1. Severity

9.85.2. Description

The server accepts a domain <create> command with one or more <hostAttr> elements containing hostnames that are in-bailiwick, but for which <hostAddr> elements are not provided.

9.85.3. Test cases

This error may be produced by the following test cases:

9.86. EPP_DOMAIN_CREATE_SERVER_ACCEPTS_INVALID_DNSSEC_DATA

9.86.1. Severity

9.86.2. Description

The server accepts a domain <create> command with one or more <hostAttr> elements containing hostnames that are in-bailiwick, but for which <hostAddr> elements are not provided.

9.86.3. Test cases

This error may be produced by the following test cases:

9.87. EPP_DOMAIN_CREATE_SERVER_ACCEPTS_INVALID_DOMAIN_NAME

9.87.1. Severity

9.87.2. Description

The server accepts a domain <create> command for a syntactically invalid domain name.

9.87.3. Test cases

This error may be produced by the following test cases:

9.88. EPP_DOMAIN_CREATE_SERVER_ACCEPTS_INVALID_HOST_OBJECT

9.88.1. Severity

9.88.2. Description

The server accepts a domain <create> command which contains a <hostObj> element referencing a syntactically invalid hostname.

9.88.3. Test cases

This error may be produced by the following test cases:

9.89. EPP_DOMAIN_CREATE_SERVER_ACCEPTS_INVALID_PERIOD

9.89.1. Severity

9.89.2. Description

The server accepts a domain <create> command which contains a <period> element with an invalid content and/or unit attribute.

9.89.3. Test cases

This error may be produced by the following test cases:

9.90. EPP_DOMAIN_CREATE_SERVER_ACCEPTS_NON_EXISTENT_CONTACT_OBJECT

9.90.1. Severity

9.90.2. Description

The server accepts a domain <create> command which contains a <registrant> and/or <contact> element referencing a non-existent contact object.

9.90.3. Test cases

This error may be produced by the following test cases:

9.91. EPP_DOMAIN_CREATE_SERVER_ACCEPTS_NON_EXISTENT_HOST_OBJECT

9.91.1. Severity

9.91.2. Description

The server accepts a domain <create> command which contains a <hostObj> element referencing a non-existent host object.

9.91.3. Test cases

This error may be produced by the following test cases:

9.92. EPP_DOMAIN_CREATE_SERVER_ACCEPTS_NO_REGISTRANT_FOR_THICK_REGISTRY

9.92.1. Severity

9.92.2. Description

The server accepts a domain <create> command which does not include a <registrant> object.

9.92.3. Test cases

This error may be produced by the following test cases:

9.93. EPP_DOMAIN_CREATE_SERVER_ACCEPTS_REGISTRANT_FOR_THIN_REGISTRY

9.93.1. Severity

9.93.2. Description

The server accepts a domain <create> command which includes a <registrant> object.

9.93.3. Test cases

This error may be produced by the following test cases:

9.94. EPP_DOMAIN_CREATE_SERVER_INCORRECTLY_ACCEPTS_HOST_ATTRIBUTES

9.94.1. Severity

9.94.2. Description

The server accepts a domain <create> command which uses <hostAttr> objects.

9.94.3. Test cases

This error may be produced by the following test cases:

9.95. EPP_DOMAIN_CREATE_SERVER_INCORRECTLY_ACCEPTS_HOST_OBJECTS

9.95.1. Severity

9.95.2. Description

The server accepts a domain <create> command which uses <hostObj> objects.

9.95.3. Test cases

This error may be produced by the following test cases:

9.96. EPP_DOMAIN_DELETE_INFO_RESPONSE_OBJECT_NOT_PENDING_DELETE

9.96.1. Severity

9.96.2. Description

Following a successful domain <delete> command, which resulted in a 1001 response, the domain did not have the pendingDelete status.

9.96.3. Test cases

This error may be produced by the following test cases:

9.97. EPP_DOMAIN_DELETE_INFO_RESPONSE_OBJECT_STILL_EXISTS

9.97.1. Severity

9.97.2. Description

Following a successful domain <delete> command, which resulted in a 1000 response, a subsequent <info> command did not result in a 2303 (“Object does not exist”) result code.

9.97.3. Test cases

This error may be produced by the following test cases:

9.98. EPP_DOMAIN_DELETE_INFO_RESPONSE_RGP_STATUS_NOT_PENDING_DELETE

9.98.1. Severity

9.98.2. Description

Following a successful domain <delete> command, which resulted in a 1001 response, the domain did not have the pendingDeleteRestorable RGP status.

9.98.3. Test cases

This error may be produced by the following test cases:

9.99. EPP_DOMAIN_UPDATE_INFO_RESPONSE_MISSING_DNSSEC_DATA

9.99.1. Severity

9.99.2. Description

Following a successful domain <update> command, a subsequent <info> response for the created object did not include all expected <dsData> or <keyData> elements.

9.99.3. Test cases

This error may be produced by the following test cases:

9.100. EPP_DOMAIN_UPDATE_INFO_RESPONSE_MISSING_HOST_ATTRIBUTE

9.100.1. Severity

9.100.2. Description

Following a successful domain <update> command, a subsequent <info> response for the created object did not include all expected <hostAttr> elements.

9.100.3. Test cases

This error may be produced by the following test cases:

9.101. EPP_DOMAIN_UPDATE_INFO_RESPONSE_MISSING_HOST_OBJECT

9.101.1. Severity

9.101.2. Description

Following a successful domain <update> command, a subsequent <info> response for the created object did not include all expected <hostObj> elements.

9.101.3. Test cases

This error may be produced by the following test cases:

9.102. EPP_DOMAIN_UPDATE_INFO_RESPONSE_MISSING_REGISTRANT

9.102.1. Severity

9.102.2. Description

Following a successful domain <update> command, a subsequent <info> response for the created object did not include the expected <registrant> element.

9.102.3. Test cases

This error may be produced by the following test cases:

9.103. EPP_DOMAIN_UPDATE_INFO_RESPONSE_MISSING_STATUS_CODE

9.103.1. Severity

9.103.2. Description

Following a successful domain <update> command, a subsequent <info> response for the created object did not include the expected <status> elements.

9.103.3. Test cases

This error may be produced by the following test cases:

9.104. EPP_DOMAIN_UPDATE_INFO_RESPONSE_UNEXPECTED_DNSSEC_DATA

9.104.1. Severity

9.104.2. Description

Following a successful domain <update> command, a subsequent <info> response for the created object included one or more unexpected <dsData> or <keyData> element(s).

9.104.3. Test cases

This error may be produced by the following test cases:

9.105. EPP_DOMAIN_UPDATE_INFO_RESPONSE_UNEXPECTED_HOST_ATTRIBUTE

9.105.1. Severity

9.105.2. Description

Following a successful domain <update> command, a subsequent <info> response for the created object included one or more unexpected <hostAttr> element(s).

9.105.3. Test cases

This error may be produced by the following test cases:

9.106. EPP_DOMAIN_UPDATE_INFO_RESPONSE_UNEXPECTED_HOST_OBJECT

9.106.1. Severity

9.106.2. Description

Following a successful domain <update> command, a subsequent <info> response for the created object included one or more unexpected <hostObj> element(s).

9.106.3. Test cases

This error may be produced by the following test cases:

9.107. EPP_DOMAIN_UPDATE_INFO_RESPONSE_UNEXPECTED_REGISTRANT

9.107.1. Severity

9.107.2. Description

Following a successful domain <update> command, a subsequent <info> response for the created object included an unexpected <registrant> element, or a <registrant> element containinin an unexpected value.

9.107.3. Test cases

This error may be produced by the following test cases:

9.108. EPP_DOMAIN_UPDATE_INFO_RESPONSE_UNEXPECTED_STATUS_CODE

9.108.1. Severity

9.108.2. Description

Following a successful domain <update> command, a subsequent <info> response for the created object included one or more unexpected <status> element(s).

9.108.3. Test cases

This error may be produced by the following test cases:

9.109. EPP_DOMAIN_UPDATE_SERVER_ACCEPTS_HOST_ATTRIBUTES_WITHOUT_GLUE

9.109.1. Severity

9.109.2. Description

The server accepts a domain <update> command with one or more <hostAttr> elements containing hostnames that are in-bailiwick, but for which <hostAddr> elements are not provided.

9.109.3. Test cases

This error may be produced by the following test cases:

9.110. EPP_DOMAIN_UPDATE_SERVER_ACCEPTS_INVALID_DNSSEC_DATA

9.110.1. Severity

9.110.2. Description

The server accepts a domain <update> command with one or more <dsData> or <keyData> elements which contain invalid parameters.

9.110.3. Test cases

This error may be produced by the following test cases:

9.111. EPP_DOMAIN_UPDATE_SERVER_ACCEPTS_INVALID_HOST_ATTRIBUTES

9.111.1. Severity

9.111.2. Description

The server accepts a domain <update> command with one or more <hostAttr> elements containing invalid hostnames and/or IP addresses.

9.111.3. Test cases

This error may be produced by the following test cases:

9.112. EPP_DOMAIN_UPDATE_SERVER_ACCEPTS_NON_EXISTENT_CONTACT_OBJECT

9.112.1. Severity

9.112.2. Description

The server accepts a domain <update> command which contains a <registrant> or <contact> element containing non-existent contact objects.

9.112.3. Test cases

This error may be produced by the following test cases:

9.113. EPP_DOMAIN_UPDATE_SERVER_ACCEPTS_NON_EXISTENT_HOST_OBJECT

9.113.1. Severity

9.113.2. Description

The server accepts a domain <update> command with one or more <hostObj> elements containing non-existent host objects.

9.113.3. Test cases

This error may be produced by the following test cases:

9.114. EPP_DOMAIN_UPDATE_SERVER_INCORRECTLY_ACCEPTS_HOST_ATTRIBUTES

9.114.1. Severity

9.114.2. Description

The server accepts a domain <update> command that contained one or more <hostAttr> elements, but the epp.hostModel input paramter is objects.

9.114.3. Test cases

This error may be produced by the following test cases:

9.115. EPP_DOMAIN_UPDATE_SERVER_INCORRECTLY_ACCEPTS_HOST_OBJECTS

9.115.1. Severity

9.115.2. Description

The server accepts a domain <update> command that contained one or more <hostAttr> elements, but the epp.hostModel input paramter is attributes.

9.115.3. Test cases

This error may be produced by the following test cases:

9.116. EPP_GENERIC_COMMAND_ERROR

9.116.1. Severity

9.116.2. Description

The client received a 2400 error from the server.

9.116.3. Test cases

This error may be produced by the following test cases:

9.117. EPP_GREETING_DOES_NOT_MATCH

9.117.1. Severity

9.117.2. Description

The XML instance in the epp.greeting input parameter does not match that returned by the server in response to a <hello> command.

9.117.3. Test cases

This error may be produced by the following test cases:

9.118. EPP_GREETING_INVALID_LANG

9.118.1. Severity

9.118.2. Description

The value of one or more of the <lang> elements in the <greeting> are invalid.

9.118.3. Test cases

This error may be produced by the following test cases:

9.119. EPP_GREETING_MISSING_EN_LANG

9.119.1. Severity

9.119.2. Description

A <lang> element with the value en was not found in the <greeting>.

9.119.3. Test cases

This error may be produced by the following test cases:

9.120. EPP_GREETING_MISSING_EXTURI

9.120.1. Severity

9.120.2. Description

A mandatory extension namespace URI is missing.

9.120.3. Test cases

This error may be produced by the following test cases:

9.121. EPP_GREETING_MISSING_OBJURI

9.121.1. Severity

9.121.2. Description

A mandatory object namespace URI is missing.

9.121.3. Test cases

This error may be produced by the following test cases:

9.122. EPP_GREETING_RECOMMENDED_EXTENSION_MISSING

9.122.1. Severity

9.122.2. Description

The server does not include the namespace URI of a recommended extension in an <extURI> element of the <greeting> frame.

9.122.3. Test cases

This error may be produced by the following test cases:

9.123. EPP_GREETING_SVDATE_INVALID

9.123.1. Severity

9.123.2. Description

The value of the <svDate> element in the <greeting> is invalid.

9.123.3. Test cases

This error may be produced by the following test cases:

9.124. EPP_GREETING_SVID_INVALID

9.124.1. Severity

9.124.2. Description

The value of the <svID> element in the <greeting> is invalid.

9.124.3. Test cases

This error may be produced by the following test cases:

9.125. EPP_GREETING_UNEXPECTED_EXTURI

9.125.1. Severity

9.125.2. Description

One or more of the <extRI> elements in the <greeting> contain invalid namespace URIs.

9.125.3. Test cases

This error may be produced by the following test cases:

9.126. EPP_GREETING_UNEXPECTED_OBJURI

9.126.1. Severity

9.126.2. Description

One or more of the <objURI> elements in the <greeting> contain invalid namespace URIs.

9.126.3. Test cases

This error may be produced by the following test cases:

9.127. EPP_GREETING_VERSION_INVALID

9.127.1. Severity

9.127.2. Description

The value of the <version> element in the <greeting> is invalid.

9.127.3. Test cases

This error may be produced by the following test cases:

9.128. EPP_HOST_CHECK_INVALID_HOST_INCORRECT_AVAIL

9.128.1. Severity

9.128.2. Description

The server responded to a <check> command with an unexpected value in one or more of the avail attributes.

9.128.3. Test cases

This error may be produced by the following test cases:

9.129. EPP_HOST_CHECK_REGISTERED_HOST_INCORRECT_AVAIL

9.129.1. Severity

9.129.2. Description

The server responded to a <check> command with an unexpected value in one or more of the avail attributes.

9.129.3. Test cases

This error may be produced by the following test cases:

9.130. EPP_HOST_CHECK_VALID_HOST_INCORRECT_AVAIL

9.130.1. Severity

9.130.2. Description

The server responded to a <check> command with an unexpected value in one or more of the avail attributes.

9.130.3. Test cases

This error may be produced by the following test cases:

9.131. EPP_HOST_CREATE_INFO_RESPONSE_MISSING_OBJECT_PROPERTIES

9.131.1. Severity

9.131.2. Description

Following a successful host <create> command, a subsequent <info> response for the created object did not include one or more elements from the <create> command.

9.131.3. Test cases

This error may be produced by the following test cases:

9.132. EPP_HOST_CREATE_INFO_RESPONSE_OBJECT_DOES_NOT_EXIST

9.132.1. Severity

9.132.2. Description

Following a successful host <create> command, a subsequent <info> command for the created object returned a 2303 “Object does not exist” result code.

9.132.3. Test cases

This error may be produced by the following test cases:

9.133. EPP_HOST_CREATE_SERVER_ACCEPTS_INVALID_HOSTNAME

9.133.1. Severity

9.133.2. Description

The server accepts a host <create> command with a <name> element that contains a syntactically invalid hostname.

9.133.3. Test cases

This error may be produced by the following test cases:

9.134. EPP_HOST_CREATE_SERVER_ACCEPTS_INVALID_IPV4_ADDRESS

9.134.1. Severity

9.134.2. Description

The server accepts a host <create> command with a <addr> element that contains a syntactically invalid IPv4 address.

9.134.3. Test cases

This error may be produced by the following test cases:

9.135. EPP_HOST_CREATE_SERVER_ACCEPTS_INVALID_IPv6_ADDRESS

9.135.1. Severity

9.135.2. Description

The server accepts a host <create> command with a <addr> element that contains a syntactically invalid IPv6 address.

9.135.3. Test cases

This error may be produced by the following test cases:

9.136. EPP_HOST_DELETE_INFO_RESPONSE_OBJECT_STILL_EXISTS

9.136.1. Severity

9.136.2. Description

Following a successful host <delete> command, a subsequent <info> command for the created object did not return a 2303 “Object does not exist” result code.

9.136.3. Test cases

This error may be produced by the following test cases:

9.137. EPP_HOST_RENAME_SERVER_ACCEPTS_INVALID_HOSTNAME

9.137.1. Severity

9.137.2. Description

The server accepts a host <update> command with a <name> element that contains a syntactically invalid hostname.

9.137.3. Test cases

This error may be produced by the following test cases:

9.138. EPP_HOST_RENAME_SERVER_ACCEPTS_RENAME_TO_ANOTHER_REGISTRARS_DOMAIN

9.138.1. Severity

9.138.2. Description

The server accepts a host <update> command with a <name> element that contains a hostname that is subordinate to a domain under the sponsorship of another registrar.

9.138.3. Test cases

This error may be produced by the following test cases:

9.139. EPP_HOST_RENAME_SERVER_ACCEPTS_RENAME_TO_NONEXISTENT_DOMAIN

9.139.1. Severity

9.139.2. Description

The server accepts a host <update> command with a <name> element that contains a hostname that is subordinate to a non-existent domain.

9.139.3. Test cases

This error may be produced by the following test cases:

9.140. EPP_HOST_RENAME_SERVER_REJECTS_OUT_OF_BAILIWICK_NAME

9.140.1. Severity

9.140.2. Description

The server rejects a host <update> command with a <name> element that contains a hostname that is out-of-bailiwick.

9.140.3. Test cases

This error may be produced by the following test cases:

9.141. EPP_HOST_RENAME_SERVER_UNEXPECTEDLY_REJECTS_RENAME

9.141.1. Severity

9.141.2. Description

The server rejects a host <update> command with a <name> element that it should have accepted.

9.141.3. Test cases

This error may be produced by the following test cases:

9.142. EPP_HOST_UPDATE_AUTHZ_ERROR

9.142.1. Severity

9.142.2. Description

The server rejects a host <update> command for a host object that is not under the sponsorship of the connected client.

9.142.3. Test cases

This error may be produced by the following test cases:

9.143. EPP_HOST_UPDATE_INFO_RESPONSE_MISSING_OBJECT_PROPERTIES

9.143.1. Severity

9.143.2. Description

Following a successful host <update> command, a subsequent <info> response for the created object did not include one or more elements from the <update> command.

9.143.3. Test cases

This error may be produced by the following test cases:

9.144. EPP_HOST_UPDATE_INFO_RESPONSE_OBJECT_DOES_NOT_EXIST

9.144.1. Severity

9.144.2. Description

Following a successful host <update> command, a subsequent <info> command for the created object unexpectedly returned a 2303 “Object does not exist” result code.

9.144.3. Test cases

This error may be produced by the following test cases:

9.145. EPP_HOST_UPDATE_SERVER_ACCEPTS_INVALID_IPV4_ADDRESS

9.145.1. Severity

9.145.2. Description

The server accepts a host <update> command with an <addr> element that contains a syntactically invalid IPv4 address.

9.145.3. Test cases

This error may be produced by the following test cases:

9.146. EPP_HOST_UPDATE_SERVER_ACCEPTS_INVALID_IPv6_ADDRESS

9.146.1. Severity

9.146.2. Description

The server accepts a host <update> command with an <addr> element that contains a syntactically invalid IPv6 address.

9.146.3. Test cases

This error may be produced by the following test cases:

9.147. EPP_HOST_UPDATE_SERVER_ACCEPTS_INVALID_STATUS_CODE

9.147.1. Severity

9.147.2. Description

The server accepts a host <update> command with a <status> element that contains an invalid status code in the s attribute.

9.147.3. Test cases

This error may be produced by the following test cases:

9.148. EPP_INTEGRITY_SERVER_ACCEPTS_DELETE_FOR_LINKED_CONTACT_OBJECT

9.148.1. Severity

9.148.2. Description

The server accepts a <delete> command for a contact object that has the linked status.

9.148.3. Test cases

This error may be produced by the following test cases:

9.149. EPP_INTEGRITY_SERVER_ACCEPTS_DELETE_FOR_LINKED_HOST_OBJECT

9.149.1. Severity

9.149.2. Description

The server accepts a <delete> command for a host object that has the linked status.

9.149.3. Test cases

This error may be produced by the following test cases:

9.150. EPP_LOGIN_ERROR

9.150.1. Severity

9.150.2. Description

The client was unable to successfully authenticate with the EPP server.

9.150.3. Test cases

This error may be produced by the following test cases:

9.151. EPP_LOGIN_UNEXPECTEDLY_FAILED

9.151.1. Severity

9.151.2. Description

The client was not able to authenticate with the provided credentials.

9.151.3. Test cases

This error may be produced by the following test cases:

9.152. EPP_LOGIN_UNEXPECTEDLY_SUCCEEDED

9.152.1. Severity

9.152.2. Description

A <login> command that should have failed unexpectedly succeeded.

9.152.3. Test cases

This error may be produced by the following test cases:

9.153. EPP_MISSING_AAAA_RECORDS

9.153.1. Severity

9.153.2. Description

No AAAA record(s) were found for the EPP server hostname.

9.153.3. Test cases

This error may be produced by the following test cases:

9.154. EPP_MISSING_A_RECORDS

9.154.1. Severity

9.154.2. Description

No A record(s) were found for the EPP server hostname.

9.154.3. Test cases

This error may be produced by the following test cases:

9.155. EPP_NO_GREETING_RECEIVED

9.155.1. Severity

9.155.2. Description

No <greeting> was received after successful connection.

9.155.3. Test cases

This error may be produced by the following test cases:

9.156. EPP_NO_SERVICE_PORTS_REACHABLE

9.156.1. Severity

9.156.2. Description

No service ports could be reached, for either IPv4 or (if supported) IPv6.

9.156.3. Test cases

This error may be produced by the following test cases:

9.157. EPP_RENEW_INFO_RESPONSE_MISSING_OR_INVALID_RGP_STATUS

9.157.1. Severity

9.157.2. Description

Following a successful <renew> command, a subsequent <info> command for the domain did not include the renewPeriod RGP status.

9.157.3. Test cases

This error may be produced by the following test cases:

9.158. EPP_RENEW_INFO_RESPONSE_UNEXPECTED_EXPIRY_DATE

9.158.1. Severity

9.158.2. Description

Following a successful <renew> command, a subsequent <info> command for the domain did not include an <exDate> element with the expected expiry date.

9.158.3. Test cases

This error may be produced by the following test cases:

9.159. EPP_RENEW_SERVER_ACCEPTS_INVALID_CURRENT_EXPIRY_DATE

9.159.1. Severity

9.159.2. Description

The server accepted an EPP <renew> command with a <curExpDate> element that contains the incorrect expiry date.

9.159.3. Test cases

This error may be produced by the following test cases:

9.160. EPP_RENEW_SERVER_ACCEPTS_INVALID_PERIOD

9.160.1. Severity

9.160.2. Description

The server accepted an EPP <renew> command with a <period> element that contains an incorrect value or unit attribute.

9.160.3. Test cases

This error may be produced by the following test cases:

9.161. EPP_RESTORE_DOMAIN_STILL_PENDINGDELETE

9.161.1. Severity

9.161.2. Description

Following a successful RGP restore command, a subsequent <info> command for the domain showed that the domain still had the pendingDelete status.

9.161.3. Test cases

This error may be produced by the following test cases:

9.162. EPP_SCHEMA_VALIDATION_ERROR

9.162.1. Severity

9.162.2. Description

The response from the server failed schema validation.

9.162.3. Test cases

This error may be produced by the following test cases:

9.163. EPP_SERVICE_PORT_NOT_CONSISTENT

9.163.1. Severity

9.163.2. Description

One or more <info> commands sent to the advertised EPP service ports resulted in inconsistent responses.

9.163.3. Test cases

This error may be produced by the following test cases:

9.164. EPP_SERVICE_PORT_UNREACHABLE

9.164.1. Severity

9.164.2. Description

The client was unable to successfully connect to the EPP server. This is not a fatal error, but if no service ports are reachable, the test will fail.

9.164.3. Test cases

This error may be produced by the following test cases:

9.165. EPP_TLS_BAD_CIPHER

9.165.1. Severity

9.165.2. Description

The server uses an encryption cipher not recommended in RFC 9325.

9.165.3. Test cases

This error may be produced by the following test cases:

9.166. EPP_TLS_CERTIFICATE_CHAIN_MISSING

9.166.1. Severity

9.166.2. Description

One or more intermediate certificates are missing.

9.166.3. Test cases

This error may be produced by the following test cases:

9.167. EPP_TLS_CERTIFICATE_HOSTNAME_MISMATCH

9.167.1. Severity

9.167.2. Description

The hostname in the TLS certificate does not match the EPP server hostname.

9.167.3. Test cases

This error may be produced by the following test cases:

9.168. EPP_TLS_CONNECTION_ERROR

9.168.1. Severity

9.168.2. Description

There was an error during the TLS handshake while connecting to the EPP server.

9.168.3. Test cases

This error may be produced by the following test cases:

9.169. EPP_TLS_EXPIRED_CERTIFICATE

9.169.1. Severity

9.169.2. Description

The TLS certificate presented by the EPP server has expired.

9.169.3. Test cases

This error may be produced by the following test cases:

9.170. EPP_TLS_FORBIDDEN_PROTOCOL_SUPPORTED

9.170.1. Severity

9.170.2. Description

The EPP server implements a forbidden protocol.

9.170.3. Test cases

This error may be produced by the following test cases:

9.171. EPP_TLS_REQUIRED_PROTOCOL_NOT_SUPPORTED

9.171.1. Severity

9.171.2. Description

The EPP server does not implement a required protocol.

9.171.3. Test cases

This error may be produced by the following test cases:

9.172. EPP_TLS_UNTRUSTED_CERTIFICATE

9.172.1. Severity

9.172.2. Description

The TLS certificate presented by the EPP server is not issued by a trusted Certificate Authority.

9.172.3. Test cases

This error may be produced by the following test cases:

9.173. EPP_TRANSFER_GAINING_REGISTRAR_NO_MESSAGE_RECEIVED

9.173.1. Severity

9.173.2. Description

Following a successful <transfer op="approve"> command submitted by the losing registrar of a transfer, the gaining registrar did not receive a message on the EPP message queue within the deadline (120 seconds).

9.173.3. Test cases

This error may be produced by the following test cases:

9.174. EPP_TRANSFER_INFO_RESPONSE_AUTHINFO_NOT_RESET

9.174.1. Severity

9.174.2. Description

Following a successful domain transfer, the authInfo of the transferred domain was not changed.

9.174.3. Test cases

This error may be produced by the following test cases:

9.175. EPP_TRANSFER_INFO_RESPONSE_MISSING_OR_INVALID_RGP_STATUS

9.175.1. Severity

9.175.2. Description

Following a successful domain transfer, a subsequent <info> response did not include the expected RGP status (transferPeriod).

9.175.3. Test cases

This error may be produced by the following test cases:

9.176. EPP_TRANSFER_INFO_RESPONSE_MISSING_OR_INVALID_STATUS_CODE

9.176.1. Severity

9.176.2. Description

Following a successful <transfer op="request"> command, a subsequent <info> response did not include the pendingTransfer status.

9.176.3. Test cases

This error may be produced by the following test cases:

9.177. EPP_TRANSFER_INFO_RESPONSE_UNEXPECTED_EXPIRY_DATE

9.177.1. Severity

9.177.2. Description

Following a successful domain transfer, a subsequent <info> response did not include the expected value of the <exDate> element.

9.177.3. Test cases

This error may be produced by the following test cases:

9.178. EPP_TRANSFER_LOSING_REGISTRAR_NO_MESSAGE_RECEIVED

9.178.1. Severity

9.178.2. Description

Following a successful <transfer op="request"> command submitted by the gaining registrar of a transfer, the losinng registrar did not receive a message on the EPP message queue within the deadline (120 seconds).

9.178.3. Test cases

This error may be produced by the following test cases:

9.179. EPP_TRANSFER_SERVER_ACCEPTS_INCORRECT_AUTHINFO

9.179.1. Severity

9.179.2. Description

The server incorrectly accepted a <transfer op="request"> command containing an invalid authInfo code.

9.179.3. Test cases

This error may be produced by the following test cases:

9.180. EPP_TRANSFER_SERVER_ACCEPTS_INSECURE_AUTHINFO

9.180.1. Severity

9.180.2. Description

An EPP server implementing Secure Authorization Information for Transfer (RFC 9154) accepted an <update> command that specified an authInfo code with insufficient entropy.

9.180.3. Test cases

This error may be produced by the following test cases:

9.181. EPP_TRANSFER_SERVER_ACCEPTS_INVALID_PERIOD

9.181.1. Severity

9.181.2. Description

The server incorrectly accepted a <transfer op="request"> command containing a <period> element that contains an incorrect value or unit attribute.

9.181.3. Test cases

This error may be produced by the following test cases:

9.182. EPP_TRANSFER_SERVER_PROCESSED_REJECTED_TRANSFER

9.182.1. Severity

9.182.2. Description

Following a successful <transfer op="reject"> command submitted by the losing registrar of a transfer, the domain was still transferred away from that registrar.

9.182.3. Test cases

This error may be produced by the following test cases:

9.183. EPP_UNEXPECTED_COMMAND_FAILURE

9.183.1. Severity

9.183.2. Description

A command that should have succeeded return a response with a status code of 2000 or higher.

9.183.3. Test cases

This error may be produced by the following test cases:

9.184. EPP_XML_PARSE_ERROR

9.184.1. Severity

9.184.2. Description

The XML response from the server could not be parsed.

9.184.3. Test cases

This error may be produced by the following test cases:

9.185. IDN_IDNONLY_TLD_ACCEPTS_ASCII_DOMAIN

9.185.1. Severity

9.185.2. Description

The server incorrectly accepted a <create> command for an ASCII domain in a TLD whose idnOnly property is true.

9.185.3. Test cases

This error may be produced by the following test cases:

9.186. IDN_SERVER_ACCEPTS_INVALID_LABEL

9.186.1. Severity

9.186.2. Description

The server accepts a <create> command with a <name> object containing an invalid label.

9.186.3. Test cases

This error may be produced by the following test cases:

9.187. IDN_SERVER_REJECTS_VALID_LABEL

9.187.1. Severity

9.187.2. Description

The server rejects a <create> command with a <name> object containing a valid label.

9.187.3. Test cases

This error may be produced by the following test cases:

9.188. IDN_VARIANT_LABEL_NOT_BLOCKED

9.188.1. Severity

9.188.2. Description

A variant label remains available for registration.

9.188.3. Test cases

This error may be produced by the following test cases:

9.189. IDN_VARIANT_SERVER_ACCEPTS_VARIANT_CREATE_FROM_INCORRECT_REGISTRAR

9.189.1. Severity

9.189.2. Description

The server accepts a <create> command for a variant of an existing domain from a registrar other than that of the original domain.

9.189.3. Test cases

This error may be produced by the following test cases:

9.190. IDN_VARIANT_SERVER_ACCEPTS_VARIANT_CREATE_WITH_INCORRECT_REGISTRANT

9.190.1. Severity

9.190.2. Description

The server accepts a <create> command for a variant of an existing domain from with a registrant other than that the original domain.

9.190.3. Test cases

This error may be produced by the following test cases:

9.191. IDN_VARIANT_SERVER_REJECTS_VARIANT_CREATE_FROM_SAME_REGISTRAR

9.191.1. Severity

9.191.2. Description

The server rejects a <create> command for a variant of an existing domain from the registrar of the original domain.

9.191.3. Test cases

This error may be produced by the following test cases:

9.192. IDN_VARIANT_SERVER_REJECTS_VARIANT_CREATE_WITH_SAME_REGISTRANT

9.192.1. Severity

9.192.2. Description

The server rejects a <create> command for a variant of an existing domain using the same registrant as of the original domain.

9.192.3. Test cases

This error may be produced by the following test cases:

9.193. INTEGRATION_DNS_QUERY_FAILED

9.193.1. Severity

9.193.2. Description

A DNS query failed. Persistent errors may result in the test failing if the expected resource records are not observed within the Service Level Requirement.

9.193.3. Test cases

This error may be produced by the following test cases:

9.194. INTEGRATION_DOMAIN_NOT_PRESENT_IN_DNS

9.194.1. Severity

9.194.2. Description

One or more expected DNS records were not observed within the Service Level Requirement. This may be due to recurrent errors performing DNS queries, or because the DNS server(s) did not respond with the expected resource records.

9.194.3. Test cases

This error may be produced by the following test cases:

9.195. INTEGRATION_DOMAIN_NOT_PRESENT_IN_RDAP

9.195.1. Severity

9.195.2. Description

One or more expected RDAP responses were not observed within the Service Level Requirement. This may be due to recurrent errors performing RDAP queries, or because the RDAP server(s) did not respond with the expected responses.

9.195.3. Test cases

This error may be produced by the following test cases:

9.196. INTEGRATION_DOMAIN_NOT_PRESENT_IN_RDE

9.196.1. Severity

9.196.2. Description

One or more expected RDE objects were not observed within the Service Level Requirement. This may be due to recurrent errors accessing the SFTP server, because the deposit file(s) could not be found, or because the objects were not present in those files.

9.196.3. Test cases

This error may be produced by the following test cases:

9.197. INTEGRATION_RDAP_REQUEST_FAILED

9.197.1. Severity

9.197.2. Description

An RDAP query failed. Persistent errors may result in the test failing if the expected resource records are not observed within the Service Level Requirement.

9.197.3. Test cases

This error may be produced by the following test cases:

9.198. INTEGRATION_RDE_SFTP_SERVER_AUTHENTICATION_ERROR

9.198.1. Severity

9.198.2. Description

There was an issue authenticating with the SFTP server. Persistent errors may result in the test failing if the expected objects are not observed in a valid deposit within the Service Level Requirement.

9.198.3. Test cases

This error may be produced by the following test cases:

9.199. INTEGRATION_RDE_SFTP_SERVER_UNREACHABLE

9.199.1. Severity

9.199.2. Description

There was an issue connecting to the SFTP server. Persistent errors may result in the test failing if the expected objects are not observed in a valid deposit within the Service Level Requirement.

9.199.3. Test cases

This error may be produced by the following test cases:

9.200. RDAP_01_IPV4VALIDATION_FAILED

9.200.1. Severity

9.200.2. Description

For more information about this error, please refer to the test case(s) that use it.

9.200.3. Test cases

This error may be produced by the following test cases:

9.201. RDAP_02_IPV6VALIDATION_FAILED

9.201.1. Severity

9.201.2. Description

For more information about this error, please refer to the test case(s) that use it.

9.201.3. Test cases

This error may be produced by the following test cases:

9.202. RDAP_03_DOMAINNAMEVALIDATION_FAILED

9.202.1. Severity

9.202.2. Description

For more information about this error, please refer to the test case(s) that use it.

9.202.3. Test cases

This error may be produced by the following test cases:

9.203. RDAP_04_WEBURIVALIDATION_FAILED

9.203.1. Severity

9.203.2. Description

For more information about this error, please refer to the test case(s) that use it.

9.203.3. Test cases

This error may be produced by the following test cases:

9.204. RDAP_05_DOMAINCASEFOLDINGVALIDATION_FAILED

9.204.1. Severity

9.204.2. Description

For more information about this error, please refer to the test case(s) that use it.

9.204.3. Test cases

This error may be produced by the following test cases:

9.205. RDAP_06_STDRDAPCONFORMANCEVALIDATION_FAILED

9.205.1. Severity

9.205.2. Description

For more information about this error, please refer to the test case(s) that use it.

9.205.3. Test cases

This error may be produced by the following test cases:

9.206. RDAP_07_STDRDAPLINKSVALIDATION_FAILED

9.206.1. Severity

9.206.2. Description

For more information about this error, please refer to the test case(s) that use it.

9.206.3. Test cases

This error may be produced by the following test cases:

9.207. RDAP_08_STDRDAPNOTICESREMARKSVALIDATION_FAILED

9.207.1. Severity

9.207.2. Description

For more information about this error, please refer to the test case(s) that use it.

9.207.3. Test cases

This error may be produced by the following test cases:

9.208. RDAP_09_STDRDAPLANGUAGEIDENTIFIERVALIDATION_FAILED

9.208.1. Severity

9.208.2. Description

For more information about this error, please refer to the test case(s) that use it.

9.208.3. Test cases

This error may be produced by the following test cases:

9.209. RDAP_10_STDRDAPEVENTSVALIDATION_FAILED

9.209.1. Severity

9.209.2. Description

For more information about this error, please refer to the test case(s) that use it.

9.209.3. Test cases

This error may be produced by the following test cases:

9.210. RDAP_11_STDRDAPSTATUSVALIDATION_FAILED

9.210.1. Severity

9.210.2. Description

For more information about this error, please refer to the test case(s) that use it.

9.210.3. Test cases

This error may be produced by the following test cases:

9.211. RDAP_12_STDRDAPPORT43WHOISSERVERVALIDATION_FAILED

9.211.1. Severity

9.211.2. Description

For more information about this error, please refer to the test case(s) that use it.

9.211.3. Test cases

This error may be produced by the following test cases:

9.212. RDAP_13_STDRDAPPUBLICIDSVALIDATION_FAILED

9.212.1. Severity

9.212.2. Description

For more information about this error, please refer to the test case(s) that use it.

9.212.3. Test cases

This error may be produced by the following test cases:

9.213. RDAP_14_STDRDAPASEVENTACTORVALIDATION_FAILED

9.213.1. Severity

9.213.2. Description

For more information about this error, please refer to the test case(s) that use it.

9.213.3. Test cases

This error may be produced by the following test cases:

9.214. RDAP_15_STDRDAPIPADDRESSESVALIDATION_FAILED

9.214.1. Severity

9.214.2. Description

For more information about this error, please refer to the test case(s) that use it.

9.214.3. Test cases

This error may be produced by the following test cases:

9.215. RDAP_16_STDRDAPVARIANTSVALIDATION_FAILED

9.215.1. Severity

9.215.2. Description

For more information about this error, please refer to the test case(s) that use it.

9.215.3. Test cases

This error may be produced by the following test cases:

9.216. RDAP_17_STDRDAPUNICODENAMEVALIDATION_FAILED

9.216.1. Severity

9.216.2. Description

For more information about this error, please refer to the test case(s) that use it.

9.216.3. Test cases

This error may be produced by the following test cases:

9.217. RDAP_18_STDRDAPLDHNAMEVALIDATION_FAILED

9.217.1. Severity

9.217.2. Description

For more information about this error, please refer to the test case(s) that use it.

9.217.3. Test cases

This error may be produced by the following test cases:

9.218. RDAP_19_STDRDAPROLESVALIDATION_FAILED

9.218.1. Severity

9.218.2. Description

For more information about this error, please refer to the test case(s) that use it.

9.218.3. Test cases

This error may be produced by the following test cases:

9.219. RDAP_20_STDRDAPENTITIESVALIDATION_FAILED

9.219.1. Severity

9.219.2. Description

For more information about this error, please refer to the test case(s) that use it.

9.219.3. Test cases

This error may be produced by the following test cases:

9.220. RDAP_21_STDRDAPSECUREDNSVALIDATION_FAILED

9.220.1. Severity

9.220.2. Description

For more information about this error, please refer to the test case(s) that use it.

9.220.3. Test cases

This error may be produced by the following test cases:

9.221. RDAP_22_STDRDAPERRORRESPONSEBODYVALIDATION_FAILED

9.221.1. Severity

9.221.2. Description

For more information about this error, please refer to the test case(s) that use it.

9.221.3. Test cases

This error may be produced by the following test cases:

9.222. RDAP_23_STDRDAPDOMAINLOOKUPVALIDATION_FAILED

9.222.1. Severity

9.222.2. Description

For more information about this error, please refer to the test case(s) that use it.

9.222.3. Test cases

This error may be produced by the following test cases:

9.223. RDAP_24_STDRDAPENTITYLOOKUPVALIDATION_FAILED

9.223.1. Severity

9.223.2. Description

For more information about this error, please refer to the test case(s) that use it.

9.223.3. Test cases

This error may be produced by the following test cases:

9.224. RDAP_25_STDRDAPNAMESERVERLOOKUPVALIDATION_FAILED

9.224.1. Severity

9.224.2. Description

For more information about this error, please refer to the test case(s) that use it.

9.224.3. Test cases

This error may be produced by the following test cases:

9.225. RDAP_26_STDRDAPHELPVALIDATION_FAILED

9.225.1. Severity

9.225.2. Description

For more information about this error, please refer to the test case(s) that use it.

9.225.3. Test cases

This error may be produced by the following test cases:

9.226. RDAP_27_STDRDAPNAMESERVERSSEARCHVALIDATION_FAILED

9.226.1. Severity

9.226.2. Description

For more information about this error, please refer to the test case(s) that use it.

9.226.3. Test cases

This error may be produced by the following test cases:

9.227. RDAP_SERVICE_PORT_NOT_CONSISTENT

9.227.1. Severity

9.227.2. Description

The responses received are not consistent across all service ports.

9.227.3. Test cases

This error may be produced by the following test cases:

9.228. RDAP_TLS_BAD_CIPHER

9.228.1. Severity

9.228.2. Description

One or more RDAP service ports do implement a forbidden encryption cipher

9.228.3. Test cases

This error may be produced by the following test cases:

9.229. RDAP_TLS_CERTIFICATE_CHAIN_MISSING

9.229.1. Severity

9.229.2. Description

One or more RDAP service ports do not provide the full chain required to validate the server’s certificate.

9.229.3. Test cases

This error may be produced by the following test cases:

9.230. RDAP_TLS_CERTIFICATE_HOSTNAME_MISMATCH

9.230.1. Severity

9.230.2. Description

One or more RDAP service ports offer a certificate that cannot be matched against the RDAP server name.

9.230.3. Test cases

This error may be produced by the following test cases:

9.231. RDAP_TLS_DNS_RESOLUTION_ERROR

9.231.1. Severity

9.231.2. Description

An error occurred during DNS resolution of one of the RDAP base URL(s).

9.231.3. Test cases

This error may be produced by the following test cases:

9.232. RDAP_TLS_EXPIRED_CERTIFICATE

9.232.1. Severity

9.232.2. Description

One or more RDAP service ports offer a certificate that has expired.

9.232.3. Test cases

This error may be produced by the following test cases:

9.233. RDAP_TLS_FORBIDDEN_PROTOCOL_SUPPORTED

9.233.1. Severity

9.233.2. Description

One or more RDAP service ports do implement a forbidden version of TLS.

9.233.3. Test cases

This error may be produced by the following test cases:

9.234. RDAP_TLS_NO_SERVICE_PORTS_REACHABLE

9.234.1. Severity

9.234.2. Description

No service ports could be reached.

9.234.3. Test cases

This error may be produced by the following test cases:

9.235. RDAP_TLS_REQUIRED_PROTOCOL_NOT_SUPPORTED

9.235.1. Severity

9.235.2. Description

One or more RDAP service ports do not implement a required version of TLS.

9.235.3. Test cases

This error may be produced by the following test cases:

9.236. RDAP_TLS_SERVICE_PORT_UNREACHABLE

9.236.1. Severity

9.236.2. Description

A service port was not reachable. If all service ports are unreachable, then the test case will fail.

9.236.3. Test cases

This error may be produced by the following test cases:

9.237. RDAP_TLS_UNTRUSTED_CERTIFICATE

9.237.1. Severity

9.237.2. Description

One or more RDAP service ports offer a certificate that was not issued by a trusted certificate authority.

9.237.3. Test cases

This error may be produced by the following test cases:

9.238. RDE_CONTACT_HAS_INVALID_CC

9.238.1. Severity

9.238.2. Description

One or more contact objects have a <cc> element which contains a country code that is not present in the ISO-3166-alpha-2 list.

9.238.3. Test cases

This error may be produced by the following test cases:

9.239. RDE_CONTACT_HAS_INVALID_EMAIL

9.239.1. Severity

9.239.2. Description

One or more contact objects have an <email> element whose value does not comply with RFC 5322 (sections 3.2.3 and 3.4.1).

9.239.3. Test cases

This error may be produced by the following test cases:

9.240. RDE_CONTACT_HAS_INVALID_ROID

9.240.1. Severity

9.240.2. Description

One or more contact objects have a <roid> element with a repository identifier not found in the IANA registry.

9.240.3. Test cases

This error may be produced by the following test cases:

9.241. RDE_CONTACT_HAS_MULTIPLE_POSTALINFO_TYPES

9.241.1. Severity

9.241.2. Description

One or more contact objects have more than <postalInfo> element with the same type attribute.

9.241.3. Test cases

This error may be produced by the following test cases:

9.242. RDE_CONTACT_HAS_NON_UNIQUE_ID

9.242.1. Severity

9.242.2. Description

One or more contact objects have the same <id> element.

9.242.3. Test cases

This error may be produced by the following test cases:

9.243. RDE_CONTACT_HAS_UNKNOWN_ACRR

9.243.1. Severity

9.243.2. Description

One or more contact objects have an <acRr> element containing a registrar ID that is not present in the deposit.

9.243.3. Test cases

This error may be produced by the following test cases:

9.244. RDE_CONTACT_HAS_UNKNOWN_CLID

9.244.1. Severity

9.244.2. Description

One or more contact objects have a <clID> element containing a registrar ID that is not present in the deposit.

9.244.3. Test cases

This error may be produced by the following test cases:

9.245. RDE_CONTACT_HAS_UNKNOWN_CRRR

9.245.1. Severity

9.245.2. Description

One or more contact objects have a <crRr> element containing a registrar ID that is not present in the deposit.

9.245.3. Test cases

This error may be produced by the following test cases:

9.246. RDE_CONTACT_HAS_UNKNOWN_RERR

9.246.1. Severity

9.246.2. Description

One or more contact objects have an <reRr> element containing a registrar ID that is not present in the deposit.

9.246.3. Test cases

This error may be produced by the following test cases:

9.247. RDE_CONTACT_HAS_UNKNOWN_UPRR

9.247.1. Severity

9.247.2. Description

One or more contact objects have an <upRr> element containing a registrar ID that is not present in the deposit.

9.247.3. Test cases

This error may be produced by the following test cases:

9.248. RDE_DECRYPTION_FAILED

9.248.1. Severity

9.248.2. Description

The deposit file could not be decrypted.

9.248.3. Test cases

This error may be produced by the following test cases:

9.249. RDE_DOMAIN_HAS_INVALID_CLID

9.249.1. Severity

9.249.2. Description

One or more domain objects have a <clID> element containing a registrar ID that is not present in the deposit.

9.249.3. Test cases

This error may be produced by the following test cases:

9.250. RDE_DOMAIN_HAS_INVALID_CRDATE

9.250.1. Severity

9.250.2. Description

One or more domain objects have an invalid <crDate> element.

9.250.3. Test cases

This error may be produced by the following test cases:

9.251. RDE_DOMAIN_HAS_INVALID_EXDATE

9.251.1. Severity

9.251.2. Description

One or more domain objects have an invalid <exDate> element.

9.251.3. Test cases

This error may be produced by the following test cases:

9.252. RDE_DOMAIN_HAS_INVALID_NAME

9.252.1. Severity

9.252.2. Description

One or more domain objects have an invalid <name> element.

9.252.3. Test cases

This error may be produced by the following test cases:

9.253. RDE_DOMAIN_HAS_INVALID_REGISTRANT

9.253.1. Severity

9.253.2. Description

One or more domain objects have an <registrant> element that is not present in the deposit.

9.253.3. Test cases

This error may be produced by the following test cases:

9.254. RDE_DOMAIN_HAS_INVALID_ROID

9.254.1. Severity

9.254.2. Description

One or more domain objects have a <roid> element with a repository identifier not found in the IANA registry.

9.254.3. Test cases

This error may be produced by the following test cases:

9.255. RDE_DOMAIN_HAS_INVALID_STATUS

9.255.1. Severity

9.255.2. Description

One or more domain objects have an invalid <status> element.

9.255.3. Test cases

This error may be produced by the following test cases:

9.256. RDE_DOMAIN_HAS_MISSING_CLID

9.256.1. Severity

9.256.2. Description

One or more domain objects have an <clID> element that is not present in the deposit.

9.256.3. Test cases

This error may be produced by the following test cases:

9.257. RDE_DOMAIN_HAS_MISSING_CRDATE

9.257.1. Severity

9.257.2. Description

One or more domain objects do not have a <crDate> element.

9.257.3. Test cases

This error may be produced by the following test cases:

9.258. RDE_DOMAIN_HAS_MISSING_EXDATE

9.258.1. Severity

9.258.2. Description

One or more domain objects do not have a <exDate> element.

9.258.3. Test cases

This error may be produced by the following test cases:

9.259. RDE_DOMAIN_HAS_MISSING_REGISTRANT

9.259.1. Severity

9.259.2. Description

One or more domain objects do not have a <registrant> element.

9.259.3. Test cases

This error may be produced by the following test cases:

9.260. RDE_DOMAIN_HAS_MISSING_ROID

9.260.1. Severity

9.260.2. Description

One or more domain objects do not have a <roid> element.

9.260.3. Test cases

This error may be produced by the following test cases:

9.261. RDE_DOMAIN_HAS_MISSING_STATUS

9.261.1. Severity

9.261.2. Description

One or more domain objects do not have a <status> element.

9.261.3. Test cases

This error may be produced by the following test cases:

9.262. RDE_GREETING_DOES_NOT_MATCH

9.262.1. Severity

9.262.2. Description

The <eppParams> object contains values which do not match the provided EPP <greeting> XML instance.

9.262.3. Test cases

This error may be produced by the following test cases:

9.263. RDE_HOST_HAS_INVALID_CLID

9.263.1. Severity

9.263.2. Description

One or more host objects have an <clID> element that is not present in the deposit.

9.263.3. Test cases

This error may be produced by the following test cases:

9.264. RDE_HOST_HAS_INVALID_IP_ADDRESS

9.264.1. Severity

9.264.2. Description

One or more host objects have an invalid IP address.

9.264.3. Test cases

This error may be produced by the following test cases:

9.265. RDE_HOST_HAS_INVALID_NAME

9.265.1. Severity

9.265.2. Description

One or more host objects have an invalid hostname.

9.265.3. Test cases

This error may be produced by the following test cases:

9.266. RDE_HOST_HAS_INVALID_ROID

9.266.1. Severity

9.266.2. Description

One or more host objects have a <roid> element with a repository identifier not found in the IANA registry.

9.266.3. Test cases

This error may be produced by the following test cases:

9.267. RDE_HOST_HAS_INVALID_STATUS

9.267.1. Severity

9.267.2. Description

One or more domain objects have an invalid <status> element.

9.267.3. Test cases

This error may be produced by the following test cases:

9.268. RDE_HOST_HAS_MISSING_CLID

9.268.1. Severity

9.268.2. Description

One or more host objects do not have a <clID> element.

9.268.3. Test cases

This error may be produced by the following test cases:

9.269. RDE_HOST_HAS_MISSING_IP_ADDRESS

9.269.1. Severity

9.269.2. Description

One or more host objects with in-bailiwick hostnames do not have a <addr> element.

9.269.3. Test cases

This error may be produced by the following test cases:

9.270. RDE_HOST_HAS_MISSING_ROID

9.270.1. Severity

9.270.2. Description

One or more host objects do not have a <clID> element.

9.270.3. Test cases

This error may be produced by the following test cases:

9.271. RDE_HOST_HAS_MISSING_STATUS

9.271.1. Severity

9.271.2. Description

One or more host objects do not have a <status> element.

9.271.3. Test cases

This error may be produced by the following test cases:

9.272. RDE_IDN_OBJECT_INVALID

9.272.1. Severity

9.272.2. Description

The deposit contains one or more invalid IDN objects.

9.272.3. Test cases

This error may be produced by the following test cases:

9.273. RDE_IDN_OBJECT_MISSING

9.273.1. Severity

9.273.2. Description

One or more IDN objects are missing.

9.273.3. Test cases

This error may be produced by the following test cases:

9.274. RDE_IDN_OBJECT_UNEXPECTED

9.274.1. Severity

9.274.2. Description

One or more unexpected IDN objects were found in the deposit.

9.274.3. Test cases

This error may be produced by the following test cases:

9.275. RDE_INVALID_CSV

9.275.1. Severity

9.275.2. Description

One or more CSV files in the deposit do not conform to RFC 4180.

9.275.3. Test cases

This error may be produced by the following test cases:

9.276. RDE_INVALID_FILENAME

9.276.1. Severity

9.276.2. Description

The filename of the deposit does not confirm to the requirements in Specification 2 of the Registry Agreement.

9.276.3. Test cases

This error may be produced by the following test cases:

9.277. RDE_INVALID_SIGNATURE

9.277.1. Severity

9.277.2. Description

The OpenPGP signature could not be validated.

9.277.3. Test cases

This error may be produced by the following test cases:

9.278. RDE_MISSING_OBJECT_URI

9.278.1. Severity

9.278.2. Description

One or more expected object URIs were not found in the header.

9.278.3. Test cases

This error may be produced by the following test cases:

9.279. RDE_MIXED_TYPES

9.279.1. Severity

9.279.2. Description

The deposit contains both XML and CSV data files.

9.279.3. Test cases

This error may be produced by the following test cases:

9.280. RDE_NNDN_CONFLICTS_WITH_DOMAIN

9.280.1. Severity

9.280.2. Description

One or more NNDN objects have names that match those of one or more domain objects.

9.280.3. Test cases

This error may be produced by the following test cases:

9.281. RDE_OBJECT_COUNT_MISMATCH

9.281.1. Severity

9.281.2. Description

The number of objects in the deposit does not match the counts found in the header.

9.281.3. Test cases

This error may be produced by the following test cases:

9.282. RDE_POLICY_OBJECT_INVALID

9.282.1. Severity

9.282.2. Description

The Policy Object is invalid.

9.282.3. Test cases

This error may be produced by the following test cases:

9.283. RDE_POLICY_OBJECT_MISSING

9.283.1. Severity

9.283.2. Description

The Policy Object is missing.

9.283.3. Test cases

This error may be produced by the following test cases:

9.284. RDE_POLICY_OBJECT_MISSING_OBJECTS

9.284.1. Severity

9.284.2. Description

The Policy Object does not contain all expected objects.

9.284.3. Test cases

This error may be produced by the following test cases:

9.285. RDE_POLICY_OBJECT_UNEXPECTED_OBJECTS

9.285.1. Severity

9.285.2. Description

The Policy Object contains unexpected objects.

9.285.3. Test cases

This error may be produced by the following test cases:

9.286. RDE_REGISTRAR_HAS_INVALID_GURID

9.286.1. Severity

9.286.2. Description

One of more registrar objects have an invalid <gurid> element.

9.286.3. Test cases

This error may be produced by the following test cases:

9.287. RDE_REGISTRAR_HAS_INVALID_ID

9.287.1. Severity

9.287.2. Description

One of more registrar objects have an invalid <id> element.

9.287.3. Test cases

This error may be produced by the following test cases:

9.288. RDE_REGISTRAR_HAS_INVALID_NAME

9.288.1. Severity

9.288.2. Description

One of more registrar objects have an invalid <name> element.

9.288.3. Test cases

This error may be produced by the following test cases:

9.289. RDE_REGISTRAR_HAS_MISSING_GURID

9.289.1. Severity

9.289.2. Description

One of more registrar objects have a missing <gurid> element.

9.289.3. Test cases

This error may be produced by the following test cases:

9.290. RDE_REGISTRAR_HAS_MISSING_ID

9.290.1. Severity

9.290.2. Description

One of more registrar objects have a missing <id> element.

9.290.3. Test cases

This error may be produced by the following test cases:

9.291. RDE_REGISTRAR_HAS_MISSING_NAME

9.291.1. Severity

9.291.2. Description

One of more registrar objects have a missing <name> element.

9.291.3. Test cases

This error may be produced by the following test cases:

9.292. RDE_SCHEMA_VALIDATION_ERROR

9.292.1. Severity

9.292.2. Description

The XML in the deposit file could not be validated against the schema.

9.292.3. Test cases

This error may be produced by the following test cases:

9.293. RDE_UNEXPECTED_OBJECT_URI

9.293.1. Severity

9.293.2. Description

The deposit contains an unexpected object URI in the header.

9.293.3. Test cases

This error may be produced by the following test cases:

9.294. RDE_XML_PARSE_ERROR

9.294.1. Severity

9.294.2. Description

The XML in the deposit file is not well-formed.

9.294.3. Test cases

This error may be produced by the following test cases:

9.295. RPMS_MISSING_CLAIMS_KEY

9.295.1. Severity

9.295.2. Description

The <check> response did not include an expected <launch:claimKey> element.

9.295.3. Test cases

This error may be produced by the following test cases:

9.296. RPMS_SUNRISE_CREATE_INFO_OBJECT_DOES_NOT_EXIST

9.296.1. Severity

9.296.2. Description

Following a sunrise <create> command, the <info> response did not return the created object.

9.296.3. Test cases

This error may be produced by the following test cases:

9.297. RPMS_SUNRISE_CREATE_INFO_OBJECT_IS_HAS_MISSING_OR_INVALID_PROPERTIES

9.297.1. Severity

9.297.2. Description

Following a sunrise <create> command, the <info> response contained missing or invalid object properties.

9.297.3. Test cases

This error may be produced by the following test cases:

9.298. RPMS_SUNRISE_CREATE_UNEXPECTED_FAILURE_USING_VALID_SMD

9.298.1. Severity

9.298.2. Description

A sunrise <create> command using a valid SMD unexpectedly failed.

9.298.3. Test cases

This error may be produced by the following test cases:

9.299. RPMS_SUNRISE_CREATE_UNEXPECTED_SUCCESS_USING_EXPIRED_SMD

9.299.1. Severity

9.299.2. Description

A sunrise <create> command using a expired SMD unexpectedly succeeded.

9.299.3. Test cases

This error may be produced by the following test cases:

9.300. RPMS_SUNRISE_CREATE_UNEXPECTED_SUCCESS_USING_INCORRECT_SMD

9.300.1. Severity

9.300.2. Description

A sunrise <create> command using an SMD that did not contain the domain unexpectedly succeeded.

9.300.3. Test cases

This error may be produced by the following test cases:

9.301. RPMS_SUNRISE_CREATE_UNEXPECTED_SUCCESS_USING_REVOKED_SMD

9.301.1. Severity

9.301.2. Description

A sunrise <create> command using a revoked SMD unexpectedly succeeded.

9.301.3. Test cases

This error may be produced by the following test cases:

9.302. RPMS_SUNRISE_CREATE_UNEXPECTED_SUCCESS_USING_SMD_WITH_REVOKED_SIGNATURE

9.302.1. Severity

9.302.2. Description

A sunrise <create> command using an SMD signed with a revoked certificate unexpectedly succeeded.

9.302.3. Test cases

This error may be produced by the following test cases:

9.303. RPMS_TRADEMARK_CREATE_INFO_OBJECT_DOES_NOT_EXIST

9.303.1. Severity

9.303.2. Description

Following a trademark claims <create> command, the <info> response did not return the created object.

9.303.3. Test cases

This error may be produced by the following test cases:

9.304. RPMS_TRADEMARK_CREATE_INFO_OBJECT_IS_HAS_MISSING_OR_INVALID_PROPERTIES

9.304.1. Severity

9.304.2. Description

Following a trademark claims <create> command, the <info> response contained missing or invalid object properties.

9.304.3. Test cases

This error may be produced by the following test cases:

9.305. RPMS_TRADEMARK_CREATE_UNEXPECTED_FAILURE_USING_VALID_CLAIM_KEY

9.305.1. Severity

9.305.2. Description

A trademark claims <create> command using a valid claim key unexpectedly failed.

9.305.3. Test cases

This error may be produced by the following test cases:

9.306. RPMS_TRADEMARK_CREATE_UNEXPECTED_SUCCESS_USING_INVALID_ACCEPTANCE_DATE

9.306.1. Severity

9.306.2. Description

A trademark claims <create> command using an invalid acceptance date unexpectedly succeeded.

9.306.3. Test cases

This error may be produced by the following test cases:

9.307. RPMS_TRADEMARK_CREATE_UNEXPECTED_SUCCESS_USING_INVALID_CLAIM_KEY

9.307.1. Severity

9.307.2. Description

A trademark claims <create> command using an invalid claim key unexpectedly succeeded.

9.307.3. Test cases

This error may be produced by the following test cases:

9.308. RPMS_UNEXPECTED_CLAIMS_KEY

9.308.1. Severity

9.308.2. Description

The <check> response included an unexpected <launch:claimKey> element.

9.308.3. Test cases

This error may be produced by the following test cases:

9.309. SRSGW_CONTACT_CREATE_FAILED

9.309.1. Severity

9.309.2. Description

The contact <create> command at the SRS Gateway EPP server failed.

9.309.3. Test cases

This error may be produced by the following test cases:

9.310. SRSGW_CONTACT_CREATE_OBJECT_HAS_MISSING_OR_INVALID_PROPERTIES

9.310.1. Severity

9.310.2. Description

Following a successful contact <create> command, the <info> response from the SRS Gateway EPP server has missing or invalid object properties.

9.310.3. Test cases

This error may be produced by the following test cases:

9.311. SRSGW_CONTACT_CREATE_OBJECT_NOT_FOUND_WITHIN_DEADLINE

9.311.1. Severity

9.311.2. Description

Following a successful contact <create> command, the primary EPP server did not respond with a successful <info> response within the deadline.

9.311.3. Test cases

This error may be produced by the following test cases:

9.312. SRSGW_DOMAIN_CREATE_FAILED

9.312.1. Severity

9.312.2. Description

The domain <create> command at the SRS Gateway EPP server failed.

9.312.3. Test cases

This error may be produced by the following test cases:

9.313. SRSGW_DOMAIN_CREATE_OBJECT_HAS_MISSING_OR_INVALID_PROPERTIES

9.313.1. Severity

9.313.2. Description

Following a successful domain <create> command, the <info> response from the SRS Gateway EPP server has missing or invalid object properties.

9.313.3. Test cases

This error may be produced by the following test cases:

9.314. SRSGW_DOMAIN_CREATE_OBJECT_NOT_FOUND_WITHIN_DEADLINE

9.314.1. Severity

9.314.2. Description

Following a successful domain <create> command, the primary EPP server did not respond with a successful <info> response within the deadline.

9.314.3. Test cases

This error may be produced by the following test cases:

9.315. SRSGW_DOMAIN_DELETE_DOMAIN_NOT_PENDINGDELETE

9.315.1. Severity

9.315.2. Description

Following a successful domain <delete> command, the domain did not have the pendingDelete status at the primary EPP server.

9.315.3. Test cases

This error may be produced by the following test cases:

9.316. SRSGW_DOMAIN_DELETE_FAILED

9.316.1. Severity

9.316.2. Description

The domain <delete> command at the SRS Gateway EPP server failed.

9.316.3. Test cases

This error may be produced by the following test cases:

9.317. SRSGW_DOMAIN_DELETE_RGP_STATUS_NOT_PENDINGDELETERESTORABLE

9.317.1. Severity

9.317.2. Description

Following a successful domain <delete> command, the domain did not have the pendingDeleteRestorable RGP status at the primary EPP server.

9.317.3. Test cases

This error may be produced by the following test cases:

9.318. SRSGW_DOMAIN_RENEW_FAILED

9.318.1. Severity

9.318.2. Description

The domain <renew> command at the SRS Gateway EPP server failed.

9.318.3. Test cases

This error may be produced by the following test cases:

9.319. SRSGW_DOMAIN_RENEW_OBJECT_NOT_UPDATED_WITHIN_DEADLINE

9.319.1. Severity

9.319.2. Description

Following a successful <renew> command, the domain’s expiry date was not updated at the primary EPP server within the deadline.

9.319.3. Test cases

This error may be produced by the following test cases:

9.320. SRSGW_DOMAIN_TRANSFER_APPROVAL_FAILED

9.320.1. Severity

9.320.2. Description

The domain <transfer op="approve"> command at the SRS Gateway EPP server failed.

9.320.3. Test cases

This error may be produced by the following test cases:

9.321. SRSGW_DOMAIN_TRANSFER_APPROVAL_OBJECT_HAS_INCORRECT_CLID

9.321.1. Severity

9.321.2. Description

Following a successful <transfer op="approve"> command, the domain is under the sponsorship of the wrong registrar.

9.321.3. Test cases

This error may be produced by the following test cases:

9.322. SRSGW_DOMAIN_TRANSFER_APPROVAL_OBJECT_NOT_UPDATED_WITHIN_DEADLINE

9.322.1. Severity

9.322.2. Description

Following a successful <transfer op="approve"> command at the SRS Gateway, the domain’s sponsor was not updated at the primary EPP server within the deadline.

9.322.3. Test cases

This error may be produced by the following test cases:

9.323. SRSGW_DOMAIN_TRANSFER_APPROVAL_OBJECT_STILL_PENDING_TRANSFER

9.323.1. Severity

9.323.2. Description

The domain <transfer op="approve"> command at the SRS Gateway, the domain’s still has the pendingTransfer status.

9.323.3. Test cases

This error may be produced by the following test cases:

9.324. SRSGW_DOMAIN_TRANSFER_REQUEST_FAILED

9.324.1. Severity

9.324.2. Description

The domain <transfer op="request"> command at the SRS Gateway EPP server failed.

9.324.3. Test cases

This error may be produced by the following test cases:

9.325. SRSGW_DOMAIN_TRANSFER_REQUEST_OBJECT_NOT_PENDING_TRANSFER

9.325.1. Severity

9.325.2. Description

Following a successful <transfer op="request"> command at the SRS Gateway, which resulted in a 1001 response, the domain does not have the pendingTransfer status.

9.325.3. Test cases

This error may be produced by the following test cases:

9.326. SRSGW_DOMAIN_TRANSFER_REQUEST_OBJECT_NOT_UPDATED_WITHIN_DEADLINE

9.326.1. Severity

9.326.2. Description

Following a successful <transfer op="request"> command at the SRS Gateway, which resulted in a 1000 response, the domain’s sponsor was not updated at the primary EPP server within the deadline.

9.326.3. Test cases

This error may be produced by the following test cases:

9.327. SRSGW_EPP_CONTACT_DELETE_FAILED

9.327.1. Severity

9.327.2. Description

The contact <delete> command at the SRS Gateway EPP server failed.

9.327.3. Test cases

This error may be produced by the following test cases:

9.328. SRSGW_EPP_CONTACT_DELETE_OBJECT_STILL_EXISTS

9.328.1. Severity

9.328.2. Description

Following a successful contact <delete> command, the object was not purged from the primary EPP server within the deadline.

9.328.3. Test cases

This error may be produced by the following test cases:

9.329. SRSGW_EPP_CONTACT_UPDATE_FAILED

9.329.1. Severity

9.329.2. Description

The contact <update> command at the SRS Gateway EPP server failed.

9.329.3. Test cases

This error may be produced by the following test cases:

9.330. SRSGW_EPP_CONTACT_UPDATE_INFO_RESPONSES_DIFFER

9.330.1. Severity

9.330.2. Description

Following a successful contact <update> command, the <info> response from the primary EPP server was not updated within the deadline.

9.330.3. Test cases

This error may be produced by the following test cases:

9.331. SRSGW_EPP_HOST_DELETE_FAILED

9.331.1. Severity

9.331.2. Description

The host <delete> command at the SRS Gateway EPP server failed.

9.331.3. Test cases

This error may be produced by the following test cases:

9.332. SRSGW_EPP_HOST_DELETE_OBJECT_STILL_EXISTS

9.332.1. Severity

9.332.2. Description

Following a successful host <delete> command, the object was not purged from the primary EPP server within the deadline.

9.332.3. Test cases

This error may be produced by the following test cases:

9.333. SRSGW_EPP_HOST_UPDATE_FAILED

9.333.1. Severity

9.333.2. Description

The host <update> command at the SRS Gateway EPP server failed.

9.333.3. Test cases

This error may be produced by the following test cases:

9.334. SRSGW_EPP_HOST_UPDATE_INFO_RESPONSES_DIFFER

9.334.1. Severity

9.334.2. Description

Following a successful host <update> command, the <info> response from the primary EPP server was not updated within the deadline.

9.334.3. Test cases

This error may be produced by the following test cases:

9.335. SRSGW_HOST_CREATE_FAILED

9.335.1. Severity

9.335.2. Description

The host <create> command at the SRS Gateway EPP server failed.

9.335.3. Test cases

This error may be produced by the following test cases:

9.336. SRSGW_HOST_CREATE_OBJECT_HAS_MISSING_OR_INVALID_PROPERTIES

9.336.1. Severity

9.336.2. Description

Following a successful host <create> command, the <info> response from the SRS Gateway EPP server has missing or invalid object properties.

9.336.3. Test cases

This error may be produced by the following test cases:

9.337. SRSGW_HOST_CREATE_OBJECT_NOT_FOUND_WITHIN_DEADLINE

9.337.1. Severity

9.337.2. Description

Following a successful host <create> command, the primary EPP server did not respond with a successful <info> response within the deadline.

9.337.3. Test cases

This error may be produced by the following test cases:

9.338. SRSGW_RDAP_DNS_RESOLUTION_ERROR

9.338.1. Severity

9.338.2. Description

None of the RDAP base URL(s) could be resolved.

9.338.3. Test cases

This error may be produced by the following test cases:

9.339. SRSGW_RDAP_QUERY_FAILED

9.339.1. Severity

9.339.2. Description

The RDAP query resulted in an unexpected response (HTTP status, media type, etc).

9.339.3. Test cases

This error may be produced by the following test cases:

9.340. SRSGW_RDAP_RESPONSES_DIFFER

9.340.1. Severity

9.340.2. Description

The responses from the SRS Gateway and Primary RDAP servers differ.

9.340.3. Test cases

This error may be produced by the following test cases:

9.341. SRSGW_RDAP_SERVICE_PORT_UNREACHABLE

9.341.1. Severity

9.341.2. Description

None of the RDAP service ports could be reached.

9.341.3. Test cases

This error may be produced by the following test cases:

9.342. SRSGW_RDAP_TLS_CONNECTION_ERROR

9.342.1. Severity

9.342.2. Description

A TLS connection could not be established to the service port.

9.342.3. Test cases

This error may be produced by the following test cases:

9.343. ZM_AAAA_BAD_RDATA

9.343.1. Severity

9.343.2. Description

Zonemaster describes this error as follows:

Nameserver {ns} answered AAAA query with an unexpected RDATA length ({length} instead of 16).

For more information about this error, please refer to the documentation for the test case this error comes from.

9.343.3. Test cases

This error may be produced by the following test cases:

9.344. ZM_AAAA_QUERY_DROPPED

9.344.1. Severity

9.344.2. Description

Zonemaster describes this error as follows:

Nameserver {ns} dropped AAAA query.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.344.3. Test cases

This error may be produced by the following test cases:

9.345. ZM_AAAA_UNEXPECTED_RCODE

9.345.1. Severity

9.345.2. Description

Zonemaster describes this error as follows:

Nameserver {ns} answered AAAA query with an unexpected rcode ({rcode}).

For more information about this error, please refer to the documentation for the test case this error comes from.

9.345.3. Test cases

This error may be produced by the following test cases:

9.346. ZM_ALGORITHM_DEPRECATED

9.346.1. Severity

9.346.2. Description

Zonemaster describes this error as follows:

The DNSKEY with tag {keytag} uses deprecated algorithm number {algo_num} ({algo_descr}).

For more information about this error, please refer to the documentation for the test case this error comes from.

9.346.3. Test cases

This error may be produced by the following test cases:

9.347. ZM_ALGORITHM_NOT_RECOMMENDED

9.347.1. Severity

9.347.2. Description

Zonemaster describes this error as follows:

The DNSKEY with tag {keytag} uses an algorithm number {algo_num} ({algo_descr}) which is not recommended to be used.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.347.3. Test cases

This error may be produced by the following test cases:

9.348. ZM_ALGORITHM_NOT_ZONE_SIGN

9.348.1. Severity

9.348.2. Description

Zonemaster describes this error as follows:

The DNSKEY with tag {keytag} uses algorithm number not meant for zone signing, algorithm number {algo_num} ({algo_descr}).

For more information about this error, please refer to the documentation for the test case this error comes from.

9.348.3. Test cases

This error may be produced by the following test cases:

9.349. ZM_ALGORITHM_PRIVATE

9.349.1. Severity

9.349.2. Description

Zonemaster describes this error as follows:

The DNSKEY with tag {keytag} uses private algorithm number {algo_num} ({algo_descr}).

For more information about this error, please refer to the documentation for the test case this error comes from.

9.349.3. Test cases

This error may be produced by the following test cases:

9.350. ZM_ALGORITHM_RESERVED

9.350.1. Severity

9.350.2. Description

Zonemaster describes this error as follows:

The DNSKEY with tag {keytag} uses reserved algorithm number {algo_num} ({algo_descr}).

For more information about this error, please refer to the documentation for the test case this error comes from.

9.350.3. Test cases

This error may be produced by the following test cases:

9.351. ZM_ALGORITHM_UNASSIGNED

9.351.1. Severity

9.351.2. Description

Zonemaster describes this error as follows:

The DNSKEY with tag {keytag} uses unassigned algorithm number {algo_num} ({algo_descr}).

For more information about this error, please refer to the documentation for the test case this error comes from.

9.351.3. Test cases

This error may be produced by the following test cases:

9.352. ZM_A_UNEXPECTED_RCODE

9.352.1. Severity

9.352.2. Description

Zonemaster describes this error as follows:

Nameserver {ns} answered A query with an unexpected rcode ({rcode}).

For more information about this error, please refer to the documentation for the test case this error comes from.

9.352.3. Test cases

This error may be produced by the following test cases:

9.353. ZM_BREAKS_ON_EDNS

9.353.1. Severity

9.353.2. Description

Zonemaster describes this error as follows:

No response from {ns} when EDNS is used in query asking for {domain}.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.353.3. Test cases

This error may be produced by the following test cases:

9.354. ZM_CAN_NOT_BE_RESOLVED

9.354.1. Severity

9.354.2. Description

Zonemaster describes this error as follows:

The following nameservers failed to resolve to an IP address : {nsname_list}.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.354.3. Test cases

This error may be produced by the following test cases:

9.355. ZM_CASE_QUERIES_RESULTS_DIFFER

9.355.1. Severity

9.355.2. Description

Zonemaster describes this error as follows:

When asked for {type} records on “{domain}” with different cases, all servers do not reply consistently.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.355.3. Test cases

This error may be produced by the following test cases:

9.356. ZM_CASE_QUERY_DIFFERENT_ANSWER

9.356.1. Severity

9.356.2. Description

Zonemaster describes this error as follows:

When asked for {type} records on “{query1}” and “{query2}”, nameserver {ns} returns different answers.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.356.3. Test cases

This error may be produced by the following test cases:

9.357. ZM_CASE_QUERY_DIFFERENT_RC

9.357.1. Severity

9.357.2. Description

Zonemaster describes this error as follows:

When asked for {type} records on “{query1}” and “{query2}”, nameserver {ns} returns different RCODE (“{rcode1}” vs “{rcode2}”).

For more information about this error, please refer to the documentation for the test case this error comes from.

9.357.3. Test cases

This error may be produced by the following test cases:

9.358. ZM_CASE_QUERY_NO_ANSWER

9.358.1. Severity

9.358.2. Description

Zonemaster describes this error as follows:

When asked for {type} records on “{domain}”, nameserver {ns} returns nothing.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.358.3. Test cases

This error may be produced by the following test cases:

9.359. ZM_CHILD_NS_FAILED

9.359.1. Severity

9.359.2. Description

Zonemaster describes this error as follows:

Unexpected or erroneous reply from {ns}.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.359.3. Test cases

This error may be produced by the following test cases:

9.360. ZM_CHILD_NS_SAME_IP

9.360.1. Severity

9.360.2. Description

Zonemaster describes this error as follows:

IP {ns_ip} in child refers to multiple nameservers ({nsname_list}).

For more information about this error, please refer to the documentation for the test case this error comes from.

9.360.3. Test cases

This error may be produced by the following test cases:

9.361. ZM_CHILD_ZONE_LAME

9.361.1. Severity

9.361.2. Description

Zonemaster describes this error as follows:

Lame delegation.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.361.3. Test cases

This error may be produced by the following test cases:

9.362. ZM_CN01_MISSING_NS_RECORD_UDP

9.362.1. Severity

9.362.2. Description

Zonemaster describes this error as follows:

Nameserver {ns} responds to a NS query with no NS records in the answer section over UDP.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.362.3. Test cases

This error may be produced by the following test cases:

9.363. ZM_CN01_MISSING_SOA_RECORD_UDP

9.363.1. Severity

9.363.2. Description

Zonemaster describes this error as follows:

Nameserver {ns} responds to a SOA query with no SOA records in the answer section over UDP.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.363.3. Test cases

This error may be produced by the following test cases:

9.364. ZM_CN01_NO_RESPONSE_NS_QUERY_UDP

9.364.1. Severity

9.364.2. Description

Zonemaster describes this error as follows:

Nameserver {ns} does not respond to NS queries over UDP.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.364.3. Test cases

This error may be produced by the following test cases:

9.365. ZM_CN01_NO_RESPONSE_SOA_QUERY_UDP

9.365.1. Severity

9.365.2. Description

Zonemaster describes this error as follows:

Nameserver {ns} does not respond to SOA queries over UDP.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.365.3. Test cases

This error may be produced by the following test cases:

9.366. ZM_CN01_NO_RESPONSE_UDP

9.366.1. Severity

9.366.2. Description

Zonemaster describes this error as follows:

Nameserver {ns} does not respond to any queries over UDP.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.366.3. Test cases

This error may be produced by the following test cases:

9.367. ZM_CN01_NS_RECORD_NOT_AA_UDP

9.367.1. Severity

9.367.2. Description

Zonemaster describes this error as follows:

Nameserver {ns} does not give an authoritative response on an NS query over UDP.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.367.3. Test cases

This error may be produced by the following test cases:

9.368. ZM_CN01_SOA_RECORD_NOT_AA_UDP

9.368.1. Severity

9.368.2. Description

Zonemaster describes this error as follows:

Nameserver {ns} does not give an authoritative response on an SOA query over UDP.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.368.3. Test cases

This error may be produced by the following test cases:

9.369. ZM_CN01_UNEXPECTED_RCODE_NS_QUERY_UDP

9.369.1. Severity

9.369.2. Description

Zonemaster describes this error as follows:

Nameserver {ns} responds with an unexpected RCODE ({rcode}) on an NS query over UDP.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.369.3. Test cases

This error may be produced by the following test cases:

9.370. ZM_CN01_UNEXPECTED_RCODE_SOA_QUERY_UDP

9.370.1. Severity

9.370.2. Description

Zonemaster describes this error as follows:

Nameserver {ns} responds with an unexpected RCODE ({rcode}) on an SOA query over UDP.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.370.3. Test cases

This error may be produced by the following test cases:

9.371. ZM_CN01_WRONG_NS_RECORD_UDP

9.371.1. Severity

9.371.2. Description

Zonemaster describes this error as follows:

Nameserver {ns} responds with a wrong owner name ({domain_found} instead of {domain_expected}) on NS queries over UDP.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.371.3. Test cases

This error may be produced by the following test cases:

9.372. ZM_CN01_WRONG_SOA_RECORD_UDP

9.372.1. Severity

9.372.2. Description

Zonemaster describes this error as follows:

Nameserver {ns} responds with a wrong owner name ({domain_found} instead of {domain_expected}) on SOA queries over UDP.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.372.3. Test cases

This error may be produced by the following test cases:

9.373. ZM_CN02_MISSING_NS_RECORD_TCP

9.373.1. Severity

9.373.2. Description

Zonemaster describes this error as follows:

Nameserver {ns} responds to a NS query with no NS records in the answer section over TCP.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.373.3. Test cases

This error may be produced by the following test cases:

9.374. ZM_CN02_MISSING_SOA_RECORD_TCP

9.374.1. Severity

9.374.2. Description

Zonemaster describes this error as follows:

Nameserver {ns} responds to a SOA query with no SOA records in the answer section over TCP.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.374.3. Test cases

This error may be produced by the following test cases:

9.375. ZM_CN02_NO_RESPONSE_NS_QUERY_TCP

9.375.1. Severity

9.375.2. Description

Zonemaster describes this error as follows:

Nameserver {ns} does not respond to NS queries over TCP.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.375.3. Test cases

This error may be produced by the following test cases:

9.376. ZM_CN02_NO_RESPONSE_SOA_QUERY_TCP

9.376.1. Severity

9.376.2. Description

Zonemaster describes this error as follows:

Nameserver {ns} does not respond to SOA queries over TCP.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.376.3. Test cases

This error may be produced by the following test cases:

9.377. ZM_CN02_NO_RESPONSE_TCP

9.377.1. Severity

9.377.2. Description

Zonemaster describes this error as follows:

Nameserver {ns} does not respond to any queries over TCP.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.377.3. Test cases

This error may be produced by the following test cases:

9.378. ZM_CN02_NS_RECORD_NOT_AA_TCP

9.378.1. Severity

9.378.2. Description

Zonemaster describes this error as follows:

Nameserver {ns} does not give an authoritative response on an NS query over TCP.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.378.3. Test cases

This error may be produced by the following test cases:

9.379. ZM_CN02_SOA_RECORD_NOT_AA_TCP

9.379.1. Severity

9.379.2. Description

Zonemaster describes this error as follows:

Nameserver {ns} does not give an authoritative response on an SOA query over TCP.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.379.3. Test cases

This error may be produced by the following test cases:

9.380. ZM_CN02_UNEXPECTED_RCODE_NS_QUERY_TCP

9.380.1. Severity

9.380.2. Description

Zonemaster describes this error as follows:

Nameserver {ns} responds with an unexpected RCODE ({rcode}) on an NS query over TCP.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.380.3. Test cases

This error may be produced by the following test cases:

9.381. ZM_CN02_UNEXPECTED_RCODE_SOA_QUERY_TCP

9.381.1. Severity

9.381.2. Description

Zonemaster describes this error as follows:

Nameserver {ns} responds with an unexpected RCODE ({rcode}) on an SOA query over TCP.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.381.3. Test cases

This error may be produced by the following test cases:

9.382. ZM_CN02_WRONG_NS_RECORD_TCP

9.382.1. Severity

9.382.2. Description

Zonemaster describes this error as follows:

Nameserver {ns} responds with a wrong owner name ({domain_found} instead of {domain_expected}) on NS queries over TCP.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.382.3. Test cases

This error may be produced by the following test cases:

9.383. ZM_CN02_WRONG_SOA_RECORD_TCP

9.383.1. Severity

9.383.2. Description

Zonemaster describes this error as follows:

Nameserver {ns} responds with a wrong owner name ({domain_found} instead of {domain_expected}) on SOA queries over TCP.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.383.3. Test cases

This error may be produced by the following test cases:

9.384. ZM_DEL_NS_SAME_IP

9.384.1. Severity

9.384.2. Description

Zonemaster describes this error as follows:

IP {ns_ip} in parent refers to multiple nameservers ({nsname_list}).

For more information about this error, please refer to the documentation for the test case this error comes from.

9.384.3. Test cases

This error may be produced by the following test cases:

9.385. ZM_DIFFERENT_SOURCE_IP

9.385.1. Severity

9.385.2. Description

Zonemaster describes this error as follows:

Nameserver {ns} replies on a SOA query with a different source address ({source}).

For more information about this error, please refer to the documentation for the test case this error comes from.

9.385.3. Test cases

This error may be produced by the following test cases:

9.386. ZM_DNSKEY_SMALLER_THAN_REC

9.386.1. Severity

9.386.2. Description

Zonemaster describes this error as follows:

DNSKEY with tag {keytag} and using algorithm {algo_num} ({algo_descr}) has a size ({keysize}) smaller than the recommended one ({keysizerec}).

For more information about this error, please refer to the documentation for the test case this error comes from.

9.386.3. Test cases

This error may be produced by the following test cases:

9.387. ZM_DNSKEY_TOO_LARGE_FOR_ALGO

9.387.1. Severity

9.387.2. Description

Zonemaster describes this error as follows:

DNSKEY with tag {keytag} and using algorithm {algo_num} ({algo_descr}) has a size ({keysize}) larger than the maximum one ({keysizemax}).

For more information about this error, please refer to the documentation for the test case this error comes from.

9.387.3. Test cases

This error may be produced by the following test cases:

9.388. ZM_DNSKEY_TOO_SMALL_FOR_ALGO

9.388.1. Severity

9.388.2. Description

Zonemaster describes this error as follows:

DNSKEY with tag {keytag} and using algorithm {algo_num} ({algo_descr}) has a size ({keysize}) smaller than the minimum one ({keysizemin}).

For more information about this error, please refer to the documentation for the test case this error comes from.

9.388.3. Test cases

This error may be produced by the following test cases:

9.389. ZM_DS01_DS_ALGO_2_MISSING

9.389.1. Severity

9.389.2. Description

Zonemaster describes this error as follows:

No DS record created by digest algorithm 2 (SHA-256) is present for zone {domain}.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.389.3. Test cases

This error may be produced by the following test cases:

9.390. ZM_DS01_DS_ALGO_DEPRECATED

9.390.1. Severity

9.390.2. Description

Zonemaster describes this error as follows:

DS record for zone {domain} with keytag {keytag} was created by digest algorithm {ds_algo_num} ({ds_algo_mnemo}) which is deprecated. Fetched from the nameservers with IP addresses “{ns_ip_list}”.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.390.3. Test cases

This error may be produced by the following test cases:

9.391. ZM_DS01_DS_ALGO_NOT_DS

9.391.1. Severity

9.391.2. Description

Zonemaster describes this error as follows:

DS record for zone {domain} with keytag {keytag} was created by digest algorithm {ds_algo_num} ({ds_algo_mnemo}) which is not meant for DS. Fetched from the nameservers with IP addresses “{ns_ip_list}”.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.391.3. Test cases

This error may be produced by the following test cases:

9.392. ZM_DS01_DS_ALGO_RESERVED

9.392.1. Severity

9.392.2. Description

Zonemaster describes this error as follows:

DS record for zone {domain} with keytag {keytag} was created with an unassigned digest algorithm (algorithm number {ds_algo_num}). Fetched from the nameservers with IP addresses “{ns_ip_list}”.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.392.3. Test cases

This error may be produced by the following test cases:

9.393. ZM_DS02_DNSKEY_NOT_FOR_ZONE_SIGNING

9.393.1. Severity

9.393.2. Description

Zonemaster describes this error as follows:

Flags field of DNSKEY record with tag {keytag} has not ZONE bit set although DS with same tag is present in parent. Fetched from the nameservers with IP addresses “{ns_ip_list}”.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.393.3. Test cases

This error may be produced by the following test cases:

9.394. ZM_DS02_DNSKEY_NOT_SEP

9.394.1. Severity

9.394.2. Description

Zonemaster describes this error as follows:

Flags field of DNSKEY record with tag {keytag} has not SEP bit set although DS with same tag is present in parent. Fetched from the nameservers with IP addresses “{ns_ip_list}”.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.394.3. Test cases

This error may be produced by the following test cases:

9.395. ZM_DS02_DNSKEY_NOT_SIGNED_BY_ANY_DS

9.395.1. Severity

9.395.2. Description

Zonemaster describes this error as follows:

The DNSKEY RRset has not been signed by any DNSKEY matched by a DS record. Fetched from the nameservers with IP addresses “{ns_ip_list}”.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.395.3. Test cases

This error may be produced by the following test cases:

9.396. ZM_DS02_NO_DNSKEY_FOR_DS

9.396.1. Severity

9.396.2. Description

Zonemaster describes this error as follows:

The DNSKEY record with tag {keytag} that the DS refers to does not exist in the DNSKEY RRset. Fetched from the nameservers with IP “{ns_ip_list}”.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.396.3. Test cases

This error may be produced by the following test cases:

9.397. ZM_DS02_NO_MATCHING_DNSKEY_RRSIG

9.397.1. Severity

9.397.2. Description

Zonemaster describes this error as follows:

The DNSKEY RRset is not signed by the DNSKEY with tag {keytag} that the DS record refers to. Fetched from the nameservers with IP “{ns_ip_list}”.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.397.3. Test cases

This error may be produced by the following test cases:

9.398. ZM_DS02_NO_MATCH_DS_DNSKEY

9.398.1. Severity

9.398.2. Description

Zonemaster describes this error as follows:

The DS record does not match the DNSKEY with tag {keytag} by algorithm or digest. Fetched from the nameservers with IP “{ns_ip_list}”.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.398.3. Test cases

This error may be produced by the following test cases:

9.399. ZM_DS02_NO_VALID_DNSKEY_FOR_ANY_DS

9.399.1. Severity

9.399.2. Description

Zonemaster describes this error as follows:

There is no valid DNSKEY matched by any of the DS records. Fetched from the nameservers with IP addresses “{ns_ip_list}”.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.399.3. Test cases

This error may be produced by the following test cases:

9.400. ZM_DS02_RRSIG_NOT_VALID_BY_DNSKEY

9.400.1. Severity

9.400.2. Description

Zonemaster describes this error as follows:

The DNSKEY RRset is signed with an RRSIG with tag {keytag} which cannot be validated by the matching DNSKEY. Fetched from the nameservers with IP addresses “{ns_ip_list}”.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.400.3. Test cases

This error may be produced by the following test cases:

9.401. ZM_DS08_DNSKEY_RRSIG_EXPIRED

9.401.1. Severity

9.401.2. Description

Zonemaster describes this error as follows:

RRSIG with keytag {keytag} and covering type DNSKEY has already expired. Fetched from the nameservers with IP addresses “{ns_ip_list}”.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.401.3. Test cases

This error may be produced by the following test cases:

9.402. ZM_DS08_DNSKEY_RRSIG_NOT_YET_VALID

9.402.1. Severity

9.402.2. Description

Zonemaster describes this error as follows:

RRSIG with keytag {keytag} and covering type DNSKEY has inception date in the future. Fetched from the nameservers with IP addresses “{ns_ip_list}”.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.402.3. Test cases

This error may be produced by the following test cases:

9.403. ZM_DS08_MISSING_RRSIG_IN_RESPONSE

9.403.1. Severity

9.403.2. Description

Zonemaster describes this error as follows:

The DNSKEY RRset is not signed, which is against expectation. Fetched from the nameservers with IP addresses “{ns_ip_list}”.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.403.3. Test cases

This error may be produced by the following test cases:

9.404. ZM_DS08_NO_MATCHING_DNSKEY

9.404.1. Severity

9.404.2. Description

Zonemaster describes this error as follows:

The DNSKEY RRset is signed with an RRSIG with tag {keytag} which does not match any DNSKEY record. Fetched from the nameservers with IP addresses “{ns_ip_list}”.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.404.3. Test cases

This error may be produced by the following test cases:

9.405. ZM_DS08_RRSIG_NOT_VALID_BY_DNSKEY

9.405.1. Severity

9.405.2. Description

Zonemaster describes this error as follows:

The DNSKEY RRset is signed with an RRSIG with tag {keytag} which cannot be validated by the matching DNSKEY. Fetched from the nameservers with IP addresses “{ns_ip_list}”.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.405.3. Test cases

This error may be produced by the following test cases:

9.406. ZM_DS09_MISSING_RRSIG_IN_RESPONSE

9.406.1. Severity

9.406.2. Description

Zonemaster describes this error as follows:

The SOA RRset is not signed, which is against expectation. Fetched from the nameservers with IP addresses “{ns_ip_list}”.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.406.3. Test cases

This error may be produced by the following test cases:

9.407. ZM_DS09_NO_MATCHING_DNSKEY

9.407.1. Severity

9.407.2. Description

Zonemaster describes this error as follows:

The SOA RRset is signed with an RRSIG with tag {keytag} which does not match any DNSKEY record. Fetched from the nameservers with IP addresses “{ns_ip_list}”.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.407.3. Test cases

This error may be produced by the following test cases:

9.408. ZM_DS09_RRSIG_NOT_VALID_BY_DNSKEY

9.408.1. Severity

9.408.2. Description

Zonemaster describes this error as follows:

The SOA RRset is signed with an RRSIG with tag {keytag} which cannot be validated by the matching DNSKEY. Fetched from the nameservers with IP addresses “{ns_ip_list}”.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.408.3. Test cases

This error may be produced by the following test cases:

9.409. ZM_DS09_SOA_RRSIG_EXPIRED

9.409.1. Severity

9.409.2. Description

Zonemaster describes this error as follows:

RRSIG with keytag {keytag} and covering type SOA has already expired. Fetched from the nameservers with IP addresses “{ns_ip_list}”.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.409.3. Test cases

This error may be produced by the following test cases:

9.410. ZM_DS09_SOA_RRSIG_NOT_YET_VALID

9.410.1. Severity

9.410.2. Description

Zonemaster describes this error as follows:

RRSIG with keytag {keytag} and covering type SOA has inception date in the future. Fetched from the nameservers with IP addresses “{ns_ip_list}”.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.410.3. Test cases

This error may be produced by the following test cases:

9.411. ZM_DS10_INCONSISTENT_NSEC_NSEC3

9.411.1. Severity

9.411.2. Description

Zonemaster describes this error as follows:

The zone is inconsistent on NSEC and NSEC3. NSEC is fetched from nameservers with IP addresses “{ns_ip_list_nsec}”. NSEC3 is fetched from nameservers with IP addresses “{ns_ip_list_nsec3}”.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.411.3. Test cases

This error may be produced by the following test cases:

9.412. ZM_DS10_MISSING_NSEC_NSEC3

9.412.1. Severity

9.412.2. Description

Zonemaster describes this error as follows:

NSEC or NSEC3 is expected but is missing. Fetched from the nameservers with IP addresses “{ns_ip_list}”.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.412.3. Test cases

This error may be produced by the following test cases:

9.413. ZM_DS10_MIXED_NSEC_NSEC3

9.413.1. Severity

9.413.2. Description

Zonemaster describes this error as follows:

Unexpectedly both NSEC and NSEC3 are reported. Fetched from the nameservers with IP addresses “{ns_ip_list}”.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.413.3. Test cases

This error may be produced by the following test cases:

9.414. ZM_DS10_NAME_NOT_COVERED_BY_NSEC

9.414.1. Severity

9.414.2. Description

Zonemaster describes this error as follows:

A non-existent name is not correctly covered by the NSEC records. Fetched from the nameservers with IP addresses “{ns_ip_list}”.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.414.3. Test cases

This error may be produced by the following test cases:

9.415. ZM_DS10_NAME_NOT_COVERED_BY_NSEC3

9.415.1. Severity

9.415.2. Description

Zonemaster describes this error as follows:

A non-existent name is not correctly covered by the NSEC3 records. Fetched from the nameservers with IP addresses “{ns_ip_list}”.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.415.3. Test cases

This error may be produced by the following test cases:

9.416. ZM_DS10_NON_EXISTENT_RESPONSE_ERROR

9.416.1. Severity

9.416.2. Description

Zonemaster describes this error as follows:

No response or error in response on an expected non-existent name. Fetched from the nameservers with IP addresses “{ns_ip_list}”.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.416.3. Test cases

This error may be produced by the following test cases:

9.417. ZM_DS10_NSEC3_MISSING_SIGNATURE

9.417.1. Severity

9.417.2. Description

Zonemaster describes this error as follows:

Missing signatures (RRSIG) for the NSEC3 record or records. Fetched from the nameservers with IP addresses “{ns_ip_list}”.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.417.3. Test cases

This error may be produced by the following test cases:

9.418. ZM_DS10_NSEC3_RRSIG_VERIFY_ERROR

9.418.1. Severity

9.418.2. Description

Zonemaster describes this error as follows:

The signatures (RRSIG) for the NSEC3 record or records cannot be verified. Fetched from the nameservers with IP addresses “{ns_ip_list}”.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.418.3. Test cases

This error may be produced by the following test cases:

9.419. ZM_DS10_NSEC_MISSING_SIGNATURE

9.419.1. Severity

9.419.2. Description

Zonemaster describes this error as follows:

Missing signatures (RRSIG) for the NSEC record or records. Fetched from the nameservers with IP addresses “{ns_ip_list}”.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.419.3. Test cases

This error may be produced by the following test cases:

9.420. ZM_DS10_NSEC_RRSIG_VERIFY_ERROR

9.420.1. Severity

9.420.2. Description

Zonemaster describes this error as follows:

The signatures (RRSIG) for the NSEC record or records cannot be verified. Fetched from the nameservers with IP addresses “{ns_ip_list}”.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.420.3. Test cases

This error may be produced by the following test cases:

9.421. ZM_DS10_UNSIGNED_ANSWER

9.421.1. Severity

9.421.2. Description

Zonemaster describes this error as follows:

The name “{domain}” of RR type “{rrtype}” in the answer section of the response is not signed by any RRSIG. Fetched from the nameservers with IP addresses “{ns_ip_list}”.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.421.3. Test cases

This error may be produced by the following test cases:

9.422. ZM_DS13_ALGO_NOT_SIGNED_DNSKEY

9.422.1. Severity

9.422.2. Description

Zonemaster describes this error as follows:

The DNSKEY RRset is not signed by algorithm {algo_num} ({algo_mnemo}) present in the DNSKEY RRset. Fetched from the nameservers with IP addresses “{ns_ip_list}”.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.422.3. Test cases

This error may be produced by the following test cases:

9.423. ZM_DS13_ALGO_NOT_SIGNED_NS

9.423.1. Severity

9.423.2. Description

Zonemaster describes this error as follows:

The NS RRset is not signed by algorithm {algo_num} ({algo_mnemo}) present in the DNSKEY RRset. Fetched from the nameservers with IP addresses “{ns_ip_list}”.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.423.3. Test cases

This error may be produced by the following test cases:

9.424. ZM_DS13_ALGO_NOT_SIGNED_SOA

9.424.1. Severity

9.424.2. Description

Zonemaster describes this error as follows:

The SOA RRset is not signed by algorithm {algo_num} ({algo_mnemo}) present in the DNSKEY RRset. Fetched from the nameservers with IP addresses “{ns_ip_list}”.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.424.3. Test cases

This error may be produced by the following test cases:

9.425. ZM_DURATION_LONG

9.425.1. Severity

9.425.2. Description

Zonemaster describes this error as follows:

RRSIG with keytag {keytag} and covering type(s) {types} has a duration of {duration} seconds, which is too long.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.425.3. Test cases

This error may be produced by the following test cases:

9.426. ZM_EDNS_RESPONSE_WITHOUT_EDNS

9.426.1. Severity

9.426.2. Description

Zonemaster describes this error as follows:

Response without EDNS from {ns} on query with EDNS0 asking for {domain}.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.426.3. Test cases

This error may be produced by the following test cases:

9.427. ZM_EDNS_VERSION_ERROR

9.427.1. Severity

9.427.2. Description

Zonemaster describes this error as follows:

Incorrect version of EDNS (expected 0) in response from {ns} on query with EDNS (version 0) asking for {domain}.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.427.3. Test cases

This error may be produced by the following test cases:

9.428. ZM_EMPTY_ASN_SET

9.428.1. Severity

9.428.2. Description

Zonemaster describes this error as follows:

AS database returned no informations for IP address {ns_ip}.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.428.3. Test cases

This error may be produced by the following test cases:

9.429. ZM_ERROR_ASN_DATABASE

9.429.1. Severity

9.429.2. Description

Zonemaster describes this error as follows:

ASN Database error. No data to analyze for {ns_ip}.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.429.3. Test cases

This error may be produced by the following test cases:

9.430. ZM_EXTRA_ADDRESS_CHILD

9.430.1. Severity

9.430.2. Description

Zonemaster describes this error as follows:

Child has extra nameserver IP address(es) not listed at parent ({ns_ip_list}).

For more information about this error, please refer to the documentation for the test case this error comes from.

9.430.3. Test cases

This error may be produced by the following test cases:

9.431. ZM_EXTRA_NAME_PARENT

9.431.1. Severity

9.431.2. Description

Zonemaster describes this error as follows:

Parent has nameserver(s) not listed at the child ({extra}).

For more information about this error, please refer to the documentation for the test case this error comes from.

9.431.3. Test cases

This error may be produced by the following test cases:

9.432. ZM_EXTRA_PROCESSING_BROKEN

9.432.1. Severity

9.432.2. Description

Zonemaster describes this error as follows:

Server at {server} sent {keys} DNSKEY records, and {sigs} RRSIG records.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.432.3. Test cases

This error may be produced by the following test cases:

9.433. ZM_IN_BAILIWICK_ADDR_MISMATCH

9.433.1. Severity

9.433.2. Description

Zonemaster describes this error as follows:

In-bailiwick name server listed at parent has a mismatch between glue data at parent ({parent_addresses}) and any equivalent address record in child zone ({zone_addresses}).

For more information about this error, please refer to the documentation for the test case this error comes from.

9.433.3. Test cases

This error may be produced by the following test cases:

9.434. ZM_IPV4_ONE_ASN

9.434.1. Severity

9.434.2. Description

Zonemaster describes this error as follows:

All authoritative nameservers have their IPv4 addresses in the same AS ({asn}).

For more information about this error, please refer to the documentation for the test case this error comes from.

9.434.3. Test cases

This error may be produced by the following test cases:

9.435. ZM_IPV6_ONE_ASN

9.435.1. Severity

9.435.2. Description

Zonemaster describes this error as follows:

All authoritative nameservers have their IPv6 addresses in the same AS ({asn}).

For more information about this error, please refer to the documentation for the test case this error comes from.

9.435.3. Test cases

This error may be produced by the following test cases:

9.436. ZM_IS_A_RECURSOR

9.436.1. Severity

9.436.2. Description

Zonemaster describes this error as follows:

Nameserver {ns} is a recursor.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.436.3. Test cases

This error may be produced by the following test cases:

9.437. ZM_IS_NOT_AUTHORITATIVE

9.437.1. Severity

9.437.2. Description

Zonemaster describes this error as follows:

Nameserver {ns} response is not authoritative on {proto} port 53.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.437.3. Test cases

This error may be produced by the following test cases:

9.438. ZM_MISSING_OPT_IN_TRUNCATED

9.438.1. Severity

9.438.2. Description

Zonemaster describes this error as follows:

Nameserver {ns} replies on an EDNS query with a truncated response without EDNS.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.438.3. Test cases

This error may be produced by the following test cases:

9.439. ZM_MNAME_DISCOURAGED_DOUBLE_DASH

9.439.1. Severity

9.439.2. Description

Zonemaster describes this error as follows:

SOA MNAME ({domain}) has a label ({label}) with a double hyphen (‘–’) in position 3 and 4 (with a prefix which is not ‘xn–’).

For more information about this error, please refer to the documentation for the test case this error comes from.

9.439.3. Test cases

This error may be produced by the following test cases:

9.440. ZM_MNAME_HAS_NO_ADDRESS

9.440.1. Severity

9.440.2. Description

Zonemaster describes this error as follows:

No IP address found for SOA ‘mname’ nameserver ({mname}).

For more information about this error, please refer to the documentation for the test case this error comes from.

9.440.3. Test cases

This error may be produced by the following test cases:

9.441. ZM_MNAME_NON_ALLOWED_CHARS

9.441.1. Severity

9.441.2. Description

Zonemaster describes this error as follows:

Found illegal characters in SOA MNAME ({domain}).

For more information about this error, please refer to the documentation for the test case this error comes from.

9.441.3. Test cases

This error may be produced by the following test cases:

9.442. ZM_MNAME_NUMERIC_TLD

9.442.1. Severity

9.442.2. Description

Zonemaster describes this error as follows:

SOA MNAME ({domain}) within a ‘numeric only’ TLD ({tld}).

For more information about this error, please refer to the documentation for the test case this error comes from.

9.442.3. Test cases

This error may be produced by the following test cases:

9.443. ZM_MULTIPLE_NS_SET

9.443.1. Severity

9.443.2. Description

Zonemaster describes this error as follows:

Found {count} NS set(s).

For more information about this error, please refer to the documentation for the test case this error comes from.

9.443.3. Test cases

This error may be produced by the following test cases:

9.444. ZM_MULTIPLE_SOA

9.444.1. Severity

9.444.2. Description

Zonemaster describes this error as follows:

Nameserver {ns} responds with multiple ({count}) SOA records on SOA queries.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.444.3. Test cases

This error may be produced by the following test cases:

9.445. ZM_MULTIPLE_SOA_MNAMES

9.445.1. Severity

9.445.2. Description

Zonemaster describes this error as follows:

Saw {count} SOA mname.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.445.3. Test cases

This error may be produced by the following test cases:

9.446. ZM_MULTIPLE_SOA_RNAMES

9.446.1. Severity

9.446.2. Description

Zonemaster describes this error as follows:

Found {count} SOA rname(s).

For more information about this error, please refer to the documentation for the test case this error comes from.

9.446.3. Test cases

This error may be produced by the following test cases:

9.447. ZM_MULTIPLE_SOA_TIME_PARAMETER_SET

9.447.1. Severity

9.447.2. Description

Zonemaster describes this error as follows:

Found {count} SOA time parameter set(s).

For more information about this error, please refer to the documentation for the test case this error comes from.

9.447.3. Test cases

This error may be produced by the following test cases:

9.448. ZM_N10_EDNS_RESPONSE_ERROR

9.448.1. Severity

9.448.2. Description

Zonemaster describes this error as follows:

Expected RCODE but received erroneous response to an EDNS version 1 query. Fetched from the nameservers with IP addresses {ns_ip_list}

For more information about this error, please refer to the documentation for the test case this error comes from.

9.448.3. Test cases

This error may be produced by the following test cases:

9.449. ZM_N10_NO_RESPONSE_EDNS1_QUERY

9.449.1. Severity

9.449.2. Description

Zonemaster describes this error as follows:

No response to an EDNS version 1 query. Fetched from the nameservers with IP addresses {ns_ip_list}

For more information about this error, please refer to the documentation for the test case this error comes from.

9.449.3. Test cases

This error may be produced by the following test cases:

9.450. ZM_N10_UNEXPECTED_RCODE

9.450.1. Severity

9.450.2. Description

Zonemaster describes this error as follows:

Erroneous RCODE (“{rcode}”) in response to an EDNS version 1 query. Fetched from the nameservers with IP addresses {ns_ip_list}

For more information about this error, please refer to the documentation for the test case this error comes from.

9.450.3. Test cases

This error may be produced by the following test cases:

9.451. ZM_N11_NO_EDNS

9.451.1. Severity

9.451.2. Description

Zonemaster describes this error as follows:

The DNS response, on query with unknown EDNS option-code, does not contain any EDNS from name servers “{ns_ip_list}”.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.451.3. Test cases

This error may be produced by the following test cases:

9.452. ZM_N11_NO_RESPONSE

9.452.1. Severity

9.452.2. Description

Zonemaster describes this error as follows:

There is no response on query with unknown EDNS option-code from name servers “{ns_ip_list}”.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.452.3. Test cases

This error may be produced by the following test cases:

9.453. ZM_N11_RETURNS_UNKNOWN_OPTION_CODE

9.453.1. Severity

9.453.2. Description

Zonemaster describes this error as follows:

The DNS response contains an unknown EDNS option-code. Returned from name servers “{ns_ip_list}”.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.453.3. Test cases

This error may be produced by the following test cases:

9.454. ZM_N11_UNEXPECTED_ANSWER_SECTION

9.454.1. Severity

9.454.2. Description

Zonemaster describes this error as follows:

The DNS response, on query with unknown EDNS option-code, does not contain the expected SOA record in the answer section from name servers “{ns_ip_list}”.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.454.3. Test cases

This error may be produced by the following test cases:

9.455. ZM_N11_UNEXPECTED_RCODE

9.455.1. Severity

9.455.2. Description

Zonemaster describes this error as follows:

The DNS response, on query with unknown EDNS option-code, has unexpected RCODE name “{rcode}” from name servers “{ns_ip_list}”.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.455.3. Test cases

This error may be produced by the following test cases:

9.456. ZM_N11_UNSET_AA

9.456.1. Severity

9.456.2. Description

Zonemaster describes this error as follows:

The DNS response, on query with unknown EDNS option-code, is unexpectedly not authoritative from name servers “{ns_ip_list}”.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.456.3. Test cases

This error may be produced by the following test cases:

9.457. ZM_NAMESERVER_IP_PRIVATE_NETWORK

9.457.1. Severity

9.457.2. Description

Zonemaster describes this error as follows:

Nameserver {nsname} has an IP address ({ns_ip}) with prefix {prefix} referenced in {reference} as a ‘{name}’.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.457.3. Test cases

This error may be produced by the following test cases:

9.458. ZM_NAMESERVER_IP_WITHOUT_REVERSE

9.458.1. Severity

9.458.2. Description

Zonemaster describes this error as follows:

Nameserver {nsname} has an IP address ({ns_ip}) without PTR configured.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.458.3. Test cases

This error may be produced by the following test cases:

9.459. ZM_NOT_ENOUGH_IPV4_NS_CHILD

9.459.1. Severity

9.459.2. Description

Zonemaster describes this error as follows:

Child does not list enough ({count}) nameservers ({nsname_list}) that resolve to IPv4 addresses ({ns_ip_list}). Lower limit set to {minimum}.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.459.3. Test cases

This error may be produced by the following test cases:

9.460. ZM_NOT_ENOUGH_IPV4_NS_DEL

9.460.1. Severity

9.460.2. Description

Zonemaster describes this error as follows:

Delegation does not list enough ({count}) nameservers ({nsname_list}) that resolve to IPv4 addresses ({ns_ip_list}). Lower limit set to {minimum}.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.460.3. Test cases

This error may be produced by the following test cases:

9.461. ZM_NOT_ENOUGH_IPV6_NS_CHILD

9.461.1. Severity

9.461.2. Description

Zonemaster describes this error as follows:

Child does not list enough ({count}) nameservers ({nsname_list}) that resolve to IPv6 addresses ({ns_ip_list}). Lower limit set to {minimum}.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.461.3. Test cases

This error may be produced by the following test cases:

9.462. ZM_NOT_ENOUGH_IPV6_NS_DEL

9.462.1. Severity

9.462.2. Description

Zonemaster describes this error as follows:

Delegation does not list enough ({count}) nameservers ({nsname_list}) that resolve to IPv6 addresses ({ns_ip_list}). Lower limit set to {minimum}.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.462.3. Test cases

This error may be produced by the following test cases:

9.463. ZM_NOT_ENOUGH_NS_CHILD

9.463.1. Severity

9.463.2. Description

Zonemaster describes this error as follows:

Child does not list enough ({count}) nameservers ({nsname_list}). Lower limit set to {minimum}.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.463.3. Test cases

This error may be produced by the following test cases:

9.464. ZM_NOT_ENOUGH_NS_DEL

9.464.1. Severity

9.464.2. Description

Zonemaster describes this error as follows:

Parent does not list enough ({count}) nameservers ({nsname_list}). Lower limit set to {minimum}.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.464.3. Test cases

This error may be produced by the following test cases:

9.465. ZM_NO_DNSKEY

9.465.1. Severity

9.465.2. Description

Zonemaster describes this error as follows:

No DNSKEYs were returned.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.465.3. Test cases

This error may be produced by the following test cases:

9.466. ZM_NO_EDNS_SUPPORT

9.466.1. Severity

9.466.2. Description

Zonemaster describes this error as follows:

Nameserver {ns} does not support EDNS0 (replies with FORMERR).

For more information about this error, please refer to the documentation for the test case this error comes from.

9.466.3. Test cases

This error may be produced by the following test cases:

9.467. ZM_NO_IPV4_NS_CHILD

9.467.1. Severity

9.467.2. Description

Zonemaster describes this error as follows:

Child lists no nameserver that resolves to an IPv4 address. If any were present, the minimum allowed would be {minimum}.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.467.3. Test cases

This error may be produced by the following test cases:

9.468. ZM_NO_IPV4_NS_DEL

9.468.1. Severity

9.468.2. Description

Zonemaster describes this error as follows:

Delegation lists no nameserver that resolves to an IPv4 address. If any were present, the minimum allowed would be {minimum}.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.468.3. Test cases

This error may be produced by the following test cases:

9.469. ZM_NO_IPV6_NS_CHILD

9.469.1. Severity

9.469.2. Description

Zonemaster describes this error as follows:

Child lists no nameserver that resolves to an IPv6 address. If any were present, the minimum allowed would be {minimum}.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.469.3. Test cases

This error may be produced by the following test cases:

9.470. ZM_NO_IPV6_NS_DEL

9.470.1. Severity

9.470.2. Description

Zonemaster describes this error as follows:

Delegation lists no nameserver that resolves to an IPv6 address. If any were present, the minimum allowed would be {minimum}.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.470.3. Test cases

This error may be produced by the following test cases:

9.471. ZM_NO_RESOLUTION

9.471.1. Severity

9.471.2. Description

Zonemaster describes this error as follows:

No nameserver was successfully resolved to an IP address.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.471.3. Test cases

This error may be produced by the following test cases:

9.472. ZM_NO_RESPONSE

9.472.1. Severity

9.472.2. Description

Zonemaster describes this error as follows:

Nameserver {ns} did not respond.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.472.3. Test cases

This error may be produced by the following test cases:

9.473. ZM_NO_RESPONSE_DNSKEY

9.473.1. Severity

9.473.2. Description

Zonemaster describes this error as follows:

Nameserver {ns} responded with no DNSKEY record(s).

For more information about this error, please refer to the documentation for the test case this error comes from.

9.473.3. Test cases

This error may be produced by the following test cases:

9.474. ZM_NO_RESPONSE_NS_QUERY

9.474.1. Severity

9.474.2. Description

Zonemaster describes this error as follows:

No response from nameserver {ns} on NS queries.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.474.3. Test cases

This error may be produced by the following test cases:

9.475. ZM_NO_RESPONSE_PTR_QUERY

9.475.1. Severity

9.475.2. Description

Zonemaster describes this error as follows:

No response from nameserver(s) on PTR query ({domain}).

For more information about this error, please refer to the documentation for the test case this error comes from.

9.475.3. Test cases

This error may be produced by the following test cases:

9.476. ZM_NO_RESPONSE_SOA_QUERY

9.476.1. Severity

9.476.2. Description

Zonemaster describes this error as follows:

No response from nameserver(s) on SOA queries.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.476.3. Test cases

This error may be produced by the following test cases:

9.477. ZM_NO_SOA_IN_RESPONSE

9.477.1. Severity

9.477.2. Description

Zonemaster describes this error as follows:

Response from nameserver {ns} on SOA queries does not contain SOA record.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.477.3. Test cases

This error may be produced by the following test cases:

9.478. ZM_NS_ERROR

9.478.1. Severity

9.478.2. Description

Zonemaster describes this error as follows:

Erroneous response from nameserver {ns}.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.478.3. Test cases

This error may be produced by the following test cases:

9.479. ZM_NS_IS_CNAME

9.479.1. Severity

9.479.2. Description

Zonemaster describes this error as follows:

Nameserver {nsname} RR points to CNAME.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.479.3. Test cases

This error may be produced by the following test cases:

9.480. ZM_OUT_OF_BAILIWICK_ADDR_MISMATCH

9.480.1. Severity

9.480.2. Description

Zonemaster describes this error as follows:

Out-of-bailiwick name server listed at parent with glue record has a mismatch between the glue at the parent ({parent_addresses}) and any equivalent address record found in authoritative zone ({zone_addresses}).

For more information about this error, please refer to the documentation for the test case this error comes from.

9.480.3. Test cases

This error may be produced by the following test cases:

9.481. ZM_QNAME_CASE_INSENSITIVE

9.481.1. Severity

9.481.2. Description

Zonemaster describes this error as follows:

Nameserver {ns} does not preserve original case of the queried name ({domain}).

For more information about this error, please refer to the documentation for the test case this error comes from.

9.481.3. Test cases

This error may be produced by the following test cases:

9.482. ZM_REFERRAL_SIZE_TOO_LARGE

9.482.1. Severity

9.482.2. Description

Zonemaster describes this error as follows:

The smallest possible legal referral packet is larger than 512 octets (it is {size}).

For more information about this error, please refer to the documentation for the test case this error comes from.

9.482.3. Test cases

This error may be produced by the following test cases:

9.483. ZM_REMAINING_LONG

9.483.1. Severity

9.483.2. Description

Zonemaster describes this error as follows:

RRSIG with keytag {keytag} and covering type(s) {types} has a remaining validity of {duration} seconds, which is too long.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.483.3. Test cases

This error may be produced by the following test cases:

9.484. ZM_REMAINING_SHORT

9.484.1. Severity

9.484.2. Description

Zonemaster describes this error as follows:

RRSIG with keytag {keytag} and covering type(s) {types} has a remaining validity of {duration} seconds, which is too short.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.484.3. Test cases

This error may be produced by the following test cases:

9.485. ZM_RNAME_MAIL_DOMAIN_INVALID

9.485.1. Severity

9.485.2. Description

Zonemaster describes this error as follows:

The SOA RNAME mail domain ({domain}) cannot be resolved to a mail server with an IP address.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.485.3. Test cases

This error may be produced by the following test cases:

9.486. ZM_RNAME_MAIL_DOMAIN_LOCALHOST

9.486.1. Severity

9.486.2. Description

Zonemaster describes this error as follows:

The SOA RNAME mail domain ({domain}) resolved to a mail server with localhost ({localhost}) IP address.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.486.3. Test cases

This error may be produced by the following test cases:

9.487. ZM_RNAME_MAIL_ILLEGAL_CNAME

9.487.1. Severity

9.487.2. Description

Zonemaster describes this error as follows:

The SOA RNAME mail domain ({domain}) refers to an address which is an alias (CNAME).

For more information about this error, please refer to the documentation for the test case this error comes from.

9.487.3. Test cases

This error may be produced by the following test cases:

9.488. ZM_RNAME_MISUSED_AT_SIGN

9.488.1. Severity

9.488.2. Description

Zonemaster describes this error as follows:

Misused ‘@’ character found in SOA RNAME field ({rname}).

For more information about this error, please refer to the documentation for the test case this error comes from.

9.488.3. Test cases

This error may be produced by the following test cases:

9.489. ZM_RNAME_RFC822_INVALID

9.489.1. Severity

9.489.2. Description

Zonemaster describes this error as follows:

Illegal character(s) found in SOA RNAME field ({rname}).

For more information about this error, please refer to the documentation for the test case this error comes from.

9.489.3. Test cases

This error may be produced by the following test cases:

9.490. ZM_RRSIG_EXPIRED

9.490.1. Severity

9.490.2. Description

Zonemaster describes this error as follows:

RRSIG with keytag {keytag} and covering type(s) {types} has already expired (expiration is: {expiration}).

For more information about this error, please refer to the documentation for the test case this error comes from.

9.490.3. Test cases

This error may be produced by the following test cases:

9.491. ZM_SAME_IP_ADDRESS

9.491.1. Severity

9.491.2. Description

Zonemaster describes this error as follows:

IP {ns_ip} refers to multiple nameservers ({nsname_list}).

For more information about this error, please refer to the documentation for the test case this error comes from.

9.491.3. Test cases

This error may be produced by the following test cases:

9.492. ZM_TOO_MANY_ITERATIONS

9.492.1. Severity

9.492.2. Description

Zonemaster describes this error as follows:

The number of NSEC3 iterations is {count}, which is too high for key length {keylength}.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.492.3. Test cases

This error may be produced by the following test cases:

9.493. ZM_TOTAL_NAME_MISMATCH

9.493.1. Severity

9.493.2. Description

Zonemaster describes this error as follows:

None of the nameservers listed at the parent are listed at the child.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.493.3. Test cases

This error may be produced by the following test cases:

9.494. ZM_UNEXPECTED_RCODE

9.494.1. Severity

9.494.2. Description

Zonemaster describes this error as follows:

Nameserver {ns} answered query with an unexpected rcode ({rcode}).

For more information about this error, please refer to the documentation for the test case this error comes from.

9.494.3. Test cases

This error may be produced by the following test cases:

9.495. ZM_WRONG_SOA

9.495.1. Severity

9.495.2. Description

Zonemaster describes this error as follows:

Nameserver {ns} responds with a wrong owner name ({owner} instead of {name}) on SOA queries.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.495.3. Test cases

This error may be produced by the following test cases:

9.496. ZM_Z_FLAGS_NOTCLEAR

9.496.1. Severity

9.496.2. Description

Zonemaster describes this error as follows:

Nameserver {ns} has one or more unknown EDNS Z flag bits set.

For more information about this error, please refer to the documentation for the test case this error comes from.

9.496.3. Test cases

This error may be produced by the following test cases:

10. Data Providers

10.1. epp-07-data

10.1.1. Description

  • Values in {parentheses} are not literal values, they indicate that an appropriate value should be computed.
    • A value of {EMPTY} indicates an empty string.
    • A value of {AUTO} means a pseudo-random value generated by a faker library that is syntactically correct as per the XML schema in RFC 5733.
    • RANDCHARS(n) means n randomly-chosen characters from the set A-Z, a-z, 0-9.
    • & indicates concatenation.
  • An EPP command passes if the code attribute of the <result> element in the response is less than or equal to 1999.
  • If the EPP server implements RFC 9154, then the authInfo field must be empty.
  • Country codes must be taken from the ISO-3166-alpha-2 list.

10.1.2. Data table

id
postalInfoType
name
org
street1
street2
street3
city
sp
pc
cc
voice
email
authInfo
passOrFail
errorCode
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string

Contact ID

Postal Info type attribute

Contact Name

Contact Org

Address line 1

Address line 2

Address line 3

City

State or province

Postal code

Country code

Phone

Email

AuthInfo code

Expected result

Error code if expected result is not produced

{AUTO}
int
{AUTO}
{AUTO}
{AUTO}
{EMPTY}
{EMPTY}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
pass
EPP_CONTACT_CREATE_INFO_RESPONSE_NOT_1000
{EMPTY}
int
{AUTO}
{AUTO}
{AUTO}
{EMPTY}
{EMPTY}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
fail
EPP_CONTACT_CREATE_SERVER_ACCEPTS_INVALID_ID
{RANDCHARS(17)}
int
{AUTO}
{AUTO}
{AUTO}
{EMPTY}
{EMPTY}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
fail
EPP_CONTACT_CREATE_SERVER_ACCEPTS_INVALID_ID
{AUTO}
tni
{AUTO}
{AUTO}
{AUTO}
{EMPTY}
{EMPTY}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
fail
EPP_CONTACT_CREATE_SERVER_ACCEPTS_INVALID_POSTALINFO_TYPE
{AUTO}
{EMPTY}
{AUTO}
{AUTO}
{AUTO}
{EMPTY}
{EMPTY}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
fail
EPP_CONTACT_CREATE_SERVER_ACCEPTS_INVALID_POSTALINFO_TYPE
{AUTO}
int
{EMPTY}
{AUTO}
{AUTO}
{EMPTY}
{EMPTY}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
fail
EPP_CONTACT_CREATE_SERVER_ACCEPTS_EMPTY_NAME
{AUTO}
int
{AUTO}
{RANDCHARS(256)}
{AUTO}
{EMPTY}
{EMPTY}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
fail
EPP_CONTACT_CREATE_SERVER_ACCEPTS_INVALID_ORG
{AUTO}
int
{AUTO}
{AUTO}
{EMPTY}
{EMPTY}
{EMPTY}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
fail
EPP_CONTACT_CREATE_SERVER_ACCEPTS_EMPTY_STREET
{AUTO}
int
{AUTO}
{AUTO}
{AUTO}
{EMPTY}
{EMPTY}
{EMPTY}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
fail
EPP_CONTACT_CREATE_SERVER_ACCEPTS_EMPTY_CITY
{AUTO}
int
{AUTO}
{AUTO}
{AUTO}
{EMPTY}
{EMPTY}
{AUTO}
{AUTO}
{AUTO}
{EMPTY}
{AUTO}
{AUTO}
{AUTO}
fail
EPP_CONTACT_CREATE_SERVER_ACCEPTS_EMPTY_CC
{AUTO}
int
{AUTO}
{AUTO}
{AUTO}
{EMPTY}
{EMPTY}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{EMPTY}
{AUTO}
{AUTO}
fail
EPP_CONTACT_CREATE_SERVER_ACCEPTS_EMPTY_VOICE
{AUTO}
int
{AUTO}
{AUTO}
{AUTO}
{EMPTY}
{EMPTY}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{EMPTY}
{AUTO}
fail
EPP_CONTACT_CREATE_SERVER_ACCEPTS_EMPTY_EMAIL
{AUTO}
int
{RANDCHARS(256)}
{AUTO}
{AUTO}
{EMPTY}
{EMPTY}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
fail
EPP_CONTACT_CREATE_SERVER_ACCEPTS_INVALID_NAME
{AUTO}
int
{AUTO}
{AUTO}
{RANDCHARS(256)}
{EMPTY}
{EMPTY}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
fail
EPP_CONTACT_CREATE_SERVER_ACCEPTS_INVALID_STREET
{AUTO}
int
{AUTO}
{AUTO}
{AUTO}
{EMPTY}
{EMPTY}
{RANDCHARS(256)}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
fail
EPP_CONTACT_CREATE_SERVER_ACCEPTS_INVALID_CITY
{AUTO}
int
{AUTO}
{AUTO}
{AUTO}
{EMPTY}
{EMPTY}
{AUTO}
{AUTO}
{AUTO}
XX
{AUTO}
{AUTO}
{AUTO}
fail
EPP_CONTACT_CREATE_SERVER_ACCEPTS_INVALID_CC
{AUTO}
int
{AUTO}
{AUTO}
{AUTO}
{EMPTY}
{EMPTY}
{AUTO}
{AUTO}
{AUTO}
U
{AUTO}
{AUTO}
{AUTO}
fail
EPP_CONTACT_CREATE_SERVER_ACCEPTS_INVALID_CC
{AUTO}
int
{AUTO}
{AUTO}
{AUTO}
{EMPTY}
{EMPTY}
{AUTO}
{AUTO}
{AUTO}
USA
{AUTO}
{AUTO}
{AUTO}
fail
EPP_CONTACT_CREATE_SERVER_ACCEPTS_INVALID_CC
{AUTO}
int
{AUTO}
{AUTO}
{AUTO}
{EMPTY}
{EMPTY}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
+12345
{AUTO}
{AUTO}
fail
EPP_CONTACT_CREATE_SERVER_ACCEPTS_INVALID_CC
{AUTO}
int
{AUTO}
{AUTO}
{AUTO}
{EMPTY}
{EMPTY}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
+1111.1
{AUTO}
{AUTO}
fail
EPP_CONTACT_CREATE_SERVER_ACCEPTS_INVALID_CC
{AUTO}
int
{AUTO}
{AUTO}
{AUTO}
{EMPTY}
{EMPTY}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
55
{AUTO}
{AUTO}
fail
EPP_CONTACT_CREATE_SERVER_ACCEPTS_INVALID_CC
{AUTO}
int
{AUTO}
{AUTO}
{AUTO}
{EMPTY}
{EMPTY}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
+1.
{AUTO}
{AUTO}
fail
EPP_CONTACT_CREATE_SERVER_ACCEPTS_INVALID_CC
{AUTO}
int
{AUTO}
{AUTO}
{AUTO}
{EMPTY}
{EMPTY}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
+1.123456789012345
{AUTO}
{AUTO}
fail
EPP_CONTACT_CREATE_SERVER_ACCEPTS_INVALID_CC
{AUTO}
int
{AUTO}
{AUTO}
{AUTO}
{EMPTY}
{EMPTY}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
+1.a
{AUTO}
{AUTO}
fail
EPP_CONTACT_CREATE_SERVER_ACCEPTS_INVALID_CC
{AUTO}
int
{AUTO}
{AUTO}
{AUTO}
{EMPTY}
{EMPTY}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
+a.1
{AUTO}
{AUTO}
fail
EPP_CONTACT_CREATE_SERVER_ACCEPTS_INVALID_CC
{AUTO}
int
{AUTO}
{AUTO}
{AUTO}
{EMPTY}
{EMPTY}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
example
{AUTO}
fail
EPP_CONTACT_CREATE_SERVER_ACCEPTS_INVALID_EMAIL
{AUTO}
int
{AUTO}
{AUTO}
{AUTO}
{EMPTY}
{EMPTY}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
example.example
{AUTO}
fail
EPP_CONTACT_CREATE_SERVER_ACCEPTS_INVALID_EMAIL
{AUTO}
int
{AUTO}
{AUTO}
{AUTO}
{EMPTY}
{EMPTY}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
@example.com
{AUTO}
fail
EPP_CONTACT_CREATE_SERVER_ACCEPTS_INVALID_EMAIL
{AUTO}
int
{AUTO}
{AUTO}
{AUTO}
{EMPTY}
{EMPTY}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
@
{AUTO}
fail
EPP_CONTACT_CREATE_SERVER_ACCEPTS_INVALID_EMAIL
{AUTO}
int
{AUTO}
{AUTO}
{AUTO}
{EMPTY}
{EMPTY}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{RANDCHARS(65) & "@example.com"}
{AUTO}
fail
EPP_CONTACT_CREATE_SERVER_ACCEPTS_INVALID_EMAIL

10.1.3. Test cases

This data provider is used by the following test cases:

10.2. idn-06-data

10.2.1. Description

This data provider contains a list of labels that are invalid under the IDNA2008 specifications, but may be valid under IDNA2003.

10.2.2. Data table

label
string

Test label

xn--foo-bar-replace-me!

10.2.3. Test cases

This data provider is used by the following test cases:

11. About this document

This document was automatically generated from the formal specification for the RST service, which is available in YAML and JSON formats. The YAML file is the normative reference, other representations are informational only.