Registry System Testing - Test Specifications

Version 3.1.2024325

Last Updated: 2024-11-20

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

2. Change Log

2.1. Wednesday, November 20, 2024

  1. Added a new test plan called Pre-Delegation Test with SRS Gateway, for TLDs that are launching with an SRS Gateway. This test plan uses the same test suites as the Pre-Delegation Test plan plus the SRS Gateway test suite.

  2. Removed the RDE_POLICY_OBJECT_UNEXPECTED_OBJECTS error from rde-14.

  3. Resolved an ordering issue in epp-16-status-data.

  4. Clarified that there must be entry in the rdap.baseURLs input parameter for each TLD being tested.

2.2. Wednesday, November 13, 2024

  1. Added the idn.testLabelsForOTE resource to the IDN test suite.

2.3. Wednesday, November 6, 2024

  1. Updates to: * srsgw-05 * srsgw-06 * srsgw-07 * srsgw-08 * srsgw-09 * rde-14.

2.4. Wednesday, October 23, 2024

  1. Updated the test procedure for srsgw-13 to be stand-alone. The same change will be made to most of the other test cases in the SRS Gateway test suite; stay tuned for updates.

  2. Standardized the definition of “canonicalization” across srsgw-13, srsgw-14 and srsgw-15.

  3. Added EPP-related error codes to srsgw-13, srsgw-14 and srsgw-15.

  4. Fixed typo in reference to RFC 5890 in dns-zz-idna2008-compliance.

2.5. Wednesday, October 16, 2024

  1. Updated the test procecdure for epp-19 so that the authInfo code is set during an <update> rather than <create>, to account for servers that implement RFC 9154 and reject non-empty authInfo elements during <create> commands. Also added the EPP_TRANSFER_SERVER_REJECTS_SECURE_AUTHINFO error code for when the server rejects an authInfo code that it should accept.

  2. Fix typo in idn-01 that made the description of the rules for variants logically incoherent.

  3. Added RDE_DOMAIN_HAS_MISSING_CONTACT and RDE_DOMAIN_HAS_MISSING_NAMESERVER to rde-07.

  4. Fixed the description of RDE_DOMAIN_HAS_MISSING_REGISTRANT.

  5. Clarified that domain and host names, and domain, host and contact ROIDs must be unique. Added the RDE_DOMAIN_HAS_NON_UNIQUE_NAME, RDE_HOST_HAS_NON_UNIQUE_NAME, RDE_DOMAIN_HAS_NON_UNIQUE_ROID, RDE_HOST_HAS_NON_UNIQUE_ROID and RDE_CONTACT_HAS_NON_UNIQUE_ROID error codes as needed to rde-08, rde-09 and rde-10.

  6. Added EPP_HOST_DELETE_RESPONSE_NOT_1000_OR_1001 to epp-24.

2.6. Wednesday, October 9, 2024

  1. Miscellaneous minor fixes.

2.7. Wednesday, October 2, 2024

  1. Miscellaneous minor fixes.

  2. Fixed the schema for the srsgw.eppRequiredContactElements input parameter.

2.8. Wednesday, September 25, 2024

  1. The epp.clientACL, integration.rdeSFTPACL and dnssecOps.xfrACL resources may now contain CIDR prefixes as well as IP addresses.

  2. Added EPP_GENERIC_COMMAND_ERROR to all EPP-related test cases.

2.9. Wednesday, September 18, 2024

  1. Updates to test cases in the RDE test suit resulting from internal review.

  2. Several EPP-related input parameters now have SRS Gateway-specific equivalents, as it is possible to allow the SRS Gateway EPP server to have a different data model to the primary EPP server.

  3. Clarified that IP-related tests are only applicable for internal hosts in epp-13.

  4. Replaced the epp.clientCertificate and epp.clientCSR resources with epp.client01Certificate and epp.client02Certificate, and epp.client01CSR and epp.client02CSR respectively, so each client can use a distinct certificate.

2.10. Thursday, September 12, 2024

  1. The version of Zonemaster that the DNS and DNSSEC test suites use has been changed from 2023.1.4 to 2024.1. The changes in Zonemaster between these versions may be found in the release notes on GitHub.

  2. idn-01, idn-02, idn-03, idn-04 and idn-06 have been folded into a single test case (a new idn-01), as a single implementation will perform all the tests.

  3. As a result of the above, idn-05 is now idn-02.

  4. In epp-20, the domain must not have the pendingTransfer status after the transfer is rejected.

  5. Clarified how the epp.restoreReportRequired input parameter affects the restore request in epp-22.

  6. Updated epp-23 to be stand-alone and also use a data provider.

  7. Updated epp-24 to be stand-alone.

  8. Added informative references to each test suite.

2.11. Wednesday, September 4, 2024

  1. Upgraded SHOULD to MUST for epp.serverIssuedClientCertificate01, epp.serverIssuedClientCertificate02, epp.registeredNameservers and epp.registeredContacts.

  2. Clarified that the values of the dnssecOps.zskRolloverZone, dnssecOps.kskRolloverZone, dnssecOps.algorithmRolloverZone input parameters must be different.

  3. The rdap.testDomains parameter is now an object with the same schema as the other input parameters for the RDAP suite.

  4. Added the rdap.profileVersion input parameter.

2.12. Friday, August 30, 2024

  1. Fixed test data sets in epp-11-data.

2.13. Tuesday, August 20, 2024

  1. Added a data provider to epp-11.

2.14. Wednesday, July 31, 2024

  1. The schema has been updated to add an Implemented property to test cases, allowing the proportion of implemented test cases to be reported for each suite and plan.

  2. Added data providers to some EPP test cases.

  3. Resolved error message inconsistency in epp-16.

  4. Further clarifications to epp-17.

  5. Made epp-18 standalone.

  6. Made epp-19 standalone.

  7. Made epp-21 standalone.

  8. Made epp-22 standalone.

2.15. Wednesday, July 24, 2024

  1. Clarified the description of epp-17.

2.16. Wednesday, July 17, 2024

  1. EPP-related test cases are being revised to avoid reuse of objects created previous test cases. Instead, each test case will be “standalone”, and will created any required objects itself. Any such objects will be deleted when the test case is finished. Any test case that still describes the reuse of objects created in a previous test case will eventually be updated to become “standalone” and should be read as such.

  2. Fixed the type of srsgw.serverIssuedClientCertificate01.

  3. Revised the error codes for epp-07, and the data provider, so that elements that can be empty do not result in errors when empty values are accepted by the server.

  4. Clarified the relationship between the items in the epp.registeredNameservers input parameters and the TLDs in the TLD set. This input parameter is now also optional.

  5. Updated the definition of the epp.registeredContacts to make a bit more sense. This is also now optional.

  6. Added a list of namespace URIs to rde-05.

  7. Updated the test procedure for srsgw-15, and added a reference to RFC 8785. The two RDAP responses may have different “last update of RDAP database” events.

  8. Added data providers to epp-13 and epp-14.

2.17. Wednesday, July 3, 2024

  1. The epp-07 and epp-09 test cases have been updated to use the newly-added epp.supportedContactElements and epp.requiredContactElements input parameters.

  2. The epp-07-data data provider has been updated to correct the error codes generated when the server accepts a <voice> element with invalid content.

  3. The dns.nameservers input parameter has been updated to allow different nameservers to be specified for each TLD being tested. The description of the DNS has been updated to reflect this change.

  4. Documented Test TLDs for RSP Evaluation.

  5. Updated the test cases in the Integration test suite to be independent from each other.

2.18. Wednesday, June 26, 2024

  1. Correct errors in epp-12.

  2. Added the srsgw.domainCreateExtension, srsgw.domainDeleteExtension, srsgw.domainRenewExtension, srsgw.domainTransferRequestExtension and srsgw.domainTransferApproveExtension input parameters, and the SRSGW_EPP_INVALID_EXTENSION error.

  3. Added the Additional DNS Transports plan.

  4. The RDAP test suite has been significantly refactored to split out separate test cases for domain, nameserver, registrar and help queries. The test coverage has not changed (since the RDAP Conformance Tool will still be used), this change is mainly to ensure that any errors are properly associated with the type of query being performed.

2.19. Wednesday, June 5, 2024

  1. This is the first release since the end of the Public Comment proceeding.

  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-02 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 previously said that the value must be empty, it now says it must be omitted.

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

  12. The DNS_INCONSISTENT_RESPONSES error has been removed from all test cases in the DNS and DNSSEC test cases, and a new test case, dns-zz-consistency has been added which will perform consistency checks using the SLA Monitoring system (SLAM).

  13. The dns.nameservers input parameter has been updated to add the supportsDoT, supportsDoH and supportsDoQ boolean flags to nameservers. This allows test subjects to indicate whether a nameserver supports DoT, DoH or DoQ, respectively.

2.20. 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.21. 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.22. 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.23. 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.24. 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.25. 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.26. 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.27. 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. Test TLDs for RSP Evaluation

RSP evaluation tests do not use existing or applied-for TLDs; instead, a unique TLD label will be defined for each test, based on the unique Application ID of the RSP application in the RSP Portal. These TLD labels will take the form:

zz-[appid]

Where [appid] will be replaced with the Application ID. For example, a MainRSPEvaluationTest test for a Main RSP application with the ID RSPI2404-M51 will use the TLD .zz-rspi2404-m51. Test subjects will need to configure their registry systems to support this TLD prior to requesting a test run.

2.7. 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: 3146

{
   "dns.nameservers" : [
      {
         "name" : "example",
         "nameservers" : [
            {
               "name" : "ns1.example.com",
               "supportsDoT" : 1,
               "v4Addrs" : [
                  "192.0.2.1"
               ],
               "v6Addrs" : [
                  "2001:DB8::53:1"
               ]
            },
            {
               "name" : "ns2.example.net",
               "supportsDoH" : 1,
               "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.example1",
      "ns2.example.example2"
   ],
   "epp.requiredContactElements" : [
      "street",
      "voice"
   ],
   "epp.requiredContactTypes" : [
      "admin"
   ],
   "epp.restoreReportRequired" : false,
   "epp.secDNSInterfaces" : "dsData",
   "epp.serverIssuedClientCertificate01" : "rst_test_client_cert.pem",
   "epp.serverIssuedClientCertificate02" : "rst_test_client_cert.pem",
   "epp.supportedContactElements" : [
      "org",
      "street",
      "sp",
      "pc",
      "voice",
      "voice:ext"
   ],
   "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.profileVersion" : "february-2019",
   "rdap.testDomains" : [
      {
         "name" : "example.example",
         "tld" : "example"
      }
   ],
   "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.1.9. Implementation status

As of the publication of this document, 82% of the test cases in this plan have been implemented in the RST system.

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: 3146

{
   "dns.nameservers" : [
      {
         "name" : "example",
         "nameservers" : [
            {
               "name" : "ns1.example.com",
               "supportsDoT" : 1,
               "v4Addrs" : [
                  "192.0.2.1"
               ],
               "v6Addrs" : [
                  "2001:DB8::53:1"
               ]
            },
            {
               "name" : "ns2.example.net",
               "supportsDoH" : 1,
               "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.example1",
      "ns2.example.example2"
   ],
   "epp.requiredContactElements" : [
      "street",
      "voice"
   ],
   "epp.requiredContactTypes" : [
      "admin"
   ],
   "epp.restoreReportRequired" : false,
   "epp.secDNSInterfaces" : "dsData",
   "epp.serverIssuedClientCertificate01" : "rst_test_client_cert.pem",
   "epp.serverIssuedClientCertificate02" : "rst_test_client_cert.pem",
   "epp.supportedContactElements" : [
      "org",
      "street",
      "sp",
      "pc",
      "voice",
      "voice:ext"
   ],
   "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.profileVersion" : "february-2019",
   "rdap.testDomains" : [
      {
         "name" : "example.example",
         "tld" : "example"
      }
   ],
   "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.9. Implementation status

As of the publication of this document, 82% of the test cases in this plan have been implemented in the RST system.

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: 970

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

4.3.9. Implementation status

As of the publication of this document, 95% of the test cases in this plan have been implemented in the RST system.

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: 790

{
   "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.registeredNames" : [
      "example.example1",
      "example.example2"
   ],
   "epp.requiredContactElements" : [
      "street",
      "voice"
   ],
   "epp.requiredContactTypes" : [
      "admin"
   ],
   "epp.serverIssuedClientCertificate01" : "rst_test_client_cert.pem",
   "epp.serverIssuedClientCertificate02" : "rst_test_client_cert.pem",
   "epp.supportedContactElements" : [
      "org",
      "street",
      "sp",
      "pc",
      "voice",
      "voice:ext"
   ],
   "general.registryDataModel" : "minimum"
}

4.4.9. Implementation status

As of the publication of this document, 0% of the test cases in this plan have been implemented in the RST system.

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: 790

{
   "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.registeredNames" : [
      "example.example1",
      "example.example2"
   ],
   "epp.requiredContactElements" : [
      "street",
      "voice"
   ],
   "epp.requiredContactTypes" : [
      "admin"
   ],
   "epp.serverIssuedClientCertificate01" : "rst_test_client_cert.pem",
   "epp.serverIssuedClientCertificate02" : "rst_test_client_cert.pem",
   "epp.supportedContactElements" : [
      "org",
      "street",
      "sp",
      "pc",
      "voice",
      "voice:ext"
   ],
   "general.registryDataModel" : "minimum"
}

4.5.9. Implementation status

As of the publication of this document, 0% of the test cases in this plan have been implemented in the RST system.

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: 2258

{
   "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.requiredContactElements" : [
      "street",
      "voice"
   ],
   "epp.requiredContactTypes" : [
      "admin"
   ],
   "epp.serverIssuedClientCertificate01" : "rst_test_client_cert.pem",
   "epp.serverIssuedClientCertificate02" : "rst_test_client_cert.pem",
   "epp.supportedContactElements" : [
      "org",
      "street",
      "sp",
      "pc",
      "voice",
      "voice:ext"
   ],
   "general.registryDataModel" : "minimum",
   "rdap.baseURLs" : [
      {
         "baseURL" : "https://rdap.example.com/example/",
         "tld" : "example"
      }
   ],
   "srsgw.domainCreateExtension" : "<extension xmlns='urn:ietf:params:xml:ns:epp-1.0'>\n  <allocationToken xmlns='urn:ietf:params:xml:ns:allocationToken-1.0'>\n    abc123\n  </allocationToken>\n</extension>\n",
   "srsgw.domainDeleteExtension" : "<!-- see srsgw.domainCreateExtension -->",
   "srsgw.domainRenewExtension" : "<!-- see srsgw.domainCreateExtension -->",
   "srsgw.domainTransferApproveExtension" : "<!-- see srsgw.domainCreateExtension -->",
   "srsgw.domainTransferRequestExtension" : "<!-- see srsgw.domainCreateExtension -->",
   "srsgw.eppClid01" : "clid-01",
   "srsgw.eppClid01DataModel" : "minimum",
   "srsgw.eppClid02" : "clid-02",
   "srsgw.eppClid02DataModel" : "minimum",
   "srsgw.eppHostName" : "epp.rsp.tech",
   "srsgw.eppPwd01" : "foo2bar",
   "srsgw.eppPwd02" : "foo3bar",
   "srsgw.eppRequiredContactElements" : [
      "org",
      "street",
      "sp",
      "pc",
      "voice",
      "voice:ext"
   ],
   "srsgw.eppRequiredContactTypes" : [
      "admin"
   ],
   "srsgw.eppSupportedContactElements" : [
      "org",
      "street",
      "sp",
      "pc",
      "voice",
      "voice:ext"
   ],
   "srsgw.rdapBaseURLs" : [
      {
         "baseURL" : "https://rdap.example.com/example/",
         "tld" : "example"
      }
   ],
   "srsgw.registryDataModel" : "minimum",
   "srsgw.serverIssuedClientCertificate01" : "cert.pem",
   "srsgw.serverIssuedClientCertificate02" : "cert.pem"
}

4.6.9. Implementation status

As of the publication of this document, 20% of the test cases in this plan have been implemented in the RST system.

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: 1987

{
   "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.example1",
      "ns2.example.example2"
   ],
   "epp.requiredContactElements" : [
      "street",
      "voice"
   ],
   "epp.requiredContactTypes" : [
      "admin"
   ],
   "epp.restoreReportRequired" : false,
   "epp.secDNSInterfaces" : "dsData",
   "epp.serverIssuedClientCertificate01" : "rst_test_client_cert.pem",
   "epp.serverIssuedClientCertificate02" : "rst_test_client_cert.pem",
   "epp.supportedContactElements" : [
      "org",
      "street",
      "sp",
      "pc",
      "voice",
      "voice:ext"
   ],
   "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.profileVersion" : "february-2019",
   "rdap.testDomains" : [
      {
         "name" : "example.example",
         "tld" : "example"
      }
   ],
   "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.7.9. Implementation status

As of the publication of this document, 68% of the test cases in this plan have been implemented in the RST system.

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: 644

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

4.8.9. Implementation status

As of the publication of this document, 94% of the test cases in this plan have been implemented in the RST system.

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: 1842

{
   "dns.nameservers" : [
      {
         "name" : "example",
         "nameservers" : [
            {
               "name" : "ns1.example.com",
               "supportsDoT" : 1,
               "v4Addrs" : [
                  "192.0.2.1"
               ],
               "v6Addrs" : [
                  "2001:DB8::53:1"
               ]
            },
            {
               "name" : "ns2.example.net",
               "supportsDoH" : 1,
               "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.9.9. Implementation status

As of the publication of this document, 82% of the test cases in this plan have been implemented in the RST system.

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: 2258

{
   "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.requiredContactElements" : [
      "street",
      "voice"
   ],
   "epp.requiredContactTypes" : [
      "admin"
   ],
   "epp.serverIssuedClientCertificate01" : "rst_test_client_cert.pem",
   "epp.serverIssuedClientCertificate02" : "rst_test_client_cert.pem",
   "epp.supportedContactElements" : [
      "org",
      "street",
      "sp",
      "pc",
      "voice",
      "voice:ext"
   ],
   "general.registryDataModel" : "minimum",
   "rdap.baseURLs" : [
      {
         "baseURL" : "https://rdap.example.com/example/",
         "tld" : "example"
      }
   ],
   "srsgw.domainCreateExtension" : "<extension xmlns='urn:ietf:params:xml:ns:epp-1.0'>\n  <allocationToken xmlns='urn:ietf:params:xml:ns:allocationToken-1.0'>\n    abc123\n  </allocationToken>\n</extension>\n",
   "srsgw.domainDeleteExtension" : "<!-- see srsgw.domainCreateExtension -->",
   "srsgw.domainRenewExtension" : "<!-- see srsgw.domainCreateExtension -->",
   "srsgw.domainTransferApproveExtension" : "<!-- see srsgw.domainCreateExtension -->",
   "srsgw.domainTransferRequestExtension" : "<!-- see srsgw.domainCreateExtension -->",
   "srsgw.eppClid01" : "clid-01",
   "srsgw.eppClid01DataModel" : "minimum",
   "srsgw.eppClid02" : "clid-02",
   "srsgw.eppClid02DataModel" : "minimum",
   "srsgw.eppHostName" : "epp.rsp.tech",
   "srsgw.eppPwd01" : "foo2bar",
   "srsgw.eppPwd02" : "foo3bar",
   "srsgw.eppRequiredContactElements" : [
      "org",
      "street",
      "sp",
      "pc",
      "voice",
      "voice:ext"
   ],
   "srsgw.eppRequiredContactTypes" : [
      "admin"
   ],
   "srsgw.eppSupportedContactElements" : [
      "org",
      "street",
      "sp",
      "pc",
      "voice",
      "voice:ext"
   ],
   "srsgw.rdapBaseURLs" : [
      {
         "baseURL" : "https://rdap.example.com/example/",
         "tld" : "example"
      }
   ],
   "srsgw.registryDataModel" : "minimum",
   "srsgw.serverIssuedClientCertificate01" : "cert.pem",
   "srsgw.serverIssuedClientCertificate02" : "cert.pem"
}

4.10.9. Implementation status

As of the publication of this document, 20% of the test cases in this plan have been implemented in the RST system.

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: 644

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

4.11.9. Implementation status

As of the publication of this document, 94% of the test cases in this plan have been implemented in the RST system.

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: 970

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

4.12.9. Implementation status

As of the publication of this document, 100% of the test cases in this plan have been implemented in the RST system.

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: 678

{
   "epp.hostModel" : "objects",
   "general.registryDataModel" : "minimum",
   "rdap.baseURLs" : [
      {
         "baseURL" : "https://rdap.example.com/example/",
         "tld" : "example"
      }
   ],
   "rdap.profileVersion" : "february-2019",
   "rdap.testDomains" : [
      {
         "name" : "example.example",
         "tld" : "example"
      }
   ],
   "rdap.testEntities" : [
      {
         "handle" : 9995,
         "tld" : "example"
      }
   ],
   "rdap.testNameservers" : [
      {
         "nameserver" : "ns1.example.com",
         "tld" : "example1"
      },
      {
         "nameserver" : "ns1.example.com",
         "tld" : "example2"
      }
   ]
}

4.13.9. Implementation status

As of the publication of this document, 100% of the test cases in this plan have been implemented in the RST system.

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: 1073

{
   "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.example1",
      "ns2.example.example2"
   ],
   "epp.requiredContactElements" : [
      "street",
      "voice"
   ],
   "epp.requiredContactTypes" : [
      "admin"
   ],
   "epp.restoreReportRequired" : false,
   "epp.secDNSInterfaces" : "dsData",
   "epp.serverIssuedClientCertificate01" : "rst_test_client_cert.pem",
   "epp.serverIssuedClientCertificate02" : "rst_test_client_cert.pem",
   "epp.supportedContactElements" : [
      "org",
      "street",
      "sp",
      "pc",
      "voice",
      "voice:ext"
   ],
   "general.registryDataModel" : "minimum"
}

4.14.9. Implementation status

As of the publication of this document, 58% of the test cases in this plan have been implemented in the RST system.

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: 282

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

4.15.9. Implementation status

As of the publication of this document, 78% of the test cases in this plan have been implemented in the RST system.

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: 2258

{
   "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.requiredContactElements" : [
      "street",
      "voice"
   ],
   "epp.requiredContactTypes" : [
      "admin"
   ],
   "epp.serverIssuedClientCertificate01" : "rst_test_client_cert.pem",
   "epp.serverIssuedClientCertificate02" : "rst_test_client_cert.pem",
   "epp.supportedContactElements" : [
      "org",
      "street",
      "sp",
      "pc",
      "voice",
      "voice:ext"
   ],
   "general.registryDataModel" : "minimum",
   "rdap.baseURLs" : [
      {
         "baseURL" : "https://rdap.example.com/example/",
         "tld" : "example"
      }
   ],
   "srsgw.domainCreateExtension" : "<extension xmlns='urn:ietf:params:xml:ns:epp-1.0'>\n  <allocationToken xmlns='urn:ietf:params:xml:ns:allocationToken-1.0'>\n    abc123\n  </allocationToken>\n</extension>\n",
   "srsgw.domainDeleteExtension" : "<!-- see srsgw.domainCreateExtension -->",
   "srsgw.domainRenewExtension" : "<!-- see srsgw.domainCreateExtension -->",
   "srsgw.domainTransferApproveExtension" : "<!-- see srsgw.domainCreateExtension -->",
   "srsgw.domainTransferRequestExtension" : "<!-- see srsgw.domainCreateExtension -->",
   "srsgw.eppClid01" : "clid-01",
   "srsgw.eppClid01DataModel" : "minimum",
   "srsgw.eppClid02" : "clid-02",
   "srsgw.eppClid02DataModel" : "minimum",
   "srsgw.eppHostName" : "epp.rsp.tech",
   "srsgw.eppPwd01" : "foo2bar",
   "srsgw.eppPwd02" : "foo3bar",
   "srsgw.eppRequiredContactElements" : [
      "org",
      "street",
      "sp",
      "pc",
      "voice",
      "voice:ext"
   ],
   "srsgw.eppRequiredContactTypes" : [
      "admin"
   ],
   "srsgw.eppSupportedContactElements" : [
      "org",
      "street",
      "sp",
      "pc",
      "voice",
      "voice:ext"
   ],
   "srsgw.rdapBaseURLs" : [
      {
         "baseURL" : "https://rdap.example.com/example/",
         "tld" : "example"
      }
   ],
   "srsgw.registryDataModel" : "minimum",
   "srsgw.serverIssuedClientCertificate01" : "cert.pem",
   "srsgw.serverIssuedClientCertificate02" : "cert.pem"
}

4.16.9. Implementation status

As of the publication of this document, 20% of the test cases in this plan have been implemented in the RST system.

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: 722

{
   "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.requiredContactElements" : [
      "street",
      "voice"
   ],
   "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"
}

4.17.9. Implementation status

As of the publication of this document, 0% of the test cases in this plan have been implemented in the RST system.

4.18. Additional DNS Transports Test

4.18.1. Description

Registry Operators may optionally provide authoritative DNS services over additional transports, such as TLS, HTTPS and QUIC.

This test plan uses the AdditionalDNSTransports test suite to verify the conformance of these services with the relevant RFCs.

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.18.2. Plan ID

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

AdditionalDNSTransportsTest

4.18.3. Test suites

This plan uses the following test suites:

  1. Additional DNS Transports

4.18.4. Resources

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

  • None specified.

4.18.5. Errors

This test plan may produce the following errors:

4.18.6. Input parameters

This plan requires the following input parameters:

4.18.7. Required files

  • None specified.

4.18.8. RST-API example

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

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

4.18.9. Implementation status

As of the publication of this document, 0% of the test cases in this plan have been implemented in the RST system.

4.19. Pre-Delegation Test with SRS Gateway

4.19.1. Description

This test plan is identical to the Pre-Delegation Test plan, but adds the SRS Gateway test suite, for TLDs which intend to launch with an SRS Gateway.

4.19.2. Plan ID

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

PreDelegationTestWithSRSGateway

4.19.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. SRS Gateway
  8. Standard Integration Test

4.19.4. Resources

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

4.19.5. Errors

This test plan may produce the following errors:

4.19.6. Input parameters

This plan requires the following input parameters:

4.19.7. Required files

4.19.8. RST-API example

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

{
   "dns.nameservers" : [
      {
         "name" : "example",
         "nameservers" : [
            {
               "name" : "ns1.example.com",
               "supportsDoT" : 1,
               "v4Addrs" : [
                  "192.0.2.1"
               ],
               "v6Addrs" : [
                  "2001:DB8::53:1"
               ]
            },
            {
               "name" : "ns2.example.net",
               "supportsDoH" : 1,
               "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.example1",
      "ns2.example.example2"
   ],
   "epp.requiredContactElements" : [
      "street",
      "voice"
   ],
   "epp.requiredContactTypes" : [
      "admin"
   ],
   "epp.restoreReportRequired" : false,
   "epp.secDNSInterfaces" : "dsData",
   "epp.serverIssuedClientCertificate01" : "rst_test_client_cert.pem",
   "epp.serverIssuedClientCertificate02" : "rst_test_client_cert.pem",
   "epp.supportedContactElements" : [
      "org",
      "street",
      "sp",
      "pc",
      "voice",
      "voice:ext"
   ],
   "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.profileVersion" : "february-2019",
   "rdap.testDomains" : [
      {
         "name" : "example.example",
         "tld" : "example"
      }
   ],
   "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",
   "srsgw.domainCreateExtension" : "<extension xmlns='urn:ietf:params:xml:ns:epp-1.0'>\n  <allocationToken xmlns='urn:ietf:params:xml:ns:allocationToken-1.0'>\n    abc123\n  </allocationToken>\n</extension>\n",
   "srsgw.domainDeleteExtension" : "<!-- see srsgw.domainCreateExtension -->",
   "srsgw.domainRenewExtension" : "<!-- see srsgw.domainCreateExtension -->",
   "srsgw.domainTransferApproveExtension" : "<!-- see srsgw.domainCreateExtension -->",
   "srsgw.domainTransferRequestExtension" : "<!-- see srsgw.domainCreateExtension -->",
   "srsgw.eppClid01" : "clid-01",
   "srsgw.eppClid01DataModel" : "minimum",
   "srsgw.eppClid02" : "clid-02",
   "srsgw.eppClid02DataModel" : "minimum",
   "srsgw.eppHostName" : "epp.rsp.tech",
   "srsgw.eppPwd01" : "foo2bar",
   "srsgw.eppPwd02" : "foo3bar",
   "srsgw.eppRequiredContactElements" : [
      "org",
      "street",
      "sp",
      "pc",
      "voice",
      "voice:ext"
   ],
   "srsgw.eppRequiredContactTypes" : [
      "admin"
   ],
   "srsgw.eppSupportedContactElements" : [
      "org",
      "street",
      "sp",
      "pc",
      "voice",
      "voice:ext"
   ],
   "srsgw.rdapBaseURLs" : [
      {
         "baseURL" : "https://rdap.example.com/example/",
         "tld" : "example"
      }
   ],
   "srsgw.registryDataModel" : "minimum",
   "srsgw.serverIssuedClientCertificate01" : "cert.pem",
   "srsgw.serverIssuedClientCertificate02" : "cert.pem"
}

4.19.9. Implementation status

As of the publication of this document, 74% of the test cases in this plan have been implemented in the RST system.

5. Test Suites

5.1. Authoritative DNS Service

5.1.1. Description

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

Most of the test cases in the DNS test suite are derived from the test plans in version v2024.1 of Zonemaster.

Zonemaster will test each of the TLDs in the test using the nameservers provided in the dns.nameservers input parameter.

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. Test cases must pass for all TLDs in the TLD set.

References

Note: this list of references is not exhaustive.

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-consistency - Nameserver consistency check
  35. 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
  6. Pre-Delegation Test with SRS Gateway

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.1.7. Implementation status

As of the publication of this document, 94% of the test cases in this suite have been implemented in the RST system.

5.2. DNS Security Extensions (DNSSEC)

5.2.1. Description

The DNS test suite validates the authoritative DNS services for the TLD(s) RSP.

Most of the test cases in the DNS test suite are derived from the test plans in version v2024.1 of Zonemaster.

Zonemaster will test each of the TLDs in the test using the nameservers provided in the dns.nameservers input parameter.

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. Test cases must pass for all TLDs in the TLD set.

References

Note: this list of references is not exhaustive.

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 - Verify NSEC3 parameters
  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
  6. Pre-Delegation Test with SRS Gateway

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.2.7. Implementation status

As of the publication of this document, 100% of the test cases in this suite have been implemented in the RST system.

5.3. Registration Data Access Protocol (RDAP)

5.3.1. Description

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

The RDAP test suite uses the RDAP Conformance Tool to perform conformance testing of RDAP services.

The RDAP Conformance Tool checks that an RDAP server properly implements the RDAP RFCs and the gTLD RDAP Profile.

The RDAP Conformance Tool will be used to check the RDAP services for each TLD in the test using the Base URL(s) specified in the rdap.baseURLs input parameter.

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.

References

5.3.2. Test cases

This suite uses the following test cases:

  1. rdap-01 - Domain query test
  2. rdap-02 - Nameserver query test
  3. rdap-03 - Registrar query test
  4. rdap-04 - Help query test
  5. rdap-05 - Domain HEAD test
  6. rdap-06 - Nameserver HEAD test
  7. rdap-07 - Entity HEAD test
  8. rdap-91 - TLS version conformance check
  9. 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. Pre-Delegation Test with SRS Gateway

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. epp.hostModel (input)
  2. general.registryDataModel (input)
  3. rdap.baseURLs (input)
  4. rdap.profileVersion (input)
  5. rdap.testDomains (input)
  6. rdap.testEntities (input)
  7. rdap.testNameservers (input)

5.3.7. Implementation status

As of the publication of this document, 100% of the test cases in this suite have been implemented in the RST system.

5.4. Extensible Provisioning Protocol (EPP)

5.4.1. Description

The EPP test suite validates the EPP service of the TLD(s) 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.

References

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. Pre-Delegation Test with SRS Gateway

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.requiredContactElements (input)
  14. epp.requiredContactTypes (input)
  15. epp.restoreReportRequired (input)
  16. epp.secDNSInterfaces (input)
  17. epp.serverIssuedClientCertificate01 (file)
  18. epp.serverIssuedClientCertificate02 (file)
  19. epp.supportedContactElements (input)
  20. general.registryDataModel (input)

5.4.7. Implementation status

As of the publication of this document, 58% of the test cases in this suite have been implemented in the RST system.

5.5. Registry Data Escrow (RDE)

5.5.1. Description

The RDE test suite validates Registry Data Escrow deposits generated for the TLD(s) 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.

References

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. Pre-Delegation Test with SRS Gateway

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. epp.hostModel (input)
  3. general.registryDataModel (input)
  4. rde.depositFile (file)
  5. rde.publicKey (file)
  6. rde.signatureFile (file)

5.5.7. Implementation status

As of the publication of this document, 78% of the test cases in this suite have been implemented in the RST system.

5.6. Internationalized Domain Names (IDN)

5.6.1. Description

The IDN test suite validates the IDN table implementation for the TLD(s) or RSP, including compliance with specifications for variant labels at the top- or second-level, and conformance with the IDN Implementation 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.

References

5.6.2. Test cases

This suite uses the following test cases:

  1. idn-01 - IDN label validation test
  2. idn-02 - ASCII domains in IDN-only TLD 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. Pre-Delegation Test with SRS Gateway

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.registeredNames (input)
  10. epp.requiredContactElements (input)
  11. epp.requiredContactTypes (input)
  12. epp.serverIssuedClientCertificate01 (file)
  13. epp.serverIssuedClientCertificate02 (file)
  14. epp.supportedContactElements (input)
  15. general.registryDataModel (input)

5.6.7. Implementation status

As of the publication of this document, 0% of the test cases in this suite have been implemented in the RST system.

5.7. SRS Gateway

5.7.1. Description

The SRS Gateway test suite validates the conformance of the Gateway registry infrastructure of the TLD(s) 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.

References

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
  4. Pre-Delegation Test with SRS Gateway

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.requiredContactElements (input)
  10. epp.requiredContactTypes (input)
  11. epp.serverIssuedClientCertificate01 (file)
  12. epp.serverIssuedClientCertificate02 (file)
  13. epp.supportedContactElements (input)
  14. general.registryDataModel (input)
  15. rdap.baseURLs (input)
  16. srsgw.domainCreateExtension (input)
  17. srsgw.domainDeleteExtension (input)
  18. srsgw.domainRenewExtension (input)
  19. srsgw.domainTransferApproveExtension (input)
  20. srsgw.domainTransferRequestExtension (input)
  21. srsgw.eppClid01 (input)
  22. srsgw.eppClid01DataModel (input)
  23. srsgw.eppClid02 (input)
  24. srsgw.eppClid02DataModel (input)
  25. srsgw.eppHostName (input)
  26. srsgw.eppPwd01 (input)
  27. srsgw.eppPwd02 (input)
  28. srsgw.eppRequiredContactElements (input)
  29. srsgw.eppRequiredContactTypes (input)
  30. srsgw.eppSupportedContactElements (input)
  31. srsgw.rdapBaseURLs (input)
  32. srsgw.registryDataModel (input)
  33. srsgw.serverIssuedClientCertificate01 (file)
  34. srsgw.serverIssuedClientCertificate02 (file)

5.7.7. Implementation status

As of the publication of this document, 20% of the test cases in this suite have been implemented in the RST system.

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.

References

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.8.7. Implementation status

As of the publication of this document, 0% of the test cases in this suite have been implemented in the RST system.

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.

References

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.requiredContactElements (input)
  10. epp.requiredContactTypes (input)
  11. epp.serverIssuedClientCertificate01 (file)
  12. epp.serverIssuedClientCertificate02 (file)
  13. general.registryDataModel (input)
  14. minimumRPMS.claimsTLD (input)
  15. minimumRPMS.sunriseModels (input)
  16. minimumRPMS.sunriseTLD (input)

5.9.7. Implementation status

As of the publication of this document, 0% of the test cases in this suite have been implemented in the RST system.

5.10. Standard Integration Test

5.10.1. Description

This test suite verifies that the critical registry services of a 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.

References

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
  3. Pre-Delegation Test with SRS Gateway

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.clid01DataModel (input)
  4. epp.hostModel (input)
  5. epp.hostName (input)
  6. epp.pwd01 (input)
  7. epp.requiredContactElements (input)
  8. epp.requiredContactTypes (input)
  9. epp.serverIssuedClientCertificate01 (file)
  10. general.registryDataModel (input)
  11. integration.rdeSFTPDirectory (input)
  12. integration.rdeSFTPHostname (input)
  13. integration.rdeSFTPUsername (input)
  14. integration.rriACL (input)
  15. rdap.baseURLs (input)

5.10.7. Implementation status

As of the publication of this document, 66% of the test cases in this suite have been implemented in the RST system.

5.11. Additional DNS Transports

5.11.1. Description

This test suite verifies that Registry Operators wishing to offer their authoritative DNS service over additional transport protocols (specifically TLS, HTTPS and QUIC) can do so in conformance with the relevant RFCs.

References

5.11.2. Test cases

This suite uses the following test cases:

  1. dns-zz-consistency - Nameserver consistency check

5.11.3. Test plans

This suite is used by the following test plans:

  1. Additional DNS Transports Test

5.11.4. Resources

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

  • None specified.

5.11.5. Errors

This test suite may produce the following errors:

5.11.6. Input parameters

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

  1. dns.nameservers (input)

5.11.7. Implementation status

As of the publication of this document, 0% of the test cases in this suite have been implemented in the RST system.

6. Resources

6.1. dnssecOps.xfrACL

6.1.1. Description

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

6.1.2. URL

This resource has different contents for different environments:

6.2. epp.client01CSR

6.2.1. Description

For servers that operate a private CA, this CSR may be used to issue a client certificate for the clients identified by the epp.clid01 and srsgw.eppClid01 input parameters.

6.2.2. URL

This resource has different contents for different environments:

6.3. epp.client01Certificate

6.3.1. Description

RFC 5734 requires servers to perform authentication of clients by means of a client certificate.

Operators that do not use a private CA MUST configure their systems to permit the client identified in the epp.clid01 and srsgw.eppClid01 input parameters to connect using the certificate found at this URL.

6.3.2. URL

This resource has different contents for different environments:

6.4. epp.client02CSR

6.4.1. Description

For servers that operate a private CA, this CSR may be used to issue a client certificate for the clients identified by the epp.clid02 and srsgw.eppClid02 input parameters.

6.4.2. URL

This resource has different contents for different environments:

6.5. epp.client02Certificate

6.5.1. Description

RFC 5734 requires servers to perform authentication of clients by means of a client certificate.

Operators that do not use a private CA MUST configure their systems to permit the client identified in the epp.clid02 and srsgw.eppClid02 input parameters to connect using the certificate found at this URL.

6.5.2. URL

This resource has different contents for different environments:

6.6. epp.clientACL

6.6.1. Description

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

6.6.2. URL

This resource has different contents for different environments:

6.7. epp.tlsCertificateStore

6.7.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.7.2. URL

6.8. idn.testLabelsForOTE

6.8.1. Description

Test cases in the IDN test suite require a set of test labels which are used to compute domain names used in EPP <create> commands. These test labels are provided when IDN table objects are created through the API.

In production, these objects will be created by ICANN org, but for OT&E, test subjects must create IDN table objects themselves, and must therefore provide test labels.

Test subjects are free to submit any test labels they wish, but in order to properly simulate a production test, the same set of labels should be used.

This resource is a zip file containing JSON files, each of which contains the test labels for the second-level reference LGR identified by the language tag in the file name. The JSON files conform to the idnTestLabels object type from the RST-API specification.

6.8.2. URL

6.9. integration.rdeSFTPACL

6.9.1. Description

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

6.9.2. URL

This resource has different contents for different environments:

6.10. integration.rdeSFTPPublicKey

6.10.1. Description

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

6.10.2. URL

This resource has different contents for different environments:

6.11. rde.encryptionKey

6.11.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.11.2. URL

This resource has different contents for different environments:

6.12. tmch.testCRL

6.12.1. Description

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

6.12.2. URL

6.13. tmch.testCert

6.13.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.13.2. URL

6.14. tmch.testDNL

6.14.1. Description

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

6.14.2. URL

This resource has different contents for different environments:

6.15. tmch.testSMDRL

6.15.1. Description

A CSV file containing a list of revoked SMDs.

6.15.2. URL

6.16. tmch.testSURL

6.16.1. Description

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

6.16.2. URL

This resource has different contents for different environments:

7. Test Cases

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

7.1.1. Implementation status

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 v2024.1 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. Implementation status

7.2.2. Description

This test case comes from version v2024.1 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.

TODO: 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. Implementation status

7.3.2. Description

This test case comes from version v2024.1 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. Implementation status

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 v2024.1 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. Implementation status

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 v2024.1 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. Implementation status

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 v2024.1 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. Implementation status

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 v2024.1 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. Implementation status

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 v2024.1 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. Implementation status

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 v2024.1 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. Implementation status

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 v2024.1 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. Implementation status

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 v2024.1 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. Implementation status

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 v2024.1 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. Implementation status

7.13.2. Description

This test case comes from version v2024.1 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. Implementation status

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 v2024.1 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. Implementation status

7.15.2. Description

This test case comes from version v2024.1 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. Implementation status

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 v2024.1 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. Implementation status

7.17.2. Description

This test case comes from version v2024.1 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. Implementation status

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 v2024.1 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. Implementation status

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 v2024.1 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. Implementation status

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 v2024.1 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. Implementation status

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 v2024.1 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. Implementation status

7.22.2. Description

This test case comes from version v2024.1 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. Implementation status

7.23.2. Description

This test case comes from version v2024.1 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. Implementation status

7.24.2. Description

This test case comes from version v2024.1 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. Implementation status

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 v2024.1 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. Implementation status

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 v2024.1 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. Implementation status

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 v2024.1 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. Implementation status

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 v2024.1 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. Implementation status

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 v2024.1 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. Implementation status

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 v2024.1 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. Implementation status

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 v2024.1 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. Implementation status

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 v2024.1 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. Implementation status

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 v2024.1 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-consistency - Nameserver consistency check

7.34.1. Implementation status

7.34.2. Description

This test case verifies that all the nameservers (both logical and physical) specified in the dns.nameservers input parameter provide consistent responses.

The test system will perform DNS queries from multiple nodes in the SLA Monitoring system (SLAM) so that multiple physical nodes within an anycasted logical nameserver are tested.

For each TLD in the test, the following queries will be sent, over UDP, TCP, and any additional transports that are supported (based on the supportsDoT, supportsDoH and supportsDoQ properties for the nameserver in question) to each IPv4 and IPv6 address for each nameserver:

  • apex SOA query;
  • apex NS query;
  • apex DNSKEY query;
  • apex NSEC3PARAM query;
  • apex TXT query;
  • A and AAAA queries for in-bailiwick nameservers, if any;
  • nic.tld NS query;
  • nic.tld DS query.

The EDNS(0) do bit, NSID option, and ZONEVERSION options will be set on all queries. The reported NSID and ZONEVERSION values in the response (if any) will be included in logs for debugging purposes.

For DoT, DoH and DoQ, no certificate validation will be performed.

The test case will fail if:

  1. one or more queries timeout (within 1000ms for UDP and 3000ms for any other protocol), or
  2. The RCODE header field, or answer, authority or additional sections of the response differs, after normalization, from those of any previously received response, with the sole exception of the serial field of SOA records.

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. dns-zz-idna2008-compliance - IDNA2008 compliance check

7.35.1. Implementation status

7.35.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 5890.

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

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-01 - Legal values for the DS hash digest algorithm

7.36.1. Implementation status

7.36.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 v2024.1 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.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-02 - DS must match a valid DNSKEY in the child zone

7.37.1. Implementation status

7.37.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 v2024.1 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.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-03 - Verify NSEC3 parameters

7.38.1. Implementation status

7.38.2. Description

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

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 v2024.1 of Zonemaster. For more information, please refer to the documentation for this test case.

Objective

The NSEC3 record type and its parameters are defined in RFC 5155. The recommended values of the parameters have been updated by RFC 9276.

For NSEC3 there are four fields that determine how the NSEC3 record are created and interpreted (RFC 5155, section 3):

  • Hash algorithm
  • Flags
  • Iterations
  • Salt

Hash algorithm: The only legal value of the hash algorithm is value 1 (SHA-1). See (RFC 5155, section 11 and IANA NSEC3 Parameters registry).

Flags: The only defined flags in the flag field is bit 7 (the least significant bit), “opt-out”. It may only be set in the NSEC record, not in the NSEC3PARAM record (RFC 5155, section 11 and IANA NSEC3 Parameters registry). “For small zones, the use of opt-out-based NSEC3 records is NOT RECOMMENDED. For very large and sparsely signed zones, where the majority of the records are insecure delegations, opt-out MAY be used” (RFC 9276, section 3.1). This means that unless the zone is a TLD or a TLD like domain found in the Public Suffix List it should not have the opt-out bit set.

Iterations: For a name server an increased number of NSEC3 iterations have a negative impact on performance. The recommendation is to have 0 iterations. “If NSEC3 must be used, then an iterations count of 0 MUST be used to alleviate computational burdens” (RFC 9276, section 3.1).

Salt: The salt parameter has been seen as a security feature but RFC 9276, section 3.1, states that zones “SHOULD NOT use a salt by indicating a zero-length salt value instead”. The justification for the recommendation is found in RFC 9276, section 2.4.

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-04 - Check for too short or too long RRSIG lifetimes

7.39.1. Implementation status

7.39.2. Description

This test case comes from version v2024.1 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.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-05 - Check for invalid DNSKEY algorithms

7.40.1. Implementation status

7.40.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 v2024.1 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 copied from IANA registry. Only the first three columns are copied. The complete table is available at IANA registry. In the table below, however, mnemonic is defined when undefined in the IANA table.

Algorithm no Algorithm (or description) Mnemonic Note
0 Delete DS DELETE
1 RSA/MD5 RSAMD5
2 Diffie-Hellman DH
3 DSA/SHA1 DSA
4 Reserved RESERVED (1)
5 RSA/SHA-1 RSASHA1
6 DSA-NSEC3-SHA1 DSA-NSEC3-SHA1
7 RSASHA1-NSEC3-SHA1 RSASHA1-NSEC3-SHA1
8 RSA/SHA-256 RSASHA256
9 Reserved RESERVED (1)
10 RSA/SHA-512 RSASHA512
11 Reserved RESERVED (1)
12 GOST R 34.10-2001 ECC-GOST
13 ECDSA Curve P-256 with SHA-256 ECDSAP256SHA256
14 ECDSA Curve P-384 with SHA-384 ECDSAP384SHA384
15 Ed25519 ED25519
16 Ed448 ED448
17-122 Unassigned UNASSIGNED (1)
123-251 Reserved RESERVED (1)
252 Reserved for Indirect Keys INDIRECT
253 private algorithm PRIVATEDNS
254 private algorithm OID PRIVATEOID
255 Reserved RESERVED (1)
  1. Mnemonic defined for Zonemaster usage when undefined in the IANA table.

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-06 - Verify DNSSEC additional processing

7.41.1. Implementation status

7.41.2. Description

This test case comes from version v2024.1 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.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-08 - Valid RRSIG for DNSKEY

7.42.1. Implementation status

7.42.2. Description

This test case comes from version v2024.1 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.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-09 - RRSIG(SOA) must be valid and created by a valid DNSKEY

7.43.1. Implementation status

7.43.2. Description

This test case comes from version v2024.1 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.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-10 - Zone contains NSEC or NSEC3 records

7.44.1. Implementation status

7.44.2. Description

This test case comes from version v2024.1 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.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-13 - All DNSKEY algorithms used to sign the zone

7.45.1. Implementation status

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 v2024.1 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.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-14 - Check for valid RSA DNSKEY key size

7.46.1. Implementation status

7.46.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 v2024.1 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.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-91 - Permitted signing algorithms

7.47.1. Implementation status

7.47.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.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-92 - Permitted DS record hash algorithm(s)

7.48.1. Implementation status

7.48.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.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. dnssec-93 - NSEC3 iterations check

7.49.1. Implementation status

7.49.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.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:

  • None specified.

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. dnssecOps01-ZSKRollover - ZSK rollover

7.50.1. Implementation status

7.50.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.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. dnssecOps02-KSKRollover - KSK rollover

7.51.1. Implementation status

7.51.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.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. dnssecOps03-AlgorithmRollover - algorithm rollover

7.52.1. Implementation status

7.52.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.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:

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:

  • None specified.

7.52.7. Test suites

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

7.53. epp-01 - Service connectivity test

7.53.1. Implementation status

7.53.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.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:

  • None specified.

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:

7.53.7. Test suites

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

7.54. epp-02 - Protocol conformance test

7.54.1. Implementation status

7.54.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.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:

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-03 - Authentication test

7.55.1. Implementation status

7.55.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.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-04 - Domain <check> command test

7.56.1. Implementation status

7.56.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.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:

  • None specified.

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-05 - Host <check> command test (if applicable)

7.57.1. Implementation status

7.57.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.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-06 - Contact <check> command test (if applicable for the registry type)

7.58.1. Implementation status

7.58.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. Otherwise, this client will select the appropriate registrar credentials based on the values of the epp.clid01DataModel and epp.clid02DataModel input parameters.

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:

7.58.5. Data providers

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

  • None specified.

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-07 - Contact <create> command test (if applicable for the registry type)

7.59.1. Implementation status

7.59.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 mandatory elements against the XML schema provided in RFC 5733:

  • <contact:id> element
  • <contact:postalInfo> element(s):
    • <contact:name> element
    • <contact:city> element
    • <contact:cc> element
  • <contact:email> element

Depending on the list of elements provided in the epp.supportedContactElements input parameter, the test will also confirm that the server checks and validates the values of the following optional elements:

  • <contact:postalInfo> element(s):
    • <contact:org> element
    • <contact:street> element(s)
    • <contact:sp> element
    • <contact:pc> element
  • <contact:voice> element
    • ext attribute of the <contact:voice> element
  • <contact:fax> element
    • ext attribute of the <contact:fax> element
  • 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:email> element that contains a value that does not conform to the format specified in RFC 5322;
  • If supported, 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.

Once objects have been created, the client will then perform <info> commands to verify that the server has correctly stored the provided values.

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):

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-08 - Contact object access control (if applicable)

7.60.1. Implementation status

7.60.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. 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 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.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-09 - Contact <update> command test (if applicable for the registry type)

7.61.1. Implementation status

7.61.2. Description

This test will perform <update> commands on the contact objects 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> (if supported)
    • <contact:addr> elements
      • <contact:street> element(s) (if supported)
      • <contact:city> element
      • <contact:sp> element (if supported)
      • <contact:pc> element (if supported)
      • <contact:cc> element
  • <contact:voice> (if supported)
    • ext attribute of <contact:voice> (if supported)
  • <contact:fax> (if supported)
    • ext attribute of <contact:fax> (if supported)
  • <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.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):

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-10 - Contact <delete> command test (if applicable for the registry type)

7.62.1. Implementation status

7.62.2. Description

This test will perform <delete> commands on contact objects, 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. Otherwise, this client will select the appropriate registrar credentials based on the values of the epp.clid01DataModel and epp.clid02DataModel input parameters.

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.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-11 - Host <create> command test (if applicable)

7.63.1. Implementation status

7.63.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: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.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):

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-12 - Host object access control (if applicable)

7.64.1. Implementation status

7.64.2. Description

This test will confirm that EPP clients are unable to perform <update> commands on objects that they do not sponsor.

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

The client will create a host object, and then use a set of alternate credentials to submit <update> commands on that object. The server MUST respond with a 2201 “authorization error” response.

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-13 - Host <update> command test (if applicable)

7.65.1. Implementation status

7.65.2. Description

This test will perform <update> commands on host objects to 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 create host objects with pseudo-randomly generated names and confirm that the server checks and validates <update> commands which transform the values of the following elements:

  • <host:status> (internal and external hosts)
  • <host:addr> elements (both IPv4 and IPv6, internal hosts only)

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

  • None specified.

7.65.5. Data providers

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

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-14 - Domain <create> command test

7.66.1. Implementation status

7.66.2. Description

This test performs a series of 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 <create> commands to test 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 with an empty <pw> element.

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 general.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.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:

7.66.5. Data providers

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

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-15 - Registry object integrity test

7.67.1. Implementation status

7.67.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 create contact and/or host objects using pseudo-randomly generated properties, and then create a domain object that uses those objects.

It will then submit <delete> commands for those contact and host objects The server MUST respond with a 2305 “Object association prohibits operation” error.

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-16 - Domain <update> command test

7.68.1. Implementation status

7.68.2. Description

This test will confirm that the client is able to perform <update> commands on domain names, 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 create a domain name (and any contact and/or host objects required) and perform <update> commands as described above.

It will then perform <info> commands to confirm that the changes have been correctly stored by the server.

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.

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):

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-17 - Service Port consistency test

7.69.1. Implementation status

7.69.2. Description

This test confirms that all EPP service ports respond with consistent object information.

The client will establish separate connections to each EPP service port (defined as TCP port 700 on all IP addresses found in the A and AAAA records for the EPP server name) and, using one of these connections, create a domain name, and any contact and/or host objects, as required.

It will then perform <info> commands on those object(s) on each of the other ports. In all cases, the server MUST respond with a 1000 response, and the content of the <infData> element of the response MUST be identical on all service ports.

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-18 - Domain <renew> command test

7.70.1. Implementation status

7.70.2. Description

This test will confirm that the client is able to renew domain names.

The client will create a domain name, and any contact and/or host objects, as required, then submit <renew> commands for that object.

  1. Following a succesful <renew> command, the expiry date of the domain MUST have been increased by the period specified by the client;
  2. The domain MUST have an RGP status of renewPeriod;
  3. The server MUST reject a <renew> command if it would result in the expiry date being more than 10 years into the future.

After each <renew> command, the client will perform an <info> command to ensure that the expiry date and RGP status of the domain are set correctly.

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-19 - Domain <transfer> command test

7.71.1. Implementation status

7.71.2. Description

This test will confirm that the client is able to initiate a domain transfer.

The client will create a domain name, and any contact and/or host objects, as required.

The client will then perform an <update> command to set an authInfo code.

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.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-20 - Domain <transfer> rejection test

7.72.1. Implementation status

7.72.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, and that the domain does not have the pendingTransfer 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-21 - Domain <delete> command test

7.73.1. Implementation status

7.73.2. Description

This test will create and then delete a domain name, to confirm that the server accepts the <delete> command with a 1xxx response code.

Once the <delete> command has been processed, the client will perform and <info> command 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.

If the <delete> command resulted in a 1000 response, the client will also submit <delete> commands for any host and/or contact objects created. These commands MUST succeed, and an <info> command for them MUST result in a 2303 “object does not exist” error.

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:

  • None specified.

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-22 - Domain restore test

7.74.1. Implementation status

7.74.2. Description

This test will perform RGP restore operations on domain objects that have previously been deleted, in order to confirm the correct operation of the server’s implementation of RFC 3915.

The client will create a domain name, and any contact and/or host objects, as required.

It will then submit a <renew> command, which MUST succeed. After the <renew> command has been submitted, the value of the s attribute of the <rgpStatus> element MUST be renewPeriod.

(The purpose of the <renew> command is to ensure that the domain does not have the addPeriod RGP status, which ensures that the domain may be restored once deleted.)

The client will then submit a <delete> command for the domain, which MUST succeed.

The client will then submit an RGP restore request: 1. If the epp.restoreReportRequired input parameter is true, then the op attribute of the <restore> element will be report, and a <report> element will be included, that contains the required elements. 2. If the epp.restoreReportRequired input parameter is false, then the op attribute of the <restore> element will be request and no <report> element will be included.

Once the restore request has been processed, the client will perform an <info> command on the object to confirm that the domain no longer has the pendingDelete status and RGP status.

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:

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-23 - Host rename test (if applicable)

7.75.1. Implementation status

7.75.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 create host one or more host objects and the perform <update> commands to confirm that the server correctly accepts or rejects those commands, for example:

  • an <update> command which specifies a syntatically invalid host name is rejected;
  • an <update> command which places the object in a different top-level domain (that uses a different EPP repository) is accepted;
  • an <update> command which places the object within a non-existent domain in the same TLD 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. A <check> command will be used to confirm that the domain exists before the <update> command is submitted.
  • an <update> command which places the object within a domain sponsored by the test client is accepted.

The client will then perform <info> commands on the objects successfully updated, to confirm that the server has correctly stored the updated values.

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):

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. epp-24 - Host <delete> command test (if applicable)

7.76.1. Implementation status

7.76.2. Description

This test will perform create host objects and then confirm that the server responds to a <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 <info> commands to confirm that the objects have been deleted.

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-01 - IDN label validation test

7.77.1. Implementation status

7.77.2. Description

This test case validates that the EPP server correctly validates IDN domains during the EPP <create> process and applies the applicable rules in relation to handling of variants.

Using the TLD(s) to which the test relates, and the sets of allocatable and unallocatable test labels associated with the IDN tables specified for those TLDs, a set of valid and invalid domain names will be generated.

The test client will then connect to the EPP server, and perform <create> commands for each domain, checking to confirm that the EPP server correctly accepts or rejects the command, as applicable.

Where a variant policy is applicable (which is determined by both the IDN table and the policy specified for the TLD), and variant domains are generated, The client will also ensure that the EPP server properly implements that policy: that is, variant domains must (a) be blocked, or (b) only be available for registration by (i) the same registrant, or (ii) if the TLD uses the minimal public data set, the same registrar.

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-02 - ASCII domains in IDN-only TLD test

7.78.1. Implementation status

7.78.2. Description

This test confirms that the EPP server rejects EPP <create> commands for a domain under TLDs that are 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.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. integration-01 - EPP -> RDAP Integration Test

7.79.1. Implementation status

7.79.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 and 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.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:

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. integration-02 - EPP -> DNS Integration Test

7.80.1. Implementation status

7.80.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 DNS 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 integration-01.

The test system will perform DNS queries to confirm that the DNS servers provide responses for the created domain names. All DNS servers MUST provide the correct DNS response for all domains within 1 hour of the domain’s <crDate> element.

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:

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. integration-03 - EPP -> RDE Integration Test

7.81.1. Implementation status

7.81.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 connect to the EPP server and create domain and (if applicable) host and contact objects using the same methodology as integration-01.

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

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:

7.81.5. Data providers

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

  • None specified.

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:

7.81.7. Test suites

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

7.82. minimumRPMs-01 - Claims <check> command test

7.82.1. Implementation status

7.82.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.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:

  • None specified.

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. minimumRPMs-02 - Sunrise domain/launch application <create> command test

7.83.1. Implementation status

7.83.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.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:

  • None specified.

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. minimumRPMs-03 - Trademark claims domain <create> command test

7.84.1. Implementation status

7.84.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.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:

  • None specified.

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:

  • None specified.

7.84.7. Test suites

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

7.85. rdap-01 - Domain query test

7.85.1. Implementation status

7.85.2. Description

This test validates the server’s response to a domain name query.

The client will send domain query requests for each domain name in the rdap.testDomains input parameter and validate the responses for conformance with the gTLD RDAP Profile.

If the value of the general.registryDataModel is minimum, then the response will be validated against the “thin” validation rules, whereas the “thick” rules will be used if the value of the parameter is maximum. If the value is per-registrar, then the response MUST correctly validate against one of the two rulesets.

If any of the responses cannot be validated, then this test case will fail.

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:

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. rdap-02 - Nameserver query test

7.86.1. Implementation status

7.86.2. Description

This test validates the server’s response to a nameserver name query. If the value of the epp.hostModel input parameter is attributes, this test will be skipped. The client will send domain query requests for each nameserver in the rdap.testNameservers input parameter and validate the responses for conformance with the gTLD RDAP Profile. If any of the responses cannot be validated, then this test case will fail.

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. rdap-03 - Registrar query test

7.87.1. Implementation status

7.87.2. Description

This test validates the server’s response to an entity query for a registrar.

The client will send domain query requests for each nameserver in the rdap.testEntities input parameter and validate the responses for conformance with the gTLD RDAP Profile.

If any of the responses cannot be validated, then this test case will fail.

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-04 - Help query test

7.88.1. Implementation status

7.88.2. Description

This test validates the server’s response to a help query.

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

The client will send a help query to each base URL specified in the rdap.baseURLs input parameter, and validate the responses for conformance with the gTLD RDAP Profile.

If any of the responses cannot be validated, then this test case will fail.

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-05 - Domain HEAD test

7.89.1. Implementation status

7.89.2. Description

This test validates that the server supports HEAD requests for domain names.

The client will issue a HEAD request for each domain name in the rdap.testDomains input parameter and confirm that the server sends a response with (a) a status code of 200, (b) a valid access-control-allow-origin header field, and (c) an empty body.

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-06 - Nameserver HEAD test

7.90.1. Implementation status

7.90.2. Description

This test validates that the server supports HEAD requests for nameservers.

The client will issue a HEAD request for each domain name in the rdap.testNameservers input parameter and confirm that the server sends a response with (a) a status code of 200, (b) a valid access-control-allow-origin header field, and (c) an empty body.

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-07 - Entity HEAD test

7.91.1. Implementation status

7.91.2. Description

This test validates that the server supports HEAD requests for entities.

The client will issue a HEAD request for each domain name in the rdap.testEntities input parameter and confirm that the server sends a response with (a) a status code of 200, (b) a valid access-control-allow-origin header field, and (c) an empty body.

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-91 - TLS version conformance check

7.92.1. Implementation status

7.92.2. Description

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

7.92.7. Test suites

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

7.93. rdap-92 - Service port consistency check

7.93.1. Implementation status

7.93.2. Description

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.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. rde-01 - Validate deposit filename format

7.94.1. Implementation status

7.94.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.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. rde-02 - Validate signature over deposit file

7.95.1. Implementation status

7.95.2. Description

The PGP signature MUST be valid for the deposit file and the RSP’s key.

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:

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. rde-03 - Decrypt deposit file(s)

7.96.1. Implementation status

7.96.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.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:

7.96.7. Test suites

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

7.97. rde-04 - Validate XML/CSV

7.97.1. Implementation status

7.97.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.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. rde-05 - Validate object types

7.98.1. Implementation status

7.98.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. At minimum, the list of URIs will include the rdeDomain URI (if using XML) or csvDomain (if using CSV).

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

Namespace URI Deposit type Notes
urn:ietf:params:xml:ns:csvContact-1.0 CSV general.registryDataModel != ‘minimum’
urn:ietf:params:xml:ns:csvDomain-1.0 CSV
urn:ietf:params:xml:ns:csvHost-1.0 CSV epp.hostModel = ‘objects’
urn:ietf:params:xml:ns:csvIDN-1.0 CSV
urn:ietf:params:xml:ns:csvNNDN-1.0 CSV
urn:ietf:params:xml:ns:csvRegistrar-1.0 CSV
urn:ietf:params:xml:ns:rdeContact-1.0 XML general.registryDataModel != ‘minimum’
urn:ietf:params:xml:ns:rdeDomain-1.0 XML
urn:ietf:params:xml:ns:rdeEppParams-1.0 XML
urn:ietf:params:xml:ns:rdeHost-1.0 XML epp.hostModel = ‘objects’
urn:ietf:params:xml:ns:rdeIDN-1.0 XML
urn:ietf:params:xml:ns:rdeNNDN-1.0 XML
urn:ietf:params:xml:ns:rdeRegistrar-1.0 XML

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. rde-06 - Validate object counts

7.99.1. Implementation status

7.99.2. Description

The number of each type of object MUST match the number of objects actually present in the deposit file.

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. rde-07 - Validate domain objects

7.100.1. Implementation status

7.100.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> (which MUST be unique)
  • <domain:roid> (which MUST comply with the specification in Section 2.8 of RFC 5730 and contain a repository ID that is registered in the EPP Repository Identifiers Registry).
  • 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.

If the domain has an <idnTableId> element, its value MUST match the id property of one of the IDN table objects in the deposit.

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. rde-08 - Validate host objects (if applicable)

7.101.1. Implementation status

7.101.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> (which MUST be unique)
  • <host:roid> (which MUST be unique and MUST comply with the specification in Section 2.8 of RFC 5730 and contain a repository ID that is registered in the EPP Repository Identifiers Registry).
  • at least one <host: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.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. rde-09 - Validate contact objects (if applicable)

7.102.1. Implementation status

7.102.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> (which MUST be unique and MUST comply with the specification in Section 2.8 of RFC 5730 and contain a repository ID that is registered in the EPP Repository Identifiers Registry);
  • The object MUST NOT have two <rdeContact:postalInfo> elements with the same type attribute;
  • The value of the <contact:cc> element MUST contain a valid ISO-3166-alpha-2 country code;
  • The value of the <contact:email> element MUST be a valid email address, as described in Section 3.4.1 of RFC 5322.

Registrar objects which are referenced in contact objects MUST be present in the deposit.

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. rde-10 - Validate registrar objects

7.103.1. Implementation status

7.103.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> which MUST be unique;
  • <rdeRegistrar:name>;
  • <rdeRegistrar:gurid> which MUST be a valid Registrar ID.

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. rde-11 - Validate IDN table objects (if applicable)

7.104.1. Implementation status

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

  • The value of the id attribute of all IDN table objects present in the deposit MUST correspond to the language tag of all IDN tables specified for the TLD in the test request, all such tables MUST have a corresponding object in the deposit.
  • The <url> element MUST (if present) contain a valid URL.
  • The <urlPolicy> element MUST (if present) contain a valid URL.

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. rde-12 - Validate NNDN objects

7.105.1. Implementation status

7.105.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 value of the <aName> element MUST NOT match the value of the <name> element of a domain object, or the <aName> element of another NNDN object.
  • The value of the <nameState> MUST contain either blocked, withheld or mirrored.
  • If the NNDN has an <idnTableId> element, its value MUST match the id property of one of the IDN table objects in the deposit.

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. rde-13 - Validate EPP parameters object

7.106.1. Implementation status

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

  • All <objURI> elements present in the EPP greeting MUST be present in the EPP Parameters object, and vice-versa.
  • All <extURI> elements present in the EPP greeting MUST be present in the EPP Parameters object, and vice-versa.

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:

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. rde-14 - Validate policy object (if applicable)

7.107.1. Implementation status

7.107.2. Description

The object policies specified by the <rdePolicy:policy> object(s) in the deposit MUST conform to the Registration Data Policy and the applicable data model.

  • If the general.registryDataModel input parameter is maximum or per-registrar, then a policy object that identifies the <registrant> element of domain objects MUST be present.

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. srsgw-01 - IPv4 and IPv6 connectivity

7.108.1. Implementation status

7.108.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.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. srsgw-02 - Host <create> synchronization (if applicable)

7.109.1. Implementation status

7.109.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.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. srsgw-03 - Contact <create> synchronization (if applicable)

7.110.1. Implementation status

7.110.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 srsgw.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 srsgw.eppClid01DataModel and epp.eppClid02DataModel 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.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. srsgw-04 - Domain <create> synchronization

7.111.1. Implementation status

7.111.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 will be created 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.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:

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. srsgw-05 - Domain <renew> synchronisation

7.112.1. Implementation status

7.112.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 <create> commands for a pseudo-randomly generated domain name. Contact and nameserver will be created if required. The server MUST respond with a 1000 or 1001 response.

It will then submit a <renew> command. The server MUST respond with a 1000 or 1001 response. The client will then perform <info> commands and will capture the responses.

It will wait for 30 seconds, and 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.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:

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. srsgw-06 - Domain <transfer> synchronisation

7.113.1. Implementation status

7.113.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 submit <create> commands for a pseudo-randomly generated domain name. Contact and nameserver will be created if required. The server MUST respond with a 1000 or 1001 response. It will then submit an <update> command to set an authInfo code for the domain. 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"> The server MUST respond with a 1000 or 1001 response.

It will wait for 30 seconds, and 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.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:

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. srsgw-07 - Domain <transfer> approval synchronisation

7.114.1. Implementation status

7.114.2. Description

This test confirms that transfer request approvals submitted in the SRS Gateway EPP system are correctly synchronized with the primary registry system.

The test client will repeat the procedure described in srsgw-06 to create a domain name, set its authInfo code, and then submit a transfer request.

If the response to the <transfer op="request"> command is 1001, then the client will connect to the SRS Gateway EPP system, authenticate, and perform an <transfer op="approve"> command. The server MUST respond with a 1000 or 1001 response.

It will wait for 30 seconds, and 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.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:

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. srsgw-08 - Domain <delete> synchronisation

7.115.1. Implementation status

7.115.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, and submit <create> commands for a pseudo-randomly generated domain name. Contact and nameserver will be created if required. The server MUST respond with a 1000 or 1001 response. It will then submit a <renew> command to ensure that the domain does not have the addPeriod status.

It will wait for 30 seconds, and then connect to the primary EPP system, authenticate, and perform an <info> command. The server MUST respond with a 1000 response.

The client will then reconnect to the SRS Gateway EPP system, authenticate, and submit a <delete> command. The server MUST respond with a 1001 response.

Finally, the client will reconnect to the primary EPP system, authenticate, and perform an <info> command. The server MUST respond with a 1000 response.

The domain object MUST have the pendingDelete status and have an RGP status of pendingDeleteRestorable.

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:

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:

  • None specified.

7.115.7. Test suites

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

7.116. srsgw-09 - Host <update> synchronization (if applicable)

7.116.1. Implementation status

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

It will wait for 30 seconds, and 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.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. srsgw-10 - Host <delete> synchronization (if applicable)

7.117.1. Implementation status

7.117.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.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. srsgw-11 - Contact <update> synchronization (if applicable)

7.118.1. Implementation status

7.118.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 srsgw.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 srsgw.eppClid01DataModel and srsgw.eppClid02DataModel 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.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:

  • None specified.

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. srsgw-12 - Contact <delete> synchronization (if applicable)

7.119.1. Implementation status

7.119.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 srsgw.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 srsgw.eppClid01DataModel and srsgw.eppClid02DataModel 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.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:

  • None specified.

7.119.7. Test suites

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

7.120. srsgw-13 - Domain RDAP synchronization

7.120.1. Implementation status

7.120.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 connect to the SRS Gateway EPP server and create one domain name for each TLD in the TLD set, and any required host and/or contact objects. This stage MUST complete successfully. Then, after 30 seconds, it will perform RDAP queries for those domains against both the primary registry RDAP server and the SRS Gateway RDAP server. The RDAP requests MUST be successful.

After canonicalization (see RFC 8785), the JSON responses from each server MUST be identical, with the sole exception of event objects with eventAction properties equal to “last update of RDAP database”.

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. srsgw-14 - Nameserver RDAP synchronization

7.121.1. Implementation status

7.121.2. Description

This test confirms that the SRS Gateway’s RDAP service provides responses to nameserver 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 canonicalization (see RFC 8785), the JSON responses from each server MUST be identical, with the sole exception of event objects with eventAction properties equal to “last update of RDAP database”.

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. srsgw-15 - Registrar RDAP synchronization

7.122.1. Implementation status

7.122.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 client will connect to the SRS Gateway EPP system, authenticate, and submit a <create> command for a pseudo-randomly generated domain name. Host and/or contact objects will created as needed.

The test system will then perform RDAP queries for this domain 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 canonicalization (see RFC 8785), the JSON responses from each server MUST be identical, with the sole exception of event objects with eventAction properties equal to “last update of RDAP database”.

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):

8. Input Parameters

8.1. dns.nameservers

8.1.1. Description

The set of nameservers that will be authoritative for the TLD.

This input parameter is an array containing objects representing TLDs, and the corresponding nameservers.

There MUST be an entry for every TLD in the TLD set.

8.1.2. Required

This input parameter is REQUIRED.

8.1.3. Example

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

8.1.4. Schema

items:
  properties:
    name:
      description: The TLD name.
      format: hostname
      type: string
    nameservers:
      description: The nameservers for the TLD
      items:
        properties:
          name:
            description: The fully-qualified nameserver name.
            format: hostname
            type: string
          supportsDoH:
            default: false
            description: |
              Whether this nameserver supports DNS over HTTPS ([RFC
              8484](https://www.rfc-editor.org/rfc/rfc8484.html)).
            type: boolean
          supportsDoQ:
            default: false
            description: |
              Whether this nameserver supports DNS over Dedicated QUIC
              Connections ([RFC
              9250](https://www.rfc-editor.org/rfc/rfc9250.html)).
            type: boolean
          supportsDoT:
            default: false
            description: |
              Whether this nameserver supports DNS over TLS ([RFC
              7858](https://www.rfc-editor.org/rfc/rfc7858.html)).
            type: boolean
          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
        type: object
      minItems: 2
      type: array
  required:
  - name
  - nameservers
  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 array containing objects representing TLDs, and the corresponding DS record(s).

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.

This value of this input parameter MUST NOT be the same as the values of the dnssecOps.kskRolloverZone and dnssecOps.zskRolloverZone parameters.

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.

This value of this input parameter MUST NOT be the same as the values of the dnssecOps.zskRolloverZone and dnssecOps.algorithmRolloverZone parameters.

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.

This value of this input parameter MUST NOT be the same as the values of the dnssecOps.kskRolloverZone and dnssecOps.algorithmRolloverZone parameters.

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:

  • None specified.

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 NOT 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 NOT 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:

  • None specified.

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:

  • None specified.

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:

  • None specified.

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 minimum, this parameter MUST be omitted. Otherwise, at least two contact IDs MUST be provided.

8.19.2. Required

This input parameter is NOT required.

8.19.3. Example

{
   "epp.registeredContacts" : [
      "abc123",
      "def321"
   ]
}

8.19.4. Schema

items:
  type: string
minItems: 2
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, for each TLD in the TLD set, this array MUST contain one hostname which is subordinate to that TLD.

However, if it is attributes, this parameter MUST be omitted.

8.21.2. Required

This input parameter is NOT required.

8.21.3. Example

{
   "epp.registeredNameservers" : [
      "ns1.example.example1",
      "ns2.example.example2"
   ]
}

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

8.22.1. Description

This input parameter is complementary to the epp.supportedContactElements parameter. It may be used to indicate those elements which are optional in RFC 5733 but are mandatory in the server policy.

All elements that are listed in this parameter MUST also be listed in the epp.supportedContactElements parameter.

This input parameter is an array of element tag names, optionally suffixed with a colon (:) followed by an attribute name.

8.22.2. Required

This input parameter is NOT required.

8.22.3. Example

{
   "epp.requiredContactElements" : [
      "street",
      "voice"
   ]
}

8.22.4. Schema

items:
  enum:
  - org
  - street
  - sp
  - pc
  - voice
  - voice:ext
  - fax
  - fax:ext
  type: string
type: array

8.22.5. Test cases

This input parameter is used in the following test cases:

  • None specified.

8.22.6. Test suites

This input parameter is also used in the following test suites:

8.23. epp.requiredContactTypes

8.23.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.23.2. Required

This input parameter is REQUIRED.

8.23.3. Example

{
   "epp.requiredContactTypes" : [
      "admin"
   ]
}

8.23.4. Schema

items:
  enum:
  - admin
  - tech
  - billing
  type: string
type: array

8.23.5. Test cases

This input parameter is used in the following test cases:

  • None specified.

8.23.6. Test suites

This input parameter is also used in the following test suites:

8.24. epp.restoreReportRequired

8.24.1. Description

Whether the server requires submission of a restore report when a client attempts to restore a domain.

8.24.2. Required

This input parameter is REQUIRED.

8.24.3. Example

{
   "epp.restoreReportRequired" : false
}

8.24.4. Schema

type: boolean

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

8.25.1. Description

Which of the interfaces defined in Section 4 of RFC 5910 the server supports (either dsData or keyData).

8.25.2. Required

This input parameter is REQUIRED.

8.25.3. Example

{
   "epp.secDNSInterfaces" : "dsData"
}

8.25.4. Schema

enum:
- dsData
- keyData
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:

  • None specified.

8.26. epp.serverIssuedClientCertificate01

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.client01CSR 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 MUST be empty.

8.26.2. Required

This input parameter is NOT required.

8.26.3. Example

{
   "epp.serverIssuedClientCertificate01" : "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. epp.serverIssuedClientCertificate02

8.27.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.client02CSR 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 MUST be omitted.

8.27.2. Required

This input parameter is NOT required.

8.27.3. Example

{
   "epp.serverIssuedClientCertificate02" : "rst_test_client_cert.pem"
}

8.27.4. Schema

type: string

8.27.5. Test cases

This input parameter is used in the following test cases:

  • None specified.

8.27.6. Test suites

This input parameter is also used in the following test suites:

8.28. epp.supportedContactElements

8.28.1. Description

In RFC 5733, the mandatory elements that MUST be included in contact <create> commands are <name>, <city>, <cc> and <email>. RFC 5733 also specifies a set of optional elements. To comply with RFC 5733, EPP servers MUST accept and process the mandatory elements, but MAY reject commands that contain optional elements.

This input parameter should be used to indicate which of the optional elements the EPP server supports.

If the value contains a colon (:), then the first part is the element name and the second part is an attribute name.

Elements that are listed in this parameter MAY also be listed in the epp.requiredContactElements parameter.

8.28.2. Required

This input parameter is REQUIRED.

8.28.3. Example

{
   "epp.supportedContactElements" : [
      "org",
      "street",
      "sp",
      "pc",
      "voice",
      "voice:ext"
   ]
}

8.28.4. Schema

items:
  enum:
  - org
  - street
  - sp
  - pc
  - voice
  - voice:ext
  - fax
  - fax:ext
  type: string
type: array

8.28.5. Test cases

This input parameter is used in the following test cases:

  • None specified.

8.28.6. Test suites

This input parameter is also used in the following test suites:

8.29. general.registryDataModel

8.29.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.29.2. Required

This input parameter is REQUIRED.

8.29.3. Example

{
   "general.registryDataModel" : "minimum"
}

8.29.4. Schema

enum:
- minimum
- maximum
- per-registrar
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:

8.30. integration.rdeSFTPDirectory

8.30.1. Description

The directory on the SFTP server where deposit files may be found.

8.30.2. Required

This input parameter is REQUIRED.

8.30.3. Example

{
   "integration.rdeSFTPDirectory" : "/path/to/deposits"
}

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

8.31.1. Description

The hostname of the operator’s SFTP server.

8.31.2. Required

This input parameter is REQUIRED.

8.31.3. Example

{
   "integration.rdeSFTPHostname" : "sftp.rsp.tech"
}

8.31.4. Schema

format: hostname
type: string

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. integration.rdeSFTPUsername

8.32.1. Description

The username that can be used to connect to the SFTP server.

8.32.2. Required

This input parameter is REQUIRED.

8.32.3. Example

{
   "integration.rdeSFTPUsername" : "icann"
}

8.32.4. Schema

type: string

8.32.5. Test cases

This input parameter is used in the following test cases:

8.32.6. Test suites

This input parameter is also used in the following test suites:

  • None specified.

8.33. integration.rriACL

8.33.1. Description

An object representing the IP addresses from which requests to the RRI will be sent.

8.33.2. Required

This input parameter is REQUIRED.

8.33.3. Example

{
   "integration.rriACL" : {
      "v4Addrs" : [
         "192.0.2.1",
         "192.0.2.2"
      ],
      "v6Addrs" : [
         "2001:DB8::22:1",
         "2001:DB8::22:2"
      ]
   }
}

8.33.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.33.5. Test cases

This input parameter is used in the following test cases:

8.33.6. Test suites

This input parameter is also used in the following test suites:

  • None specified.

8.34. minimumRPMS.claimsTLD

8.34.1. Description

A TLD, or other registry-class zone, which has been configured to be in perpetual trademark claims.

8.34.2. Required

This input parameter is REQUIRED.

8.34.3. Example

{
   "minimumRPMS.claimsTLD" : "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. minimumRPMS.sunriseModels

8.35.1. Description

The sunrise models supported by the EPP server. The possible values for this parameter are: * start-date * end-date * both

8.35.2. Required

This input parameter is REQUIRED.

8.35.3. Example

{
   "minimumRPMS.sunriseModels" : "start-date"
}

8.35.4. Schema

enum:
- start-date
- end-date
- both
type: string

8.35.5. Test cases

This input parameter is used in the following test cases:

  • None specified.

8.35.6. Test suites

This input parameter is also used in the following test suites:

8.36. minimumRPMS.sunriseTLD

8.36.1. Description

A TLD, or other registry-class zone, which has been configured to be in perpetual sunrise.

8.36.2. Required

This input parameter is REQUIRED.

8.36.3. Example

{
   "minimumRPMS.sunriseTLD" : "tmclaims.rsp.tech"
}

8.36.4. Schema

format: hostname
type: string

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

8.37.1. Description

The RDAP base URL(s) for the TLD(s). A base URL MUST be provided for each TLD being tested.

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.37.2. Required

This input parameter is REQUIRED.

8.37.3. Example

{
   "rdap.baseURLs" : [
      {
         "baseURL" : "https://rdap.example.com/example/",
         "tld" : "example"
      }
   ]
}

8.37.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.37.5. Test cases

This input parameter is used in the following test cases:

8.37.6. Test suites

This input parameter is also used in the following test suites:

8.38. rdap.profileVersion

8.38.1. Description

The version of the gTLD RDAP Profile that is supported. For more information, please see https://www.icann.org/gtld-rdap-profile.

  • Before 2024-08-21, gTLD registries MUST implement the February-2019 version of the gTLD RDAP profile.

  • From 2024-08-21 to 2025-08-20, gTLD registries MAY implement either the February-2019 or the February-2024 version of the gTLD RDAP profile.

  • From 2025-08-21 onwards, gTLD registries MUST implement the February-2024 version of the gTLD RDAP profile.

8.38.2. Required

This input parameter is REQUIRED.

8.38.3. Example

{
   "rdap.profileVersion" : "february-2019"
}

8.38.4. Schema

enum:
- february-2019
- february-2024
type: string

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. rdap.testDomains

8.39.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.39.2. Required

This input parameter is REQUIRED.

8.39.3. Example

{
   "rdap.testDomains" : [
      {
         "name" : "example.example",
         "tld" : "example"
      }
   ]
}

8.39.4. Schema

items:
  properties:
    name:
      description: The domain name.
      format: hostname
      type: string
    tld:
      description: The TLD or equivalent registry-class domain name.
      format: hostname
      type: string
  required:
  - tld
  - name
  type: object
minItems: 1
type: array

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. rdap.testEntities

8.40.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.40.2. Required

This input parameter is REQUIRED.

8.40.3. Example

{
   "rdap.testEntities" : [
      {
         "handle" : 9995,
         "tld" : "example"
      }
   ]
}

8.40.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.40.5. Test cases

This input parameter is used in the following test cases:

  • None specified.

8.40.6. Test suites

This input parameter is also used in the following test suites:

8.41. rdap.testNameservers

8.41.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.41.2. Required

This input parameter is REQUIRED.

8.41.3. Example

{
   "rdap.testNameservers" : [
      {
         "nameserver" : "ns1.example.com",
         "tld" : "example1"
      },
      {
         "nameserver" : "ns1.example.com",
         "tld" : "example2"
      }
   ]
}

8.41.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.41.5. Test cases

This input parameter is used in the following test cases:

  • None specified.

8.41.6. Test suites

This input parameter is also used in the following test suites:

8.42. rde.depositFile

8.42.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.42.2. Required

This input parameter is REQUIRED.

8.42.3. Example

{
   "rde.depositFile" : "example_20231004_FULL_S1_R0.ryde"
}

8.42.4. Schema

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. rde.publicKey

8.43.1. Description

a PGP public key block

8.43.2. Required

This input parameter is REQUIRED.

8.43.3. Example

{
   "rde.publicKey" : "rsp-rde-signing-key.asc"
}

8.43.4. Schema

type: string

8.43.5. Test cases

This input parameter is used in the following test cases:

8.43.6. Test suites

This input parameter is also used in the following test suites:

  • None specified.

8.44. rde.signatureFile

8.44.1. Description

an ASCII-armoured OpenPGP signature covering the deposit file

8.44.2. Required

This input parameter is REQUIRED.

8.44.3. Example

{
   "rde.signatureFile" : "example_20231004_FULL_S1_R0.sig"
}

8.44.4. Schema

type: string

8.44.5. Test cases

This input parameter is used in the following test cases:

8.44.6. Test suites

This input parameter is also used in the following test suites:

  • None specified.

8.45. srsgw.domainCreateExtension

8.45.1. Description

If a domain <create> command submitted through the SRS Gateway requires one or more extension in its <extension> element in order to succeed, then this parameter can be used to provide the XML syntax that should be used.

This parameter should contain a valid EPP <extension> element containing all the extension elements that are required for the domain <create> command. This element will be imported into the domain <create> command frame before being sent to the server.

The XML namespace URIs of the child elements of the <extension> element MUST appear in <extURI> elements in the <greeting> and the extensions MUST be registered in the EPP Extension Registry.

If no extensions are required, this input parameter MUST be omitted. If provided, it will not be validated until the test run occurs, at which point an SRSGW_EPP_INVALID_EXTENSION error will be emitted.

8.45.2. Required

This input parameter is NOT required.

8.45.3. Example

{
   "srsgw.domainCreateExtension" : "<extension xmlns='urn:ietf:params:xml:ns:epp-1.0'>\n  <allocationToken xmlns='urn:ietf:params:xml:ns:allocationToken-1.0'>\n    abc123\n  </allocationToken>\n</extension>\n"
}

8.45.4. Schema

type: string

8.45.5. Test cases

This input parameter is used in the following test cases:

8.45.6. Test suites

This input parameter is also used in the following test suites:

  • None specified.

8.46. srsgw.domainDeleteExtension

8.46.1. Description

This input parameter is used to provide the extension elements required to perform a domain <update> command through the SRS Gateway. Other than the different EPP command it relates to, it is identical to the srsgw.domainCreateExtension element.

8.46.2. Required

This input parameter is NOT required.

8.46.3. Example

{
   "srsgw.domainDeleteExtension" : "<!-- see srsgw.domainCreateExtension -->"
}

8.46.4. Schema

type: string

8.46.5. Test cases

This input parameter is used in the following test cases:

8.46.6. Test suites

This input parameter is also used in the following test suites:

  • None specified.

8.47. srsgw.domainRenewExtension

8.47.1. Description

This input parameter is used to provide the extension elements required to perform a domain <renew> command through the SRS Gateway. Other than the different EPP command it relates to, it is identical to the srsgw.domainCreateExtension element.

8.47.2. Required

This input parameter is NOT required.

8.47.3. Example

{
   "srsgw.domainRenewExtension" : "<!-- see srsgw.domainCreateExtension -->"
}

8.47.4. Schema

type: string

8.47.5. Test cases

This input parameter is used in the following test cases:

8.47.6. Test suites

This input parameter is also used in the following test suites:

  • None specified.

8.48. srsgw.domainTransferApproveExtension

8.48.1. Description

This input parameter is used to provide the extension elements required to perform a domain <transfer op="approve"> command through the SRS Gateway. Other than the different EPP command it relates to, it is identical to the srsgw.domainCreateExtension element.

8.48.2. Required

This input parameter is NOT required.

8.48.3. Example

{
   "srsgw.domainTransferApproveExtension" : "<!-- see srsgw.domainCreateExtension -->"
}

8.48.4. Schema

type: string

8.48.5. Test cases

This input parameter is used in the following test cases:

8.48.6. Test suites

This input parameter is also used in the following test suites:

  • None specified.

8.49. srsgw.domainTransferRequestExtension

8.49.1. Description

This input parameter is used to provide the extension elements required to perform a domain <transfer op="request"> command through the SRS Gateway. Other than the different EPP command it relates to, it is identical to the srsgw.domainCreateExtension element.

8.49.2. Required

This input parameter is NOT required.

8.49.3. Example

{
   "srsgw.domainTransferRequestExtension" : "<!-- see srsgw.domainCreateExtension -->"
}

8.49.4. Schema

type: string

8.49.5. Test cases

This input parameter is used in the following test cases:

8.49.6. Test suites

This input parameter is also used in the following test suites:

  • None specified.

8.50. srsgw.eppClid01

8.50.1. Description

the username used to log in to the SRS Gateway EPP server.

8.50.2. Required

This input parameter is REQUIRED.

8.50.3. Example

{
   "srsgw.eppClid01" : "clid-01"
}

8.50.4. Schema

minLength: 3
type: string

8.50.5. Test cases

This input parameter is used in the following test cases:

  • None specified.

8.50.6. Test suites

This input parameter is also used in the following test suites:

8.51. srsgw.eppClid01DataModel

8.51.1. Description

The data model for the srsgw.eppClid01 client. This may be omitted and will in any case be ignored unless the value of the srsgw.registryDataModel input parameter is per-registrar.

If set, then the value of this input parameter MUST be different from the value of the srsgw.eppClid02DataModel input parameter.

8.51.2. Required

This input parameter is NOT required.

8.51.3. Example

{
   "srsgw.eppClid01DataModel" : "minimum"
}

8.51.4. Schema

enum:
- minimum
- maximum
type: string

8.51.5. Test cases

This input parameter is used in the following test cases:

  • None specified.

8.51.6. Test suites

This input parameter is also used in the following test suites:

8.52. srsgw.eppClid02

8.52.1. Description

the username used for transfer tests.

8.52.2. Required

This input parameter is REQUIRED.

8.52.3. Example

{
   "srsgw.eppClid02" : "clid-02"
}

8.52.4. Schema

type: string

8.52.5. Test cases

This input parameter is used in the following test cases:

  • None specified.

8.52.6. Test suites

This input parameter is also used in the following test suites:

8.53. srsgw.eppClid02DataModel

8.53.1. Description

The data model for the srsgw.eppClid02 client. This may be omitted and will in any case be ignored unless the value of the srsgw.registryDataModel input parameter is per-registrar.

If set, then the value of this input parameter MUST be different from the value of the srsgw.eppClid01DataModel input parameter.

8.53.2. Required

This input parameter is NOT required.

8.53.3. Example

{
   "srsgw.eppClid02DataModel" : "minimum"
}

8.53.4. Schema

enum:
- minimum
- maximum
type: string

8.53.5. Test cases

This input parameter is used in the following test cases:

  • None specified.

8.53.6. Test suites

This input parameter is also used in the following test suites:

8.54. srsgw.eppHostName

8.54.1. Description

the fully-qualified domain name of the SRS Gateway EPP server.

8.54.2. Required

This input parameter is REQUIRED.

8.54.3. Example

{
   "srsgw.eppHostName" : "epp.rsp.tech"
}

8.54.4. Schema

format: hostname
type: string

8.54.5. Test cases

This input parameter is used in the following test cases:

  • None specified.

8.54.6. Test suites

This input parameter is also used in the following test suites:

8.55. srsgw.eppPwd01

8.55.1. Description

the password used to log in to the SRS Gateway EPP server.

8.55.2. Required

This input parameter is REQUIRED.

8.55.3. Example

{
   "srsgw.eppPwd01" : "foo2bar"
}

8.55.4. Schema

type: string

8.55.5. Test cases

This input parameter is used in the following test cases:

  • None specified.

8.55.6. Test suites

This input parameter is also used in the following test suites:

8.56. srsgw.eppPwd02

8.56.1. Description

the password used for transfer tests.

8.56.2. Required

This input parameter is REQUIRED.

8.56.3. Example

{
   "srsgw.eppPwd02" : "foo3bar"
}

8.56.4. Schema

type: string

8.56.5. Test cases

This input parameter is used in the following test cases:

  • None specified.

8.56.6. Test suites

This input parameter is also used in the following test suites:

8.57. srsgw.eppRequiredContactElements

8.57.1. Description

This input parameter has the same semantics as the epp.requiredContactElements input parameter but relates to the SRS Gateway EPP Server.

8.57.2. Required

This input parameter is REQUIRED.

8.57.3. Example

{
   "srsgw.eppRequiredContactElements" : [
      "org",
      "street",
      "sp",
      "pc",
      "voice",
      "voice:ext"
   ]
}

8.57.4. Schema

items:
  enum:
  - org
  - street
  - sp
  - pc
  - voice
  - voice:ext
  - fax
  - fax:ext
  type: string
type: array

8.57.5. Test cases

This input parameter is used in the following test cases:

  • None specified.

8.57.6. Test suites

This input parameter is also used in the following test suites:

8.58. srsgw.eppRequiredContactTypes

8.58.1. Description

This input parameter has the same semantics as the epp.requiredContactTypes input parameter but relates to the SRS Gateway EPP Server.

8.58.2. Required

This input parameter is REQUIRED.

8.58.3. Example

{
   "srsgw.eppRequiredContactTypes" : [
      "admin"
   ]
}

8.58.4. Schema

items:
  enum:
  - admin
  - tech
  - billing
  type: string
type: array

8.58.5. Test cases

This input parameter is used in the following test cases:

  • None specified.

8.58.6. Test suites

This input parameter is also used in the following test suites:

8.59. srsgw.eppSupportedContactElements

8.59.1. Description

This input parameter has the same semantics as the epp.supportedContactElements input parameter but relates to the SRS Gateway EPP Server.

8.59.2. Required

This input parameter is NOT required.

8.59.3. Example

{
   "srsgw.eppSupportedContactElements" : [
      "org",
      "street",
      "sp",
      "pc",
      "voice",
      "voice:ext"
   ]
}

8.59.4. Schema

items:
  enum:
  - org
  - street
  - sp
  - pc
  - voice
  - voice:ext
  - fax
  - fax:ext
  type: string
type: array

8.59.5. Test cases

This input parameter is used in the following test cases:

  • None specified.

8.59.6. Test suites

This input parameter is also used in the following test suites:

8.60. srsgw.rdapBaseURLs

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

If an RDAP Base URL includes a port, it MUST be 443.

8.60.2. Required

This input parameter is REQUIRED.

8.60.3. Example

{
   "srsgw.rdapBaseURLs" : [
      {
         "baseURL" : "https://rdap.example.com/example/",
         "tld" : "example"
      }
   ]
}

8.60.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.60.5. Test cases

This input parameter is used in the following test cases:

  • None specified.

8.60.6. Test suites

This input parameter is also used in the following test suites:

8.61. srsgw.registryDataModel

8.61.1. Description

This input parameter identifies the data model for the SRS Gateway, which may be different to that of the Primary EPP server (for example, because the Gateway requires registrant information in order to verify their identity).

It has identical semantics to the general.registryDataModel input parameter.

8.61.2. Required

This input parameter is REQUIRED.

8.61.3. Example

{
   "srsgw.registryDataModel" : "minimum"
}

8.61.4. Schema

enum:
- minimum
- maximum
- per-registrar
type: string

8.61.5. Test cases

This input parameter is used in the following test cases:

  • None specified.

8.61.6. Test suites

This input parameter is also used in the following test suites:

8.62. srsgw.serverIssuedClientCertificate01

8.62.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.client01CSR 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.62.2. Required

This input parameter is REQUIRED.

8.62.3. Example

{
   "srsgw.serverIssuedClientCertificate01" : "cert.pem"
}

8.62.4. Schema

type: string

8.62.5. Test cases

This input parameter is used in the following test cases:

  • None specified.

8.62.6. Test suites

This input parameter is also used in the following test suites:

8.63. srsgw.serverIssuedClientCertificate02

8.63.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.client02CSR 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.63.2. Required

This input parameter is REQUIRED.

8.63.3. Example

{
   "srsgw.serverIssuedClientCertificate02" : "cert.pem"
}

8.63.4. Schema

type: string

8.63.5. Test cases

This input parameter is used in the following test cases:

  • None specified.

8.63.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_CONSISTENCY_QUERY_FAILED

9.16.1. Severity

9.16.2. Description

One or more responses to DNS queries sent to the subject DNS servers failed.

9.16.3. Test cases

This error may be produced by the following test cases:

9.17. DNS_IDNA2008_INVALID_MNAME

9.17.1. Severity

9.17.2. Description

The mname field of the SOA record 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_NS_NSDNAME

9.18.1. Severity

9.18.2. Description

One or more NS records at the zone apex 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_INVALID_RNAME

9.19.1. Severity

9.19.2. Description

The rname field of the SOA record contains one or more labels that are not compliant with IDNA2008.

9.19.3. Test cases

This error may be produced by the following test cases:

9.20. DNS_IDNA2008_QUERY_FAILED

9.20.1. Severity

9.20.2. Description

The SOA query failed.

9.20.3. Test cases

This error may be produced by the following test cases:

9.21. DNS_INCONSISTENT_RESPONSES

9.21.1. Severity

9.21.2. Description

One or more responses to DNS queries sent to the subject DNS servers were not consistent across all vantage points.

9.21.3. Test cases

This error may be produced by the following test cases:

9.22. EPP_CONTACT_CHECK_INVALID_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_REGISTERED_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_CHECK_VALID_CONTACT_ID_INCORRECT_AVAIL

9.24.1. Severity

9.24.2. Description

The server responded to a <check> command with an unexpected value in one or more of the avail attributes.

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_CC

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 <cc> 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_CITY

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 <city> 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_EMAIL

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 <email> 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_FAX

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 <fax> 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_FAX_EXT

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 ext attribute of the <fax> 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_ID

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 <id> 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_NAME

9.31.1. Severity

9.31.2. Description

Following a successful contact <create> command, a subsequent <info> response for the created object contained an incorrect or missing <name> element.

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_ORG

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 <org> 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_PC

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 <pc> 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_POSTALINFO_TYPE

9.34.1. Severity

9.34.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.34.3. Test cases

This error may be produced by the following test cases:

9.35. EPP_CONTACT_CREATE_INFO_RESPONSE_MISSING_OR_INCORRECT_SP

9.35.1. Severity

9.35.2. Description

Following a successful contact <create> command, a subsequent <info> response for the created object contained an incorrect or missing <sp> element.

9.35.3. Test cases

This error may be produced by the following test cases:

9.36. EPP_CONTACT_CREATE_INFO_RESPONSE_MISSING_OR_INCORRECT_STREET

9.36.1. Severity

9.36.2. Description

Following a successful contact <create> command, a subsequent <info> response for the created object contained an incorrect or missing <status> element.

9.36.3. Test cases

This error may be produced by the following test cases:

9.37. EPP_CONTACT_CREATE_INFO_RESPONSE_MISSING_OR_INCORRECT_VOICE

9.37.1. Severity

9.37.2. Description

Following a successful contact <create> command, a subsequent <info> response for the created object contained an incorrect or missing <voice> element.

9.37.3. Test cases

This error may be produced by the following test cases:

9.38. EPP_CONTACT_CREATE_INFO_RESPONSE_MISSING_OR_INCORRECT_VOICE_EXT

9.38.1. Severity

9.38.2. Description

Following a successful contact <create> command, a subsequent <info> response for the created object contained an incorrect or missing ext attribute of the <voice> element.

9.38.3. Test cases

This error may be produced by the following test cases:

9.39. EPP_CONTACT_CREATE_INFO_RESPONSE_NOT_1000

9.39.1. Severity

9.39.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.39.3. Test cases

This error may be produced by the following test cases:

9.40. EPP_CONTACT_CREATE_SERVER_ACCEPTS_EMPTY_CC

9.40.1. Severity

9.40.2. Description

The server incorrectly accepted an empty value for the <cc> 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_CITY

9.41.1. Severity

9.41.2. Description

The server incorrectly accepted an empty value for the <name> 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_EMPTY_EMAIL

9.42.1. Severity

9.42.2. Description

The server incorrectly accepted an empty value for the <email> 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_EMPTY_FAX

9.43.1. Severity

9.43.2. Description

The server incorrectly accepted an empty value for the <fax> 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_EMPTY_NAME

9.44.1. Severity

9.44.2. Description

The server incorrectly accepted an empty value for the <name> 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_EMPTY_VOICE

9.45.1. Severity

9.45.2. Description

The server incorrectly accepted an empty value for the <voice> 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_CC

9.46.1. Severity

9.46.2. Description

The server incorrectly accepted an invalid value for the <cc> 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_CITY

9.47.1. Severity

9.47.2. Description

The server incorrectly accepted an empty value for the <city> 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_EMAIL

9.48.1. Severity

9.48.2. Description

The server incorrectly accepted an invalid value for the <email> 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_FAX

9.49.1. Severity

9.49.2. Description

The server incorrectly accepted an invalid value for the <fax> 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_ID

9.50.1. Severity

9.50.2. Description

The server incorrectly accepted an invalid value for the <id> 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_CREATE_SERVER_ACCEPTS_INVALID_NAME

9.51.1. Severity

9.51.2. Description

The server incorrectly accepted an invalid value for the <name> element in a contact <create> command.

9.51.3. Test cases

This error may be produced by the following test cases:

9.52. EPP_CONTACT_CREATE_SERVER_ACCEPTS_INVALID_ORG

9.52.1. Severity

9.52.2. Description

The server incorrectly accepted an invalid value for the <org> element in a contact <create> command.

9.52.3. Test cases

This error may be produced by the following test cases:

9.53. EPP_CONTACT_CREATE_SERVER_ACCEPTS_INVALID_POSTALINFO_TYPE

9.53.1. Severity

9.53.2. Description

The server incorrectly accepted an invalid value for the type attribute of the <postalInfo> element in a contact <create> command.

9.53.3. Test cases

This error may be produced by the following test cases:

9.54. EPP_CONTACT_CREATE_SERVER_ACCEPTS_INVALID_STREET

9.54.1. Severity

9.54.2. Description

The server incorrectly accepted an invalid value for the <street> element in a contact <create> command.

9.54.3. Test cases

This error may be produced by the following test cases:

9.55. EPP_CONTACT_CREATE_SERVER_ACCEPTS_INVALID_VOICE

9.55.1. Severity

9.55.2. Description

The server incorrectly accepted an invalid value for the <voice> element in a contact <create> command.

9.55.3. Test cases

This error may be produced by the following test cases:

9.56. EPP_CONTACT_DELETE_OBJECT_STILL_EXISTS

9.56.1. Severity

9.56.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.56.3. Test cases

This error may be produced by the following test cases:

9.57. EPP_CONTACT_DELETE_RESPONSE_NOT_1000_OR_1001

9.57.1. Severity

9.57.2. Description

The server did not response to a contact <delete> command with a 1xxx result code.

9.57.3. Test cases

This error may be produced by the following test cases:

9.58. EPP_CONTACT_INFO_RESPONSE_NOT_2201

9.58.1. Severity

9.58.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.58.3. Test cases

This error may be produced by the following test cases:

9.59. EPP_CONTACT_UPDATE_INFO_RESPONSE_MISSING_OR_INCORRECT_CC

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 <cc> 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_CITY

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 <city> 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_EMAIL

9.61.1. Severity

9.61.2. Description

Following a successful contact <update> command, a subsequent <info> response for the created object contained an incorrect or missing <email> element.

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_FAX

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 <fax> 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_FAX_EXT

9.63.1. Severity

9.63.2. Description

Following a successful contact <update> command, a subsequent <info> response for the created object contained an incorrect or missing ext attribute of the <fax> element.

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_ID

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 <id> 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_NAME

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 <name> element.

9.65.3. Test cases

This error may be produced by the following test cases:

9.66. EPP_CONTACT_UPDATE_INFO_RESPONSE_MISSING_OR_INCORRECT_ORG

9.66.1. Severity

9.66.2. Description

Following a successful contact <update> command, a subsequent <info> response for the created object contained an incorrect or missing <org> element.

9.66.3. Test cases

This error may be produced by the following test cases:

9.67. EPP_CONTACT_UPDATE_INFO_RESPONSE_MISSING_OR_INCORRECT_PC

9.67.1. Severity

9.67.2. Description

Following a successful contact <update> command, a subsequent <info> response for the created object contained an incorrect or missing <pc> element.

9.67.3. Test cases

This error may be produced by the following test cases:

9.68. EPP_CONTACT_UPDATE_INFO_RESPONSE_MISSING_OR_INCORRECT_POSTALINFO_TYPE

9.68.1. Severity

9.68.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.68.3. Test cases

This error may be produced by the following test cases:

9.69. EPP_CONTACT_UPDATE_INFO_RESPONSE_MISSING_OR_INCORRECT_SP

9.69.1. Severity

9.69.2. Description

Following a successful contact <update> command, a subsequent <info> response for the created object contained an incorrect or missing <sp> element.

9.69.3. Test cases

This error may be produced by the following test cases:

9.70. EPP_CONTACT_UPDATE_INFO_RESPONSE_MISSING_OR_INCORRECT_STATUS

9.70.1. Severity

9.70.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.70.3. Test cases

This error may be produced by the following test cases:

9.71. EPP_CONTACT_UPDATE_INFO_RESPONSE_MISSING_OR_INCORRECT_STREET

9.71.1. Severity

9.71.2. Description

Following a successful contact <update> command, a subsequent <info> response for the created object contained an incorrect or missing <street> element.

9.71.3. Test cases

This error may be produced by the following test cases:

9.72. EPP_CONTACT_UPDATE_INFO_RESPONSE_MISSING_OR_INCORRECT_VOICE

9.72.1. Severity

9.72.2. Description

Following a successful contact <update> command, a subsequent <info> response for the created object contained an incorrect or missing <voice> element.

9.72.3. Test cases

This error may be produced by the following test cases:

9.73. EPP_CONTACT_UPDATE_INFO_RESPONSE_MISSING_OR_INCORRECT_VOICE_EXT

9.73.1. Severity

9.73.2. Description

Following a successful contact <update> command, a subsequent <info> response for the created object contained an incorrect or missing ext attribute of the <voice> element.

9.73.3. Test cases

This error may be produced by the following test cases:

9.74. EPP_CONTACT_UPDATE_INFO_RESPONSE_NOT_1000

9.74.1. Severity

9.74.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.74.3. Test cases

This error may be produced by the following test cases:

9.75. EPP_CONTACT_UPDATE_RESPONSE_NOT_2201

9.75.1. Severity

9.75.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.75.3. Test cases

This error may be produced by the following test cases:

9.76. EPP_CONTACT_UPDATE_SERVER_ACCEPTS_EMPTY_CC

9.76.1. Severity

9.76.2. Description

The server incorrectly accepted an empty <cc> element in a <postalInfo> 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_EMPTY_CITY

9.77.1. Severity

9.77.2. Description

The server incorrectly accepted an empty <city> element in a <postalInfo> element in a contact <update> command.

9.77.3. Test cases

This error may be produced by the following test cases:

9.78. EPP_CONTACT_UPDATE_SERVER_ACCEPTS_EMPTY_NAME

9.78.1. Severity

9.78.2. Description

The server incorrectly accepted an empty <name> element in a <postalInfo> element in a contact <update> command.

9.78.3. Test cases

This error may be produced by the following test cases:

9.79. EPP_CONTACT_UPDATE_SERVER_ACCEPTS_INVALID_CC

9.79.1. Severity

9.79.2. Description

The server incorrectly accepted an invalid value for the <cc> element in a contact <update> command.

9.79.3. Test cases

This error may be produced by the following test cases:

9.80. EPP_CONTACT_UPDATE_SERVER_ACCEPTS_INVALID_CITY

9.80.1. Severity

9.80.2. Description

The server incorrectly accepted an invalid value for the <city> element in a contact <update> command.

9.80.3. Test cases

This error may be produced by the following test cases:

9.81. EPP_CONTACT_UPDATE_SERVER_ACCEPTS_INVALID_EMAIL

9.81.1. Severity

9.81.2. Description

The server incorrectly accepted an invalid value for the <email> element in a contact <update> command.

9.81.3. Test cases

This error may be produced by the following test cases:

9.82. EPP_CONTACT_UPDATE_SERVER_ACCEPTS_INVALID_FAX

9.82.1. Severity

9.82.2. Description

Following a successful contact <update> command, a subsequent <info> response for the created object contained an incorrect or missing <fax> element.

9.82.3. Test cases

This error may be produced by the following test cases:

9.83. EPP_CONTACT_UPDATE_SERVER_ACCEPTS_INVALID_ORG

9.83.1. Severity

9.83.2. Description

The server incorrectly accepted an invalid value for the <org> element in a contact <update> command.

9.83.3. Test cases

This error may be produced by the following test cases:

9.84. EPP_CONTACT_UPDATE_SERVER_ACCEPTS_INVALID_PC

9.84.1. Severity

9.84.2. Description

The server incorrectly accepted an invalid value for the <pc> element in a contact <update> command.

9.84.3. Test cases

This error may be produced by the following test cases:

9.85. EPP_CONTACT_UPDATE_SERVER_ACCEPTS_INVALID_POSTALINFO_TYPE

9.85.1. Severity

9.85.2. Description

The server incorrectly accepted an invalid value for the type attribute of a <postalInfo> element in a contact <update> command.

9.85.3. Test cases

This error may be produced by the following test cases:

9.86. EPP_CONTACT_UPDATE_SERVER_ACCEPTS_INVALID_SP

9.86.1. Severity

9.86.2. Description

The server incorrectly accepted an invalid value for the <sp> element in a contact <update> command.

9.86.3. Test cases

This error may be produced by the following test cases:

9.87. EPP_CONTACT_UPDATE_SERVER_ACCEPTS_INVALID_STATUS_CODE

9.87.1. Severity

9.87.2. Description

The server incorrectly accepted a <status> element in element with an invalid s attribute in a contact <update> command.

9.87.3. Test cases

This error may be produced by the following test cases:

9.88. EPP_CONTACT_UPDATE_SERVER_ACCEPTS_INVALID_STREET

9.88.1. Severity

9.88.2. Description

The server incorrectly accepted an invalid value for the <street> element in a contact <update> command.

9.88.3. Test cases

This error may be produced by the following test cases:

9.89. EPP_CONTACT_UPDATE_SERVER_ACCEPTS_INVALID_VOICE

9.89.1. Severity

9.89.2. Description

The server incorrectly accepted an invalid value for the <voice> element in a contact <update> command.

9.89.3. Test cases

This error may be produced by the following test cases:

9.90. EPP_DNS_RESOLUTION_ERROR

9.90.1. Severity

9.90.2. Description

There was an error while performing a DNS query for the EPP server hostname.

9.90.3. Test cases

This error may be produced by the following test cases:

9.91. EPP_DOMAIN_CHECK_INVALID_DOMAIN_INCORRECT_AVAIL

9.91.1. Severity

9.91.2. Description

The server responded to a <check> command with an unexpected value in one or more of the avail attributes.

9.91.3. Test cases

This error may be produced by the following test cases:

9.92. EPP_DOMAIN_CHECK_REGISTERED_DOMAIN_INCORRECT_AVAIL

9.92.1. Severity

9.92.2. Description

The server responded to a <check> command with an unexpected value in one or more of the avail attributes.

9.92.3. Test cases

This error may be produced by the following test cases:

9.93. EPP_DOMAIN_CHECK_VALID_DOMAIN_INCORRECT_AVAIL

9.93.1. Severity

9.93.2. Description

The server responded to a <check> command with an unexpected value in one or more of the avail attributes.

9.93.3. Test cases

This error may be produced by the following test cases:

9.94. EPP_DOMAIN_CREATE_INFO_RESPONSE_INVALID_ROID

9.94.1. Severity

9.94.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.94.3. Test cases

This error may be produced by the following test cases:

9.95. EPP_DOMAIN_CREATE_INFO_RESPONSE_MISSING_OBJECT_PROPERTIES

9.95.1. Severity

9.95.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.95.3. Test cases

This error may be produced by the following test cases:

9.96. EPP_DOMAIN_CREATE_SERVER_ACCEPTS_AUTHINFO

9.96.1. Severity

9.96.2. Description

The server accepts a domain <create> command with a <pw> element with an invalid value.

9.96.3. Test cases

This error may be produced by the following test cases:

9.97. EPP_DOMAIN_CREATE_SERVER_ACCEPTS_HOST_ATTRIBUTES_WITHOUT_GLUE

9.97.1. Severity

9.97.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.97.3. Test cases

This error may be produced by the following test cases:

9.98. EPP_DOMAIN_CREATE_SERVER_ACCEPTS_HOST_ATTRIBUTES_WITH_INVALID_GLUE

9.98.1. Severity

9.98.2. Description

The server incorrectly accepted an invalid value for the <hostAddr> element in a <hostAttr> element in a domain <create> command.

9.98.3. Test cases

This error may be produced by the following test cases:

9.99. EPP_DOMAIN_CREATE_SERVER_ACCEPTS_INVALID_DNSSEC_DATA

9.99.1. Severity

9.99.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.99.3. Test cases

This error may be produced by the following test cases:

9.100. EPP_DOMAIN_CREATE_SERVER_ACCEPTS_INVALID_DOMAIN_NAME

9.100.1. Severity

9.100.2. Description

The server accepts a domain <create> command for a syntactically invalid domain name.

9.100.3. Test cases

This error may be produced by the following test cases:

9.101. EPP_DOMAIN_CREATE_SERVER_ACCEPTS_INVALID_HOST_OBJECT

9.101.1. Severity

9.101.2. Description

The server accepts a domain <create> command which contains a <hostObj> element referencing a syntactically invalid hostname.

9.101.3. Test cases

This error may be produced by the following test cases:

9.102. EPP_DOMAIN_CREATE_SERVER_ACCEPTS_INVALID_PERIOD

9.102.1. Severity

9.102.2. Description

The server accepts a domain <create> command which contains a <period> element with an invalid content and/or unit attribute.

9.102.3. Test cases

This error may be produced by the following test cases:

9.103. EPP_DOMAIN_CREATE_SERVER_ACCEPTS_NON_EXISTENT_CONTACT_OBJECT

9.103.1. Severity

9.103.2. Description

The server accepts a domain <create> command which contains a <registrant> and/or <contact> element referencing a non-existent contact object.

9.103.3. Test cases

This error may be produced by the following test cases:

9.104. EPP_DOMAIN_CREATE_SERVER_ACCEPTS_NON_EXISTENT_HOST_OBJECT

9.104.1. Severity

9.104.2. Description

The server accepts a domain <create> command which contains a <hostObj> element referencing a non-existent host object.

9.104.3. Test cases

This error may be produced by the following test cases:

9.105. EPP_DOMAIN_CREATE_SERVER_ACCEPTS_NO_REGISTRANT_FOR_THICK_REGISTRY

9.105.1. Severity

9.105.2. Description

The server accepts a domain <create> command which does not include a <registrant> object.

9.105.3. Test cases

This error may be produced by the following test cases:

9.106. EPP_DOMAIN_CREATE_SERVER_ACCEPTS_REGISTRANT_FOR_THIN_REGISTRY

9.106.1. Severity

9.106.2. Description

The server accepts a domain <create> command which includes a <registrant> object.

9.106.3. Test cases

This error may be produced by the following test cases:

9.107. EPP_DOMAIN_CREATE_SERVER_INCORRECTLY_ACCEPTS_HOST_ATTRIBUTES

9.107.1. Severity

9.107.2. Description

The server accepts a domain <create> command which uses <hostAttr> objects.

9.107.3. Test cases

This error may be produced by the following test cases:

9.108. EPP_DOMAIN_CREATE_SERVER_INCORRECTLY_ACCEPTS_HOST_OBJECTS

9.108.1. Severity

9.108.2. Description

The server accepts a domain <create> command which uses <hostObj> objects.

9.108.3. Test cases

This error may be produced by the following test cases:

9.109. EPP_DOMAIN_DELETE_INFO_RESPONSE_OBJECT_NOT_PENDING_DELETE

9.109.1. Severity

9.109.2. Description

Following a successful domain <delete> command, which resulted in a 1001 response, the domain did not have the pendingDelete status.

9.109.3. Test cases

This error may be produced by the following test cases:

9.110. EPP_DOMAIN_DELETE_INFO_RESPONSE_OBJECT_STILL_EXISTS

9.110.1. Severity

9.110.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.110.3. Test cases

This error may be produced by the following test cases:

9.111. EPP_DOMAIN_DELETE_INFO_RESPONSE_RGP_STATUS_NOT_PENDING_DELETE

9.111.1. Severity

9.111.2. Description

Following a successful domain <delete> command, which resulted in a 1001 response, the domain did not have the pendingDeleteRestorable RGP status.

9.111.3. Test cases

This error may be produced by the following test cases:

9.112. EPP_DOMAIN_UPDATE_INFO_RESPONSE_MISSING_DNSSEC_DATA

9.112.1. Severity

9.112.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.112.3. Test cases

This error may be produced by the following test cases:

9.113. EPP_DOMAIN_UPDATE_INFO_RESPONSE_MISSING_HOST_ATTRIBUTE

9.113.1. Severity

9.113.2. Description

Following a successful domain <update> command, a subsequent <info> response for the created object did not include all expected <hostAttr> elements.

9.113.3. Test cases

This error may be produced by the following test cases:

9.114. EPP_DOMAIN_UPDATE_INFO_RESPONSE_MISSING_HOST_OBJECT

9.114.1. Severity

9.114.2. Description

Following a successful domain <update> command, a subsequent <info> response for the created object did not include all expected <hostObj> elements.

9.114.3. Test cases

This error may be produced by the following test cases:

9.115. EPP_DOMAIN_UPDATE_INFO_RESPONSE_MISSING_REGISTRANT

9.115.1. Severity

9.115.2. Description

Following a successful domain <update> command, a subsequent <info> response for the created object did not include the expected <registrant> element.

9.115.3. Test cases

This error may be produced by the following test cases:

9.116. EPP_DOMAIN_UPDATE_INFO_RESPONSE_MISSING_STATUS_CODE

9.116.1. Severity

9.116.2. Description

Following a successful domain <update> command, a subsequent <info> response for the created object did not include the expected <status> elements.

9.116.3. Test cases

This error may be produced by the following test cases:

9.117. EPP_DOMAIN_UPDATE_INFO_RESPONSE_UNEXPECTED_DNSSEC_DATA

9.117.1. Severity

9.117.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.117.3. Test cases

This error may be produced by the following test cases:

9.118. EPP_DOMAIN_UPDATE_INFO_RESPONSE_UNEXPECTED_HOST_ATTRIBUTE

9.118.1. Severity

9.118.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.118.3. Test cases

This error may be produced by the following test cases:

9.119. EPP_DOMAIN_UPDATE_INFO_RESPONSE_UNEXPECTED_HOST_OBJECT

9.119.1. Severity

9.119.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.119.3. Test cases

This error may be produced by the following test cases:

9.120. EPP_DOMAIN_UPDATE_INFO_RESPONSE_UNEXPECTED_REGISTRANT

9.120.1. Severity

9.120.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.120.3. Test cases

This error may be produced by the following test cases:

9.121. EPP_DOMAIN_UPDATE_INFO_RESPONSE_UNEXPECTED_STATUS_CODE

9.121.1. Severity

9.121.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.121.3. Test cases

This error may be produced by the following test cases:

9.122. EPP_DOMAIN_UPDATE_SERVER_ACCEPTS_HOST_ATTRIBUTES_WITHOUT_GLUE

9.122.1. Severity

9.122.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.122.3. Test cases

This error may be produced by the following test cases:

9.123. EPP_DOMAIN_UPDATE_SERVER_ACCEPTS_INVALID_DNSSEC_DATA

9.123.1. Severity

9.123.2. Description

The server accepts a domain <update> command with one or more <dsData> or <keyData> elements which contain invalid parameters.

9.123.3. Test cases

This error may be produced by the following test cases:

9.124. EPP_DOMAIN_UPDATE_SERVER_ACCEPTS_INVALID_HOST_ATTRIBUTES

9.124.1. Severity

9.124.2. Description

The server accepts a domain <update> command with one or more <hostAttr> elements containing invalid hostnames and/or IP addresses.

9.124.3. Test cases

This error may be produced by the following test cases:

9.125. EPP_DOMAIN_UPDATE_SERVER_ACCEPTS_INVALID_STATUS_CODE

9.125.1. Severity

9.125.2. Description

The server incorrectly accepted a <status> element in element with an invalid s attribute in a domain <update> command.

9.125.3. Test cases

This error may be produced by the following test cases:

9.126. EPP_DOMAIN_UPDATE_SERVER_ACCEPTS_NON_EXISTENT_CONTACT_OBJECT

9.126.1. Severity

9.126.2. Description

The server accepts a domain <update> command which contains a <registrant> or <contact> element containing non-existent contact objects.

9.126.3. Test cases

This error may be produced by the following test cases:

9.127. EPP_DOMAIN_UPDATE_SERVER_ACCEPTS_NON_EXISTENT_HOST_OBJECT

9.127.1. Severity

9.127.2. Description

The server accepts a domain <update> command with one or more <hostObj> elements containing non-existent host objects.

9.127.3. Test cases

This error may be produced by the following test cases:

9.128. EPP_DOMAIN_UPDATE_SERVER_INCORRECTLY_ACCEPTS_HOST_ATTRIBUTES

9.128.1. Severity

9.128.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.128.3. Test cases

This error may be produced by the following test cases:

9.129. EPP_DOMAIN_UPDATE_SERVER_INCORRECTLY_ACCEPTS_HOST_OBJECTS

9.129.1. Severity

9.129.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.129.3. Test cases

This error may be produced by the following test cases:

9.130. EPP_GENERIC_COMMAND_ERROR

9.130.1. Severity

9.130.2. Description

The client received a 2400 error from the server.

9.130.3. Test cases

This error may be produced by the following test cases:

9.131. EPP_GREETING_DOES_NOT_MATCH

9.131.1. Severity

9.131.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.131.3. Test cases

This error may be produced by the following test cases:

9.132. EPP_GREETING_INVALID_LANG

9.132.1. Severity

9.132.2. Description

The value of one or more of the <lang> elements in the <greeting> are invalid.

9.132.3. Test cases

This error may be produced by the following test cases:

9.133. EPP_GREETING_MISSING_EN_LANG

9.133.1. Severity

9.133.2. Description

A <lang> element with the value en was not found in the <greeting>.

9.133.3. Test cases

This error may be produced by the following test cases:

9.134. EPP_GREETING_MISSING_EXTURI

9.134.1. Severity

9.134.2. Description

A mandatory extension namespace URI is missing.

9.134.3. Test cases

This error may be produced by the following test cases:

9.135. EPP_GREETING_MISSING_OBJURI

9.135.1. Severity

9.135.2. Description

A mandatory object namespace URI is missing.

9.135.3. Test cases

This error may be produced by the following test cases:

9.136. EPP_GREETING_RECOMMENDED_EXTENSION_MISSING

9.136.1. Severity

9.136.2. Description

The server does not include the namespace URI of a recommended extension in an <extURI> element of the <greeting> frame.

9.136.3. Test cases

This error may be produced by the following test cases:

9.137. EPP_GREETING_SVDATE_INVALID

9.137.1. Severity

9.137.2. Description

The value of the <svDate> element in the <greeting> is invalid.

9.137.3. Test cases

This error may be produced by the following test cases:

9.138. EPP_GREETING_SVID_INVALID

9.138.1. Severity

9.138.2. Description

The value of the <svID> element in the <greeting> is invalid.

9.138.3. Test cases

This error may be produced by the following test cases:

9.139. EPP_GREETING_UNEXPECTED_EXTURI

9.139.1. Severity

9.139.2. Description

One or more of the <extRI> elements in the <greeting> contain invalid namespace URIs.

9.139.3. Test cases

This error may be produced by the following test cases:

9.140. EPP_GREETING_UNEXPECTED_OBJURI

9.140.1. Severity

9.140.2. Description

One or more of the <objURI> elements in the <greeting> contain invalid namespace URIs.

9.140.3. Test cases

This error may be produced by the following test cases:

9.141. EPP_GREETING_VERSION_INVALID

9.141.1. Severity

9.141.2. Description

The value of the <version> element in the <greeting> is invalid.

9.141.3. Test cases

This error may be produced by the following test cases:

9.142. EPP_HOST_CHECK_INVALID_HOST_INCORRECT_AVAIL

9.142.1. Severity

9.142.2. Description

The server responded to a <check> command with an unexpected value in one or more of the avail attributes.

9.142.3. Test cases

This error may be produced by the following test cases:

9.143. EPP_HOST_CHECK_REGISTERED_HOST_INCORRECT_AVAIL

9.143.1. Severity

9.143.2. Description

The server responded to a <check> command with an unexpected value in one or more of the avail attributes.

9.143.3. Test cases

This error may be produced by the following test cases:

9.144. EPP_HOST_CHECK_VALID_HOST_INCORRECT_AVAIL

9.144.1. Severity

9.144.2. Description

The server responded to a <check> command with an unexpected value in one or more of the avail attributes.

9.144.3. Test cases

This error may be produced by the following test cases:

9.145. EPP_HOST_CREATE_INFO_RESPONSE_MISSING_OBJECT_PROPERTIES

9.145.1. Severity

9.145.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.145.3. Test cases

This error may be produced by the following test cases:

9.146. EPP_HOST_CREATE_INFO_RESPONSE_OBJECT_DOES_NOT_EXIST

9.146.1. Severity

9.146.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.146.3. Test cases

This error may be produced by the following test cases:

9.147. EPP_HOST_CREATE_SERVER_ACCEPTS_INVALID_HOSTNAME

9.147.1. Severity

9.147.2. Description

The server accepts a host <create> command with a <name> element that contains a syntactically invalid hostname.

9.147.3. Test cases

This error may be produced by the following test cases:

9.148. EPP_HOST_CREATE_SERVER_ACCEPTS_INVALID_IPV4_ADDRESS

9.148.1. Severity

9.148.2. Description

The server accepts a host <create> command with a <addr> element that contains a syntactically invalid IPv4 address.

9.148.3. Test cases

This error may be produced by the following test cases:

9.149. EPP_HOST_CREATE_SERVER_ACCEPTS_INVALID_IPv6_ADDRESS

9.149.1. Severity

9.149.2. Description

The server accepts a host <create> command with a <addr> element that contains a syntactically invalid IPv6 address.

9.149.3. Test cases

This error may be produced by the following test cases:

9.150. EPP_HOST_CREATE_SERVER_DOES_NOT_REQUIRE_GLUE

9.150.1. Severity

9.150.2. Description

The server accepts a host <create> command for an in-bailiwick hostname that does not include any <addr> elements.

9.150.3. Test cases

This error may be produced by the following test cases:

9.151. EPP_HOST_DELETE_INFO_RESPONSE_OBJECT_STILL_EXISTS

9.151.1. Severity

9.151.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.151.3. Test cases

This error may be produced by the following test cases:

9.152. EPP_HOST_DELETE_RESPONSE_NOT_1000_OR_1001

9.152.1. Severity

9.152.2. Description

The server did not response to a host <delete> command with a 1xxx result code.

9.152.3. Test cases

This error may be produced by the following test cases:

9.153. EPP_HOST_RENAME_SERVER_ACCEPTS_INVALID_HOSTNAME

9.153.1. Severity

9.153.2. Description

The server accepts a host <update> command with a <name> element that contains a syntactically invalid hostname.

9.153.3. Test cases

This error may be produced by the following test cases:

9.154. EPP_HOST_RENAME_SERVER_ACCEPTS_RENAME_TO_ANOTHER_REGISTRARS_DOMAIN

9.154.1. Severity

9.154.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.154.3. Test cases

This error may be produced by the following test cases:

9.155. EPP_HOST_RENAME_SERVER_ACCEPTS_RENAME_TO_NONEXISTENT_DOMAIN

9.155.1. Severity

9.155.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.155.3. Test cases

This error may be produced by the following test cases:

9.156. EPP_HOST_RENAME_SERVER_REJECTS_OUT_OF_BAILIWICK_NAME

9.156.1. Severity

9.156.2. Description

The server rejects a host <update> command with a <name> element that contains a hostname that is out-of-bailiwick.

9.156.3. Test cases

This error may be produced by the following test cases:

9.157. EPP_HOST_RENAME_SERVER_UNEXPECTEDLY_REJECTS_RENAME

9.157.1. Severity

9.157.2. Description

The server rejects a host <update> command with a <name> element that it should have accepted.

9.157.3. Test cases

This error may be produced by the following test cases:

9.158. EPP_HOST_UPDATE_AUTHZ_ERROR

9.158.1. Severity

9.158.2. Description

The server rejects a host <update> command for a host object that is not under the sponsorship of the connected client.

9.158.3. Test cases

This error may be produced by the following test cases:

9.159. EPP_HOST_UPDATE_INFO_RESPONSE_MISSING_OBJECT_PROPERTIES

9.159.1. Severity

9.159.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.159.3. Test cases

This error may be produced by the following test cases:

9.160. EPP_HOST_UPDATE_INFO_RESPONSE_OBJECT_DOES_NOT_EXIST

9.160.1. Severity

9.160.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.160.3. Test cases

This error may be produced by the following test cases:

9.161. EPP_HOST_UPDATE_SERVER_ACCEPTS_INVALID_IPV4_ADDRESS

9.161.1. Severity

9.161.2. Description

The server accepts a host <update> command with an <addr> element that contains a syntactically invalid IPv4 address.

9.161.3. Test cases

This error may be produced by the following test cases:

9.162. EPP_HOST_UPDATE_SERVER_ACCEPTS_INVALID_IPv6_ADDRESS

9.162.1. Severity

9.162.2. Description

The server accepts a host <update> command with an <addr> element that contains a syntactically invalid IPv6 address.

9.162.3. Test cases

This error may be produced by the following test cases:

9.163. EPP_HOST_UPDATE_SERVER_ACCEPTS_INVALID_STATUS_CODE

9.163.1. Severity

9.163.2. Description

The server accepts a host <update> command with a <status> element that contains an invalid status code in the s attribute.

9.163.3. Test cases

This error may be produced by the following test cases:

9.164. EPP_INTEGRITY_SERVER_ACCEPTS_DELETE_FOR_LINKED_CONTACT_OBJECT

9.164.1. Severity

9.164.2. Description

The server accepts a <delete> command for a contact object that has the linked status.

9.164.3. Test cases

This error may be produced by the following test cases:

9.165. EPP_INTEGRITY_SERVER_ACCEPTS_DELETE_FOR_LINKED_HOST_OBJECT

9.165.1. Severity

9.165.2. Description

The server accepts a <delete> command for a host object that has the linked status.

9.165.3. Test cases

This error may be produced by the following test cases:

9.166. EPP_LOGIN_ERROR

9.166.1. Severity

9.166.2. Description

The client was unable to successfully authenticate with the EPP server.

9.166.3. Test cases

This error may be produced by the following test cases:

9.167. EPP_LOGIN_UNEXPECTEDLY_FAILED

9.167.1. Severity

9.167.2. Description

The client was not able to authenticate with the provided credentials.

9.167.3. Test cases

This error may be produced by the following test cases:

9.168. EPP_LOGIN_UNEXPECTEDLY_SUCCEEDED

9.168.1. Severity

9.168.2. Description

A <login> command that should have failed unexpectedly succeeded.

9.168.3. Test cases

This error may be produced by the following test cases:

9.169. EPP_MISSING_AAAA_RECORDS

9.169.1. Severity

9.169.2. Description

No AAAA record(s) were found for the EPP server hostname.

9.169.3. Test cases

This error may be produced by the following test cases:

9.170. EPP_MISSING_A_RECORDS

9.170.1. Severity

9.170.2. Description

No A record(s) were found for the EPP server hostname.

9.170.3. Test cases

This error may be produced by the following test cases:

9.171. EPP_NO_GREETING_RECEIVED

9.171.1. Severity

9.171.2. Description

No <greeting> was received after successful connection.

9.171.3. Test cases

This error may be produced by the following test cases:

9.172. EPP_NO_SERVICE_PORTS_REACHABLE

9.172.1. Severity

9.172.2. Description

No service ports could be reached, for either IPv4 or (if supported) IPv6.

9.172.3. Test cases

This error may be produced by the following test cases:

9.173. EPP_RENEW_INFO_RESPONSE_MISSING_OR_INVALID_RGP_STATUS

9.173.1. Severity

9.173.2. Description

Following a successful <renew> command, a subsequent <info> command for the domain did not include the renewPeriod RGP status.

9.173.3. Test cases

This error may be produced by the following test cases:

9.174. EPP_RENEW_INFO_RESPONSE_UNEXPECTED_EXPIRY_DATE

9.174.1. Severity

9.174.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.174.3. Test cases

This error may be produced by the following test cases:

9.175. EPP_RENEW_SERVER_ACCEPTS_INVALID_CURRENT_EXPIRY_DATE

9.175.1. Severity

9.175.2. Description

The server accepted an EPP <renew> command with a <curExpDate> element that contains the incorrect expiry date.

9.175.3. Test cases

This error may be produced by the following test cases:

9.176. EPP_RENEW_SERVER_ACCEPTS_INVALID_PERIOD

9.176.1. Severity

9.176.2. Description

The server accepted an EPP <renew> command with a <period> element that contains an incorrect value or unit attribute.

9.176.3. Test cases

This error may be produced by the following test cases:

9.177. EPP_RESTORE_DOMAIN_STILL_PENDINGDELETE

9.177.1. Severity

9.177.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.177.3. Test cases

This error may be produced by the following test cases:

9.178. EPP_SCHEMA_VALIDATION_ERROR

9.178.1. Severity

9.178.2. Description

The response from the server failed schema validation.

9.178.3. Test cases

This error may be produced by the following test cases:

9.179. EPP_SERVICE_PORT_NOT_CONSISTENT

9.179.1. Severity

9.179.2. Description

One or more <info> commands sent to the advertised EPP service ports resulted in inconsistent responses.

9.179.3. Test cases

This error may be produced by the following test cases:

9.180. EPP_SERVICE_PORT_UNREACHABLE

9.180.1. Severity

9.180.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.180.3. Test cases

This error may be produced by the following test cases:

9.181. EPP_TLS_BAD_CIPHER

9.181.1. Severity

9.181.2. Description

The server uses an encryption cipher not recommended in RFC 9325.

9.181.3. Test cases

This error may be produced by the following test cases:

9.182. EPP_TLS_CERTIFICATE_CHAIN_MISSING

9.182.1. Severity

9.182.2. Description

One or more intermediate certificates are missing.

9.182.3. Test cases

This error may be produced by the following test cases:

9.183. EPP_TLS_CERTIFICATE_HOSTNAME_MISMATCH

9.183.1. Severity

9.183.2. Description

The hostname in the TLS certificate does not match the EPP server hostname.

9.183.3. Test cases

This error may be produced by the following test cases:

9.184. EPP_TLS_CONNECTION_ERROR

9.184.1. Severity

9.184.2. Description

There was an error during the TLS handshake while connecting to the EPP server.

9.184.3. Test cases

This error may be produced by the following test cases:

9.185. EPP_TLS_EXPIRED_CERTIFICATE

9.185.1. Severity

9.185.2. Description

The TLS certificate presented by the EPP server has expired.

9.185.3. Test cases

This error may be produced by the following test cases:

9.186. EPP_TLS_FORBIDDEN_PROTOCOL_SUPPORTED

9.186.1. Severity

9.186.2. Description

The EPP server implements a forbidden protocol.

9.186.3. Test cases

This error may be produced by the following test cases:

9.187. EPP_TLS_REQUIRED_PROTOCOL_NOT_SUPPORTED

9.187.1. Severity

9.187.2. Description

The EPP server does not implement a required protocol.

9.187.3. Test cases

This error may be produced by the following test cases:

9.188. EPP_TLS_UNTRUSTED_CERTIFICATE

9.188.1. Severity

9.188.2. Description

The TLS certificate presented by the EPP server is not issued by a trusted Certificate Authority.

9.188.3. Test cases

This error may be produced by the following test cases:

9.189. EPP_TRANSFER_GAINING_REGISTRAR_NO_MESSAGE_RECEIVED

9.189.1. Severity

9.189.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.189.3. Test cases

This error may be produced by the following test cases:

9.190. EPP_TRANSFER_INFO_RESPONSE_AUTHINFO_NOT_RESET

9.190.1. Severity

9.190.2. Description

Following a successful domain transfer, the authInfo of the transferred domain was not changed.

9.190.3. Test cases

This error may be produced by the following test cases:

9.191. EPP_TRANSFER_INFO_RESPONSE_MISSING_OR_INVALID_RGP_STATUS

9.191.1. Severity

9.191.2. Description

Following a successful domain transfer, a subsequent <info> response did not include the expected RGP status (transferPeriod).

9.191.3. Test cases

This error may be produced by the following test cases:

9.192. EPP_TRANSFER_INFO_RESPONSE_MISSING_OR_INVALID_STATUS_CODE

9.192.1. Severity

9.192.2. Description

Following a successful <transfer op="request"> command, a subsequent <info> response did not include the pendingTransfer status.

9.192.3. Test cases

This error may be produced by the following test cases:

9.193. EPP_TRANSFER_INFO_RESPONSE_UNEXPECTED_EXPIRY_DATE

9.193.1. Severity

9.193.2. Description

Following a successful domain transfer, a subsequent <info> response did not include the expected value of the <exDate> element.

9.193.3. Test cases

This error may be produced by the following test cases:

9.194. EPP_TRANSFER_LOSING_REGISTRAR_NO_MESSAGE_RECEIVED

9.194.1. Severity

9.194.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.194.3. Test cases

This error may be produced by the following test cases:

9.195. EPP_TRANSFER_SERVER_ACCEPTS_INCORRECT_AUTHINFO

9.195.1. Severity

9.195.2. Description

The server incorrectly accepted a <transfer op="request"> command containing an invalid authInfo code.

9.195.3. Test cases

This error may be produced by the following test cases:

9.196. EPP_TRANSFER_SERVER_ACCEPTS_INSECURE_AUTHINFO

9.196.1. Severity

9.196.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.196.3. Test cases

This error may be produced by the following test cases:

9.197. EPP_TRANSFER_SERVER_ACCEPTS_INVALID_PERIOD

9.197.1. Severity

9.197.2. Description

The server incorrectly accepted a <transfer op="request"> command containing a <period> element that contains an incorrect value or unit attribute.

9.197.3. Test cases

This error may be produced by the following test cases:

9.198. EPP_TRANSFER_SERVER_PROCESSED_REJECTED_TRANSFER

9.198.1. Severity

9.198.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.198.3. Test cases

This error may be produced by the following test cases:

9.199. EPP_TRANSFER_SERVER_REJECTS_SECURE_AUTHINFO

9.199.1. Severity

9.199.2. Description

An EPP server implementing Secure Authorization Information for Transfer (RFC 9154) rejected an <update> command that specified an authInfo code with at least as much entropy as specified in Section 4.1 of that RFC (that is, 128 bits).

9.199.3. Test cases

This error may be produced by the following test cases:

9.200. EPP_UNEXPECTED_COMMAND_FAILURE

9.200.1. Severity

9.200.2. Description

A command that should have succeeded return a response with a status code of 2000 or higher.

9.200.3. Test cases

This error may be produced by the following test cases:

9.201. EPP_UNEXPECTED_COMMAND_SUCCESS

9.201.1. Severity

9.201.2. Description

A command that should have failed return a response with a status code of 1999 or lower.

9.201.3. Test cases

This error may be produced by the following test cases:

9.202. EPP_XML_PARSE_ERROR

9.202.1. Severity

9.202.2. Description

The XML response from the server could not be parsed.

9.202.3. Test cases

This error may be produced by the following test cases:

9.203. IDN_IDNONLY_TLD_ACCEPTS_ASCII_DOMAIN

9.203.1. Severity

9.203.2. Description

The server incorrectly accepted a <create> command for an ASCII domain in a TLD whose idnOnly property is true.

9.203.3. Test cases

This error may be produced by the following test cases:

9.204. IDN_SERVER_ACCEPTS_INVALID_LABEL

9.204.1. Severity

9.204.2. Description

The server accepts a <create> command with a <name> object containing an invalid label.

9.204.3. Test cases

This error may be produced by the following test cases:

9.205. IDN_SERVER_REJECTS_VALID_LABEL

9.205.1. Severity

9.205.2. Description

The server rejects a <create> command with a <name> object containing a valid label.

9.205.3. Test cases

This error may be produced by the following test cases:

9.206. IDN_VARIANT_LABEL_NOT_BLOCKED

9.206.1. Severity

9.206.2. Description

A variant label remains available for registration.

9.206.3. Test cases

This error may be produced by the following test cases:

9.207. IDN_VARIANT_SERVER_ACCEPTS_VARIANT_CREATE_FROM_INCORRECT_REGISTRAR

9.207.1. Severity

9.207.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.207.3. Test cases

This error may be produced by the following test cases:

9.208. IDN_VARIANT_SERVER_ACCEPTS_VARIANT_CREATE_WITH_INCORRECT_REGISTRANT

9.208.1. Severity

9.208.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.208.3. Test cases

This error may be produced by the following test cases:

9.209. IDN_VARIANT_SERVER_REJECTS_VARIANT_CREATE_FROM_SAME_REGISTRAR

9.209.1. Severity

9.209.2. Description

The server rejects a <create> command for a variant of an existing domain from the registrar of the original domain.

9.209.3. Test cases

This error may be produced by the following test cases:

9.210. IDN_VARIANT_SERVER_REJECTS_VARIANT_CREATE_WITH_SAME_REGISTRANT

9.210.1. Severity

9.210.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.210.3. Test cases

This error may be produced by the following test cases:

9.211. INTEGRATION_DNS_QUERY_FAILED

9.211.1. Severity

9.211.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.211.3. Test cases

This error may be produced by the following test cases:

9.212. INTEGRATION_DOMAIN_NOT_PRESENT_IN_DNS

9.212.1. Severity

9.212.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.212.3. Test cases

This error may be produced by the following test cases:

9.213. INTEGRATION_DOMAIN_NOT_PRESENT_IN_RDAP

9.213.1. Severity

9.213.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.213.3. Test cases

This error may be produced by the following test cases:

9.214. INTEGRATION_DOMAIN_NOT_PRESENT_IN_RDE

9.214.1. Severity

9.214.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.214.3. Test cases

This error may be produced by the following test cases:

9.215. INTEGRATION_RDAP_REQUEST_FAILED

9.215.1. Severity

9.215.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.215.3. Test cases

This error may be produced by the following test cases:

9.216. INTEGRATION_RDE_SFTP_SERVER_AUTHENTICATION_ERROR

9.216.1. Severity

9.216.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.216.3. Test cases

This error may be produced by the following test cases:

9.217. INTEGRATION_RDE_SFTP_SERVER_UNREACHABLE

9.217.1. Severity

9.217.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.217.3. Test cases

This error may be produced by the following test cases:

9.218. RDAP_DOMAIN_HEAD_FAILED

9.218.1. Severity

9.218.2. Description

The response from the server could not be validated.

9.218.3. Test cases

This error may be produced by the following test cases:

9.219. RDAP_DOMAIN_RESPONSE_VALIDATION_FAILED

9.219.1. Severity

9.219.2. Description

The response from the server could not be validated.

9.219.3. Test cases

This error may be produced by the following test cases:

9.220. RDAP_ENTITY_HEAD_FAILED

9.220.1. Severity

9.220.2. Description

The response from the server could not be validated.

9.220.3. Test cases

This error may be produced by the following test cases:

9.221. RDAP_ENTITY_RESPONSE_VALIDATION_FAILED

9.221.1. Severity

9.221.2. Description

The response from the server could not be validated.

9.221.3. Test cases

This error may be produced by the following test cases:

9.222. RDAP_HELP_RESPONSE_VALIDATION_FAILED

9.222.1. Severity

9.222.2. Description

The response from the server could not be validated.

9.222.3. Test cases

This error may be produced by the following test cases:

9.223. RDAP_NAMESERVER_HEAD_FAILED

9.223.1. Severity

9.223.2. Description

The response from the server could not be validated.

9.223.3. Test cases

This error may be produced by the following test cases:

9.224. RDAP_NAMESERVER_RESPONSE_VALIDATION_FAILED

9.224.1. Severity

9.224.2. Description

The response from the server could not be validated.

9.224.3. Test cases

This error may be produced by the following test cases:

9.225. RDAP_SERVICE_PORT_NOT_CONSISTENT

9.225.1. Severity

9.225.2. Description

The responses received are not consistent across all service ports.

9.225.3. Test cases

This error may be produced by the following test cases:

9.226. RDAP_TLS_BAD_CIPHER

9.226.1. Severity

9.226.2. Description

One or more RDAP service ports do implement a forbidden encryption cipher

9.226.3. Test cases

This error may be produced by the following test cases:

9.227. RDAP_TLS_CERTIFICATE_CHAIN_MISSING

9.227.1. Severity

9.227.2. Description

One or more RDAP service ports do not provide the full chain required to validate the server’s certificate.

9.227.3. Test cases

This error may be produced by the following test cases:

9.228. RDAP_TLS_CERTIFICATE_HOSTNAME_MISMATCH

9.228.1. Severity

9.228.2. Description

One or more RDAP service ports offer a certificate that cannot be matched against the RDAP server name.

9.228.3. Test cases

This error may be produced by the following test cases:

9.229. RDAP_TLS_DNS_RESOLUTION_ERROR

9.229.1. Severity

9.229.2. Description

An error occurred during DNS resolution of one of the RDAP base URL(s).

9.229.3. Test cases

This error may be produced by the following test cases:

9.230. RDAP_TLS_EXPIRED_CERTIFICATE

9.230.1. Severity

9.230.2. Description

One or more RDAP service ports offer a certificate that has expired.

9.230.3. Test cases

This error may be produced by the following test cases:

9.231. RDAP_TLS_FORBIDDEN_PROTOCOL_SUPPORTED

9.231.1. Severity

9.231.2. Description

One or more RDAP service ports do implement a forbidden version of TLS.

9.231.3. Test cases

This error may be produced by the following test cases:

9.232. RDAP_TLS_NO_SERVICE_PORTS_REACHABLE

9.232.1. Severity

9.232.2. Description

No service ports could be reached.

9.232.3. Test cases

This error may be produced by the following test cases:

9.233. RDAP_TLS_REQUIRED_PROTOCOL_NOT_SUPPORTED

9.233.1. Severity

9.233.2. Description

One or more RDAP service ports do not implement a required version of TLS.

9.233.3. Test cases

This error may be produced by the following test cases:

9.234. RDAP_TLS_SERVICE_PORT_UNREACHABLE

9.234.1. Severity

9.234.2. Description

A service port was not reachable. If all service ports are unreachable, then the test case will fail.

9.234.3. Test cases

This error may be produced by the following test cases:

9.235. RDAP_TLS_UNTRUSTED_CERTIFICATE

9.235.1. Severity

9.235.2. Description

One or more RDAP service ports offer a certificate that was not issued by a trusted certificate authority.

9.235.3. Test cases

This error may be produced by the following test cases:

9.236. RDE_CONTACT_HAS_INVALID_CC

9.236.1. Severity

9.236.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.236.3. Test cases

This error may be produced by the following test cases:

9.237. RDE_CONTACT_HAS_INVALID_EMAIL

9.237.1. Severity

9.237.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.237.3. Test cases

This error may be produced by the following test cases:

9.238. RDE_CONTACT_HAS_INVALID_ROID

9.238.1. Severity

9.238.2. Description

One or more contact objects have a <roid> element with a repository identifier not found in the IANA registry.

9.238.3. Test cases

This error may be produced by the following test cases:

9.239. RDE_CONTACT_HAS_MULTIPLE_POSTALINFO_TYPES

9.239.1. Severity

9.239.2. Description

One or more contact objects have more than <postalInfo> element with the same type attribute.

9.239.3. Test cases

This error may be produced by the following test cases:

9.240. RDE_CONTACT_HAS_NON_UNIQUE_ID

9.240.1. Severity

9.240.2. Description

One or more contact objects have the same <id> element.

9.240.3. Test cases

This error may be produced by the following test cases:

9.241. RDE_CONTACT_HAS_NON_UNIQUE_ROID

9.241.1. Severity

9.241.2. Description

One or more contact objects have the same <roid> element.

9.241.3. Test cases

This error may be produced by the following test cases:

9.242. RDE_CONTACT_HAS_UNKNOWN_ACRR

9.242.1. Severity

9.242.2. Description

One or more contact objects have an <acRr> element containing a registrar ID that is not present in the deposit.

9.242.3. Test cases

This error may be produced by the following test cases:

9.243. RDE_CONTACT_HAS_UNKNOWN_CLID

9.243.1. Severity

9.243.2. Description

One or more contact objects have a <clID> 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_CRRR

9.244.1. Severity

9.244.2. Description

One or more contact objects have a <crRr> 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_RERR

9.245.1. Severity

9.245.2. Description

One or more contact objects have an <reRr> 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_UPRR

9.246.1. Severity

9.246.2. Description

One or more contact objects have an <upRr> 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_DECRYPTION_FAILED

9.247.1. Severity

9.247.2. Description

The deposit file could not be decrypted.

9.247.3. Test cases

This error may be produced by the following test cases:

9.248. RDE_DOMAIN_HAS_INVALID_CLID

9.248.1. Severity

9.248.2. Description

One or more domain objects have a <clID> element containing a registrar ID that is not present in the deposit.

9.248.3. Test cases

This error may be produced by the following test cases:

9.249. RDE_DOMAIN_HAS_INVALID_CRDATE

9.249.1. Severity

9.249.2. Description

One or more domain objects have an invalid <crDate> element.

9.249.3. Test cases

This error may be produced by the following test cases:

9.250. RDE_DOMAIN_HAS_INVALID_EXDATE

9.250.1. Severity

9.250.2. Description

One or more domain objects have an invalid <exDate> element.

9.250.3. Test cases

This error may be produced by the following test cases:

9.251. RDE_DOMAIN_HAS_INVALID_NAME

9.251.1. Severity

9.251.2. Description

One or more domain objects have an invalid <name> element.

9.251.3. Test cases

This error may be produced by the following test cases:

9.252. RDE_DOMAIN_HAS_INVALID_REGISTRANT

9.252.1. Severity

9.252.2. Description

One or more domain objects have an <registrant> element that is not present in the deposit.

9.252.3. Test cases

This error may be produced by the following test cases:

9.253. RDE_DOMAIN_HAS_INVALID_ROID

9.253.1. Severity

9.253.2. Description

One or more domain objects have a <roid> element with a repository identifier not found in the IANA registry.

9.253.3. Test cases

This error may be produced by the following test cases:

9.254. RDE_DOMAIN_HAS_INVALID_STATUS

9.254.1. Severity

9.254.2. Description

One or more domain objects have an invalid <status> element.

9.254.3. Test cases

This error may be produced by the following test cases:

9.255. RDE_DOMAIN_HAS_MISSING_CLID

9.255.1. Severity

9.255.2. Description

One or more domain objects have an <clID> element that is not present in the deposit.

9.255.3. Test cases

This error may be produced by the following test cases:

9.256. RDE_DOMAIN_HAS_MISSING_CONTACT

9.256.1. Severity

9.256.2. Description

One or more domain objects have a <contact> element which 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_NAMESERVER

9.259.1. Severity

9.259.2. Description

One or more domain objects have a <hostObj> element which is not present in the deposit.

9.259.3. Test cases

This error may be produced by the following test cases:

9.260. RDE_DOMAIN_HAS_MISSING_REGISTRANT

9.260.1. Severity

9.260.2. Description

One or more domain objects have a <registrant> element which is not present in the deposit.

9.260.3. Test cases

This error may be produced by the following test cases:

9.261. RDE_DOMAIN_HAS_MISSING_ROID

9.261.1. Severity

9.261.2. Description

One or more domain objects do not have a <roid> element.

9.261.3. Test cases

This error may be produced by the following test cases:

9.262. RDE_DOMAIN_HAS_MISSING_STATUS

9.262.1. Severity

9.262.2. Description

One or more domain objects do not have a <status> element.

9.262.3. Test cases

This error may be produced by the following test cases:

9.263. RDE_DOMAIN_HAS_NON_UNIQUE_NAME

9.263.1. Severity

9.263.2. Description

One or more domain objects have the same <name> element.

9.263.3. Test cases

This error may be produced by the following test cases:

9.264. RDE_DOMAIN_HAS_NON_UNIQUE_ROID

9.264.1. Severity

9.264.2. Description

One or more domain objects have the same <roid> element.

9.264.3. Test cases

This error may be produced by the following test cases:

9.265. RDE_GREETING_DOES_NOT_MATCH

9.265.1. Severity

9.265.2. Description

The <eppParams> object contains values which do not match the provided EPP <greeting> XML instance.

9.265.3. Test cases

This error may be produced by the following test cases:

9.266. RDE_HOST_HAS_INVALID_CLID

9.266.1. Severity

9.266.2. Description

One or more host objects have an <clID> element that is not present in the deposit.

9.266.3. Test cases

This error may be produced by the following test cases:

9.267. RDE_HOST_HAS_INVALID_IP_ADDRESS

9.267.1. Severity

9.267.2. Description

One or more host objects have an invalid IP address.

9.267.3. Test cases

This error may be produced by the following test cases:

9.268. RDE_HOST_HAS_INVALID_NAME

9.268.1. Severity

9.268.2. Description

One or more host objects have an invalid hostname.

9.268.3. Test cases

This error may be produced by the following test cases:

9.269. RDE_HOST_HAS_INVALID_ROID

9.269.1. Severity

9.269.2. Description

One or more host objects have a <roid> element with a repository identifier not found in the IANA registry.

9.269.3. Test cases

This error may be produced by the following test cases:

9.270. RDE_HOST_HAS_INVALID_STATUS

9.270.1. Severity

9.270.2. Description

One or more domain objects have an invalid <status> element.

9.270.3. Test cases

This error may be produced by the following test cases:

9.271. RDE_HOST_HAS_MISSING_CLID

9.271.1. Severity

9.271.2. Description

One or more host objects do not have a <clID> element.

9.271.3. Test cases

This error may be produced by the following test cases:

9.272. RDE_HOST_HAS_MISSING_IP_ADDRESS

9.272.1. Severity

9.272.2. Description

One or more host objects with in-bailiwick hostnames do not have a <addr> element.

9.272.3. Test cases

This error may be produced by the following test cases:

9.273. RDE_HOST_HAS_MISSING_ROID

9.273.1. Severity

9.273.2. Description

One or more host objects do not have a <clID> element.

9.273.3. Test cases

This error may be produced by the following test cases:

9.274. RDE_HOST_HAS_MISSING_STATUS

9.274.1. Severity

9.274.2. Description

One or more host objects do not have a <status> element.

9.274.3. Test cases

This error may be produced by the following test cases:

9.275. RDE_HOST_HAS_NON_UNIQUE_NAME

9.275.1. Severity

9.275.2. Description

One or more host objects have the same <name> element.

9.275.3. Test cases

This error may be produced by the following test cases:

9.276. RDE_HOST_HAS_NON_UNIQUE_ROID

9.276.1. Severity

9.276.2. Description

One or more host objects have the same <roid> element.

9.276.3. Test cases

This error may be produced by the following test cases:

9.277. RDE_IDN_OBJECT_INVALID

9.277.1. Severity

9.277.2. Description

The deposit contains one or more invalid IDN objects.

9.277.3. Test cases

This error may be produced by the following test cases:

9.278. RDE_IDN_OBJECT_MISSING

9.278.1. Severity

9.278.2. Description

One or more IDN objects are missing.

9.278.3. Test cases

This error may be produced by the following test cases:

9.279. RDE_IDN_OBJECT_UNEXPECTED

9.279.1. Severity

9.279.2. Description

One or more unexpected IDN objects were found in the deposit.

9.279.3. Test cases

This error may be produced by the following test cases:

9.280. RDE_INVALID_CSV

9.280.1. Severity

9.280.2. Description

One or more CSV files in the deposit do not conform to RFC 4180.

9.280.3. Test cases

This error may be produced by the following test cases:

9.281. RDE_INVALID_FILENAME

9.281.1. Severity

9.281.2. Description

The filename of the deposit does not confirm to the requirements in Specification 2 of the Registry Agreement.

9.281.3. Test cases

This error may be produced by the following test cases:

9.282. RDE_INVALID_SIGNATURE

9.282.1. Severity

9.282.2. Description

The OpenPGP signature could not be validated.

9.282.3. Test cases

This error may be produced by the following test cases:

9.283. RDE_MISSING_OBJECT_URI

9.283.1. Severity

9.283.2. Description

One or more expected object URIs were not found in the header.

9.283.3. Test cases

This error may be produced by the following test cases:

9.284. RDE_MIXED_TYPES

9.284.1. Severity

9.284.2. Description

The deposit contains both XML and CSV data files.

9.284.3. Test cases

This error may be produced by the following test cases:

9.285. RDE_NNDN_CONFLICTS_WITH_DOMAIN

9.285.1. Severity

9.285.2. Description

One or more NNDN objects have names that match those of one or more domain objects.

9.285.3. Test cases

This error may be produced by the following test cases:

9.286. RDE_OBJECT_COUNT_MISMATCH

9.286.1. Severity

9.286.2. Description

The number of objects in the deposit does not match the counts found in the header.

9.286.3. Test cases

This error may be produced by the following test cases:

9.287. RDE_POLICY_OBJECT_INVALID

9.287.1. Severity

9.287.2. Description

The Policy Object is invalid.

9.287.3. Test cases

This error may be produced by the following test cases:

9.288. RDE_POLICY_OBJECT_MISSING

9.288.1. Severity

9.288.2. Description

The Policy Object is missing.

9.288.3. Test cases

This error may be produced by the following test cases:

9.289. RDE_POLICY_OBJECT_MISSING_OBJECTS

9.289.1. Severity

9.289.2. Description

The Policy Object does not contain all expected objects.

9.289.3. Test cases

This error may be produced by the following test cases:

9.290. RDE_REGISTRAR_HAS_INVALID_GURID

9.290.1. Severity

9.290.2. Description

One of more registrar objects have an invalid <gurid> element.

9.290.3. Test cases

This error may be produced by the following test cases:

9.291. RDE_REGISTRAR_HAS_INVALID_ID

9.291.1. Severity

9.291.2. Description

One of more registrar objects have an invalid <id> element.

9.291.3. Test cases

This error may be produced by the following test cases:

9.292. RDE_REGISTRAR_HAS_INVALID_NAME

9.292.1. Severity

9.292.2. Description

One of more registrar objects have an invalid <name> element.

9.292.3. Test cases

This error may be produced by the following test cases:

9.293. RDE_REGISTRAR_HAS_MISSING_GURID

9.293.1. Severity

9.293.2. Description

One of more registrar objects have a missing <gurid> element.

9.293.3. Test cases

This error may be produced by the following test cases:

9.294. RDE_REGISTRAR_HAS_MISSING_ID

9.294.1. Severity

9.294.2. Description

One of more registrar objects have a missing <id> element.

9.294.3. Test cases

This error may be produced by the following test cases:

9.295. RDE_REGISTRAR_HAS_MISSING_NAME

9.295.1. Severity

9.295.2. Description

One of more registrar objects have a missing <name> element.

9.295.3. Test cases

This error may be produced by the following test cases:

9.296. RDE_SCHEMA_VALIDATION_ERROR

9.296.1. Severity

9.296.2. Description

The XML in the deposit file could not be validated against the schema.

9.296.3. Test cases

This error may be produced by the following test cases:

9.297. RDE_UNEXPECTED_OBJECT_URI

9.297.1. Severity

9.297.2. Description

The deposit contains an unexpected object URI in the header.

9.297.3. Test cases

This error may be produced by the following test cases:

9.298. RDE_XML_PARSE_ERROR

9.298.1. Severity

9.298.2. Description

The XML in the deposit file is not well-formed.

9.298.3. Test cases

This error may be produced by the following test cases:

9.299. RPMS_MISSING_CLAIMS_KEY

9.299.1. Severity

9.299.2. Description

The <check> response did not include an expected <launch:claimKey> element.

9.299.3. Test cases

This error may be produced by the following test cases:

9.300. RPMS_SUNRISE_CREATE_INFO_OBJECT_DOES_NOT_EXIST

9.300.1. Severity

9.300.2. Description

Following a sunrise <create> command, the <info> response did not return the created object.

9.300.3. Test cases

This error may be produced by the following test cases:

9.301. RPMS_SUNRISE_CREATE_INFO_OBJECT_IS_HAS_MISSING_OR_INVALID_PROPERTIES

9.301.1. Severity

9.301.2. Description

Following a sunrise <create> command, the <info> response contained missing or invalid object properties.

9.301.3. Test cases

This error may be produced by the following test cases:

9.302. RPMS_SUNRISE_CREATE_UNEXPECTED_FAILURE_USING_VALID_SMD

9.302.1. Severity

9.302.2. Description

A sunrise <create> command using a valid SMD unexpectedly failed.

9.302.3. Test cases

This error may be produced by the following test cases:

9.303. RPMS_SUNRISE_CREATE_UNEXPECTED_SUCCESS_USING_EXPIRED_SMD

9.303.1. Severity

9.303.2. Description

A sunrise <create> command using a expired SMD unexpectedly succeeded.

9.303.3. Test cases

This error may be produced by the following test cases:

9.304. RPMS_SUNRISE_CREATE_UNEXPECTED_SUCCESS_USING_INCORRECT_SMD

9.304.1. Severity

9.304.2. Description

A sunrise <create> command using an SMD that did not contain the domain unexpectedly succeeded.

9.304.3. Test cases

This error may be produced by the following test cases:

9.305. RPMS_SUNRISE_CREATE_UNEXPECTED_SUCCESS_USING_REVOKED_SMD

9.305.1. Severity

9.305.2. Description

A sunrise <create> command using a revoked SMD unexpectedly succeeded.

9.305.3. Test cases

This error may be produced by the following test cases:

9.306. RPMS_SUNRISE_CREATE_UNEXPECTED_SUCCESS_USING_SMD_WITH_REVOKED_SIGNATURE

9.306.1. Severity

9.306.2. Description

A sunrise <create> command using an SMD signed with a revoked certificate unexpectedly succeeded.

9.306.3. Test cases

This error may be produced by the following test cases:

9.307. RPMS_TRADEMARK_CREATE_INFO_OBJECT_DOES_NOT_EXIST

9.307.1. Severity

9.307.2. Description

Following a trademark claims <create> command, the <info> response did not return the created object.

9.307.3. Test cases

This error may be produced by the following test cases:

9.308. RPMS_TRADEMARK_CREATE_INFO_OBJECT_IS_HAS_MISSING_OR_INVALID_PROPERTIES

9.308.1. Severity

9.308.2. Description

Following a trademark claims <create> command, the <info> response contained missing or invalid object properties.

9.308.3. Test cases

This error may be produced by the following test cases:

9.309. RPMS_TRADEMARK_CREATE_UNEXPECTED_FAILURE_USING_VALID_CLAIM_KEY

9.309.1. Severity

9.309.2. Description

A trademark claims <create> command using a valid claim key unexpectedly failed.

9.309.3. Test cases

This error may be produced by the following test cases:

9.310. RPMS_TRADEMARK_CREATE_UNEXPECTED_SUCCESS_USING_INVALID_ACCEPTANCE_DATE

9.310.1. Severity

9.310.2. Description

A trademark claims <create> command using an invalid acceptance date unexpectedly succeeded.

9.310.3. Test cases

This error may be produced by the following test cases:

9.311. RPMS_TRADEMARK_CREATE_UNEXPECTED_SUCCESS_USING_INVALID_CLAIM_KEY

9.311.1. Severity

9.311.2. Description

A trademark claims <create> command using an invalid claim key unexpectedly succeeded.

9.311.3. Test cases

This error may be produced by the following test cases:

9.312. RPMS_UNEXPECTED_CLAIMS_KEY

9.312.1. Severity

9.312.2. Description

The <check> response included an unexpected <launch:claimKey> element.

9.312.3. Test cases

This error may be produced by the following test cases:

9.313. SRSGW_CONTACT_CREATE_FAILED

9.313.1. Severity

9.313.2. Description

The contact <create> command at the SRS Gateway EPP server failed.

9.313.3. Test cases

This error may be produced by the following test cases:

9.314. SRSGW_CONTACT_CREATE_OBJECT_HAS_MISSING_OR_INVALID_PROPERTIES

9.314.1. Severity

9.314.2. Description

Following a successful contact <create> command, the <info> response from the SRS Gateway EPP server has missing or invalid object properties.

9.314.3. Test cases

This error may be produced by the following test cases:

9.315. SRSGW_CONTACT_CREATE_OBJECT_NOT_FOUND_WITHIN_DEADLINE

9.315.1. Severity

9.315.2. Description

Following a successful contact <create> command, the primary EPP server did not respond with a successful <info> response within the deadline.

9.315.3. Test cases

This error may be produced by the following test cases:

9.316. SRSGW_DOMAIN_CREATE_FAILED

9.316.1. Severity

9.316.2. Description

The domain <create> 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_CREATE_OBJECT_HAS_MISSING_OR_INVALID_PROPERTIES

9.317.1. Severity

9.317.2. Description

Following a successful domain <create> command, the <info> response from the SRS Gateway EPP server has missing or invalid object properties.

9.317.3. Test cases

This error may be produced by the following test cases:

9.318. SRSGW_DOMAIN_CREATE_OBJECT_NOT_FOUND_WITHIN_DEADLINE

9.318.1. Severity

9.318.2. Description

Following a successful domain <create> command, the primary EPP server did not respond with a successful <info> response within the deadline.

9.318.3. Test cases

This error may be produced by the following test cases:

9.319. SRSGW_DOMAIN_DELETE_DOMAIN_NOT_PENDINGDELETE

9.319.1. Severity

9.319.2. Description

Following a successful domain <delete> command, the domain did not have the pendingDelete status at the primary EPP server.

9.319.3. Test cases

This error may be produced by the following test cases:

9.320. SRSGW_DOMAIN_DELETE_FAILED

9.320.1. Severity

9.320.2. Description

The domain <delete> 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_DELETE_RGP_STATUS_NOT_PENDINGDELETERESTORABLE

9.321.1. Severity

9.321.2. Description

Following a successful domain <delete> command, the domain did not have the pendingDeleteRestorable RGP status at the primary EPP server.

9.321.3. Test cases

This error may be produced by the following test cases:

9.322. SRSGW_DOMAIN_RENEW_FAILED

9.322.1. Severity

9.322.2. Description

The domain <renew> command at the SRS Gateway EPP server failed.

9.322.3. Test cases

This error may be produced by the following test cases:

9.323. SRSGW_DOMAIN_RENEW_OBJECT_NOT_UPDATED_WITHIN_DEADLINE

9.323.1. Severity

9.323.2. Description

Following a successful <renew> command, the domain’s expiry date was not updated at the primary EPP server within the deadline.

9.323.3. Test cases

This error may be produced by the following test cases:

9.324. SRSGW_DOMAIN_TRANSFER_APPROVAL_FAILED

9.324.1. Severity

9.324.2. Description

The domain <transfer op="approve"> 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_APPROVAL_OBJECT_HAS_INCORRECT_CLID

9.325.1. Severity

9.325.2. Description

Following a successful <transfer op="approve"> command, the domain is under the sponsorship of the wrong registrar.

9.325.3. Test cases

This error may be produced by the following test cases:

9.326. SRSGW_DOMAIN_TRANSFER_APPROVAL_OBJECT_NOT_UPDATED_WITHIN_DEADLINE

9.326.1. Severity

9.326.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.326.3. Test cases

This error may be produced by the following test cases:

9.327. SRSGW_DOMAIN_TRANSFER_APPROVAL_OBJECT_STILL_PENDING_TRANSFER

9.327.1. Severity

9.327.2. Description

The domain <transfer op="approve"> command at the SRS Gateway, the domain’s still has the pendingTransfer status.

9.327.3. Test cases

This error may be produced by the following test cases:

9.328. SRSGW_DOMAIN_TRANSFER_REQUEST_FAILED

9.328.1. Severity

9.328.2. Description

The domain <transfer op="request"> command at the SRS Gateway EPP server failed.

9.328.3. Test cases

This error may be produced by the following test cases:

9.329. SRSGW_DOMAIN_TRANSFER_REQUEST_OBJECT_NOT_PENDING_TRANSFER

9.329.1. Severity

9.329.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.329.3. Test cases

This error may be produced by the following test cases:

9.330. SRSGW_DOMAIN_TRANSFER_REQUEST_OBJECT_NOT_UPDATED_WITHIN_DEADLINE

9.330.1. Severity

9.330.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.330.3. Test cases

This error may be produced by the following test cases:

9.331. SRSGW_EPP_CONTACT_DELETE_FAILED

9.331.1. Severity

9.331.2. Description

The contact <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_CONTACT_DELETE_OBJECT_STILL_EXISTS

9.332.1. Severity

9.332.2. Description

Following a successful contact <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_CONTACT_UPDATE_FAILED

9.333.1. Severity

9.333.2. Description

The contact <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_CONTACT_UPDATE_INFO_RESPONSES_DIFFER

9.334.1. Severity

9.334.2. Description

Following a successful contact <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_EPP_HOST_DELETE_FAILED

9.335.1. Severity

9.335.2. Description

The host <delete> 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_EPP_HOST_DELETE_OBJECT_STILL_EXISTS

9.336.1. Severity

9.336.2. Description

Following a successful host <delete> command, the object was not purged from the primary EPP server within the deadline.

9.336.3. Test cases

This error may be produced by the following test cases:

9.337. SRSGW_EPP_HOST_UPDATE_FAILED

9.337.1. Severity

9.337.2. Description

The host <update> command at the SRS Gateway EPP server failed.

9.337.3. Test cases

This error may be produced by the following test cases:

9.338. SRSGW_EPP_HOST_UPDATE_INFO_RESPONSES_DIFFER

9.338.1. Severity

9.338.2. Description

Following a successful host <update> command, the <info> response from the primary EPP server was not updated within the deadline.

9.338.3. Test cases

This error may be produced by the following test cases:

9.339. SRSGW_EPP_INVALID_EXTENSION

9.339.1. Severity

9.339.2. Description

The XML instance provided in the srsgw.domainCreateExtension, srsgw.domainDeleteExtension, srsgw.domainRenewExtension, srsgw.domainTransferRequestExtension or srsgw.domainTransferApproveExtension input parameters was invalid. This may be because (a) it was not a well-formed XML instance, (b) specified an extension that was not registered in the EPP Extension Registry or (c) could not be validated against the XML schema(s) for that extension.

9.339.3. Test cases

This error may be produced by the following test cases:

9.340. SRSGW_HOST_CREATE_FAILED

9.340.1. Severity

9.340.2. Description

The host <create> command at the SRS Gateway EPP server failed.

9.340.3. Test cases

This error may be produced by the following test cases:

9.341. SRSGW_HOST_CREATE_OBJECT_HAS_MISSING_OR_INVALID_PROPERTIES

9.341.1. Severity

9.341.2. Description

Following a successful host <create> command, the <info> response from the SRS Gateway EPP server has missing or invalid object properties.

9.341.3. Test cases

This error may be produced by the following test cases:

9.342. SRSGW_HOST_CREATE_OBJECT_NOT_FOUND_WITHIN_DEADLINE

9.342.1. Severity

9.342.2. Description

Following a successful host <create> command, the primary EPP server did not respond with a successful <info> response within the deadline.

9.342.3. Test cases

This error may be produced by the following test cases:

9.343. SRSGW_RDAP_DNS_RESOLUTION_ERROR

9.343.1. Severity

9.343.2. Description

None of the RDAP base URL(s) could be resolved.

9.343.3. Test cases

This error may be produced by the following test cases:

9.344. SRSGW_RDAP_QUERY_FAILED

9.344.1. Severity

9.344.2. Description

The RDAP query resulted in an unexpected response (HTTP status, media type, etc).

9.344.3. Test cases

This error may be produced by the following test cases:

9.345. SRSGW_RDAP_RESPONSES_DIFFER

9.345.1. Severity

9.345.2. Description

The responses from the SRS Gateway and Primary RDAP servers differ.

9.345.3. Test cases

This error may be produced by the following test cases:

9.346. SRSGW_RDAP_SERVICE_PORT_UNREACHABLE

9.346.1. Severity

9.346.2. Description

None of the RDAP service ports could be reached.

9.346.3. Test cases

This error may be produced by the following test cases:

9.347. SRSGW_RDAP_TLS_CONNECTION_ERROR

9.347.1. Severity

9.347.2. Description

A TLS connection could not be established to the service port.

9.347.3. Test cases

This error may be produced by the following test cases:

9.348. ZM_AAAA_BAD_RDATA

9.348.1. Severity

9.348.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.348.3. Test cases

This error may be produced by the following test cases:

9.349. ZM_AAAA_QUERY_DROPPED

9.349.1. Severity

9.349.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.349.3. Test cases

This error may be produced by the following test cases:

9.350. ZM_AAAA_UNEXPECTED_RCODE

9.350.1. Severity

9.350.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.350.3. Test cases

This error may be produced by the following test cases:

9.351. ZM_ALGORITHM_DEPRECATED

9.351.1. Severity

9.351.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.351.3. Test cases

This error may be produced by the following test cases:

9.352. ZM_ALGORITHM_NOT_RECOMMENDED

9.352.1. Severity

9.352.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.352.3. Test cases

This error may be produced by the following test cases:

9.353. ZM_ALGORITHM_NOT_ZONE_SIGN

9.353.1. Severity

9.353.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.353.3. Test cases

This error may be produced by the following test cases:

9.354. ZM_ALGORITHM_PRIVATE

9.354.1. Severity

9.354.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.354.3. Test cases

This error may be produced by the following test cases:

9.355. ZM_ALGORITHM_RESERVED

9.355.1. Severity

9.355.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.355.3. Test cases

This error may be produced by the following test cases:

9.356. ZM_ALGORITHM_UNASSIGNED

9.356.1. Severity

9.356.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.356.3. Test cases

This error may be produced by the following test cases:

9.357. ZM_A_UNEXPECTED_RCODE

9.357.1. Severity

9.357.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.357.3. Test cases

This error may be produced by the following test cases:

9.358. ZM_BREAKS_ON_EDNS

9.358.1. Severity

9.358.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.358.3. Test cases

This error may be produced by the following test cases:

9.359. ZM_CAN_NOT_BE_RESOLVED

9.359.1. Severity

9.359.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.359.3. Test cases

This error may be produced by the following test cases:

9.360. ZM_CASE_QUERIES_RESULTS_DIFFER

9.360.1. Severity

9.360.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.360.3. Test cases

This error may be produced by the following test cases:

9.361. ZM_CASE_QUERY_DIFFERENT_ANSWER

9.361.1. Severity

9.361.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.361.3. Test cases

This error may be produced by the following test cases:

9.362. ZM_CASE_QUERY_DIFFERENT_RC

9.362.1. Severity

9.362.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.362.3. Test cases

This error may be produced by the following test cases:

9.363. ZM_CASE_QUERY_NO_ANSWER

9.363.1. Severity

9.363.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.363.3. Test cases

This error may be produced by the following test cases:

9.364. ZM_CHILD_NS_FAILED

9.364.1. Severity

9.364.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.364.3. Test cases

This error may be produced by the following test cases:

9.365. ZM_CHILD_NS_SAME_IP

9.365.1. Severity

9.365.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.365.3. Test cases

This error may be produced by the following test cases:

9.366. ZM_CHILD_ZONE_LAME

9.366.1. Severity

9.366.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.366.3. Test cases

This error may be produced by the following test cases:

9.367. ZM_CN01_MISSING_NS_RECORD_UDP

9.367.1. Severity

9.367.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.367.3. Test cases

This error may be produced by the following test cases:

9.368. ZM_CN01_MISSING_SOA_RECORD_UDP

9.368.1. Severity

9.368.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.368.3. Test cases

This error may be produced by the following test cases:

9.369. ZM_CN01_NO_RESPONSE_NS_QUERY_UDP

9.369.1. Severity

9.369.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.369.3. Test cases

This error may be produced by the following test cases:

9.370. ZM_CN01_NO_RESPONSE_SOA_QUERY_UDP

9.370.1. Severity

9.370.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.370.3. Test cases

This error may be produced by the following test cases:

9.371. ZM_CN01_NO_RESPONSE_UDP

9.371.1. Severity

9.371.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.371.3. Test cases

This error may be produced by the following test cases:

9.372. ZM_CN01_NS_RECORD_NOT_AA_UDP

9.372.1. Severity

9.372.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.372.3. Test cases

This error may be produced by the following test cases:

9.373. ZM_CN01_SOA_RECORD_NOT_AA_UDP

9.373.1. Severity

9.373.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.373.3. Test cases

This error may be produced by the following test cases:

9.374. ZM_CN01_UNEXPECTED_RCODE_NS_QUERY_UDP

9.374.1. Severity

9.374.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.374.3. Test cases

This error may be produced by the following test cases:

9.375. ZM_CN01_UNEXPECTED_RCODE_SOA_QUERY_UDP

9.375.1. Severity

9.375.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.375.3. Test cases

This error may be produced by the following test cases:

9.376. ZM_CN01_WRONG_NS_RECORD_UDP

9.376.1. Severity

9.376.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.376.3. Test cases

This error may be produced by the following test cases:

9.377. ZM_CN01_WRONG_SOA_RECORD_UDP

9.377.1. Severity

9.377.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.377.3. Test cases

This error may be produced by the following test cases:

9.378. ZM_CN02_MISSING_NS_RECORD_TCP

9.378.1. Severity

9.378.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.378.3. Test cases

This error may be produced by the following test cases:

9.379. ZM_CN02_MISSING_SOA_RECORD_TCP

9.379.1. Severity

9.379.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.379.3. Test cases

This error may be produced by the following test cases:

9.380. ZM_CN02_NO_RESPONSE_NS_QUERY_TCP

9.380.1. Severity

9.380.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.380.3. Test cases

This error may be produced by the following test cases:

9.381. ZM_CN02_NO_RESPONSE_SOA_QUERY_TCP

9.381.1. Severity

9.381.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.381.3. Test cases

This error may be produced by the following test cases:

9.382. ZM_CN02_NO_RESPONSE_TCP

9.382.1. Severity

9.382.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.382.3. Test cases

This error may be produced by the following test cases:

9.383. ZM_CN02_NS_RECORD_NOT_AA_TCP

9.383.1. Severity

9.383.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.383.3. Test cases

This error may be produced by the following test cases:

9.384. ZM_CN02_SOA_RECORD_NOT_AA_TCP

9.384.1. Severity

9.384.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.384.3. Test cases

This error may be produced by the following test cases:

9.385. ZM_CN02_UNEXPECTED_RCODE_NS_QUERY_TCP

9.385.1. Severity

9.385.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.385.3. Test cases

This error may be produced by the following test cases:

9.386. ZM_CN02_UNEXPECTED_RCODE_SOA_QUERY_TCP

9.386.1. Severity

9.386.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.386.3. Test cases

This error may be produced by the following test cases:

9.387. ZM_CN02_WRONG_NS_RECORD_TCP

9.387.1. Severity

9.387.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.387.3. Test cases

This error may be produced by the following test cases:

9.388. ZM_CN02_WRONG_SOA_RECORD_TCP

9.388.1. Severity

9.388.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.388.3. Test cases

This error may be produced by the following test cases:

9.389. ZM_DEL_NS_SAME_IP

9.389.1. Severity

9.389.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.389.3. Test cases

This error may be produced by the following test cases:

9.390. ZM_DIFFERENT_SOURCE_IP

9.390.1. Severity

9.390.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.390.3. Test cases

This error may be produced by the following test cases:

9.391. ZM_DNSKEY_SMALLER_THAN_REC

9.391.1. Severity

9.391.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.391.3. Test cases

This error may be produced by the following test cases:

9.392. ZM_DNSKEY_TOO_LARGE_FOR_ALGO

9.392.1. Severity

9.392.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.392.3. Test cases

This error may be produced by the following test cases:

9.393. ZM_DNSKEY_TOO_SMALL_FOR_ALGO

9.393.1. Severity

9.393.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.393.3. Test cases

This error may be produced by the following test cases:

9.394. ZM_DS01_DS_ALGO_2_MISSING

9.394.1. Severity

9.394.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.394.3. Test cases

This error may be produced by the following test cases:

9.395. ZM_DS01_DS_ALGO_DEPRECATED

9.395.1. Severity

9.395.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.395.3. Test cases

This error may be produced by the following test cases:

9.396. ZM_DS01_DS_ALGO_NOT_DS

9.396.1. Severity

9.396.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.396.3. Test cases

This error may be produced by the following test cases:

9.397. ZM_DS01_DS_ALGO_RESERVED

9.397.1. Severity

9.397.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.397.3. Test cases

This error may be produced by the following test cases:

9.398. ZM_DS02_DNSKEY_NOT_FOR_ZONE_SIGNING

9.398.1. Severity

9.398.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.398.3. Test cases

This error may be produced by the following test cases:

9.399. ZM_DS02_DNSKEY_NOT_SEP

9.399.1. Severity

9.399.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.399.3. Test cases

This error may be produced by the following test cases:

9.400. ZM_DS02_DNSKEY_NOT_SIGNED_BY_ANY_DS

9.400.1. Severity

9.400.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.400.3. Test cases

This error may be produced by the following test cases:

9.401. ZM_DS02_NO_DNSKEY_FOR_DS

9.401.1. Severity

9.401.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.401.3. Test cases

This error may be produced by the following test cases:

9.402. ZM_DS02_NO_MATCHING_DNSKEY_RRSIG

9.402.1. Severity

9.402.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.402.3. Test cases

This error may be produced by the following test cases:

9.403. ZM_DS02_NO_MATCH_DS_DNSKEY

9.403.1. Severity

9.403.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.403.3. Test cases

This error may be produced by the following test cases:

9.404. ZM_DS02_NO_VALID_DNSKEY_FOR_ANY_DS

9.404.1. Severity

9.404.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.404.3. Test cases

This error may be produced by the following test cases:

9.405. ZM_DS02_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_DS03_ERR_MULT_NSEC3

9.406.1. Severity

9.406.2. Description

Zonemaster describes this error as follows:

Multiple NSEC3 records when one is expected. Fetched from name servers “{ns_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_DS03_ILLEGAL_HASH_ALGO

9.407.1. Severity

9.407.2. Description

Zonemaster describes this error as follows:

The following servers respond with an illegal hash algorithm for NSEC3 ({algo_num}). Fetched from name servers “{ns_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_DS03_ILLEGAL_ITERATION_VALUE

9.408.1. Severity

9.408.2. Description

Zonemaster describes this error as follows:

The following servers respond with the NSEC3 iteration value {int}. The recommended practice is to set this value to 0. Fetched from name servers “{ns_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_DS03_ILLEGAL_SALT_LENGTH

9.409.1. Severity

9.409.2. Description

Zonemaster describes this error as follows:

The following servers respond with a non-empty salt in NSEC3 ({int} octets). The recommended practice is to use an empty salt. Fetched from name servers “{ns_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_DS03_INCONSISTENT_HASH_ALGO

9.410.1. Severity

9.410.2. Description

Zonemaster describes this error as follows:

Inconsistent hash algorithm in NSEC3 in responses for the child zone from different name servers.

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_DS03_INCONSISTENT_ITERATION

9.411.1. Severity

9.411.2. Description

Zonemaster describes this error as follows:

Inconsistent NSEC3 iteration value in responses for the child zone from different name servers.

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_DS03_INCONSISTENT_NSEC3_FLAGS

9.412.1. Severity

9.412.2. Description

Zonemaster describes this error as follows:

Inconsistent NSEC3 flag list in responses for the child zone from different name servers.

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_DS03_INCONSISTENT_SALT_LENGTH

9.413.1. Severity

9.413.2. Description

Zonemaster describes this error as follows:

Inconsistent salt length in NSEC3 in responses for the child zone from different name servers.

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_DS03_NO_DNSSEC_SUPPORT

9.414.1. Severity

9.414.2. Description

Zonemaster describes this error as follows:

The zone is not DNSSEC signed or not properly DNSSEC signed. Testing for NSEC3 has been skipped. Fetched from name servers “{ns_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_DS03_SERVER_NO_DNSSEC_SUPPORT

9.415.1. Severity

9.415.2. Description

Zonemaster describes this error as follows:

The following name servers do not support DNSSEC or have not been properly configured. Testing for NSEC3 has been skipped on those servers. Fetched from name servers “{ns_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_DS03_SERVER_NO_NSEC3

9.416.1. Severity

9.416.2. Description

Zonemaster describes this error as follows:

The following name servers do not use NSEC3, but others do. Testing for NSEC3 has been skipped on the following servers. Fetched from name servers “{ns_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_DS03_UNASSIGNED_FLAG_USED

9.417.1. Severity

9.417.2. Description

Zonemaster describes this error as follows:

The following servers respond with an NSEC3 record where an unassigned flag is used (bit {int}). Fetched from name servers “{ns_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_DS08_DNSKEY_RRSIG_EXPIRED

9.418.1. Severity

9.418.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.418.3. Test cases

This error may be produced by the following test cases:

9.419. ZM_DS08_DNSKEY_RRSIG_NOT_YET_VALID

9.419.1. Severity

9.419.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.419.3. Test cases

This error may be produced by the following test cases:

9.420. ZM_DS08_MISSING_RRSIG_IN_RESPONSE

9.420.1. Severity

9.420.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.420.3. Test cases

This error may be produced by the following test cases:

9.421. ZM_DS08_NO_MATCHING_DNSKEY

9.421.1. Severity

9.421.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.421.3. Test cases

This error may be produced by the following test cases:

9.422. ZM_DS08_RRSIG_NOT_VALID_BY_DNSKEY

9.422.1. Severity

9.422.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.422.3. Test cases

This error may be produced by the following test cases:

9.423. ZM_DS09_MISSING_RRSIG_IN_RESPONSE

9.423.1. Severity

9.423.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.423.3. Test cases

This error may be produced by the following test cases:

9.424. ZM_DS09_NO_MATCHING_DNSKEY

9.424.1. Severity

9.424.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.424.3. Test cases

This error may be produced by the following test cases:

9.425. ZM_DS09_RRSIG_NOT_VALID_BY_DNSKEY

9.425.1. Severity

9.425.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.425.3. Test cases

This error may be produced by the following test cases:

9.426. ZM_DS09_SOA_RRSIG_EXPIRED

9.426.1. Severity

9.426.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.426.3. Test cases

This error may be produced by the following test cases:

9.427. ZM_DS09_SOA_RRSIG_NOT_YET_VALID

9.427.1. Severity

9.427.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.427.3. Test cases

This error may be produced by the following test cases:

9.428. ZM_DS10_INCONSISTENT_NSEC_NSEC3

9.428.1. Severity

9.428.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.428.3. Test cases

This error may be produced by the following test cases:

9.429. ZM_DS10_MISSING_NSEC_NSEC3

9.429.1. Severity

9.429.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.429.3. Test cases

This error may be produced by the following test cases:

9.430. ZM_DS10_MIXED_NSEC_NSEC3

9.430.1. Severity

9.430.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.430.3. Test cases

This error may be produced by the following test cases:

9.431. ZM_DS10_NAME_NOT_COVERED_BY_NSEC

9.431.1. Severity

9.431.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.431.3. Test cases

This error may be produced by the following test cases:

9.432. ZM_DS10_NAME_NOT_COVERED_BY_NSEC3

9.432.1. Severity

9.432.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.432.3. Test cases

This error may be produced by the following test cases:

9.433. ZM_DS10_NON_EXISTENT_RESPONSE_ERROR

9.433.1. Severity

9.433.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.433.3. Test cases

This error may be produced by the following test cases:

9.434. ZM_DS10_NSEC3_MISSING_SIGNATURE

9.434.1. Severity

9.434.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.434.3. Test cases

This error may be produced by the following test cases:

9.435. ZM_DS10_NSEC3_RRSIG_VERIFY_ERROR

9.435.1. Severity

9.435.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.435.3. Test cases

This error may be produced by the following test cases:

9.436. ZM_DS10_NSEC_MISSING_SIGNATURE

9.436.1. Severity

9.436.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.436.3. Test cases

This error may be produced by the following test cases:

9.437. ZM_DS10_NSEC_RRSIG_VERIFY_ERROR

9.437.1. Severity

9.437.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.437.3. Test cases

This error may be produced by the following test cases:

9.438. ZM_DS10_UNSIGNED_ANSWER

9.438.1. Severity

9.438.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.438.3. Test cases

This error may be produced by the following test cases:

9.439. ZM_DS13_ALGO_NOT_SIGNED_DNSKEY

9.439.1. Severity

9.439.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.439.3. Test cases

This error may be produced by the following test cases:

9.440. ZM_DS13_ALGO_NOT_SIGNED_NS

9.440.1. Severity

9.440.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.440.3. Test cases

This error may be produced by the following test cases:

9.441. ZM_DS13_ALGO_NOT_SIGNED_SOA

9.441.1. Severity

9.441.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.441.3. Test cases

This error may be produced by the following test cases:

9.442. ZM_DURATION_LONG

9.442.1. Severity

9.442.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.442.3. Test cases

This error may be produced by the following test cases:

9.443. ZM_EDNS_RESPONSE_WITHOUT_EDNS

9.443.1. Severity

9.443.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.443.3. Test cases

This error may be produced by the following test cases:

9.444. ZM_EDNS_VERSION_ERROR

9.444.1. Severity

9.444.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.444.3. Test cases

This error may be produced by the following test cases:

9.445. ZM_EMPTY_ASN_SET

9.445.1. Severity

9.445.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.445.3. Test cases

This error may be produced by the following test cases:

9.446. ZM_ERROR_ASN_DATABASE

9.446.1. Severity

9.446.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.446.3. Test cases

This error may be produced by the following test cases:

9.447. ZM_EXTRA_ADDRESS_CHILD

9.447.1. Severity

9.447.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.447.3. Test cases

This error may be produced by the following test cases:

9.448. ZM_EXTRA_NAME_PARENT

9.448.1. Severity

9.448.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.448.3. Test cases

This error may be produced by the following test cases:

9.449. ZM_EXTRA_PROCESSING_BROKEN

9.449.1. Severity

9.449.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.449.3. Test cases

This error may be produced by the following test cases:

9.450. ZM_IN_BAILIWICK_ADDR_MISMATCH

9.450.1. Severity

9.450.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.450.3. Test cases

This error may be produced by the following test cases:

9.451. ZM_IPV4_ONE_ASN

9.451.1. Severity

9.451.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.451.3. Test cases

This error may be produced by the following test cases:

9.452. ZM_IPV6_ONE_ASN

9.452.1. Severity

9.452.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.452.3. Test cases

This error may be produced by the following test cases:

9.453. ZM_IS_A_RECURSOR

9.453.1. Severity

9.453.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.453.3. Test cases

This error may be produced by the following test cases:

9.454. ZM_IS_NOT_AUTHORITATIVE

9.454.1. Severity

9.454.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.454.3. Test cases

This error may be produced by the following test cases:

9.455. ZM_MISSING_OPT_IN_TRUNCATED

9.455.1. Severity

9.455.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.455.3. Test cases

This error may be produced by the following test cases:

9.456. ZM_MNAME_DISCOURAGED_DOUBLE_DASH

9.456.1. Severity

9.456.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.456.3. Test cases

This error may be produced by the following test cases:

9.457. ZM_MNAME_HAS_NO_ADDRESS

9.457.1. Severity

9.457.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.457.3. Test cases

This error may be produced by the following test cases:

9.458. ZM_MNAME_NON_ALLOWED_CHARS

9.458.1. Severity

9.458.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.458.3. Test cases

This error may be produced by the following test cases:

9.459. ZM_MNAME_NUMERIC_TLD

9.459.1. Severity

9.459.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.459.3. Test cases

This error may be produced by the following test cases:

9.460. ZM_MULTIPLE_NS_SET

9.460.1. Severity

9.460.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.460.3. Test cases

This error may be produced by the following test cases:

9.461. ZM_MULTIPLE_SOA

9.461.1. Severity

9.461.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.461.3. Test cases

This error may be produced by the following test cases:

9.462. ZM_MULTIPLE_SOA_MNAMES

9.462.1. Severity

9.462.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.462.3. Test cases

This error may be produced by the following test cases:

9.463. ZM_MULTIPLE_SOA_RNAMES

9.463.1. Severity

9.463.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.463.3. Test cases

This error may be produced by the following test cases:

9.464. ZM_MULTIPLE_SOA_TIME_PARAMETER_SET

9.464.1. Severity

9.464.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.464.3. Test cases

This error may be produced by the following test cases:

9.465. ZM_N10_EDNS_RESPONSE_ERROR

9.465.1. Severity

9.465.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.465.3. Test cases

This error may be produced by the following test cases:

9.466. ZM_N10_NO_RESPONSE_EDNS1_QUERY

9.466.1. Severity

9.466.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.466.3. Test cases

This error may be produced by the following test cases:

9.467. ZM_N10_UNEXPECTED_RCODE

9.467.1. Severity

9.467.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.467.3. Test cases

This error may be produced by the following test cases:

9.468. ZM_N11_NO_EDNS

9.468.1. Severity

9.468.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.468.3. Test cases

This error may be produced by the following test cases:

9.469. ZM_N11_NO_RESPONSE

9.469.1. Severity

9.469.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.469.3. Test cases

This error may be produced by the following test cases:

9.470. ZM_N11_RETURNS_UNKNOWN_OPTION_CODE

9.470.1. Severity

9.470.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.470.3. Test cases

This error may be produced by the following test cases:

9.471. ZM_N11_UNEXPECTED_ANSWER_SECTION

9.471.1. Severity

9.471.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.471.3. Test cases

This error may be produced by the following test cases:

9.472. ZM_N11_UNEXPECTED_RCODE

9.472.1. Severity

9.472.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.472.3. Test cases

This error may be produced by the following test cases:

9.473. ZM_N11_UNSET_AA

9.473.1. Severity

9.473.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.473.3. Test cases

This error may be produced by the following test cases:

9.474. ZM_NAMESERVER_IP_PRIVATE_NETWORK

9.474.1. Severity

9.474.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.474.3. Test cases

This error may be produced by the following test cases:

9.475. ZM_NAMESERVER_IP_WITHOUT_REVERSE

9.475.1. Severity

9.475.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.475.3. Test cases

This error may be produced by the following test cases:

9.476. ZM_NOT_ENOUGH_IPV4_NS_CHILD

9.476.1. Severity

9.476.2. Description

Zonemaster describes this error as follows:

Child does not list enough ({count}) nameservers that resolve to IPv4 addresses. Lower limit set to {minimum}. Name servers: {ns_list}

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_NOT_ENOUGH_IPV4_NS_DEL

9.477.1. Severity

9.477.2. Description

Zonemaster describes this error as follows:

Delegation does not list enough ({count}) nameservers that resolve to IPv4 addresses. Lower limit set to {minimum}. Name servers: {ns_list}

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_NOT_ENOUGH_IPV6_NS_CHILD

9.478.1. Severity

9.478.2. Description

Zonemaster describes this error as follows:

Child does not list enough ({count}) nameservers that resolve to IPv6 addresses. Lower limit set to {minimum}. Name servers: {ns_list}

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_NOT_ENOUGH_IPV6_NS_DEL

9.479.1. Severity

9.479.2. Description

Zonemaster describes this error as follows:

Delegation does not list enough ({count}) nameservers that resolve to IPv6 addresses. Lower limit set to {minimum}. Name servers: {ns_list}

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_NOT_ENOUGH_NS_CHILD

9.480.1. Severity

9.480.2. Description

Zonemaster describes this error as follows:

Child does not list enough ({count}) nameservers. Lower limit set to {minimum}. Name servers: {nsname_list}

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_NOT_ENOUGH_NS_DEL

9.481.1. Severity

9.481.2. Description

Zonemaster describes this error as follows:

Delegation does not list enough ({count}) nameservers. Lower limit set to {minimum}. Name servers: {nsname_list}

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_NO_EDNS_SUPPORT

9.482.1. Severity

9.482.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.482.3. Test cases

This error may be produced by the following test cases:

9.483. ZM_NO_IPV4_NS_CHILD

9.483.1. Severity

9.483.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.483.3. Test cases

This error may be produced by the following test cases:

9.484. ZM_NO_IPV4_NS_DEL

9.484.1. Severity

9.484.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.484.3. Test cases

This error may be produced by the following test cases:

9.485. ZM_NO_IPV6_NS_CHILD

9.485.1. Severity

9.485.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.485.3. Test cases

This error may be produced by the following test cases:

9.486. ZM_NO_IPV6_NS_DEL

9.486.1. Severity

9.486.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.486.3. Test cases

This error may be produced by the following test cases:

9.487. ZM_NO_RESOLUTION

9.487.1. Severity

9.487.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.487.3. Test cases

This error may be produced by the following test cases:

9.488. ZM_NO_RESPONSE

9.488.1. Severity

9.488.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.488.3. Test cases

This error may be produced by the following test cases:

9.489. ZM_NO_RESPONSE_DNSKEY

9.489.1. Severity

9.489.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.489.3. Test cases

This error may be produced by the following test cases:

9.490. ZM_NO_RESPONSE_NS_QUERY

9.490.1. Severity

9.490.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.490.3. Test cases

This error may be produced by the following test cases:

9.491. ZM_NO_RESPONSE_PTR_QUERY

9.491.1. Severity

9.491.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.491.3. Test cases

This error may be produced by the following test cases:

9.492. ZM_NO_RESPONSE_SOA_QUERY

9.492.1. Severity

9.492.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.492.3. Test cases

This error may be produced by the following test cases:

9.493. ZM_NO_SOA_IN_RESPONSE

9.493.1. Severity

9.493.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.493.3. Test cases

This error may be produced by the following test cases:

9.494. ZM_NS_ERROR

9.494.1. Severity

9.494.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.494.3. Test cases

This error may be produced by the following test cases:

9.495. ZM_NS_IS_CNAME

9.495.1. Severity

9.495.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.495.3. Test cases

This error may be produced by the following test cases:

9.496. ZM_OUT_OF_BAILIWICK_ADDR_MISMATCH

9.496.1. Severity

9.496.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.496.3. Test cases

This error may be produced by the following test cases:

9.497. ZM_QNAME_CASE_INSENSITIVE

9.497.1. Severity

9.497.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.497.3. Test cases

This error may be produced by the following test cases:

9.498. ZM_REFERRAL_SIZE_TOO_LARGE

9.498.1. Severity

9.498.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.498.3. Test cases

This error may be produced by the following test cases:

9.499. ZM_REMAINING_LONG

9.499.1. Severity

9.499.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.499.3. Test cases

This error may be produced by the following test cases:

9.500. ZM_REMAINING_SHORT

9.500.1. Severity

9.500.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.500.3. Test cases

This error may be produced by the following test cases:

9.501. ZM_RNAME_MAIL_DOMAIN_INVALID

9.501.1. Severity

9.501.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.501.3. Test cases

This error may be produced by the following test cases:

9.502. ZM_RNAME_MAIL_DOMAIN_LOCALHOST

9.502.1. Severity

9.502.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.502.3. Test cases

This error may be produced by the following test cases:

9.503. ZM_RNAME_MAIL_ILLEGAL_CNAME

9.503.1. Severity

9.503.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.503.3. Test cases

This error may be produced by the following test cases:

9.504. ZM_RNAME_MISUSED_AT_SIGN

9.504.1. Severity

9.504.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.504.3. Test cases

This error may be produced by the following test cases:

9.505. ZM_RNAME_RFC822_INVALID

9.505.1. Severity

9.505.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.505.3. Test cases

This error may be produced by the following test cases:

9.506. ZM_RRSIG_EXPIRED

9.506.1. Severity

9.506.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.506.3. Test cases

This error may be produced by the following test cases:

9.507. ZM_SAME_IP_ADDRESS

9.507.1. Severity

9.507.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.507.3. Test cases

This error may be produced by the following test cases:

9.508. ZM_TOTAL_NAME_MISMATCH

9.508.1. Severity

9.508.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.508.3. Test cases

This error may be produced by the following test cases:

9.509. ZM_UNEXPECTED_RCODE

9.509.1. Severity

9.509.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.509.3. Test cases

This error may be produced by the following test cases:

9.510. ZM_WRONG_SOA

9.510.1. Severity

9.510.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.510.3. Test cases

This error may be produced by the following test cases:

9.511. ZM_Z_FLAGS_NOTCLEAR

9.511.1. Severity

9.511.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.511.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
voiceExt
fax
faxExt
email
authInfo
passOrFail
errorCode
string
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 (if supported)


Address line 1 (if supported)


Address line 2 (if supported)


Address line 3 (if supported)


City


State or province (if supported)


Postal code (if supported)


Country code


Phone (if supported)


Voice extension (if supported)


Fax (if supported)


Fax extension (if supported)


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}
{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}
{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}
{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}
{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}
{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}
{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}
{AUTO}
{AUTO}
{AUTO}
fail
EPP_CONTACT_CREATE_SERVER_ACCEPTS_INVALID_ORG


{AUTO}
int
{AUTO}
{AUTO}
{AUTO}
{EMPTY}
{EMPTY}
{EMPTY}
{AUTO}
{AUTO}
{AUTO}
{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}
{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}
{AUTO}
{AUTO}
{AUTO}
fail
EPP_CONTACT_CREATE_SERVER_ACCEPTS_EMPTY_VOICE


{AUTO}
int
{AUTO}
{AUTO}
{AUTO}
{EMPTY}
{EMPTY}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{EMPTY}
{AUTO}
fail
EPP_CONTACT_CREATE_SERVER_ACCEPTS_EMPTY_EMAIL


{AUTO}
int
{AUTO}
{RANDCHARS(256)}
{AUTO}
{EMPTY}
{EMPTY}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
fail
EPP_CONTACT_CREATE_SERVER_ACCEPTS_INVALID_ORG


{AUTO}
int
{AUTO}
{AUTO}
{RANDCHARS(256)}
{EMPTY}
{EMPTY}
{AUTO}
{AUTO}
{AUTO}
{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}
{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}
{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}
{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}
{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}
{AUTO}
{AUTO}
{AUTO}
fail
EPP_CONTACT_CREATE_SERVER_ACCEPTS_INVALID_VOICE


{AUTO}
int
{AUTO}
{AUTO}
{AUTO}
{EMPTY}
{EMPTY}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
+1111.1
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
fail
EPP_CONTACT_CREATE_SERVER_ACCEPTS_INVALID_VOICE


{AUTO}
int
{AUTO}
{AUTO}
{AUTO}
{EMPTY}
{EMPTY}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
55
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
fail
EPP_CONTACT_CREATE_SERVER_ACCEPTS_INVALID_VOICE


{AUTO}
int
{AUTO}
{AUTO}
{AUTO}
{EMPTY}
{EMPTY}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
+1.
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
fail
EPP_CONTACT_CREATE_SERVER_ACCEPTS_INVALID_VOICE


{AUTO}
int
{AUTO}
{AUTO}
{AUTO}
{EMPTY}
{EMPTY}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
+1.123456789012345
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
fail
EPP_CONTACT_CREATE_SERVER_ACCEPTS_INVALID_VOICE


{AUTO}
int
{AUTO}
{AUTO}
{AUTO}
{EMPTY}
{EMPTY}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
+1.a
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
fail
EPP_CONTACT_CREATE_SERVER_ACCEPTS_INVALID_VOICE


{AUTO}
int
{AUTO}
{AUTO}
{AUTO}
{EMPTY}
{EMPTY}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
+a.1
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
fail
EPP_CONTACT_CREATE_SERVER_ACCEPTS_INVALID_VOICE


{AUTO}
int
{AUTO}
{AUTO}
{AUTO}
{EMPTY}
{EMPTY}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
+12345
{AUTO}
{AUTO}
{AUTO}
fail
EPP_CONTACT_CREATE_SERVER_ACCEPTS_INVALID_FAX


{AUTO}
int
{AUTO}
{AUTO}
{AUTO}
{EMPTY}
{EMPTY}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
+1111.1
{AUTO}
{AUTO}
{AUTO}
fail
EPP_CONTACT_CREATE_SERVER_ACCEPTS_INVALID_FAX


{AUTO}
int
{AUTO}
{AUTO}
{AUTO}
{EMPTY}
{EMPTY}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
55
{AUTO}
{AUTO}
{AUTO}
fail
EPP_CONTACT_CREATE_SERVER_ACCEPTS_INVALID_FAX


{AUTO}
int
{AUTO}
{AUTO}
{AUTO}
{EMPTY}
{EMPTY}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
+1.
{AUTO}
{AUTO}
{AUTO}
fail
EPP_CONTACT_CREATE_SERVER_ACCEPTS_INVALID_FAX


{AUTO}
int
{AUTO}
{AUTO}
{AUTO}
{EMPTY}
{EMPTY}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
+1.123456789012345
{AUTO}
{AUTO}
{AUTO}
fail
EPP_CONTACT_CREATE_SERVER_ACCEPTS_INVALID_FAX


{AUTO}
int
{AUTO}
{AUTO}
{AUTO}
{EMPTY}
{EMPTY}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
+1.a
{AUTO}
{AUTO}
{AUTO}
fail
EPP_CONTACT_CREATE_SERVER_ACCEPTS_INVALID_FAX


{AUTO}
int
{AUTO}
{AUTO}
{AUTO}
{EMPTY}
{EMPTY}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
+a.1
{AUTO}
{AUTO}
{AUTO}
fail
EPP_CONTACT_CREATE_SERVER_ACCEPTS_INVALID_FAX


{AUTO}
int
{AUTO}
{AUTO}
{AUTO}
{EMPTY}
{EMPTY}
{AUTO}
{AUTO}
{AUTO}
{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}
{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}
{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}
{AUTO}
{AUTO}
@
{AUTO}
fail
EPP_CONTACT_CREATE_SERVER_ACCEPTS_INVALID_EMAIL


{AUTO}
int
{AUTO}
{AUTO}
{AUTO}
{EMPTY}
{EMPTY}
{AUTO}
{AUTO}
{AUTO}
{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. epp-09-other-data
10.2.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.2.2. Data table
action
voice
voiceExt
fax
faxExt
email
passOrFail
errorCode


string
string
string
string
string
string




Phone (if supported)


Voice extension (if supported)


Fax (if supported)


Fax extension (if supported)


Email


Expected result


Error code if expected result is not produced




chg
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
pass
EPP_UNEXPECTED_COMMAND_FAILURE


chg
+12345
{AUTO}
{AUTO}
{AUTO}
{AUTO}
fail
EPP_CONTACT_UPDATE_SERVER_ACCEPTS_INVALID_VOICE


chg
+1111.1
{AUTO}
{AUTO}
{AUTO}
{AUTO}
fail
EPP_CONTACT_UPDATE_SERVER_ACCEPTS_INVALID_VOICE


chg
55
{AUTO}
{AUTO}
{AUTO}
{AUTO}
fail
EPP_CONTACT_UPDATE_SERVER_ACCEPTS_INVALID_VOICE


chg
+1.
{AUTO}
{AUTO}
{AUTO}
{AUTO}
fail
EPP_CONTACT_UPDATE_SERVER_ACCEPTS_INVALID_VOICE


chg
+1.123456789012345
{AUTO}
{AUTO}
{AUTO}
{AUTO}
fail
EPP_CONTACT_UPDATE_SERVER_ACCEPTS_INVALID_VOICE


chg
+1.a
{AUTO}
{AUTO}
{AUTO}
{AUTO}
fail
EPP_CONTACT_UPDATE_SERVER_ACCEPTS_INVALID_VOICE


chg
+a.1
{AUTO}
{AUTO}
{AUTO}
{AUTO}
fail
EPP_CONTACT_UPDATE_SERVER_ACCEPTS_INVALID_VOICE


chg
{AUTO}
{AUTO}
+12345
{AUTO}
{AUTO}
fail
EPP_CONTACT_UPDATE_SERVER_ACCEPTS_INVALID_FAX


chg
{AUTO}
{AUTO}
+1111.1
{AUTO}
{AUTO}
fail
EPP_CONTACT_UPDATE_SERVER_ACCEPTS_INVALID_FAX


chg
{AUTO}
{AUTO}
55
{AUTO}
{AUTO}
fail
EPP_CONTACT_UPDATE_SERVER_ACCEPTS_INVALID_FAX


chg
{AUTO}
{AUTO}
+1.
{AUTO}
{AUTO}
fail
EPP_CONTACT_UPDATE_SERVER_ACCEPTS_INVALID_FAX


chg
{AUTO}
{AUTO}
+1.123456789012345
{AUTO}
{AUTO}
fail
EPP_CONTACT_UPDATE_SERVER_ACCEPTS_INVALID_FAX


chg
{AUTO}
{AUTO}
+1.a
{AUTO}
{AUTO}
fail
EPP_CONTACT_UPDATE_SERVER_ACCEPTS_INVALID_FAX


chg
{AUTO}
{AUTO}
+a.1
{AUTO}
{AUTO}
fail
EPP_CONTACT_UPDATE_SERVER_ACCEPTS_INVALID_FAX


chg
{AUTO}
{AUTO}
{AUTO}
{AUTO}
example
fail
EPP_CONTACT_UPDATE_SERVER_ACCEPTS_INVALID_EMAIL


chg
{AUTO}
{AUTO}
{AUTO}
{AUTO}
example.example
fail
EPP_CONTACT_UPDATE_SERVER_ACCEPTS_INVALID_EMAIL


chg
{AUTO}
{AUTO}
{AUTO}
{AUTO}
@example.com
fail
EPP_CONTACT_UPDATE_SERVER_ACCEPTS_INVALID_EMAIL


chg
{AUTO}
{AUTO}
{AUTO}
{AUTO}
@
fail
EPP_CONTACT_UPDATE_SERVER_ACCEPTS_INVALID_EMAIL


chg
{AUTO}
{AUTO}
{AUTO}
{AUTO}
{RANDCHARS(65) & "@example.com"}
fail
EPP_CONTACT_UPDATE_SERVER_ACCEPTS_INVALID_EMAIL


10.2.3. Test cases
This data provider is used by the following test cases:


10.3. epp-09-postalinfo-data
10.3.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.3.2. Data table
action
postalInfoType
name
org
street1
street2
street3
city
sp
pc
cc
passOrFail
errorCode


string
string
string
string
string
string
string
string
string
string
string
string
string




Postal Info type attribute


Contact Name


Contact Org (if supported)


Address line 1 (if supported)


Address line 2 (if supported)


Address line 3 (if supported)


City


State or province (if supported)


Postal code (if supported)


Country code


Expected result


Error code if expected result is not produced




chg
int
{AUTO}
{AUTO}
{AUTO}
{EMPTY}
{EMPTY}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
pass
EPP_UNEXPECTED_COMMAND_FAILURE


chg
tni
{AUTO}
{AUTO}
{AUTO}
{EMPTY}
{EMPTY}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
fail
EPP_CONTACT_UPDATE_SERVER_ACCEPTS_INVALID_POSTALINFO_TYPE


chg
{EMPTY}
{AUTO}
{AUTO}
{AUTO}
{EMPTY}
{EMPTY}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
fail
EPP_CONTACT_UPDATE_SERVER_ACCEPTS_INVALID_POSTALINFO_TYPE


chg
int
{EMPTY}
{AUTO}
{AUTO}
{EMPTY}
{EMPTY}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
fail
EPP_CONTACT_UPDATE_SERVER_ACCEPTS_EMPTY_NAME


chg
int
{AUTO}
{RANDCHARS(256)}
{AUTO}
{EMPTY}
{EMPTY}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
fail
EPP_CONTACT_UPDATE_SERVER_ACCEPTS_INVALID_ORG


chg
int
{AUTO}
{AUTO}
{AUTO}
{EMPTY}
{EMPTY}
{EMPTY}
{AUTO}
{AUTO}
{AUTO}
fail
EPP_CONTACT_UPDATE_SERVER_ACCEPTS_EMPTY_CITY


chg
int
{AUTO}
{AUTO}
{AUTO}
{EMPTY}
{EMPTY}
{AUTO}
{AUTO}
{AUTO}
{EMPTY}
fail
EPP_CONTACT_UPDATE_SERVER_ACCEPTS_EMPTY_CC


chg
int
{RANDCHARS(256)}
{AUTO}
{AUTO}
{EMPTY}
{EMPTY}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
fail
EPP_CONTACT_UPDATE_SERVER_ACCEPTS_INVALID_ORG


chg
int
{AUTO}
{AUTO}
{RANDCHARS(256)}
{EMPTY}
{EMPTY}
{AUTO}
{AUTO}
{AUTO}
{AUTO}
fail
EPP_CONTACT_UPDATE_SERVER_ACCEPTS_INVALID_STREET


chg
int
{AUTO}
{AUTO}
{AUTO}
{EMPTY}
{EMPTY}
{RANDCHARS(256)}
{AUTO}
{AUTO}
{AUTO}
fail
EPP_CONTACT_UPDATE_SERVER_ACCEPTS_INVALID_CITY


chg
int
{AUTO}
{AUTO}
{AUTO}
{EMPTY}
{EMPTY}
{AUTO}
{AUTO}
{AUTO}
XX
fail
EPP_CONTACT_UPDATE_SERVER_ACCEPTS_INVALID_CC


chg
int
{AUTO}
{AUTO}
{AUTO}
{EMPTY}
{EMPTY}
{AUTO}
{AUTO}
{AUTO}
U
fail
EPP_CONTACT_UPDATE_SERVER_ACCEPTS_INVALID_CC


chg
int
{AUTO}
{AUTO}
{AUTO}
{EMPTY}
{EMPTY}
{AUTO}
{AUTO}
{AUTO}
USA
fail
EPP_CONTACT_UPDATE_SERVER_ACCEPTS_INVALID_CC


10.3.3. Test cases
This data provider is used by the following test cases:


10.4. epp-09-status-data
10.4.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.
      • 

    • 

  • Any row containing an “action” value of “add” and a passOrFail value
of “pass” should result in an object property being added, which will be
validated using an <info> command.
    • 

  • The cell values for rows with action=rem do not occur in previous
rows, so the objects should not have those properties, meaning a
successful response is an error.
    • 



10.4.2. Data table
action
status
passOrFail
errorCode


string
string
string
string




Status Code


Expected result


Error code if expected result is not produced




add
clientUpdateProhibited
pass
EPP_UNEXPECTED_COMMAND_FAILURE


add
clientUpdateProhibited
fail
EPP_UNEXPECTED_COMMAND_SUCCESS


rem
clientUpdateProhibited
pass
EPP_UNEXPECTED_COMMAND_FAILURE


add
clientDeleteProhibited
pass
EPP_UNEXPECTED_COMMAND_FAILURE


add
clientDeleteProhibited
fail
EPP_UNEXPECTED_COMMAND_SUCCESS


add
clientHold
fail
EPP_CONTACT_UPDATE_SERVER_ACCEPTS_INVALID_STATUS_CODE


add
linked
fail
EPP_CONTACT_UPDATE_SERVER_ACCEPTS_INVALID_STATUS_CODE


add
ok
fail
EPP_CONTACT_UPDATE_SERVER_ACCEPTS_INVALID_STATUS_CODE


add
pendingCreate
fail
EPP_CONTACT_UPDATE_SERVER_ACCEPTS_INVALID_STATUS_CODE


add
pendingDelete
fail
EPP_CONTACT_UPDATE_SERVER_ACCEPTS_INVALID_STATUS_CODE


add
pendingTransfer
fail
EPP_CONTACT_UPDATE_SERVER_ACCEPTS_INVALID_STATUS_CODE


add
pendingUpdate
fail
EPP_CONTACT_UPDATE_SERVER_ACCEPTS_INVALID_STATUS_CODE


add
serverDeleteProhibited
fail
EPP_CONTACT_UPDATE_SERVER_ACCEPTS_INVALID_STATUS_CODE


add
serverUpdateProhibited
fail
EPP_CONTACT_UPDATE_SERVER_ACCEPTS_INVALID_STATUS_CODE


add
invalidStatusCode
fail
EPP_CONTACT_UPDATE_SERVER_ACCEPTS_INVALID_STATUS_CODE


rem
clientUpdateProhibited
fail
EPP_UNEXPECTED_COMMAND_SUCCESS


rem
clientDeleteProhibited
pass
EPP_UNEXPECTED_COMMAND_FAILURE


rem
clientDeleteProhibited
fail
EPP_UNEXPECTED_COMMAND_SUCCESS


rem
ok
fail
EPP_UNEXPECTED_COMMAND_SUCCESS


rem
pendingCreate
fail
EPP_UNEXPECTED_COMMAND_SUCCESS


rem
pendingDelete
fail
EPP_UNEXPECTED_COMMAND_SUCCESS


rem
pendingTransfer
fail
EPP_UNEXPECTED_COMMAND_SUCCESS


rem
pendingUpdate
fail
EPP_UNEXPECTED_COMMAND_SUCCESS


rem
serverDeleteProhibited
fail
EPP_UNEXPECTED_COMMAND_SUCCESS


rem
serverUpdateProhibited
fail
EPP_UNEXPECTED_COMMAND_SUCCESS


rem
invalidStatusCode
fail
EPP_UNEXPECTED_COMMAND_SUCCESS


10.4.3. Test cases
This data provider is used by the following test cases:


10.5. epp-11-data
10.5.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.
      • 

    • 



10.5.2. Data table
name
createParentFirst
ip
addr
passOrFail
errorCode


string
boolean
string
string
string
string


Hostname


Whether the superordinate domain name should be created before the
subordinate host name is created (if it does not already exist)


IP Version


IP Address


Expected result


Error code if expected result is not produced




ns1.epp-11.rst.icann
false
{EMPTY}
{EMPTY}
pass
EPP_UNEXPECTED_COMMAND_FAILURE


!.invalid
false
{EMPTY}
{EMPTY}
fail
EPP_HOST_CREATE_SERVER_ACCEPTS_INVALID_HOSTNAME


{"ns1.epp-11.rst." & $TLD}
false
{EMPTY}
{EMPTY}
fail
EPP_HOST_CREATE_SERVER_ACCEPTS_INVALID_HOSTNAME


{"!.epp-11.rst." & $TLD}
true
{EMPTY}
{EMPTY}
fail
EPP_HOST_CREATE_SERVER_ACCEPTS_INVALID_HOSTNAME


{RANDCHARS(64) & ".epp-11.rst." & $TLD}
true
{EMPTY}
{EMPTY}
fail
EPP_HOST_CREATE_SERVER_ACCEPTS_INVALID_HOSTNAME


{"ns1.epp-11.rst." & $TLD}
true
v4
192.0.2.1
pass
EPP_UNEXPECTED_COMMAND_FAILURE


{"ns2.epp-11.rst." & $TLD}
true
{EMPTY}
{EMPTY}
fail
EPP_HOST_CREATE_SERVER_DOES_NOT_REQUIRE_GLUE


{"ns2.epp-11.rst." & $TLD}
true
v4
{EMPTY}
fail
EPP_HOST_CREATE_SERVER_ACCEPTS_INVALID_IPV4_ADDRESS


{"ns2.epp-11.rst." & $TLD}
true
v4
2001:DB8::53:1
fail
EPP_HOST_CREATE_SERVER_ACCEPTS_INVALID_IPV4_ADDRESS


{"ns2.epp-11.rst." & $TLD}
true
v4
192.0.2
fail
EPP_HOST_CREATE_SERVER_ACCEPTS_INVALID_IPV4_ADDRESS


{"ns2.epp-11.rst." & $TLD}
true
v4
a.b.c.d
fail
EPP_HOST_CREATE_SERVER_ACCEPTS_INVALID_IPV4_ADDRESS


{"ns2.epp-11.rst." & $TLD}
true
v4
256.1.1.1
fail
EPP_HOST_CREATE_SERVER_ACCEPTS_INVALID_IPV4_ADDRESS


{"ns2.epp-11.rst." & $TLD}
true
v4
1.2.3.4.5
fail
EPP_HOST_CREATE_SERVER_ACCEPTS_INVALID_IPV4_ADDRESS


{"ns2.epp-11.rst." & $TLD}
true
v5
192.0.2.1
fail
EPP_UNEXPECTED_COMMAND_SUCCESS


{"ns2.epp-11.rst." & $TLD}
true
v6
2001:DB8::53:1
pass
EPP_UNEXPECTED_COMMAND_FAILURE


{"ns3.epp-11.rst." & $TLD}
true
v6
192.168.0.1
fail
EPP_HOST_CREATE_SERVER_ACCEPTS_INVALID_IPv6_ADDRESS


{"ns3.epp-11.rst." & $TLD}
true
v6
::
fail
EPP_HOST_CREATE_SERVER_ACCEPTS_INVALID_IPv6_ADDRESS


{"ns3.epp-11.rst." & $TLD}
true
v6
::1
fail
EPP_HOST_CREATE_SERVER_ACCEPTS_INVALID_IPv6_ADDRESS


{"ns3.epp-11.rst." & $TLD}
true
v6
::X
fail
EPP_HOST_CREATE_SERVER_ACCEPTS_INVALID_IPv6_ADDRESS


{"ns3.epp-11.rst." & $TLD}
true
v6
NOT::HEX::
fail
EPP_HOST_CREATE_SERVER_ACCEPTS_INVALID_IPv6_ADDRESS


10.5.3. Test cases
This data provider is used by the following test cases:


10.6. epp-13-addr-data
10.6.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.
      • 

    • 

  • Any row containing an “action” value of “add” and a passOrFail value
of “pass” should result in an object property being added, which will be
validated using an ` command.
    • 

  • The cell values for rows with action=rem do not occur in previous
rows, so the objects should not have those properties, meaning a
successful response is an error.
    • 



10.6.2. Data table
action
ip
addr
passOrFail
errorCode


string
string
string
string
string




IP Version


IP Address


Expected result


Error code if expected result is not produced




add
v4
192.0.2.1
pass
EPP_UNEXPECTED_COMMAND_FAILURE


add
v4
{EMPTY}
fail
EPP_HOST_UPDATE_SERVER_ACCEPTS_INVALID_IPV4_ADDRESS


add
v4
2001:DB8::53:1
fail
EPP_HOST_UPDATE_SERVER_ACCEPTS_INVALID_IPV4_ADDRESS


add
v4
192.0.2
fail
EPP_HOST_UPDATE_SERVER_ACCEPTS_INVALID_IPV4_ADDRESS


add
v4
a.b.c.d
fail
EPP_HOST_UPDATE_SERVER_ACCEPTS_INVALID_IPV4_ADDRESS


add
v4
256.1.1.1
fail
EPP_HOST_UPDATE_SERVER_ACCEPTS_INVALID_IPV4_ADDRESS


add
v4
1.2.3.4.5
fail
EPP_HOST_UPDATE_SERVER_ACCEPTS_INVALID_IPV4_ADDRESS


add
v5
192.0.2.1
fail
EPP_UNEXPECTED_COMMAND_SUCCESS


add
v6
2001:DB8::53:1
pass
EPP_UNEXPECTED_COMMAND_FAILURE


add
v6
192.168.0.1
fail
EPP_HOST_UPDATE_SERVER_ACCEPTS_INVALID_IPv6_ADDRESS


add
v6
::
fail
EPP_HOST_UPDATE_SERVER_ACCEPTS_INVALID_IPv6_ADDRESS


add
v6
::1
fail
EPP_HOST_UPDATE_SERVER_ACCEPTS_INVALID_IPv6_ADDRESS


add
v6
::X
fail
EPP_HOST_UPDATE_SERVER_ACCEPTS_INVALID_IPv6_ADDRESS


add
v6
NOT::HEX::
fail
EPP_HOST_UPDATE_SERVER_ACCEPTS_INVALID_IPv6_ADDRESS


rem
v4
192.0.2.2
fail
EPP_UNEXPECTED_COMMAND_SUCCESS


rem
v6
2001:DB8::53:2
fail
EPP_UNEXPECTED_COMMAND_SUCCESS


10.6.3. Test cases
This data provider is used by the following test cases:


10.7. epp-13-status-data
10.7.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.
      • 

    • 

  • Any row containing an “action” value of “add” and a passOrFail value
of “pass” should result in an object property being added, which will be
validated using an <info> command.
    • 

  • The cell values for rows with action=rem do not occur in previous
rows, so the objects should not have those properties, meaning a
successful response is an error.
    • 



10.7.2. Data table
action
status
passOrFail
errorCode


string
string
string
string




IP Version


Expected result


Error code if expected result is not produced




add
clientUpdateProhibited
pass
EPP_UNEXPECTED_COMMAND_FAILURE


rem
clientUpdateProhibited
pass
EPP_UNEXPECTED_COMMAND_FAILURE


add
clientDeleteProhibited
pass
EPP_UNEXPECTED_COMMAND_FAILURE


add
clientHold
fail
EPP_HOST_UPDATE_SERVER_ACCEPTS_INVALID_STATUS_CODE


add
linked
fail
EPP_HOST_UPDATE_SERVER_ACCEPTS_INVALID_STATUS_CODE


add
ok
fail
EPP_HOST_UPDATE_SERVER_ACCEPTS_INVALID_STATUS_CODE


add
pendingCreate
fail
EPP_HOST_UPDATE_SERVER_ACCEPTS_INVALID_STATUS_CODE


add
pendingDelete
fail
EPP_HOST_UPDATE_SERVER_ACCEPTS_INVALID_STATUS_CODE


add
pendingTransfer
fail
EPP_HOST_UPDATE_SERVER_ACCEPTS_INVALID_STATUS_CODE


add
pendingUpdate
fail
EPP_HOST_UPDATE_SERVER_ACCEPTS_INVALID_STATUS_CODE


add
serverDeleteProhibited
fail
EPP_HOST_UPDATE_SERVER_ACCEPTS_INVALID_STATUS_CODE


add
serverUpdateProhibited
fail
EPP_HOST_UPDATE_SERVER_ACCEPTS_INVALID_STATUS_CODE


add
invalidStatusCode
fail
EPP_HOST_UPDATE_SERVER_ACCEPTS_INVALID_STATUS_CODE


rem
clientDeleteProhibited
pass
EPP_UNEXPECTED_COMMAND_FAILURE


rem
clientHold
fail
EPP_UNEXPECTED_COMMAND_SUCCESS


rem
clientHold
fail
EPP_UNEXPECTED_COMMAND_SUCCESS


rem
linked
fail
EPP_UNEXPECTED_COMMAND_SUCCESS


rem
ok
fail
EPP_UNEXPECTED_COMMAND_SUCCESS


rem
pendingCreate
fail
EPP_UNEXPECTED_COMMAND_SUCCESS


rem
pendingDelete
fail
EPP_UNEXPECTED_COMMAND_SUCCESS


rem
pendingTransfer
fail
EPP_UNEXPECTED_COMMAND_SUCCESS


rem
pendingUpdate
fail
EPP_UNEXPECTED_COMMAND_SUCCESS


rem
serverDeleteProhibited
fail
EPP_UNEXPECTED_COMMAND_SUCCESS


rem
serverUpdateProhibited
fail
EPP_UNEXPECTED_COMMAND_SUCCESS


rem
invalidStatusCode
fail
EPP_UNEXPECTED_COMMAND_SUCCESS


10.7.3. Test cases
This data provider is used by the following test cases:


10.8. epp-14-data
10.8.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 pw
field must be empty.
    • 



10.8.2. Data table
name
period
periodUnit
registrant
adminContact
techContact
billingContact
hostModel
ns1
ns1ipv4
ns1ipv6
ns2
ns2ipv4
ns2ipv6
keyTag
dsDataAlg
digestType
digest
flags
protocol
keyDataAlg
pubKey
passOrFail
errorCode


string
integer
string
string
string
string
string
string
string
string
string
string
string
string
integer
integer
integer
string
integer
integer
integer
string
string
string


Domain name


Registration period


Registration period units


Registrant ID (if applicable)


Admin Contact ID (if applicable)


Tech Contact ID (if applicable)


Billing Contact ID (if applicable)


Host model (row will be skipped if it does not match the input
parameter)


Nameserver name (object will be created if needed)


IPv4 address (if host attributes)


IPv6 address (if host attributes)


Nameserver name (object will be created if needed)


IPv4 address (if host attributes)


IPv6 address (if host attributes)


DS record Key Tag (if applicable)


DS record algorithm (if applicable)


DS record digest type (if applicable)


DS record digest (if applicable)


DNSKEY record flags (if applicable)


DNSKEY record protocol (if applicable)


DNSKEY record algorithm (if applicable)


DNSKEY record public key (if applicable)


Expected result


Error code if expected result is not produced




{AUTO}
1
y
{AUTO}
{AUTO}
{AUTO}
{AUTO}
either
ns1.epp-14.rst.icann
{EMPTY}
{EMPTY}
ns2.epp-14.rst.icann
{EMPTY}
{EMPTY}
{AUTO}
16
2
{RANDHEX(32}
257
3
16
7JCMl8WwNOyFNWF6GBuMlIdtf08Cr1bO/hToZ6xCvKcu4o5ShXBzbCgzTGJHovhoUgj9wsMA1aWA
pass
EPP_UNEXPECTED_COMMAND_FAILURE


{RANDCHARS(64) & "." & $TLD}
1
y
{AUTO}
{AUTO}
{AUTO}
{AUTO}
either
ns1.epp-14.rst.icann
{EMPTY}
{EMPTY}
ns2.epp-14.rst.icann
{EMPTY}
{EMPTY}
{AUTO}
16
2
{RANDHEX(32}
257
3
16
7JCMl8WwNOyFNWF6GBuMlIdtf08Cr1bO/hToZ6xCvKcu4o5ShXBzbCgzTGJHovhoUgj9wsMA1aWA
fail
EPP_DOMAIN_CREATE_SERVER_ACCEPTS_INVALID_DOMAIN_NAME


{"XX--123." & $TLD}
1
y
{AUTO}
{AUTO}
{AUTO}
{AUTO}
either
ns1.epp-14.rst.icann
{EMPTY}
{EMPTY}
ns2.epp-14.rst.icann
{EMPTY}
{EMPTY}
{AUTO}
16
2
{RANDHEX(32}
257
3
16
7JCMl8WwNOyFNWF6GBuMlIdtf08Cr1bO/hToZ6xCvKcu4o5ShXBzbCgzTGJHovhoUgj9wsMA1aWA
fail
EPP_DOMAIN_CREATE_SERVER_ACCEPTS_INVALID_DOMAIN_NAME


{AUTO}
10
y
{AUTO}
{AUTO}
{AUTO}
{AUTO}
either
ns1.epp-14.rst.icann
{EMPTY}
{EMPTY}
ns2.epp-14.rst.icann
{EMPTY}
{EMPTY}
{AUTO}
16
2
{RANDHEX(32}
257
3
16
7JCMl8WwNOyFNWF6GBuMlIdtf08Cr1bO/hToZ6xCvKcu4o5ShXBzbCgzTGJHovhoUgj9wsMA1aWA
pass
EPP_UNEXPECTED_COMMAND_FAILURE


{AUTO}
11
y
{AUTO}
{AUTO}
{AUTO}
{AUTO}
either
ns1.epp-14.rst.icann
{EMPTY}
{EMPTY}
ns2.epp-14.rst.icann
{EMPTY}
{EMPTY}
{AUTO}
16
2
{RANDHEX(32}
257
3
16
7JCMl8WwNOyFNWF6GBuMlIdtf08Cr1bO/hToZ6xCvKcu4o5ShXBzbCgzTGJHovhoUgj9wsMA1aWA
fail
EPP_DOMAIN_CREATE_SERVER_ACCEPTS_INVALID_PERIOD


{AUTO}
-1
y
{AUTO}
{AUTO}
{AUTO}
{AUTO}
either
ns1.epp-14.rst.icann
{EMPTY}
{EMPTY}
ns2.epp-14.rst.icann
{EMPTY}
{EMPTY}
{AUTO}
16
2
{RANDHEX(32}
257
3
16
7JCMl8WwNOyFNWF6GBuMlIdtf08Cr1bO/hToZ6xCvKcu4o5ShXBzbCgzTGJHovhoUgj9wsMA1aWA
fail
EPP_DOMAIN_CREATE_SERVER_ACCEPTS_INVALID_PERIOD


{AUTO}
1.5
y
{AUTO}
{AUTO}
{AUTO}
{AUTO}
either
ns1.epp-14.rst.icann
{EMPTY}
{EMPTY}
ns2.epp-14.rst.icann
{EMPTY}
{EMPTY}
{AUTO}
16
2
{RANDHEX(32}
257
3
16
7JCMl8WwNOyFNWF6GBuMlIdtf08Cr1bO/hToZ6xCvKcu4o5ShXBzbCgzTGJHovhoUgj9wsMA1aWA
fail
EPP_DOMAIN_CREATE_SERVER_ACCEPTS_INVALID_PERIOD


{AUTO}
1
x
{AUTO}
{AUTO}
{AUTO}
{AUTO}
either
ns1.epp-14.rst.icann
{EMPTY}
{EMPTY}
ns2.epp-14.rst.icann
{EMPTY}
{EMPTY}
{AUTO}
16
2
{RANDHEX(32}
257
3
16
7JCMl8WwNOyFNWF6GBuMlIdtf08Cr1bO/hToZ6xCvKcu4o5ShXBzbCgzTGJHovhoUgj9wsMA1aWA
fail
EPP_DOMAIN_CREATE_SERVER_ACCEPTS_INVALID_PERIOD


{AUTO}
1
y
{RANDCHARS(16)}
{AUTO}
{AUTO}
{AUTO}
either
ns1.epp-14.rst.icann
{EMPTY}
{EMPTY}
ns2.epp-14.rst.icann
{EMPTY}
{EMPTY}
{AUTO}
16
2
{RANDHEX(32}
257
3
16
7JCMl8WwNOyFNWF6GBuMlIdtf08Cr1bO/hToZ6xCvKcu4o5ShXBzbCgzTGJHovhoUgj9wsMA1aWA
fail
EPP_DOMAIN_CREATE_SERVER_ACCEPTS_NON_EXISTENT_CONTACT_OBJECT


{AUTO}
1
y
{AUTO}
{RANDCHARS(16)}
{AUTO}
{AUTO}
either
ns1.epp-14.rst.icann
{EMPTY}
{EMPTY}
ns2.epp-14.rst.icann
{EMPTY}
{EMPTY}
{AUTO}
16
2
{RANDHEX(32}
257
3
16
7JCMl8WwNOyFNWF6GBuMlIdtf08Cr1bO/hToZ6xCvKcu4o5ShXBzbCgzTGJHovhoUgj9wsMA1aWA
fail
EPP_DOMAIN_CREATE_SERVER_ACCEPTS_NON_EXISTENT_CONTACT_OBJECT


{AUTO}
1
y
{AUTO}
{AUTO}
{RANDCHARS(16)}
{AUTO}
either
ns1.epp-14.rst.icann
{EMPTY}
{EMPTY}
ns2.epp-14.rst.icann
{EMPTY}
{EMPTY}
{AUTO}
16
2
{RANDHEX(32}
257
3
16
7JCMl8WwNOyFNWF6GBuMlIdtf08Cr1bO/hToZ6xCvKcu4o5ShXBzbCgzTGJHovhoUgj9wsMA1aWA
fail
EPP_DOMAIN_CREATE_SERVER_ACCEPTS_NON_EXISTENT_CONTACT_OBJECT


{AUTO}
1
y
{AUTO}
{AUTO}
{AUTO}
{RANDCHARS(16)}
either
ns1.epp-14.rst.icann
{EMPTY}
{EMPTY}
ns2.epp-14.rst.icann
{EMPTY}
{EMPTY}
{AUTO}
16
2
{RANDHEX(32}
257
3
16
7JCMl8WwNOyFNWF6GBuMlIdtf08Cr1bO/hToZ6xCvKcu4o5ShXBzbCgzTGJHovhoUgj9wsMA1aWA
fail
EPP_DOMAIN_CREATE_SERVER_ACCEPTS_NON_EXISTENT_CONTACT_OBJECT


{AUTO}
1
y
{AUTO}
{AUTO}
{AUTO}
{AUTO}
attributes
{"ns1." & $name}
{EMPTY}
{EMPTY}
ns2.epp-14.rst.icann
{EMPTY}
{EMPTY}
{AUTO}
16
2
{RANDHEX(32}
257
3
16
7JCMl8WwNOyFNWF6GBuMlIdtf08Cr1bO/hToZ6xCvKcu4o5ShXBzbCgzTGJHovhoUgj9wsMA1aWA
fail
EPP_DOMAIN_CREATE_SERVER_ACCEPTS_HOST_ATTRIBUTES_WITHOUT_GLUE


{AUTO}
1
y
{AUTO}
{AUTO}
{AUTO}
{AUTO}
attributes
{"ns1." & $name}
192.0.2.1
{EMPTY}
ns2.epp-14.rst.icann
{EMPTY}
{EMPTY}
{AUTO}
16
2
{RANDHEX(32}
257
3
16
7JCMl8WwNOyFNWF6GBuMlIdtf08Cr1bO/hToZ6xCvKcu4o5ShXBzbCgzTGJHovhoUgj9wsMA1aWA
pass
EPP_UNEXPECTED_COMMAND_FAILURE


{AUTO}
1
y
{AUTO}
{AUTO}
{AUTO}
{AUTO}
attributes
{"ns1." & $name}
2001:DB8::53:1
{EMPTY}
ns2.epp-14.rst.icann
{EMPTY}
{EMPTY}
{AUTO}
16
2
{RANDHEX(32}
257
3
16
7JCMl8WwNOyFNWF6GBuMlIdtf08Cr1bO/hToZ6xCvKcu4o5ShXBzbCgzTGJHovhoUgj9wsMA1aWA
fail
EPP_DOMAIN_CREATE_SERVER_ACCEPTS_HOST_ATTRIBUTES_WITH_INVALID_GLUE


{AUTO}
1
y
{AUTO}
{AUTO}
{AUTO}
{AUTO}
attributes
{"ns1." & $name}
192.0.2
{EMPTY}
ns2.epp-14.rst.icann
{EMPTY}
{EMPTY}
{AUTO}
16
2
{RANDHEX(32}
257
3
16
7JCMl8WwNOyFNWF6GBuMlIdtf08Cr1bO/hToZ6xCvKcu4o5ShXBzbCgzTGJHovhoUgj9wsMA1aWA
fail
EPP_DOMAIN_CREATE_SERVER_ACCEPTS_HOST_ATTRIBUTES_WITH_INVALID_GLUE


{AUTO}
1
y
{AUTO}
{AUTO}
{AUTO}
{AUTO}
attributes
{"ns1." & $name}
a.b.c.d
{EMPTY}
ns2.epp-14.rst.icann
{EMPTY}
{EMPTY}
{AUTO}
16
2
{RANDHEX(32}
257
3
16
7JCMl8WwNOyFNWF6GBuMlIdtf08Cr1bO/hToZ6xCvKcu4o5ShXBzbCgzTGJHovhoUgj9wsMA1aWA
fail
EPP_DOMAIN_CREATE_SERVER_ACCEPTS_HOST_ATTRIBUTES_WITH_INVALID_GLUE


{AUTO}
1
y
{AUTO}
{AUTO}
{AUTO}
{AUTO}
attributes
{"ns1." & $name}
256.1.1.1
{EMPTY}
ns2.epp-14.rst.icann
{EMPTY}
{EMPTY}
{AUTO}
16
2
{RANDHEX(32}
257
3
16
7JCMl8WwNOyFNWF6GBuMlIdtf08Cr1bO/hToZ6xCvKcu4o5ShXBzbCgzTGJHovhoUgj9wsMA1aWA
fail
EPP_DOMAIN_CREATE_SERVER_ACCEPTS_HOST_ATTRIBUTES_WITH_INVALID_GLUE


{AUTO}
1
y
{AUTO}
{AUTO}
{AUTO}
{AUTO}
attributes
{"ns1." & $name}
1.2.3.4.5
{EMPTY}
ns2.epp-14.rst.icann
{EMPTY}
{EMPTY}
{AUTO}
16
2
{RANDHEX(32}
257
3
16
7JCMl8WwNOyFNWF6GBuMlIdtf08Cr1bO/hToZ6xCvKcu4o5ShXBzbCgzTGJHovhoUgj9wsMA1aWA
fail
EPP_DOMAIN_CREATE_SERVER_ACCEPTS_HOST_ATTRIBUTES_WITH_INVALID_GLUE


{AUTO}
1
y
{AUTO}
{AUTO}
{AUTO}
{AUTO}
attributes
{"ns1." & $name}
{EMPTY}
2001:DB8::53:1
ns2.epp-14.rst.icann
{EMPTY}
{EMPTY}
{AUTO}
16
2
{RANDHEX(32}
257
3
16
7JCMl8WwNOyFNWF6GBuMlIdtf08Cr1bO/hToZ6xCvKcu4o5ShXBzbCgzTGJHovhoUgj9wsMA1aWA
pass
EPP_UNEXPECTED_COMMAND_FAILURE


{AUTO}
1
y
{AUTO}
{AUTO}
{AUTO}
{AUTO}
attributes
{"ns1." & $name}
{EMPTY}
192.168.0.1
ns2.epp-14.rst.icann
{EMPTY}
{EMPTY}
{AUTO}
16
2
{RANDHEX(32}
257
3
16
7JCMl8WwNOyFNWF6GBuMlIdtf08Cr1bO/hToZ6xCvKcu4o5ShXBzbCgzTGJHovhoUgj9wsMA1aWA
fail
EPP_DOMAIN_CREATE_SERVER_ACCEPTS_HOST_ATTRIBUTES_WITH_INVALID_GLUE


{AUTO}
1
y
{AUTO}
{AUTO}
{AUTO}
{AUTO}
attributes
{"ns1." & $name}
{EMPTY}
::
ns2.epp-14.rst.icann
{EMPTY}
{EMPTY}
{AUTO}
16
2
{RANDHEX(32}
257
3
16
7JCMl8WwNOyFNWF6GBuMlIdtf08Cr1bO/hToZ6xCvKcu4o5ShXBzbCgzTGJHovhoUgj9wsMA1aWA
fail
EPP_DOMAIN_CREATE_SERVER_ACCEPTS_HOST_ATTRIBUTES_WITH_INVALID_GLUE


{AUTO}
1
y
{AUTO}
{AUTO}
{AUTO}
{AUTO}
attributes
{"ns1." & $name}
{EMPTY}
::1
ns2.epp-14.rst.icann
{EMPTY}
{EMPTY}
{AUTO}
16
2
{RANDHEX(32}
257
3
16
7JCMl8WwNOyFNWF6GBuMlIdtf08Cr1bO/hToZ6xCvKcu4o5ShXBzbCgzTGJHovhoUgj9wsMA1aWA
fail
EPP_DOMAIN_CREATE_SERVER_ACCEPTS_HOST_ATTRIBUTES_WITH_INVALID_GLUE


{AUTO}
1
y
{AUTO}
{AUTO}
{AUTO}
{AUTO}
attributes
{"ns1." & $name}
{EMPTY}
::X
ns2.epp-14.rst.icann
{EMPTY}
{EMPTY}
{AUTO}
16
2
{RANDHEX(32}
257
3
16
7JCMl8WwNOyFNWF6GBuMlIdtf08Cr1bO/hToZ6xCvKcu4o5ShXBzbCgzTGJHovhoUgj9wsMA1aWA
fail
EPP_DOMAIN_CREATE_SERVER_ACCEPTS_HOST_ATTRIBUTES_WITH_INVALID_GLUE


{AUTO}
1
y
{AUTO}
{AUTO}
{AUTO}
{AUTO}
attributes
{"ns1." & $name}
{EMPTY}
NOT::HEX::
ns2.epp-14.rst.icann
{EMPTY}
{EMPTY}
{AUTO}
16
2
{RANDHEX(32}
257
3
16
7JCMl8WwNOyFNWF6GBuMlIdtf08Cr1bO/hToZ6xCvKcu4o5ShXBzbCgzTGJHovhoUgj9wsMA1aWA
fail
EPP_DOMAIN_CREATE_SERVER_ACCEPTS_HOST_ATTRIBUTES_WITH_INVALID_GLUE


{AUTO}
1
y
{AUTO}
{AUTO}
{AUTO}
{AUTO}
attributes
{EMPTY}
{EMPTY}
NOT::HEX::
ns2.epp-14.rst.icann
{EMPTY}
{EMPTY}
{EMPTY}
16
2
{RANDHEX(32}
257
3
16
7JCMl8WwNOyFNWF6GBuMlIdtf08Cr1bO/hToZ6xCvKcu4o5ShXBzbCgzTGJHovhoUgj9wsMA1aWA
fail
EPP_DOMAIN_CREATE_SERVER_ACCEPTS_INVALID_DNSSEC_DATA


{AUTO}
1
y
{AUTO}
{AUTO}
{AUTO}
{AUTO}
attributes
{EMPTY}
{EMPTY}
NOT::HEX::
ns2.epp-14.rst.icann
{EMPTY}
{EMPTY}
{AUTO}
{EMPTY}
2
{RANDHEX(32}
257
3
16
7JCMl8WwNOyFNWF6GBuMlIdtf08Cr1bO/hToZ6xCvKcu4o5ShXBzbCgzTGJHovhoUgj9wsMA1aWA
fail
EPP_DOMAIN_CREATE_SERVER_ACCEPTS_INVALID_DNSSEC_DATA


{AUTO}
1
y
{AUTO}
{AUTO}
{AUTO}
{AUTO}
attributes
{EMPTY}
{EMPTY}
NOT::HEX::
ns2.epp-14.rst.icann
{EMPTY}
{EMPTY}
{AUTO}
-1
2
{RANDHEX(32}
257
3
16
7JCMl8WwNOyFNWF6GBuMlIdtf08Cr1bO/hToZ6xCvKcu4o5ShXBzbCgzTGJHovhoUgj9wsMA1aWA
fail
EPP_DOMAIN_CREATE_SERVER_ACCEPTS_INVALID_DNSSEC_DATA


{AUTO}
1
y
{AUTO}
{AUTO}
{AUTO}
{AUTO}
attributes
{EMPTY}
{EMPTY}
NOT::HEX::
ns2.epp-14.rst.icann
{EMPTY}
{EMPTY}
{AUTO}
A
2
{RANDHEX(32}
257
3
16
7JCMl8WwNOyFNWF6GBuMlIdtf08Cr1bO/hToZ6xCvKcu4o5ShXBzbCgzTGJHovhoUgj9wsMA1aWA
fail
EPP_DOMAIN_CREATE_SERVER_ACCEPTS_INVALID_DNSSEC_DATA


{AUTO}
1
y
{AUTO}
{AUTO}
{AUTO}
{AUTO}
attributes
{EMPTY}
{EMPTY}
NOT::HEX::
ns2.epp-14.rst.icann
{EMPTY}
{EMPTY}
{AUTO}
123
2
{RANDHEX(32}
257
3
16
7JCMl8WwNOyFNWF6GBuMlIdtf08Cr1bO/hToZ6xCvKcu4o5ShXBzbCgzTGJHovhoUgj9wsMA1aWA
fail
EPP_DOMAIN_CREATE_SERVER_ACCEPTS_INVALID_DNSSEC_DATA


{AUTO}
1
y
{AUTO}
{AUTO}
{AUTO}
{AUTO}
attributes
{EMPTY}
{EMPTY}
NOT::HEX::
ns2.epp-14.rst.icann
{EMPTY}
{EMPTY}
{AUTO}
16
{EMPTY}
{RANDHEX(32}
257
3
16
7JCMl8WwNOyFNWF6GBuMlIdtf08Cr1bO/hToZ6xCvKcu4o5ShXBzbCgzTGJHovhoUgj9wsMA1aWA
fail
EPP_DOMAIN_CREATE_SERVER_ACCEPTS_INVALID_DNSSEC_DATA


{AUTO}
1
y
{AUTO}
{AUTO}
{AUTO}
{AUTO}
attributes
{EMPTY}
{EMPTY}
NOT::HEX::
ns2.epp-14.rst.icann
{EMPTY}
{EMPTY}
{AUTO}
16
-1
{RANDHEX(32}
257
3
16
7JCMl8WwNOyFNWF6GBuMlIdtf08Cr1bO/hToZ6xCvKcu4o5ShXBzbCgzTGJHovhoUgj9wsMA1aWA
fail
EPP_DOMAIN_CREATE_SERVER_ACCEPTS_INVALID_DNSSEC_DATA


{AUTO}
1
y
{AUTO}
{AUTO}
{AUTO}
{AUTO}
attributes
{EMPTY}
{EMPTY}
NOT::HEX::
ns2.epp-14.rst.icann
{EMPTY}
{EMPTY}
{AUTO}
16
A
{RANDHEX(32}
257
3
16
7JCMl8WwNOyFNWF6GBuMlIdtf08Cr1bO/hToZ6xCvKcu4o5ShXBzbCgzTGJHovhoUgj9wsMA1aWA
fail
EPP_DOMAIN_CREATE_SERVER_ACCEPTS_INVALID_DNSSEC_DATA


{AUTO}
1
y
{AUTO}
{AUTO}
{AUTO}
{AUTO}
attributes
{EMPTY}
{EMPTY}
NOT::HEX::
ns2.epp-14.rst.icann
{EMPTY}
{EMPTY}
{AUTO}
16
255
{RANDHEX(32}
257
3
16
7JCMl8WwNOyFNWF6GBuMlIdtf08Cr1bO/hToZ6xCvKcu4o5ShXBzbCgzTGJHovhoUgj9wsMA1aWA
fail
EPP_DOMAIN_CREATE_SERVER_ACCEPTS_INVALID_DNSSEC_DATA


{AUTO}
1
y
{AUTO}
{AUTO}
{AUTO}
{AUTO}
attributes
{EMPTY}
{EMPTY}
NOT::HEX::
ns2.epp-14.rst.icann
{EMPTY}
{EMPTY}
{AUTO}
16
2
{EMPTY}
257
3
16
7JCMl8WwNOyFNWF6GBuMlIdtf08Cr1bO/hToZ6xCvKcu4o5ShXBzbCgzTGJHovhoUgj9wsMA1aWA
fail
EPP_DOMAIN_CREATE_SERVER_ACCEPTS_INVALID_DNSSEC_DATA


{AUTO}
1
y
{AUTO}
{AUTO}
{AUTO}
{AUTO}
attributes
{EMPTY}
{EMPTY}
NOT::HEX::
ns2.epp-14.rst.icann
{EMPTY}
{EMPTY}
{AUTO}
16
2
{RANDHEX(32})
{EMPTY}
3
16
7JCMl8WwNOyFNWF6GBuMlIdtf08Cr1bO/hToZ6xCvKcu4o5ShXBzbCgzTGJHovhoUgj9wsMA1aWA
fail
EPP_DOMAIN_CREATE_SERVER_ACCEPTS_INVALID_DNSSEC_DATA


{AUTO}
1
y
{AUTO}
{AUTO}
{AUTO}
{AUTO}
attributes
{EMPTY}
{EMPTY}
NOT::HEX::
ns2.epp-14.rst.icann
{EMPTY}
{EMPTY}
{AUTO}
16
2
{RANDHEX(32})
1
3
16
7JCMl8WwNOyFNWF6GBuMlIdtf08Cr1bO/hToZ6xCvKcu4o5ShXBzbCgzTGJHovhoUgj9wsMA1aWA
fail
EPP_DOMAIN_CREATE_SERVER_ACCEPTS_INVALID_DNSSEC_DATA


{AUTO}
1
y
{AUTO}
{AUTO}
{AUTO}
{AUTO}
attributes
{EMPTY}
{EMPTY}
NOT::HEX::
ns2.epp-14.rst.icann
{EMPTY}
{EMPTY}
{AUTO}
16
2
{RANDHEX(32})
256
3
16
7JCMl8WwNOyFNWF6GBuMlIdtf08Cr1bO/hToZ6xCvKcu4o5ShXBzbCgzTGJHovhoUgj9wsMA1aWA
fail
EPP_DOMAIN_CREATE_SERVER_ACCEPTS_INVALID_DNSSEC_DATA


{AUTO}
1
y
{AUTO}
{AUTO}
{AUTO}
{AUTO}
attributes
{EMPTY}
{EMPTY}
NOT::HEX::
ns2.epp-14.rst.icann
{EMPTY}
{EMPTY}
{AUTO}
16
2
{RANDHEX(32})
-1
3
16
7JCMl8WwNOyFNWF6GBuMlIdtf08Cr1bO/hToZ6xCvKcu4o5ShXBzbCgzTGJHovhoUgj9wsMA1aWA
fail
EPP_DOMAIN_CREATE_SERVER_ACCEPTS_INVALID_DNSSEC_DATA


{AUTO}
1
y
{AUTO}
{AUTO}
{AUTO}
{AUTO}
attributes
{EMPTY}
{EMPTY}
NOT::HEX::
ns2.epp-14.rst.icann
{EMPTY}
{EMPTY}
{AUTO}
16
2
{RANDHEX(32})
A
3
16
7JCMl8WwNOyFNWF6GBuMlIdtf08Cr1bO/hToZ6xCvKcu4o5ShXBzbCgzTGJHovhoUgj9wsMA1aWA
fail
EPP_DOMAIN_CREATE_SERVER_ACCEPTS_INVALID_DNSSEC_DATA


{AUTO}
1
y
{AUTO}
{AUTO}
{AUTO}
{AUTO}
attributes
{EMPTY}
{EMPTY}
NOT::HEX::
ns2.epp-14.rst.icann
{EMPTY}
{EMPTY}
{AUTO}
16
2
{RANDHEX(32})
257
{EMPTY}
16
7JCMl8WwNOyFNWF6GBuMlIdtf08Cr1bO/hToZ6xCvKcu4o5ShXBzbCgzTGJHovhoUgj9wsMA1aWA
fail
EPP_DOMAIN_CREATE_SERVER_ACCEPTS_INVALID_DNSSEC_DATA


{AUTO}
1
y
{AUTO}
{AUTO}
{AUTO}
{AUTO}
attributes
{EMPTY}
{EMPTY}
NOT::HEX::
ns2.epp-14.rst.icann
{EMPTY}
{EMPTY}
{AUTO}
16
2
{RANDHEX(32})
257
1
16
7JCMl8WwNOyFNWF6GBuMlIdtf08Cr1bO/hToZ6xCvKcu4o5ShXBzbCgzTGJHovhoUgj9wsMA1aWA
fail
EPP_DOMAIN_CREATE_SERVER_ACCEPTS_INVALID_DNSSEC_DATA


{AUTO}
1
y
{AUTO}
{AUTO}
{AUTO}
{AUTO}
attributes
{EMPTY}
{EMPTY}
NOT::HEX::
ns2.epp-14.rst.icann
{EMPTY}
{EMPTY}
{AUTO}
16
2
{RANDHEX(32})
257
256
16
7JCMl8WwNOyFNWF6GBuMlIdtf08Cr1bO/hToZ6xCvKcu4o5ShXBzbCgzTGJHovhoUgj9wsMA1aWA
fail
EPP_DOMAIN_CREATE_SERVER_ACCEPTS_INVALID_DNSSEC_DATA


{AUTO}
1
y
{AUTO}
{AUTO}
{AUTO}
{AUTO}
attributes
{EMPTY}
{EMPTY}
NOT::HEX::
ns2.epp-14.rst.icann
{EMPTY}
{EMPTY}
{AUTO}
16
2
{RANDHEX(32})
257
-1
16
7JCMl8WwNOyFNWF6GBuMlIdtf08Cr1bO/hToZ6xCvKcu4o5ShXBzbCgzTGJHovhoUgj9wsMA1aWA
fail
EPP_DOMAIN_CREATE_SERVER_ACCEPTS_INVALID_DNSSEC_DATA


{AUTO}
1
y
{AUTO}
{AUTO}
{AUTO}
{AUTO}
attributes
{EMPTY}
{EMPTY}
NOT::HEX::
ns2.epp-14.rst.icann
{EMPTY}
{EMPTY}
{AUTO}
16
2
{RANDHEX(32})
257
A
16
7JCMl8WwNOyFNWF6GBuMlIdtf08Cr1bO/hToZ6xCvKcu4o5ShXBzbCgzTGJHovhoUgj9wsMA1aWA
fail
EPP_DOMAIN_CREATE_SERVER_ACCEPTS_INVALID_DNSSEC_DATA


{AUTO}
1
y
{AUTO}
{AUTO}
{AUTO}
{AUTO}
attributes
{EMPTY}
{EMPTY}
NOT::HEX::
ns2.epp-14.rst.icann
{EMPTY}
{EMPTY}
{AUTO}
16
2
{RANDHEX(32})
257
3
{EMPTY}
7JCMl8WwNOyFNWF6GBuMlIdtf08Cr1bO/hToZ6xCvKcu4o5ShXBzbCgzTGJHovhoUgj9wsMA1aWA
fail
EPP_DOMAIN_CREATE_SERVER_ACCEPTS_INVALID_DNSSEC_DATA


{AUTO}
1
y
{AUTO}
{AUTO}
{AUTO}
{AUTO}
attributes
{EMPTY}
{EMPTY}
NOT::HEX::
ns2.epp-14.rst.icann
{EMPTY}
{EMPTY}
{AUTO}
16
2
{RANDHEX(32})
257
3
-1
7JCMl8WwNOyFNWF6GBuMlIdtf08Cr1bO/hToZ6xCvKcu4o5ShXBzbCgzTGJHovhoUgj9wsMA1aWA
fail
EPP_DOMAIN_CREATE_SERVER_ACCEPTS_INVALID_DNSSEC_DATA


{AUTO}
1
y
{AUTO}
{AUTO}
{AUTO}
{AUTO}
attributes
{EMPTY}
{EMPTY}
NOT::HEX::
ns2.epp-14.rst.icann
{EMPTY}
{EMPTY}
{AUTO}
16
2
{RANDHEX(32})
257
3
A
7JCMl8WwNOyFNWF6GBuMlIdtf08Cr1bO/hToZ6xCvKcu4o5ShXBzbCgzTGJHovhoUgj9wsMA1aWA
fail
EPP_DOMAIN_CREATE_SERVER_ACCEPTS_INVALID_DNSSEC_DATA


{AUTO}
1
y
{AUTO}
{AUTO}
{AUTO}
{AUTO}
attributes
{EMPTY}
{EMPTY}
NOT::HEX::
ns2.epp-14.rst.icann
{EMPTY}
{EMPTY}
{AUTO}
16
2
{RANDHEX(32})
257
3
123
7JCMl8WwNOyFNWF6GBuMlIdtf08Cr1bO/hToZ6xCvKcu4o5ShXBzbCgzTGJHovhoUgj9wsMA1aWA
fail
EPP_DOMAIN_CREATE_SERVER_ACCEPTS_INVALID_DNSSEC_DATA


{AUTO}
1
y
{AUTO}
{AUTO}
{AUTO}
{AUTO}
attributes
{EMPTY}
{EMPTY}
NOT::HEX::
ns2.epp-14.rst.icann
{EMPTY}
{EMPTY}
{AUTO}
16
2
{RANDHEX(32})
257
3
16
{EMPTY}
fail
EPP_DOMAIN_CREATE_SERVER_ACCEPTS_INVALID_DNSSEC_DATA


{AUTO}
1
y
{AUTO}
{AUTO}
{AUTO}
{AUTO}
attributes
{EMPTY}
{EMPTY}
NOT::HEX::
ns2.epp-14.rst.icann
{EMPTY}
{EMPTY}
{AUTO}
16
2
{RANDHEX(32})
257
3
16
this is not a DNSKEY.
fail
EPP_DOMAIN_CREATE_SERVER_ACCEPTS_INVALID_DNSSEC_DATA


10.8.3. Test cases
This data provider is used by the following test cases:


10.9. epp-16-ns-data
10.9.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.
      • 

    • 

  • Any row containing an “action” value of “add” and a passOrFail value
of “pass” should result in an object property being added, which will be
validated using an <info> command.
    • 

  • The cell values for rows with action=rem do not occur in previous
rows, so the objects should not have those properties, meaning a
successful response is an error.
    • 



10.9.2. Data table
action
createIfNeeded
hostname
passOrFail
errorCode


string
boolean
string
string
string




If a host object (if applicable) should be created


Host name


Expected result


Error code if expected result is not produced




add
true
ns1.epp-16.rst.icann
pass
EPP_UNEXPECTED_COMMAND_SUCCESS


add
true
ns1.epp-16.rst.icann
fail
EPP_UNEXPECTED_COMMAND_FAILURE


add
false
does-not-exist.epp-16.rst.icann
fail
EPP_UNEXPECTED_COMMAND_FAILURE


rem
false
ns1.epp-16.rst.icann
pass
EPP_UNEXPECTED_COMMAND_SUCCESS


rem
false
ns1.epp-16.rst.icann
fail
EPP_UNEXPECTED_COMMAND_FAILURE


10.9.3. Test cases
This data provider is used by the following test cases:


10.10. epp-16-status-data
10.10.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.
      • 

    • 

  • Any row containing an “action” value of “add” and a passOrFail value
of “pass” should result in an object property being added, which will be
validated using an <info> command.
    • 

  • The cell values for rows with action=rem do not occur in previous
rows, so the objects should not have those properties, meaning a
successful response is an error.
    • 



10.10.2. Data table
action
status
passOrFail
errorCode


string
string
string
string




Status Code


Expected result


Error code if expected result is not produced




add
clientDeleteProhibited
pass
EPP_UNEXPECTED_COMMAND_FAILURE


add
clientDeleteProhibited
fail
EPP_UNEXPECTED_COMMAND_SUCCESS


add
clientHold
pass
EPP_UNEXPECTED_COMMAND_FAILURE


add
clientHold
fail
EPP_UNEXPECTED_COMMAND_SUCCESS


add
clientRenewProhibited
pass
EPP_UNEXPECTED_COMMAND_FAILURE


add
clientRenewProhibited
fail
EPP_UNEXPECTED_COMMAND_SUCCESS


add
clientTransferProhibited
pass
EPP_UNEXPECTED_COMMAND_FAILURE


add
clientTransferProhibited
fail
EPP_UNEXPECTED_COMMAND_SUCCESS


add
clientUpdateProhibited
pass
EPP_UNEXPECTED_COMMAND_FAILURE


add
clientUpdateProhibited
fail
EPP_UNEXPECTED_COMMAND_SUCCESS


rem
clientUpdateProhibited
pass
EPP_UNEXPECTED_COMMAND_FAILURE


rem
clientUpdateProhibited
fail
EPP_UNEXPECTED_COMMAND_SUCCESS


add
linked
fail
EPP_DOMAIN_UPDATE_SERVER_ACCEPTS_INVALID_STATUS_CODE


add
ok
fail
EPP_DOMAIN_UPDATE_SERVER_ACCEPTS_INVALID_STATUS_CODE


add
pendingCreate
fail
EPP_DOMAIN_UPDATE_SERVER_ACCEPTS_INVALID_STATUS_CODE


add
pendingDelete
fail
EPP_DOMAIN_UPDATE_SERVER_ACCEPTS_INVALID_STATUS_CODE


add
pendingTransfer
fail
EPP_DOMAIN_UPDATE_SERVER_ACCEPTS_INVALID_STATUS_CODE


add
pendingUpdate
fail
EPP_DOMAIN_UPDATE_SERVER_ACCEPTS_INVALID_STATUS_CODE


add
serverDeleteProhibited
fail
EPP_DOMAIN_UPDATE_SERVER_ACCEPTS_INVALID_STATUS_CODE


add
serverRenewProhibited
fail
EPP_DOMAIN_UPDATE_SERVER_ACCEPTS_INVALID_STATUS_CODE


add
serverTransferProhibited
fail
EPP_DOMAIN_UPDATE_SERVER_ACCEPTS_INVALID_STATUS_CODE


add
serverUpdateProhibited
fail
EPP_DOMAIN_UPDATE_SERVER_ACCEPTS_INVALID_STATUS_CODE


add
invalidStatusCode
fail
EPP_DOMAIN_UPDATE_SERVER_ACCEPTS_INVALID_STATUS_CODE


rem
clientDeleteProhibited
pass
EPP_UNEXPECTED_COMMAND_FAILURE


rem
clientDeleteProhibited
fail
EPP_UNEXPECTED_COMMAND_SUCCESS


rem
clientHold
pass
EPP_UNEXPECTED_COMMAND_FAILURE


rem
clientHold
fail
EPP_UNEXPECTED_COMMAND_SUCCESS


rem
clientRenewProhibited
pass
EPP_UNEXPECTED_COMMAND_FAILURE


rem
clientRenewProhibited
fail
EPP_UNEXPECTED_COMMAND_SUCCESS


rem
clientTransferProhibited
pass
EPP_UNEXPECTED_COMMAND_FAILURE


rem
clientTransferProhibited
fail
EPP_UNEXPECTED_COMMAND_SUCCESS


rem
invalidStatusCode
fail
EPP_UNEXPECTED_COMMAND_SUCCESS


10.10.3. Test cases
This data provider is used by the following test cases:


10.11. epp-23-data
10.11.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.
      • 

    • 



10.11.2. Data table
name
createParentFirst
passOrFail
errorCode


string
boolean
string
string


The new hostname for the object


Whether the superordinate domain name should be created before the
subordinate host name is created (if it does not already exist)


Expected result


Error code if expected result is not produced




!.invalid
false
fail
EPP_HOST_RENAME_SERVER_ACCEPTS_INVALID_HOSTNAME


ns1.epp-23.icann
false
pass
EPP_HOST_RENAME_SERVER_REJECTS_OUT_OF_BAILIWICK_NAME


{"ns1.epp-23." & RANDCHARS(64) & "." & $TLD}
false
fail
EPP_HOST_RENAME_SERVER_ACCEPTS_RENAME_TO_NONEXISTENT_DOMAIN


{"ns1.epp-23." & $RESERVEDNAME}
false
fail
EPP_HOST_RENAME_SERVER_ACCEPTS_RENAME_TO_ANOTHER_REGISTRARS_DOMAIN


{"ns1.epp-23." & RANDCHARS(64) & "." & $TLD}
true
pass
EPP_HOST_RENAME_SERVER_UNEXPECTEDLY_REJECTS_RENAME


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