Data Migration from SRS to IRS ================================= Data migration items that need registrars attention ---------------------------------------------------- Length of term migration ~~~~~~~~~~~~~~~~~~~~~~~~~~~ **Description:** The term field in the current Shared Registry System (SRS, old system) represents the registration duration for the next renewal, whereas the term field in the InternetNZ Registry System (IRS, new system) contains the registration duration for the last create or renewal. The term field in the SRS was based on months with a range from 1 to 120. In the IRS the unit has changed from months to years, with a range of 1 to 10. This means the minimum registration period is now 1 year. **Approach:** The SRS term field will not be migrated as it represents the future term. On migration the IRS term field will be calculated as the last term used for the domain create or renewal transaction, rounded to the nearest year i.e. <12 months will migrate as 1 year. This field will be used for internal reporting in the IRS. **What do you need to do:** * Registrars who currently set a renewal term in advance will need to make changes to their renewal processes, by allowing the domain to auto-renew for 1 year or explicitly renewing the domain when it becomes due for renewal. * Registrars who have domains on a monthly auto-renewal will need to allow for the minimum term changing to 1 year. Legacy billing transactions and legacy invoices ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ **Description:** The SRS pending transactions (billing transactions) will not be migrated to the IRS. **Approach:** The cutover to the new system target date is 3 August 2022. The July invoice will include all transactions that occurred since the June invoice to the time of the cutover. All of July and 1-3 August transactions will be included in the invoices generated from the SRS (old system) on 8 August 2022. **What do you need to know:** The August invoice will be generated from the IRS on the 1 September and include all transactions since the cutover in August. Conversion to Host Objects ~~~~~~~~~~~~~~~~~~~~~~~~~~~ **IP addresses** **Description:** In the current SRS, IP addresses are only required for a host if it’s a self-serving host. Name servers that are not self-serving, do not need to contain an IP address. In the IRS, it is mandatory to store IP addresses for all local hosts, regardless of whether they are self-serving. **Approach:** For data migration the IP address will be left blank if it is not present for a local host. **What do you need to know:** After migration, registrars will receive an error when they update a local host record that does not have an IP address. There will only be a small number of host records without IP addresses and it will only impact those registrars who are the host object sponsor. An action will be required when the host record is updated, to add an IP address. Example In the SRS you could have the situation shown in the table below, note there are no IP addresses for the dnshoster.nz namerservers and dnshoster.nz is managed by a different registrar to the domains that use the nameservers. ============== ==================== ======================= ============= SRS domain + nameserver details Host object Registrar ============== ==================== ======================= ============= ab.nz ns1.dnshoster.nz N/A A ac.nz ns2.dnshoster.nz N/A B ad.nz ns3.dnshoster.nz N/A D xy.nz ns4.dnshoster.nz N/A A dnshoster.nz ns11.cloudns.net N/A C ============== ==================== ======================= ============= ============== ==================== ======================= ============== IRS domain Domain Registrar Linked Host object Host Registrar ============== ==================== ======================= ============== ab.nz A ns1.dnshoster.nz C ac.nz B ns2.dnshoster.nz C ad.nz D ns3.dnshoster.nz C xy.nz A ns4.dnshoster.nz C dnshoster.nz C ns11.cloudns.net X ============== ==================== ======================= ============== Number of nameservers ~~~~~~~~~~~~~~~~~~~~~ **Description:** In the current SRS you can have 0-10 nameservers linked to a domain. IRS requires either 0, or 2-13 name servers. **Approach:** For data migration, nameservers will be migrated to host objects and linked to domains, including those domains that only have one nameserver. **What do you need to know:** In the SRS there are less than 200 domains with one name server. After the migration, if any of these domains are updated, an error message will be received, indicating two or more nameservers are required. Nameserver records for non-existent .nz domains ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ **Description:** IRS expects all nameservers ending in ".nz" to have a valid parent domain within the registry, which isn't true in SRS. The SRS treats nameserver "server_name" records as text with limited validation and no triggers to search for deleted records when domains are released. The diagram below illustrates this. .. image:: namserver_records_for_non-existent_domains.png **Approach:** For data migration, we will drop the .nz host records with non-existent parent domains. We will notify registrars of their impacted domains. **What do you need to know:** There are ~300 .nz “Hosts” with non-existent parent domains. This may result in further domains having insufficient nameservers. As outlined above, after the migration, if any of these domains are updated, an error message will be received, indicating two or more nameservers are required. Migration of privacy flags ~~~~~~~~~~~~~~~~~~~~~~~~~~~ **Description:** In the current SRS, privacy can be set at the contact level, i.e. for any contact associated with a domain: registrant, admin and/or technical. In the IRS this changes to privacy at the domain level, and is no longer available on a per contact basis. **Approach:** The privacy migration will be based on the current registrant privacy status, i.e.: If the registrant contact is currently private, the domain will be set to private at migration; If the registrant contact is currently public, no privacy will be applied at migration. **What do you need to know:** Registrars will be advised of how their domains will be migrated (esp. those with mixed privacy settings) and will have time to alter their data before the migration if required. The majority of SRS domain names with privacy are set at the registrant contact level. For those domains that have privacy set at the admin or technical contact but not at the registrant contact we will advise registrars of these domains. Authorisation Code length and migration ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ **Description:** Auth-codes are changing from 8 to 16 characters in length in the IRS. For full details on the authorisation code changes see the InternetNZ Product Documentation **Approach:** We will not be migrating current UDAIs, new authorisation codes will be auto-generated for each domain. **What do you need to do:** Some registrants could be in the process of transferring their domains at the time of the system migration, and their previously issued UDAI/auth-codes will become invalid. Registrars will need to regenerate auth-codes for affected registrants and advise them accordingly. Migration of names in grace periods ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ **Description:** During the data migration we will not be carrying over the SRS domain grace period states for registration and renewals. Any name in a grace period before go-live which is subsequently cancelled will need to be checked: * for any applicable rebates; and * names in the add grace period. These names will not be deleted immediately, but will go through a registry approval process and the registry will then process the delete request. **Approach:** We will put all names known to be in their grace period on an approval list, and in the event of a cancellation, a notification will be sent to registry support. On receiving a notification, registry support can then: * Confirm the name is still in it’s grace period at the date/time of cancellation; * Immediately delete any newly created names that were in the add grace period from the IRS; * Delete any names that were in the renewal grace period; and * Manually cancel the name in the old system to ensure a rebate is processed before generating invoices for the month before cutover. **What do you need to know:** For any of the affected domains that are cancelled, registrars will receive a command completed successfully with action pending message (EPP code = 1001). The registry will then follow the approach outlined above and any rebates will be applied to the next invoice. .. Note:: This means that in the first week after the cutover to the IRS, there will be a delay with these cancellations whilst they are being processed by the registry. Data migration items that are for informational purposes and/or items that will cause system errors after the migration ------------------------------------------------------------------------------------------------------------------------ Ownership of out-of-zone host objects ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ **Description:** In the IRS all host objects must have a sponsoring registrar ID. This is the registrar who will be responsible for updates to the host object. For host objects that do not end with .nz, i.e. out-of-zone host objects, and have multiple domains linked to them spread across a number of registrars, we must select a sponsoring registrar ID. **Approach:** When importing out-of-zone host objects for the IRS data migration, we must select a sponsoring registrar ID. This is the registrar who will be responsible for updates to the host object. InternetNZ’s preference is to base the owner on the earliest active domain name sponsor linked to the out-of-zone host object. Where distinct registrars with identical earliest usage dates exist, we will select the one with the most linked domains—if this is impossible, we will pick one at random, as this has minimal impact. **What do you need to know:** No impact to registrars, as there is no need to update out-of-zone objects. Change to the number of DNSSEC DS /DNSKEY records allowed ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ **Description:** The IRS has a maximum DS record limit of 6, whereas the current SRS has a limit of 10. **Approach:** We will work with one impacted registrar to reduce the number of DS records before migration. EPP contact ID (Handle) collisions during migration ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ **Description:** In SRS, contact handles, the equivalent to EPP contact IDs, are unique per registrar, whereas in the IRS, they are unique to the system. We currently have 227 collisions; all except one are **“auto_“** or **“nzrs_auto_”** handles automatically generated for registrars and domain transfers respectively. **Approach:** We will work with registrars to update these contact handles before the migration. Any remaining collisions will be updated during migration with unique registrar-specific handles. Phone/Fax ~~~~~~~~~~ **Description:** There are 79 contacts which have incorrect format phone or fax. **Approach:** For the data migration to the IRS, Phone/Fax formats will remain unchanged, but after the migration an error will occur when the contact record is updated with an incorrect phone/fax format. Email address ~~~~~~~~~~~~~ **Description:** There are 32 contacts which do not have an email address. **Approach:** For the data migration to the IRS, the Email address can be blank, but after the migration an error will occur when the contact record is updated with a blank email address. Host record with same name as domain name ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ **Description:** There are 54 hosts with the same name as their domain name **Approach:** For the data migration to the IRS, the host name will stay the same, but after the migration an Invalid Host Name Format error will be received when the host record is updated. Duplicated DS record ~~~~~~~~~~~~~~~~~~~~~~~ **Description:** There are 4 domains with duplicate DS records. **Approach:** The duplicate records will be removed during data migration. Alignment of expiry dates ~~~~~~~~~~~~~~~~~~~~~~~~~~ **Description:** With the move to annual renewals, it becomes harder to align expiry dates for registrants with multiple domains. **Approach:** This has no impact on data migration; however, registrars may want to communicate with portfolio holders and resellers, advising them to take this opportunity to align their renewal dates to the same month, by renewing all domain names by the number of months required to match the furthest month.