| gTLD | Full Legal Name | E-mail suffix | Detail | | .bostik | Bostik SA | bostik.com | View |
Table of Contents :
1 - Receipt of data from registrars concerning registration of domain names and nameservers : Shared Registration System (SRS)
2 - Operation of the Registry zone servers
3 - Provision to registrars of status information relating to the zone servers for the TLD
3.1 - Standard DNS related status information
3.2 - Emergency DNS related status information
4 - Dissemination of TLD zone files.
4.1 - Incremental updates every 10 minutes
4.2 - Complete publication of the zone
4.3 - Propagation mechanism
4.4 - Zone File Access⁄Distribution
5 - Dissemination of contact or other information concerning domain name registrations (Whois service)
6 - Internationalized Domain Names
7 - DNS Security Extensions (DNSSEC)
7.1 - Registrar Services
7.2 - Signing Activity
8 - Other relevant services
8.1 - Security and Redundancy
8.2 - Consensus Policy Compliance
------------------------
1 - Receipt of data from registrars concerning registration of domain names and nameservers : Shared Registration System (SRS)
Operated by AFNIC, the .BOSTIK TLD will adapt a domain shared registration system used in production by AFNIC to operate .fr zone and which has been fully functional for the past 15 years. This Extensible Provisioning Protocol (EPP) based Shared Registration System (SRS) has exhibited the ability to meet stringent SLAs as well as to scale from the operational management of an initial thousands of domain names to over 2 million in late 2011.
The SRS exists to interact with the Registrar’s systems, who are responsible for the provisioning of a registrant’s domain name with the .BOSTIK TLD registry. Registrars interact with the registry through two primary mechanisms :
* Communication machine to machine via an EPP client (Registrar) to an EPP Server API (Registry).
* A Web Portal Interface that expresses the functionality of the EPP API. The Web Portal also provides access to user configuration and other back-office functions such as report and invoice retrieval.
SRS functionality includes standard functions and features such as :
* Domain Registration : The AFNIC SRS supports synchronous registrations (creations) of domain names through the EPP domain create command. It supports updates of associative status, DNS and DNSSEC delegation information and EPP contact objects with a domain and the deletion of existing domains. This allows Registrars to create domain registrations, modify them and ultimately delete them.
* Domain Renewal : The AFNIC SRS allows registrars to renew sponsored domains using the EPP renew command. The SRS automatically renews domain names upon expiry.
* Transfer : The AFNIC SRS supports the transfer of a given domain between two Registrars in a secure fashion by requiring two party confirmations and the exchange of a token (the EPP authinfo code) associated with the domain.
* Contact Objects : The AFNIC SRS supports the creation, update, association to domain objects, and deletion of EPP contact objects. This functionality supports the required information to supply contact data displayed in Registration Data Directory Services (RDDS) (Whois) systems.
* Hosts : A subordinate object of the domain object in an EPP based SRS, internal hosts are supported in the AFNIC SRS. These hosts cannot be removed when other 2nd level domains within the .BOSTIK TLD zone are delegated to these nameservers. Delegation must be removed prior to the removal of the child hosts and a parent domain name to a given host in turn cannot be removed prior to the deletion of the related child host.
* Redemption Grace Period (RGP) & Restoring deleted domain name registrations : AFNIC SRS supports the RGP for the purpose of retrieving erroneously deleted domain names prior to being made available again for public registration.
Other features include :
* Additional EPP commands in order to manage and update both domain and contact objects in the registry which are EPP info, check, delete and update commands.
* An inline billing system which is synchronised with the SRS. Actions can be taken daily from simple alerts to concrete account blocking.
* Grace Periods and Refunds : the AFNIC SRS will support standard grace periods such as Add, Renew, Autorenew, Transfer and RGP grace periods. Refunds issued will reflect actual values deducted from registrar’s balance in consideration of any rebates issued conjunctively or separately for the relevant domain registration.
* The capacity to deal with reserved domain name registration. Reserved names are stored in a specific back office tool. Specific authorisations codes can be delivered out of band by support team to “unlock” creation of these reserved names. SRS uses standard EPP auth_info field in conformity with EPP RFCs to prevent or allow the registration of the domain name.
[see attached diagram Q23_1_authorisation_code_workflow.pdf]
Diagram : Reserved names unlock
Description : This diagram illustrates process to unlock registration of reserved names. An out of band email process is used to deliver a specific authorisation_code, that can be used in EPP or through the web interface to register the domain name.
SRS EPP functions are compatible with the following list of RFCs :
RFCs 5910, 5730, 5731, 5732, 5733 and 5734. Since AFNIC will implement the Registry Grace Period (RGP), it will comply with RFC 3915 and the successors of the aforementioned RFCs.
------------------------
2 - Operation of the Registry zone servers
The DNS resolution service is a core business of the Registry Operator. It is an essential function that must be provided with a very high level of service quality to satisfy queries concerning a zone 100% of the time with a response time as short as possible.
As the registry back-end service provider for the .BOSTIK TLD, AFNIC has a set of sites, distributed internationally, to answer these queries. The high availability of responses is ensured by the number of servers that host the zone information; the response time is in turn linked to the geographical location of the servers (as near as possible to the exchange points and as a result to users).
To ensure a very high level of availability of information and a response time as short as possible to a DNS query for a given zone, AFNIC has chosen to deploy its own DNS architecture, operated by our teams, while also relying on a set of internationally recognized service providers in order to significantly increase the number of servers hosting the zone to be published.
The AFNIC DNS service is based on the standards of RFCs (RFCs 1034, 1035, 1982, 2181, 2182, 2671, 3226, 3596, 3597, 4343, and 5966 and any future successors), related to the Internet, and the DNS in particular.
In addition, special attention has been paid to the security component of the DNS servers and services in order to maintain a very high level of availability of the information, for example in the event of attacks or the denial of services. At present, a series of national and international servers are deployed as close as possible to the exchange points to ensure the DNS resolution service. To ensure a high level of availability, Anycast technology is applied to overcome the issues involved in the geographical location of sensitive servers. Through an effective pooling of DNS server resources, it ensures better resistance to denial of service attacks as the number of physical servers to attack is very high, and the geographical attraction of traffic by each server is very strong. Maintenance of the nodes is also improved since interventions on a given server have no effect on the visibility of the Anycast cloud for users.
As explained in the answer to Question 34 (Geographic Diversity), the registry also relies on two operators of Anycast clouds to expand the international coverage of the DNS nodes which must respond to queries for the domain extensions hosted on them. The two operators are Netnod Autonomica and PCH (Packet Clearing House) who are both known for their high quality services; in addition, Netnod Autonomica hosts one the root server i.root-servers.net.
------------------------
3 - Provision to registrars of status information relating to the zone servers for the TLD
Registrars interactions with the Registry Systems in two states in regards to the state of the TLD zone servers :
* an operational state where normal registry transactions and operational policies⁄practices result in a cause and effect in resolution of relevant domains AND
* an emergency state where resolution could be threatened by operational problems due to either internal or external factors to the DNS services.
------------------------
3.1 - Standard DNS related status information
The SRS supports related updates to domain objects that allow a Registrar to populate internal (glue record) and or external DNS hosts associated with the domain. External hosts result in the correct associated NS records being inserted into the current TLD zone file, this in turns results in DNS resolution being delegated to the identified external hosts. The SRS expresses this status to the Registrar as “Active” in both the EPP API and the SRS Web Portal. The registrar may suspend the NS records associated with the external hosts by applying an EPP client HOLD in the system, which will also be displayed as a status in the same manner. This holds true of the Registry when it applied “Server Hold”. Internal hosts follow the same behaviour with one exception, IP addresses must also be provided to the SRS by the registrar for Internal hosts, resulting in A records or⁄and AAAA records for IPv6 (also known as glue records) being added to the zone file.
------------------------
3.2 - Emergency DNS related status information
AFNIC registry services maintain emergency Network Operation Center (NOC) and Customer Service personnel on a 24⁄7⁄365 basis to address escalation and customer issue management. Part of these teams responsibility is to maintain contact lists for technical notification of regular or emergency situations including email lists, names and contact numbers. In the unlikely event that DNS resolution or DNS updates were or were expected to fall out of ICANN mandated SLAs, registrars will be contacted proactively by their email lists, status alerts will be posted to the Registry Operator’s Registrar Relations Web Portals and Customer Service personnel will be prepared to take and address calls on the current DNS status.
------------------------
4 - Dissemination of TLD zone files.
Publication of DNS resolution data to the TLD DNS nodes serving resolution :
One of the main challenges of DNS resolution is to provide updated information about the resources associated with a registered domain name. As soon as information is updated by a registrar on behalf of a customer, the latter expects the server to be accessible to its users as soon as possible.
For this reason, updates of DNS resolution data (publication) are entered into the AFNIC SRS, subsequently generated into incremented zone files, and are distributed to the authoritative DNS servers using the two following methods :
* Incremental updates every 10 minutes
and
* Complete publication of the zone.
------------------------
4.1 - Incremental updates every 10 minutes
The principle of publication by Dynamic Update (RFC 2136 and 2137) is designed to publish only the changes to the zone that have occurred since the last update. At the registry level, we have opted to propagate every 10 minutes the changes made during the last 10 minutes on all the zones managed. In this way, any changes made will naturally be published in the next 10 minutes.
------------------------
4.2 - Complete publication of the zone
In addition to the publication described above, the registry’s DNS operations team produces a complete publication of all the data for all the zones once a week by running a series of computer scripts which regenerates zonefile from database, through the same validation and integrity mechanisms as dynamic publication. This is used as a training for eventual recovery measures to be triggered.
------------------------
4.3 - Propagation mechanism
Whether during the publication by Dynamic Update or complete publication, the propagation mechanism is the same. The process involving the generation of the various zone files is triggered, without blocking any operation on the registration system.
These zone files are then transmitted in full to the authoritative server, via the AXFR protocol in conformance with RFC 5936. Once received and processed by the authoritative server, notifications are sent to secondary servers that will retrieve the changes in the different zones via the IXFR protocol in conformity with RFC 1995. The choice of an incremental (rather than complete) update of the zone files to the secondary servers during the dissemination process has been made to avoid sending large amounts of data to remote sites.
------------------------
4.4 - Zone File Access⁄Distribution
In compliance with Specification 4, Section 2, AFNIC registry services will offer a subscription service for qualifying applicants to download a stateful copy of the TLD zone file no more than once per 24 hours period. Distribution of the zone file will occur through the ICANN authorized Centralized Zone Data Access Provider.
------------------------
5 - Dissemination of contact or other information concerning domain name registrations (Whois service)
The AFNIC RDDS (Whois) service is in direct connection with the database of the Shared Registration System and offers access to the public administrative and technical data of the TLD. Contact data associated with registrations in the SRS is accessible both on port 43 (following specifications of RFC 3912) and through web access.
Data that can be accessed through the RDDS include:
* contact data : holder, administrative, technical, billing
* domain data : domain name, status
* host data : name servers, IP addresses
* ephemeris : creation, expiration dates
* registrar data
These data elements are fully compliant to the mapping of RFCs 5730 to 5734 and an example of standard port 43 output is given at the end of answer to Question 26 (WHOIS).
Both web and port 43 RDDS offer natively compliance with privacy law with a “restricted diffusion” flag. This option is activated through EPP (see Question 25 (EPP)) while creating or updating a contact and automatically understood by the Whois server to anonymize the data. The choice to activate restricted diffusion is made in compliance with the policy and the local rules of the TLD.
This service is accessible both in IPv4 and IPv6. The AFNIC RDDS service access is rate limited to ensure performance in the event of extreme query volumes generated in the cases of distributed denial of service (DDOS) and⁄or RDDS data-mining activities.
------------------------
6 - Internationalized Domain Names
Based on AFNIC’s Back-end registry’s operation experience, the .BOSTIK TLD will allow registration of IDN domain names in full compliance with RFCs 5890 to 5893 and based on the character set described in detail in our answer to Question 44 (IDN). This feature will be available upon launch of the TLD and will be implemented following the policies presented in detail in our answer to Question 44 (IDN). For the purpose of clarity, a brief summary of this information is presented below.
The list of characters includes the French language as well as several other regional languages in use in France : Occitan, Breton, Frankish, Reunion Creole, Catalan, Corsican and Guadeloupe Creole. The list consists of some of the characters of the Latin1 standard (ISO-8859-1) and the Latin9 standard (ISO-8859-15), respectively in Unicode Latin-1 Supplement and Latin Extended-A blocks.
------------------------
7 - DNS Security Extensions (DNSSEC).
AFNIC registry services fully support DNSSEC and will sign the .BOSTIK TLD zone from initiation into the root servers.
------------------------
7.1 - Registrar Services
Operations are available for registrars through EPP with the SecDNS EPP extension version 1.1 exclusively (as defined in RFC 5910) or through registrars extranet (with a web form). Among the two interfaces defined in the RFC 5910, AFNIC chose the “dsData” interface : domain names keys are solely under registrars management and are not exchanged, only the keys hashes (DS records) are sent by the registrars to the registry back-end service provider. Each domain name can be associated to 6 distinct key materials at most.
Zonecheck : A complementary monitoring and validation service.
AFNIC notes that “Zonecheck” is a DNS monitoring and validation service that is outside standard registry services and could be offered by third parties other than a Registry Operator. In respect of DNSSEC monitoring, each change of DS data related to a domain name is verified by the AFNIC ZoneCheck tool, out of band of standard EPP registry functions. Registrar are notified via email of detected errors. This helps Registrars ensure the DNSSEC validation will operate correctly, for example by avoiding the “Security Lameness” scenario outlined in section 4.4.3 of RFC 4641.
Registrar transfer by default removes DS data from the zonefile. This is done to cover cases when a current signed domain names goes from a DNSSEC enabled registrar to another registrar that is not yet prepared to handle DNSSEC materials (the registrar can also be the DNS hoster or not, but in both cases DS data of the domain name has to flow from the registrar to the registry, hence the registrar must have the technical capabilities to do so).
------------------------
7.2 - Signing Activity
Each public-facing DNS server operated by AFNIC or through its anycast providers is fully DNSSEC enabled through RFC 4033, 4034, and 4035 by virtue of using standard open source software (BIND & NSD) that are developed according to these RFCs.
Each zone uses a standard Key Signing Key (KSK)⁄Zone Signing Key (ZSK) split (as defined in RFC 4641, section 3.1), which enables longer KSKs and frequent re-signing of zone content to deter DNSSEC-related brute force attacks and to make sure that keys rollovers are part of registry staff operational habits. All keys are created using RSA algorithms, as defined in RFC 4641 section 3.4 : KSKs are 2048 bits long (as recommended for “high value domains” in section 3.5 of RFC 4641), and ZSKs are 1024 bits. Algorithm SHA-256 (as defined in RFC 4509) is used for DS generations. Signatures of zone resources records are done using SHA-2 and more specifically RSA⁄SHA-256 as defined by RFC 5702.
Each zone has its set of dedicated KSKs and ZSKs: one of each is active at all time, while a second of each is ready to be used at next rollover. A third ZSK may be kept in the zone after being inactive (not used any more for signing) to ease transitions and make sure DNS caches can still use it to verify old resource records signatures. Following recommendations in section 4.1.1 “Time considerations” of RFC 4641, with a zone maximum TTL being 2 days and a zone minimum TTL of 1.5 hour, ZSK rollovers are done each 2 months, KSK rollovers are done each 2 years. Their expirations are monitored. Rollovers are operated according to the “Pre-Publish Key Rollover” procedure detailed in section 4.2.1.1 of RFC 4641.
1 year worth of key materials is generated in advance. Encrypted backup of keys is made on Hardware Security Module (HSM) cards (Storage Master Key), which are securely stored physically.
------------------------
8 - Other relevant services
------------------------
8.1 - Security and Redundancy
AFNIC maintains primary and secondary datacenter locations as well as redundant key personal operating locations. High availability of AFNIC Registry infrastructure is provided through the implementation of either load‐balancing, or fail‐over capacity in various layers of the architecture. It also enables fast scalability through expertise in virtualization technologies. AFNIC’s infrastructure is globally virtualized apart from services requiring very high performance rate and⁄or specific access to dedicated CPU for demanding computation such as DNSSEC zone signing or databases.
AFNIC maintains robust secure policies, protocols and third party testing and certification of security measures and practises. Systems involved in the AFNIC registry services used standard multi-factor authentication, high encryption transmission of data and are kept current with industry advancement in security technologies and best practices in prevention of data breaches. Registry systems follow standard EPP practices including required passphrases associated with each domain object and the use of those passphrases to successfully negotiate and verify domain transfers. Registrars are networked source restricted (2 IP addresses authorized by registrar) for SRS access in addition to the use of digital certificates and contact to Customer Service is restricted to registered Registrar personnel only (identified by personal passphrases⁄credentials listed on file).
------------------------
8.2 - Consensus Policy Compliance
AFNIC registry services will fully comply with Specification 1 of the Application Guidebook, below is a list of current consensus policies that have cause and effect on the systems of a registry operator. This list will be updated from time to time as per the ICANN process and the AFNIC registry services will be adjusted to maintain and support full compliance.
* Uniform Domain Name Dispute Resolution Policy (adopted by ICANN Board 26 August 1999; form of implementation documents approved 24 October 1999).
* Inter-Registrar Transfer Policy (effective on 12 November 2004, adopted by ICANN Board 25 April 2003; implementation documents issued 13 July 2004).
* Registry Services Evaluation Policy (effective on 15 August 2006, adopted by ICANN Board 8 November 2005; implementation documents posted 25 July 2006)
* AGP Limits Policy (effective on 1 April 2009, adopted by ICANN Board on 26 June 2008; implementation documents posted 17 December 2008)
| gTLD | Full Legal Name | E-mail suffix | Detail | | .alsace | REGION D ALSACE | sdv.fr | View |
Table of Contents :
1 - Receipt of data from registrars concerning registration of domain names and nameservers : Shared Registration System (SRS)
2 - Operation of the Registry zone servers
3 - Provision to registrars of status information relating to the zone servers for the TLD
3.1 - Standard DNS related status information
3.2 - Emergency DNS related status information
4 - Dissemination of TLD zone files.
4.1 - Incremental updates every 10 minutes
4.2 - Complete publication of the zone
4.3 - Propagation mechanism
4.4 - Zone File Access⁄Distribution
5 - Dissemination of contact or other information concerning domain name registrations (Whois service)
6 - Internationalized Domain Names
7 - DNS Security Extensions (DNSSEC)
7.1 - Registrar Services
7.2 - Signing Activity
8 - Other relevant services
8.1 - Security and Redundancy
8.2 - Consensus Policy Compliance
------------------------
1 - Receipt of data from registrars concerning registration of domain names and nameservers : Shared Registration System (SRS)
This answer was drafted based on AFNICʹs experience, as AFNIC was selected to advise the Alsace Région during the submission of the application. The final selection of the back-end registry operator will take place before june 2012. this selection will follow a public tender process. The Alsace Région will ensure that candidates fulfill or exceed all commitments detailed in this answer.
Operated by AFNIC, the .ALSACE TLD will adapt a domain shared registration system used in production by AFNIC to operate .fr zone and which has been fully functional for the past 15 years. This Extensible Provisioning Protocol (EPP) based Shared Registration System (SRS) has exhibited the ability to meet stringent SLAs as well as to scale from the operational management of an initial thousands of domain names to over 2 million in late 2011.
The SRS exists to interact with the Registrar’s systems, who are responsible for the provisioning of a registrant’s domain name with the .ALSACE TLD registry. Registrars interact with the registry through two primary mechanisms :
* Communication machine to machine via an EPP client (Registrar) to an EPP Server API (Registry).
* A Web Portal Interface that expresses the functionality of the EPP API. The Web Portal also provides access to user configuration and other back-office functions such as report and invoice retrieval.
SRS functionality includes standard functions and features such as :
* Domain Registration : The AFNIC SRS supports synchronous registrations (creations) of domain names through the EPP domain create command. It supports updates of associative status, DNS and DNSSEC delegation information and EPP contact objects with a domain and the deletion of existing domains. This allows Registrars to create domain registrations, modify them and ultimately delete them.
* Domain Renewal : The AFNIC SRS allows registrars to renew sponsored domains using the EPP renew command. The SRS automatically renews domain names upon expiry.
* Transfer : The AFNIC SRS supports the transfer of a given domain between two Registrars in a secure fashion by requiring two party confirmations and the exchange of a token (the EPP authinfo code) associated with the domain.
* Contact Objects : The AFNIC SRS supports the creation, update, association to domain objects, and deletion of EPP contact objects. This functionality supports the required information to supply contact data displayed in Registration Data Directory Services (RDDS) (Whois) systems.
* Hosts : A subordinate object of the domain object in an EPP based SRS, internal hosts are supported in the AFNIC SRS. These hosts cannot be removed when other 2nd level domains within the .ALSACE TLD zone are delegated to these nameservers. Delegation must be removed prior to the removal of the child hosts and a parent domain name to a given host in turn cannot be removed prior to the deletion of the related child host.
* Redemption Grace Period (RGP) & Restoring deleted domain name registrations : AFNIC SRS supports the RGP for the purpose of retrieving erroneously deleted domain names prior to being made available again for public registration.
Other features include :
* Additional EPP commands in order to manage and update both domain and contact objects in the registry which are EPP info, check, delete and update commands.
* An inline billing system which is synchronised with the SRS. Actions can be taken daily from simple alerts to concrete account blocking.
* Grace Periods and Refunds : the AFNIC SRS will support standard grace periods such as Add, Renew, Autorenew, Transfer and RGP grace periods. Refunds issued will reflect actual values deducted from registrar’s balance in consideration of any rebates issued conjunctively or separately for the relevant domain registration.
* The capacity to deal with reserved domain name registration. Reserved names are stored in a specific back office tool. Specific authorisations codes can be delivered out of band by support team to “unlock” creation of these reserved names. SRS uses standard EPP auth_info field in conformity with EPP RFCs to prevent or allow the registration of the domain name.
[see attached diagram Q23_1_authorisation_code_workflow.pdf]
Diagram : Reserved names unlock
Description : This diagram illustrates process to unlock registration of reserved names. An out of band email process is used to deliver a specific authorisation_code, that can be used in EPP or through the web interface to register the domain name.
SRS EPP functions are compatible with the following list of RFCs :
RFCs 5910, 5730, 5731, 5732, 5733 and 5734. Since AFNIC will implement the Registry Grace Period (RGP), it will comply with RFC 3915 and the successors of the aforementioned RFCs.
------------------------
2 - Operation of the Registry zone servers
The DNS resolution service is a core business of the Registry Operator. It is an essential function that must be provided with a very high level of service quality to satisfy queries concerning a zone 100% of the time with a response time as short as possible.
As the registry back-end service provider for the .ALSACE TLD, AFNIC has a set of sites, distributed internationally, to answer these queries. The high availability of responses is ensured by the number of servers that host the zone information; the response time is in turn linked to the geographical location of the servers (as near as possible to the exchange points and as a result to users).
To ensure a very high level of availability of information and a response time as short as possible to a DNS query for a given zone, AFNIC has chosen to deploy its own DNS architecture, operated by our teams, while also relying on a set of internationally recognized service providers in order to significantly increase the number of servers hosting the zone to be published.
The AFNIC DNS service is based on the standards of RFCs (RFCs 1034, 1035, 1982, 2181, 2182, 2671, 3226, 3596, 3597, 4343, and 5966 and any future successors), related to the Internet, and the DNS in particular.
In addition, special attention has been paid to the security component of the DNS servers and services in order to maintain a very high level of availability of the information, for example in the event of attacks or the denial of services. At present, a series of national and international servers are deployed as close as possible to the exchange points to ensure the DNS resolution service. To ensure a high level of availability, Anycast technology is applied to overcome the issues involved in the geographical location of sensitive servers. Through an effective pooling of DNS server resources, it ensures better resistance to denial of service attacks as the number of physical servers to attack is very high, and the geographical attraction of traffic by each server is very strong. Maintenance of the nodes is also improved since interventions on a given server have no effect on the visibility of the Anycast cloud for users.
As explained in the answer to Question 34 (Geographic Diversity), the registry also relies on two operators of Anycast clouds to expand the international coverage of the DNS nodes which must respond to queries for the domain extensions hosted on them. The two operators are Netnod Autonomica and PCH (Packet Clearing House) who are both known for their high quality services; in addition, Netnod Autonomica hosts one the root server i.root-servers.net.
------------------------
3 - Provision to registrars of status information relating to the zone servers for the TLD
Registrars interactions with the Registry Systems in two states in regards to the state of the TLD zone servers :
* an operational state where normal registry transactions and operational policies⁄practices result in a cause and effect in resolution of relevant domains AND
* an emergency state where resolution could be threatened by operational problems due to either internal or external factors to the DNS services.
------------------------
3.1 - Standard DNS related status information
The SRS supports related updates to domain objects that allow a Registrar to populate internal (glue record) and or external DNS hosts associated with the domain. External hosts result in the correct associated NS records being inserted into the current TLD zone file, this in turns results in DNS resolution being delegated to the identified external hosts. The SRS expresses this status to the Registrar as “Active” in both the EPP API and the SRS Web Portal. The registrar may suspend the NS records associated with the external hosts by applying an EPP client HOLD in the system, which will also be displayed as a status in the same manner. This holds true of the Registry when it applied “Server Hold”. Internal hosts follow the same behaviour with one exception, IP addresses must also be provided to the SRS by the registrar for Internal hosts, resulting in A records or⁄and AAAA records for IPv6 (also known as glue records) being added to the zone file.
------------------------
3.2 - Emergency DNS related status information
AFNIC registry services maintain emergency Network Operation Center (NOC) and Customer Service personnel on a 24⁄7⁄365 basis to address escalation and customer issue management. Part of these teams responsibility is to maintain contact lists for technical notification of regular or emergency situations including email lists, names and contact numbers. In the unlikely event that DNS resolution or DNS updates were or were expected to fall out of ICANN mandated SLAs, registrars will be contacted proactively by their email lists, status alerts will be posted to the Registry Operator’s Registrar Relations Web Portals and Customer Service personnel will be prepared to take and address calls on the current DNS status.
------------------------
4 - Dissemination of TLD zone files.
Publication of DNS resolution data to the TLD DNS nodes serving resolution :
One of the main challenges of DNS resolution is to provide updated information about the resources associated with a registered domain name. As soon as information is updated by a registrar on behalf of a customer, the latter expects the server to be accessible to its users as soon as possible.
For this reason, updates of DNS resolution data (publication) are entered into the AFNIC SRS, subsequently generated into incremented zone files, and are distributed to the authoritative DNS servers using the two following methods :
* Incremental updates every 10 minutes
and
* Complete publication of the zone.
------------------------
4.1 - Incremental updates every 10 minutes
The principle of publication by Dynamic Update (RFC 2136 and 2137) is designed to publish only the changes to the zone that have occurred since the last update. At the registry level, we have opted to propagate every 10 minutes the changes made during the last 10 minutes on all the zones managed. In this way, any changes made will naturally be published in the next 10 minutes.
------------------------
4.2 - Complete publication of the zone
In addition to the publication described above, the registry’s DNS operations team produces a complete publication of all the data for all the zones once a week by running a series of computer scripts which regenerates zonefile from database, through the same validation and integrity mechanisms as dynamic publication. This is used as a training for eventual recovery measures to be triggered.
------------------------
4.3 - Propagation mechanism
Whether during the publication by Dynamic Update or complete publication, the propagation mechanism is the same. The process involving the generation of the various zone files is triggered, without blocking any operation on the registration system.
These zone files are then transmitted in full to the authoritative server, via the AXFR protocol in conformance with RFC 5936. Once received and processed by the authoritative server, notifications are sent to secondary servers that will retrieve the changes in the different zones via the IXFR protocol in conformity with RFC 1995. The choice of an incremental (rather than complete) update of the zone files to the secondary servers during the dissemination process has been made to avoid sending large amounts of data to remote sites.
------------------------
4.4 - Zone File Access⁄Distribution
In compliance with Specification 4, Section 2, AFNIC registry services will offer a subscription service for qualifying applicants to download a stateful copy of the TLD zone file no more than once per 24 hours period. Distribution of the zone file will occur through the ICANN authorized Centralized Zone Data Access Provider.
------------------------
5 - Dissemination of contact or other information concerning domain name registrations (Whois service)
The AFNIC RDDS (Whois) service is in direct connection with the database of the Shared Registration System and offers access to the public administrative and technical data of the TLD. Contact data associated with registrations in the SRS is accessible both on port 43 (following specifications of RFC 3912) and through web access.
Data that can be accessed through the RDDS include:
* contact data : holder, administrative, technical, billing
* domain data : domain name, status
* host data : name servers, IP addresses
* ephemeris : creation, expiration dates
* registrar data
These data elements are fully compliant to the mapping of RFCs 5730 to 5734 and an example of standard port 43 output is given at the end of answer to Question 26 (WHOIS).
Both web and port 43 RDDS offer natively compliance with privacy law with a “restricted diffusion” flag. This option is activated through EPP (see Question 25 (EPP)) while creating or updating a contact and automatically understood by the Whois server to anonymize the data. The choice to activate restricted diffusion is made in compliance with the policy and the local rules of the TLD.
This service is accessible both in IPv4 and IPv6. The AFNIC RDDS service access is rate limited to ensure performance in the event of extreme query volumes generated in the cases of distributed denial of service (DDOS) and⁄or RDDS data-mining activities.
------------------------
6 - Internationalized Domain Names
Based on AFNIC’s Back-end registry’s operation experience, the .ALSACE TLD will eventually allow registration of IDN domain names in full compliance with RFCs 5890 to 5893 and based on the character set described in detail in our answer to Question 44 (IDN). This feature will not be available upon launch of the TLD and shall be implemented in the future following the policies presented in detail in our answer to Question 44 (IDN). For the purpose of clarity, a brief summary of this information is presented below.
The list of characters includes the French language as well as several other regional languages in use in France : Occitan, Breton, Frankish, Reunion Creole, Catalan, Corsican and Guadeloupe Creole. The list consists of some of the characters of the Latin1 standard (ISO-8859-1) and the Latin9 standard (ISO-8859-15), respectively in Unicode Latin-1 Supplement and Latin Extended-A blocks.
Each domain name registration is autonomous : the registration of an ASCII domain name and the registration of one of its diacritic variants are independent. The actual registered domain name is the only one to be effectively registered and published by the Whois and DNS Services.
However, the registration of a given ASCII or IDN domain name leads to a default preference to its registrant (original registrant) for the subsequent registration of any of its diacritics variants. Any of these variants can be registered normally by the original registrant at any time. Other registrants are required to request a specific authorization code delivered by the Registry Operator before they can proceed to the registration of such names. This policy applies whether the original registrant initially applies for an ASCII domain name or a diacritic variant of that ASCII domain name. In the latter case, the ASCII name is subject to the same preference policy than the other diacritic variants of the domain name.
------------------------
7 - DNS Security Extensions (DNSSEC).
AFNIC registry services fully support DNSSEC and will sign the .ALSACE TLD zone from initiation into the root servers.
------------------------
7.1 - Registrar Services
Operations are available for registrars through EPP with the SecDNS EPP extension version 1.1 exclusively (as defined in RFC 5910) or through registrars extranet (with a web form). Among the two interfaces defined in the RFC 5910, AFNIC chose the “dsData” interface : domain names keys are solely under registrars management and are not exchanged, only the keys hashes (DS records) are sent by the registrars to the registry back-end service provider. Each domain name can be associated to 6 distinct key materials at most.
Zonecheck : A complementary monitoring and validation service.
AFNIC notes that “Zonecheck” is a DNS monitoring and validation service that is outside standard registry services and could be offered by third parties other than a Registry Operator. In respect of DNSSEC monitoring, each change of DS data related to a domain name is verified by the AFNIC ZoneCheck tool, out of band of standard EPP registry functions. Registrar are notified via email of detected errors. This helps Registrars ensure the DNSSEC validation will operate correctly, for example by avoiding the “Security Lameness” scenario outlined in section 4.4.3 of RFC 4641.
Registrar transfer by default removes DS data from the zonefile. This is done to cover cases when a current signed domain names goes from a DNSSEC enabled registrar to another registrar that is not yet prepared to handle DNSSEC materials (the registrar can also be the DNS hoster or not, but in both cases DS data of the domain name has to flow from the registrar to the registry, hence the registrar must have the technical capabilities to do so).
------------------------
7.2 - Signing Activity
Each public-facing DNS server operated by AFNIC or through its anycast providers is fully DNSSEC enabled through RFC 4033, 4034, and 4035 by virtue of using standard open source software (BIND & NSD) that are developed according to these RFCs.
Each zone uses a standard Key Signing Key (KSK)⁄Zone Signing Key (ZSK) split (as defined in RFC 4641, section 3.1), which enables longer KSKs and frequent re-signing of zone content to deter DNSSEC-related brute force attacks and to make sure that keys rollovers are part of registry staff operational habits. All keys are created using RSA algorithms, as defined in RFC 4641 section 3.4 : KSKs are 2048 bits long (as recommended for “high value domains” in section 3.5 of RFC 4641), and ZSKs are 1024 bits. Algorithm SHA-256 (as defined in RFC 4509) is used for DS generations. Signatures of zone resources records are done using SHA-2 and more specifically RSA⁄SHA-256 as defined by RFC 5702.
Each zone has its set of dedicated KSKs and ZSKs: one of each is active at all time, while a second of each is ready to be used at next rollover. A third ZSK may be kept in the zone after being inactive (not used any more for signing) to ease transitions and make sure DNS caches can still use it to verify old resource records signatures. Following recommendations in section 4.1.1 “Time considerations” of RFC 4641, with a zone maximum TTL being 2 days and a zone minimum TTL of 1.5 hour, ZSK rollovers are done each 2 months, KSK rollovers are done each 2 years. Their expirations are monitored. Rollovers are operated according to the “Pre-Publish Key Rollover” procedure detailed in section 4.2.1.1 of RFC 4641.
1 year worth of key materials is generated in advance. Encrypted backup of keys is made on Hardware Security Module (HSM) cards (Storage Master Key), which are securely stored physically.
------------------------
8 - Other relevant services
------------------------
8.1 - Security and Redundancy
AFNIC maintains primary and secondary datacenter locations as well as redundant key personal operating locations. High availability of AFNIC Registry infrastructure is provided through the implementation of either load‐balancing, or fail‐over capacity in various layers of the architecture. It also enables fast scalability through expertise in virtualization technologies. AFNIC’s infrastructure is globally virtualized apart from services requiring very high performance rate and⁄or specific access to dedicated CPU for demanding computation such as DNSSEC zone signing or databases.
AFNIC maintains robust secure policies, protocols and third party testing and certification of security measures and practises. Systems involved in the AFNIC registry services used standard multi-factor authentication, high encryption transmission of data and are kept current with industry advancement in security technologies and best practices in prevention of data breaches. Registry systems follow standard EPP practices including required passphrases associated with each domain object and the use of those passphrases to successfully negotiate and verify domain transfers. Registrars are networked source restricted (2 IP addresses authorized by registrar) for SRS access in addition to the use of digital certificates and contact to Customer Service is restricted to registered Registrar personnel only (identified by personal passphrases⁄credentials listed on file).
------------------------
8.2 - Consensus Policy Compliance
AFNIC registry services will fully comply with Specification 1 of the Application Guidebook, below is a list of current consensus policies that have cause and effect on the systems of a registry operator. This list will be updated from time to time as per the ICANN process and the AFNIC registry services will be adjusted to maintain and support full compliance.
* Uniform Domain Name Dispute Resolution Policy (adopted by ICANN Board 26 August 1999; form of implementation documents approved 24 October 1999).
* Inter-Registrar Transfer Policy (effective on 12 November 2004, adopted by ICANN Board 25 April 2003; implementation documents issued 13 July 2004).
* Registry Services Evaluation Policy (effective on 15 August 2006, adopted by ICANN Board 8 November 2005; implementation documents posted 25 July 2006)
* AGP Limits Policy (effective on 1 April 2009, adopted by ICANN Board on 26 June 2008; implementation documents posted 17 December 2008)