23 Provide name and full description of all the Registry Services to be provided

Prototypical answer:

We will provide the following registry services to registrars,
registrants and the community (not all services will be provided for
all of the above):

1. Receipt of data from registrars concerning registration of domain
names and name servers
2. Dissemination of Top Level Domain (TLD) zone files
3. Dissemination of contact or other information concerning domain
name registrations
4. Latin Script Internationalized Domain Names
5. Provision of status information relating to the zone, registration
and Whois servers for the .UOL TLD
6. DNS Security Extensions (DNSSEC)


Those services are described in more detail below. In addition, we
will provide services that are required from existing or might be
required from future Consensus Policies.


1. Receipt of data from registrars concerning registration of domain
names and name servers

1.1 - Description

All communication with registrars will be carried over Extensible
Provisioning Protocol (EPP) - RFC5730 (Request For Comments). This EPP
implementation supports the following object mappings and extensions:

* Domain Name Mapping (RFC5731)
* Contact Mapping (RFC5733)
* Transport Over TCP (Transmission Control Protocol) Extension (RFC5734)
* Domain Name System (DNS) Security Extensions Mapping (RFC4310)
* EPP Grace Period Mapping (RFC3915)

Host objects, as described in the Host Mapping (RFC5732), are not
supported as this registry operates name server information as domain
attributes.

In all domains that are registered by a brazilian individual or
organization, the registrant needs to be uniquely identified by a
document ID, which can be CPF (Cadastro de Pessoa Física - individual)
or CNPJ (Cadastro Nacional de Pessoa Jurídica - organization). This
document must also be valid according to the brazilian internal
revenue service.

When a registrant makes a request for a domain name, the domain is
created with a serverHold status, until all of its pendencies are
solved. Most common pendencies are authoritative DNS (Domain Name
System) servers and documentation issues. Once all pendencies are
successfully dealt with, the domain is finally published.

1.2 - Supported operations

All supported operations are based in RFCs and they handle two main
objects: domain and contact.

1.2.1 - Domain

Domain operations are described in RFC5731. The registry supports the
following domain operations: create, update, info, check, renew,
delete and transfer. Domain update, info and check transactions are
provided at no cost, only needing to respect non-abusive usage; Domain
create, renew, delete and transfer are subject to then-current
policies.

1.2.2 - Contact

Contact operations are described in RFC5733. The registry supports the
following contact operations: create, update, check, info and
transfer. Contact operations do not have a cost, only needing to
respect non-abusive usage.

1.3 - Security

The transport is secured using TCP over Transport Layer Security (TLS)
(RFC5734). Once a registrar is accredited to operate the system, the
registry issues a certificate that must be used by the registrar in
order to establish a connection. This certificate is valid for a
period of 3 years.

The registrar can only connect from previously informed IP (Internet
Protocol) addresses or ranges. The maximum number of allowed IP
addresses⁄ranges is four.

The system provides password authentication for the registrars. The
password is not stored in plain text in the registry system.


2 - Dissemination of TLD zone files

2.1 - DNS Publication

Zones generation and dissemination are handled by a proprietary NIC.br
(Núcleo de Informação e Coordenação do Ponto BR) software which works
as a hidden master. The zones are transferred to geographically
dispersed clusters of authoritative slaves that run open source DNS
servers.

Some instances of these DNS clusters also participate in a
shared-unicast (also known as anycast) system to increase the
geographic distribution of DNS servers and also reduce latency for DNS
queries.

2.2 Zone file publication

FTP(File Transfer Protocol) access to the zone files will be provided
at no cost thru the CZDA (Centralized Zone Data Access Provider) to
Internet users for lawful purposes, after the user satisfies the
request to provide it with information sufficient to correctly
identify and locate the user. Such user information will include,
without limitation, company name, contact name, address, telephone
number, facsimile number, email address, and the Internet host machine
name and IP address.

Provided that, (a) user takes all reasonable steps to protect against
unauthorized access to and use and disclosure of the data, and (b)
under no circumstances will Registry Operator be required or permitted
to allow user to use the data to, (i) allow, enable, or otherwise
support the transmission by e- mail, telephone, or facsimile of mass
unsolicited, commercial advertising or solicitations to entities other
than users own existing customers, or (ii) enable high volume,
automated, electronic processes that send queries or data to the
systems of Registry Operator or any ICANN-accredited (Internet
Corporation for Assigned Names and Numbers) registrar.

Zone files will be published using a sub-format of the Standard Master
File format as originally defined in RFC 1035, Section 5, as follows:

2.2.1. Each record must include all fields in one line as:
lt domain-name gt lt TTL gt lt class gt lt type gt lt RDATA gt
where:
lt = symbol for less than
gt = symbol for greater than
2.2.2. Class and Type must use the standard mnemonics and must be in
lower case.
2.2.3. TTL (Time To Live) must be present as a decimal integer.
2.2.4. Use of ⁄X and ⁄DDD inside domain names is allowed.
2.2.5. All domain names must be in lower case.
2.2.6. Must use exactly one tab as separator of fields inside a
record.
2.2.7. All domain names must be fully qualified.
2.2.8. No $ORIGIN directives.
2.2.9. No use of ʺ@ʺ to denote current origin.
2.2.10. No use of ʺblank domain namesʺ at the beginning of a record to
continue the use of the domain name in the previous record.
2.2.11. No $INCLUDE directives.
2.2.12. No $TTL directives.
2.2.13. No use of parentheses, e.g., to continue the list of fields in
a record across a line boundary.
2.2.14. No use of comments.
2.2.15. No blank lines.
2.2.16. The SOA (Start Of Authority) record should be present at the
top and (duplicated at) the end of the zone file.
2.2.17. With the exception of the SOA record, all the records in a
file must be in alphabetical order.
2.2.18. One zone per file. If a TLD divides its DNS data into multiple
zones, each goes into a separate file named as above, with all the
files combined using tar into a file called UOL.zone.tar.

Registry Operator shall provide bulk access to the zone files for the
.UOL TLD to the EBERO (Emergency Back-End Registry Operators)
designated by ICANN on a continuous basis in the manner ICANN may
reasonably specify from time to time.


3. Dissemination of contact or other information concerning domain
name registrations

The WHOIS service supports lookup capability that is compliant with
RFC3912(port-43 WHOIS) and will include RESTful-WHOIS when the
Internet Engineering Task Force (IETF) finishes such specifications
and⁄or ICANN Consensus Policies adopt RESTful-WHOIS . There are two
types of data records supported in this implementation: domain and
contact.

High availability of the service is provided by balancing the load on
two or more distinct instances of the whois server.

To avoid any possible abusive activity, thereʹs the option of limiting
the rate of queries one single client is allowed to send.

WHOIS services are provided at no cost to the Internet community.


4. Latin Script Internationalized Domain Names

The system supports IDNs according to RFCs 3492, 5890-5892. Only Latin
Script Brazilian Portuguese characters are allowed.

IDN registrations will be available from the beginning of .UOL
operation.


5. Provision of status information relating to the zone, registration
and WHOIS servers for the .UOL TLD

An web-based status dashboard will be provided with the most
up-to-date information available at any given time regarding
availability of the SRS, DNS publication, EPP and WHOIS services.

Status information are targeted at registrars due to its technical
nature and will be provided at no cost.


6. DNS Security Extensions (DNSSEC)

DNSSEC is available to all domains registered in the .UOL TLD. All
zones are signed using a proprietary NIC.br software that is compliant
with RFCs 4033-4035 and 4509.

In order to provide authenticated denial of existence this system uses
NSEC3 (Next Secure), as described in RFC5155.

Creation and management of Zone Signing Keys (ZSK) and Key Signing
Keys (KSK) are done in accordance to a publicized DPS (DNSSEC Practice
Statement).

Provisioning of DNSSEC DS (Delegation Signer) records is available at
no extra cost to all domain registrants.

Similar gTLD applications: (4)