ICANN New gTLD Application

New gTLD Application Submitted to ICANN by: UBN INTERNET LTDA.

String: uol

Originally Posted: 13 June 2012

Application ID: 1-1151-36619


Applicant Information


1. Full legal name

 
UBN INTERNET LTDA.

2. Address of the principal place of business

 
Av. Marcos Penteado Ulhoa Rodrigues, 700 - Parte
 Santana do Parnaíba São Paulo 06543-001
BR

3. Phone number

 
+55 11 3038 8627

4. Fax number

 
+55 11 3038 8202

5. If applicable, website or URL

 
http:⁄⁄www.uol.com.br

Primary Contact


6(a). Name

 
Ms. Marlene Aparecida Pinto McDonnell

6(b). Title

 
Product Analyst

6(c). Address

6(d). Phone Number

 
+55 11 5509 3537 4038

6(e). Fax Number

 
+55 11 5509 3501

6(f). Email Address

 
mpmcdonnell@registro.br

Secondary Contact


7(a). Name

 
Mr. Anderson Nakandakare Gonçalves

7(b). Title

 
Analyst

7(c). Address

7(d). Phone Number

 
+55 11 5509 3537 4037

7(e). Fax Number

 
+55 11 5509 3501

7(f). Email Address

 
angoncalves@registro.br

Proof of Legal Establishment


8(a). Legal form of the Applicant

 
Limited Liability Company

8(b). State the specific national or other jursidiction that defines the type of entity identified in 8(a).

 
New Brazilian Civil Code of 2002 ( Lei 10.406⁄2002 - articles 1052⁄1087)

8(c). Attach evidence of the applicant's establishment.

 
Attachments are not displayed on this form.

9(a). If applying company is publicly traded, provide the exchange and symbol. 







9(b). If the applying entity is a subsidiary, provide the parent company.



Universo Online S.A. 






9(c). If the applying entity is a joint venture, list all joint venture partners.











Applicant Background
 





11(a). Name(s) and position(s) of all directors









11(b). Name(s) and position(s) of all officers and partners



Eduardo AlcaroDirector
Marcelo EpstejnDirector






11(c). Name(s) and position(s) of all shareholders holding at least 15% of shares



Luiz Frias
Universo Online S.A.Not Applicable






11(d). For an applying entity that does not have directors, officers, partners, or shareholders: Name(s) and position(s) of all individuals having legal or executive responsibility











Applied-for gTLD string
 





13. Provide the applied-for gTLD string. If an IDN, provide the U-label.



uol






14(a). If an IDN, provide the A-label (beginning with "xn--").









14(b). If an IDN, provide the meaning or restatement of the string 

in English, that is, a description of the literal meaning of the string in the 

opinion of the applicant.









14(c). If an IDN, provide the language of the label (in English).









14(c). If an IDN, provide the language of the label (as referenced by ISO-639-1).









14(d). If an IDN, provide the script of the label (in English).









14(d). If an IDN, provide the script of the label (as referenced by ISO 15924).









14(e). If an IDN, list all code points contained in the U-label according to Unicode form.









15(a). If an IDN, Attach IDN Tables for the proposed registry.



Attachments are not displayed on this form.






15(b). Describe the process used for development of the IDN tables submitted, including consultations and sources used.









15(c). List any variant strings to the applied-for gTLD string according to the relevant IDN tables.









16. Describe the applicant's efforts to ensure that there are no known operational or rendering problems concerning the applied-for gTLD string.

If such issues are known, describe steps that will be taken to mitigate these issues in software and other applications.



The applied-for gTLD string is not an IDN so rendering issues are not expected.
We have no knowledge of operational issues besides those already listed by ICANN in its Universal Acceptance reports and by the IETF in RFC 3696. Weʹll encourage the industry to adopt tools like the ICANNʹs Universal Acceptance Toolkit (https:⁄⁄github.com⁄icann) and provide support information to registrants regarding Universal Acceptance. 








17. (OPTIONAL) Provide a representation of the label according to the International Phonetic Alphabet (http://www.langsci.ucl.ac.uk/ipa/).













Mission/Purpose
 





18(a). Describe the mission/purpose of your proposed gTLD.



Our mission is to provide content of great quality, safety and innovation in services and multiple option of entertainment.  The word universe is the root of our brand, and we offer an infinite universe of digital content and services to internet users and companies. The TLD .uol will have the mission to contain itself all this universe of digital content and show it to the world with quality, security, innovation and variety.
Our name itself seems like a TLD: UOL. This Acronym which is used to designate Universo Online and shows itself so strong as a brand that we rarely use the extended version. We were the first content portal in Brazil, founded in 1996. Sixteen years later we are the biggest content portal in Portuguese distributed in more than 1,000 channels and we reach seven in ten Brazilians on the Internet. According Ibope⁄NetRatings (a joint venture between Grupo Ibope, a Brazilian research company, and Nielsen NetRatings) we have more than 33.1 million unique visitors per month (reach of 68% of Brazilian active users). Our home page has 5 million daily unique visitors and 35 million page views daily according to measurement tool we use in our site: Omniture SiteCatalyst.
Beyond our own digital content, UOL offers contents from prestigious channels worldwide such as The New York Times, Der Spiegel, Financial Times, USA Today, BBC and Reuters available in Portuguese. As well TV UOL, pioneer in audiovisual contents in Brazil, offers entertainment contents in partnership with Cartoon Network, Nickelodeon, VH1, Discovery and BBC in Portuguese.
In addition to this amount of contents and channels, we offer several internet services to private individuals and companies, from price comparison for consumers to secure data center services for some of the Brazilian largest e-commerce companies. The recent acquisitions and mergers turned UOL into one of the strongest communication and technology groups in Latin America.






18(b). How do you expect that your proposed gTLD will benefit registrants, Internet users, and others?



Our universe under a unique extension! The gTLD “.uol” will be the reason for unifying the services we provide to end users with benefits for ours branding efforts, in business and marketing perspectives. 
We already have a strong brand and we are the biggest in content and one of the biggest in internet services in Brazil and Latin America. More than innovation, these touch points give us the status needed to offer a reliable navigation experience with the new TLD and reinforce our brand in the world of Internet.
To be one of the first is also important to us because, as a pioneer company on the Internet in Brazil and Latin America, we also want to be in the new top level domains segment.
Another point is to avoid any type of typosquatting⁄cybersquat⁄cybersquatting and⁄or frauds. As UOL has many services and partners in its content, even with our several security levels, this kind of security layer will guarantee the content origin and tenting its legitimacy, which benefits the company and users for creating the separation between our own sites, our partners and our platforms of services. With the gTLD “.uol” it would be possible to create individual domains to each partner and service and still keep them related to UOL´s brand, creating an information barrier to separate and isolate services, avoiding the user´s information interchange between these services and preventing conflict of interests, just as indicated in Chinese Wall concept. Besides, the gTLD “.uol” will be a closed register system and only UOL will be able to create domains, which increase even more security by assuring that when someone is visiting a “.uol” domain this person is really seeing UOL´s content, making difficult phishing practices.
All “.uol” management will be done by UBN Internet Ltda. and private individuals won’t be allowed to request registration.






18(c). What operating rules will you adopt to eliminate or minimize social costs?



The new brand top level domain “.uol” will have a closed registry model. It means that private individuals wonʹt be able to request registrations for “.uol”.
Once all channels and services are managed by UBN Internet Ltda., which will also be responsible for the “.uol” management, the process of creating new “.uol” domains wonʹt generate any economic transactions in terms of costs and incomes.










Community-based Designation
 





19.	Is the application for a community-based TLD?



No






20(a). Provide the name and full description of the community that the applicant is committing to serve.









20(b). Explain the applicant's relationship to the community identified in 20(a).









20(c). Provide a description of the community-based purpose of the applied-for gTLD.









20(d). Explain the relationship between the applied-for gTLD string and the community identified in 20(a).









20(e). Provide a description of the applicant's intended registration policies in support of the community-based purpose of the applied-for gTLD.









20(f). Attach any written endorsements from institutions/groups representative of the community identified in 20(a).



Attachments are not displayed on this form.










Geographic Names
 





21(a). Is the application for a geographic name?



No






Protection of Geographic Names






22. Describe proposed measures for protection of geographic names at

 the second and other levels in the applied-for gTLD.



The country and territory names contained in the following internationally recognized lists shall be initially reserved at the second level, which will be the only level that will have domain name delegations:

- The short form (in English) of all country and territory names contained on the ISO 3166- 1 list, as updated from time to time, including the European Union, which is exceptionally reserved on the ISO 3166-1 list, and its scope extended in August 1999 to any application needing to represent the name European Union 〈http:⁄⁄www.iso.org⁄iso⁄support⁄country_codes⁄iso_3166_code_lists⁄iso-3166- 1_decoding_table.htm#EU〉; 
- The United Nations Group of Experts on Geographical Names, Technical Reference Manual for the Standardization of Geographical Names, Part III Names of Countries of the World; 
- The list of United Nations member states in 6 official United Nations languages prepared by the Working Group on Country Names of the United Nations Conference on the Standardization of Geographical Names and
- The list of United Nations member states in Portuguese, translated from the English version of the list prepared by the Working Group on Country Names of the United Nations Conference on the Standardization of Geographical Names.

Provided, that the reservation of specific country and territory names may be released to the extent that Registry Operator reaches agreement with the applicable government(s), provided, further, that Registry Operator may also propose release of these reservations, subject to review by ICANNʹs Governmental Advisory Committee and approval by ICANN.












Registry Services
 





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



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.










Demonstration of Technical & Operational Capability
 





24. Shared Registration System (SRS) Performance



1. Introduction

Shared Registration System (SRS) is serviced through a NIC.br (Núcleo
de Informação e Coordenação do Ponto BR) proprietary implementation of
the EPP (Extensible Provisioning Protocol) standards. Itʹs based on
the software currently in use successfully for more than 5 years at a
2.8+ million domain names ccTLD (Country Code Top Level Domain)
Registry. 

2. Architecture

The plan for .UOL is to operate SRS in a clustered
environment, with the use of redundant load balancing hardware to
distribute load among multiple instances (initially 2 instances) of
EPP servers as shown in [Q24-diagram1].
 
3. High availability and performance

This architecture allows for continuous operation of the SRS in the
event of hardware failures or planned maintenance windows, while also
permitting easy service performance growth, by simply including
additional EPP server instances as needed.

In addition, the setup described in [Q24-diagram1] is replicated at a
cold standby secondary site, where service can be restored in up to 4
hours should a catastrophic event affect the primary site.

Past experience with the .br ccTLD Registry gives us confidence that
this initial setup can easily accommodate the amount of commands
estimated for the first 5+ years of operation, including the sunrise
period when there is an usual increase on registration demand.

Performance tests with 200 simultaneous clients reached an average of
400 domain registrations per second in an lab environment comprised of
EPP and database servers running on hosts with equivalent hardware
specifications planned for the production environment. This numbers
far exceed the expected load on regular operations.

During these performance tests, round-trip times (RTTs) of session,
query and transform commands averaged around 20 milliseconds on local
network. Even considering a scenario with RTTs of 500 milliseconds for
clients with very poor connectivity to our network, Service Level
Agreement (SLA) specified in the Registry Agreement can still be
easily honored. As a benchmark, RTTs for DNS queries sent from our
network to servers in the US West Coast is under 200 milliseconds, to
servers in Europe is around 210 milliseconds, and to servers in
Southeast Asia is around 320 milliseconds.

In order to minimize service disruptions caused by denial of service
attacks against our EPP servers, TCP connections to this service are
only allowed from previously registered IP addresses⁄ranges. TCP
connection attempts coming from unregistered addresses are silently
dropped.

4. Data synchronization

All transform operations are written to a centralized transactional
database server, which is asynchronously replicated to several
read-only database (DB) servers. These DB servers are used for
read-only services such as RDDS (Registration Data Directory Services)
and periodic reports in order to distribute the the Registryʹs DB work
load, keeping the primary master database server busy only with
services that require insert, update or delete grants or services that
require up-to-date data to work properly.

Although asynchronous, synchronization between the primary master
database server and each read-only database server is continuous,
having shown a delay of milliseconds most of the time.

5. Resourcing plan

.UOL back-end registry will be fully outsourced to NIC.br.

The EPP component of the Registry System is built on current NIC.br
infrastructure and acquisition of new server hardware. This combined
hardware system will be used for all NIC.br new gTLDs operations and
is detailed in response to question 32.

Initial hardware and software configuration setup and service
maintenance for all NIC.br new gTLD operations will be trusted to the
personnel who currently run the .br Registry operations: network,
system and software engineer teams composed of 12 engineers, along
with NIC.br 24x7 Network Operations Center (NOC).

These setup and operational costs are distributed among all NIC.br new
gTLDs operations as detailed in each Financial Projections as
Operating (Technical Labor and Operation of SRS) and Capital (Hardware
and Software) Expenditures.






25. Extensible Provisioning Protocol (EPP)



1 - Description

Extensible Provisioning Protocol (EPP) is a protocol that provides
means for the provisioning of domain operations between registries and
registrars. The communication is XML (eXtensible Markup Language)
based, which allows for easy integration and automation of the
process.

EPP is a standardized interface and all provisioning operations can be
done over it.

2 - What is supported

Our EPP implementation supports the following object mappings and
extensions:

* Domain Name Mapping (RFC5731 - Request For Comments)
* Contact Mapping (RFC5733)
* Transport Over TCP (Transmission Control Protocol) Extension (RFC5734)
* Domain Name System (DNS) Security Extensions Mapping (RFC4310)
* EPP Grace Period Mapping (RFC3915)
* Trademark Clearinghouse (TMCH) Mapping (TBD)

Host objects, as described in the Host Mapping (RFC5732), are not
supported as this registry operates name server information as domain
attributes. Coexistence of host objects and hosts as domain attributes
is prohibited by the EPP specifications as described in Section 1.1 of
RFC 5731:

ʺName server hosts for domain delegation can be specified either as
 references to existing host objects or as domain attributes that
 describe a host machine.  A server operator MUST use one name server
 specification form consistently.  A server operator that announces
 support for host objects in an EPP greeting MUST NOT allow domain
 attributes to describe a name server host machine.  A server operator
 that does not announce support for host objects MUST allow domain
 attributes to describe a name server host machine.ʺ

TMCH Mapping will be used for the Sunrise and Trademark Claims
periods. Implementation of this mapping is planned to begin as soon as
its EPP specifications are made available by the ICANN staff, the
Implementation Assistance Group (IAG), the selected Clearinghouse
provider or as a result of IETFʹs provreg working group.

There are two main objects that are subject to provisioning: domain
and contact.

3 - Commands

This section describes the commands used to handle the main objects.

3.1 - Contact

All commands described in the Contact Mapping (RFC5733) are
supported.

3.2 - Domain

Domain objects support all commands described in the EPP Domain
Mapping (RFC5731).

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

5 - Software

The server application is based on the NIC.br (Núcleo de Informação e
Coordernação do Ponto BR) EPP server that handles registration for .br
domains, handling over 2.8 million domains. It runs on multiple
machines to provide for fail-over redundancy.

This EPP server implementation was written in 2006 from scratch by
NIC.br developers team based on the initial EPP specification (Request
For Comments (RFC) 3730-3735) and has been following the EPP
specification updates ever since.

6 - Registrar technical accreditation

Registrars must pass a technical accreditation procedure to have
access to the EPP production interface. Accreditation procedure
consists of a pre-defined series of EPP commands that the Registrar
candidate must execute successfully.

Successful execution of all EPP Domain, Contact and RGP commands are
checked. In addition, to be approved in the accreditation procedure,
Registrars must be able to at least remove Delegation Signer (DS)
records from a domain name.

The DS removal requirement exists because a domain transfer request
may force the gaining Registrar to change the domain name to an
unsigned state.

7 - Resourcing plan

.UOL back-end registry will be fully outsourced to NIC.br.

The EPP component of the Registry System is built on current NIC.br
infrastructure and acquisition of new server hardware. This combined
hardware system will be used for all NIC.br new gTLDs operations and
is detailed in response to question 32.

Initial hardware and software configuration setup and service
maintenance for all NIC.br new gTLD operations will be trusted to the
personnel who currently run the .br Registry operations: network,
system and software engineer teams composed of 12 engineers, along
with NIC.br 24x7 Network Operations Center (NOC).

These setup and operational costs are distributed among all NIC.br new
gTLDs operations as detailed in each Financial Projections as
Operating (Technical Labor and Operation of SRS) and Capital (Hardware
and Software) Expenditures.






26. Whois



1. Description

The Whois service is provided by a NIC.br (Núcleo de Informação e
Coordernação do Ponto BR) implementation. It supports lookup
functionality for domains, user IDs and registrar data.

Service is available via port 43 in accordance with RFC 3912 (Request
For Comments), and as a web-based directory service at
whois.nic.UOL.


2. High availability and performance

To guarantee high availability of the service, it is redundant by
having different instances of the server software running on separate
machines behind a load balancer hardware. The [Q26-diagram1]
illustrates that topology:

With this architecture, availability of whois service is possible even
during partial hardware failures or system maintenance windows.

Requested data is fetched from a database server that is configured as
read-only and is kept synchronized with the main database through
replication. Although data replication is asynchronous,
synchronization delay between the primary master database server and
each read-only database server is continuous and is measured in terms
of milliseconds most of the time.

Performance tests carried out in a lab environment, which was
equivalent to the planned production hardware and software, gives us
confidence that the planned initial setup with 2 whois servers is able
to handle hundreds of simultaneous clients without negatively
affecting service performance.

During these performance tests, round-trip times (RTTs) of whois
queries averaged around 10 milliseconds on local network. Even
considering a scenario with RTTs of 500 milliseconds for clients with
very poor connectivity to our network, Service Level Agreement (SLA)
specified in the Registry Agreement can still be easily honored. As a
benchmark, RTTs for DNS queries sent from our network to servers in
the US West Coast is under 200 milliseconds, to servers in Europe is
around 210 milliseconds, and to servers in Southeast Asia is around
320 milliseconds.


3. Security

Even though the whois specification does not make strong provisions
for security, our implementation has a mechanism to help avoid abuse
by limiting the rate of queries per IP (Internet Protocol). For
instance, a limit could be set for the number of queries per 5 minute
period and⁄or queries per hour, and so on. Because this query rate
limit is based on the client IP address, the load balancer works in a
way that guarantees that queries originating from one client are
always directed to the same real server.

Since there may be some service providers and registrars that require
to make a significant amount of legitimate queries on our whois
server, there is the option of adding some IP addresses to a white
list. Additionally, there is also a black list where known abusers can
be included and therefore will no longer be allowed to send whois
queries.


4. Query⁄Response Examples

4.1 Domain Name Data

  4.1.1 Query format: whois example.UOL

  4.1.2 Response format:

   Domain Name: example.UOL
   Domain ID: d-123-tld
   Whois Server: whois.nic.UOL
   Creation Date: 2012-01-01 08:00:00
   Last Update Date: 2012-01-01 08:00:00
   Expiration Date: 2014-01-01 08:00:00
   Sponsoring Registrar ID: R-EXR-TLD
   Sponsoring Registrar Name: Example Registrar Ltda
   Domain Status: clientTransferProhibited
   Registrant ID: ABCDE-TLD
   Registrant Name: Example Registrant Org
   Registrant Organization: Example Registrant Org
   Registrant Street: 111 Example Street
   Registrant City: Example City
   Registrant State⁄Province: 
   Registrant Postal Code: 11111
   Registrant Country: BR
   Registrant Phone: +55.1155555555
   Registrant Phone Ext:
   Registrant Fax: 
   Registrant Fax Ext:
   Registrant Email: email@example.UOL
   Admin ID: XYYZZ-TLD
   Admin Name: Example Registrant Admin
   Admin Organization: Example Registrant Org
   Admin Street: 111 Example Street
   Admin City: Example City
   Admin State⁄Province: 
   Admin Postal Code: 11111
   Admin Country: BR
   Admin Phone: +55.1155555556
   Admin Phone Ext:
   Admin Fax: 
   Admin Fax Ext:
   Admin Email: email@example.UOL
   Tech ID: XYYZZ-TLD
   Tech Name: Example Registrant Tech
   Tech Organization: Example Registrant Org
   Tech Street: 111 Example Street
   Tech City: Example City
   Tech State⁄Province: 
   Tech Postal Code: 11111
   Tech Country: BR
   Tech Phone: +55.1155555556
   Tech Phone Ext:
   Tech Fax: 
   Tech Fax Ext:
   Tech Email: email@example.UOL
   Name server: ns1.exampleregistrar.UOL
   Name server check status: 2012-01-10 AA
   Name server last AA status: 2012-01-10
   Name server: ns2.exampleregistrar.UOL
   Name server check status: 2012-01-10 AA
   Name server last AA status: 2012-01-10
   DNSSEC: signed
   DS: 57436 RSA⁄SHA-1 CCB7D717A8868B8739A78FEC8FB60E62EBE2D89B
   DS check status: 2012-01-10 DSOK

4.2 Contact Data

  4.2.1 Query format: whois XYYZZ-TLD

  4.2.2 Response format:

   Contact ID: XYYZZ-TLD
   Contact Name: Example Registrant
   Contact Organization: Example Registrant Org
   Contact Street: 111 Example Street
   Contact City: Example City
   Contact State⁄Province: 
   Contact Postal Code: 11111
   Contact Country: BR
   Contact Phone: +55.1155555556
   Contact Phone Ext:
   Contact Fax: 
   Contact Fax Ext:
   Contact Email: email@example.UOL

4.3 Registrar Data

  4.3.1 Query format: whois R-EXR-TLD

  4.3.2 Response format:

   Registrar ID: R-EXR-TLD
   Registrar Name: Example Registrar Ltda
   Registrar Street: 222 Example Street
   Registrar City: Example City
   Registrar State⁄Province: 
   Registrar Postal Code: 22222
   Registrar Country: BR
   Registrar Phone: +55.1155555550
   Registrar Phone Ext:
   Registrar Fax: 
   Registrar Fax Ext:
   Registrar Email: email@exampleregistrar.UOL
   Registrar Whois Server: whois.exampleregistrar.UOL
   Registrar URL: http:⁄⁄www.exampleregistrar.UOL
   Admin ID: EXREG-TLD
   Admin Name: Example Registrar Admin
   Admin Organization: Example Registrar
   Admin Street: 111 Example Street
   Admin City: Example City
   Admin State⁄Province: 
   Admin Postal Code: 11111
   Admin Country: BR
   Admin Phone: +55.1155555556
   Admin Phone Ext:
   Admin Fax: 
   Admin Fax Ext:
   Admin Email: email@exampleregistrar.UOL


4.4 Nameserver Data

  This query is not supported because hostnames are mapped as domain
  attributes.


5. Bulk Registration Data Access to ICANN (Internet Corporation for
   Assigned Names and Numbers)

  A weekly report on all registered domain names and sponsoring
  registrars will be made available to ICANN. This report will contain
  a subset of the Data Escrow Records and be formatted according to
  the Data Escrow Format Specification, as specified in the new .UOL
  TLD (Top Level Domain) Agreement.

  A Data Escrow formatted file reporting all domain names of a given
  registrar will also be made available at ICANN request.


6. Resourcing plan

.UOL back-end registry will be fully outsourced to NIC.br.

The Whois component of the Registry System is built on current NIC.br
infrastructure and acquisition of new server hardware. This combined
hardware system will be used for all NIC.br new gTLDs operations and
is detailed in response to question 32.

Initial hardware and software configuration setup and service
maintenance for all NIC.br new gTLD operations will be trusted to the
personnel who currently run the .br Registry operations: network,
system and software engineer teams composed of 12 engineers, along
with NIC.br 24x7 Network Operations Center (NOC).

These setup and operational costs are distributed among all NIC.br new
gTLDs operations as detailed in each Financial Projections as
Operating (Technical Labor and Operation of SRS) and Capital (Hardware
and Software) Expenditures.






27. Registration Life Cycle



1 - Registration Life Cycle

All registration life cycle is done using the Extensible Provisioning
Protocol (EPP) interface (described in question 25). The state diagram
[Q27-diagram1] describes the registration life cycle. Each state is
described in the following sections.

1.1 - Request a domain

In order to register a domain the registrant must make request for a
domain and fulfill some requirements. This includes having at least
two fully functional authoritative nameservers for the domain.

After the domain is created, it is put in a serverHold status, not being
published until all pendencies are solved.

1.2 - Solve pendencies

The main pre-requisite for a domain to be registered is to have valid
Domain Name System (DNS) authoritative servers. During the serverHold
period, the registrar is notified via EPP poll messages.

There can also be other types of pendencies specific to the .UOL
gTLD (Generic Top Level Domain), such as some restrictions on the type
of registrant that are eligible for the domain. In those cases the
approval for the domain registration will be granted via out of band
channel.

1.3 - Domain is published

Once all pendencies are solved the domain is published. This is done
by a service that runs periodically. The domain is published within 10
minutes at most.

2 - Domain renewal

Registrar must renew the domain manually via EPP command. If the
registrar does not renew the domain, it will be cancelled according to
the schedule described in section 4.


3 - Domain transfer

Domain transfers between registrars are allowed via EPP command as
long as domain status permits. The registrant must first contact the
current registrar, asking for the transfer token, which must then be
passed to the new registrar, so that the request can be made.

Upon receipt of the transfer request, the Registry system immediately
queues a service message for retrieval via the EPP poll command. From
this point in time, the current sponsoring client has up to 5 days to
approve or reject the transfer. At any time in this period of 5 days,
and provided that the request has not yet been approved or rejected,
it is possible for the registrant to cancel the domain transfer
request.

If no subsequent transfer request operation is received by the
Registry system after 5 days, itʹs automatically approved and service
messages for both Registrars are queued for retrieval via EPP poll
command.

4 - Domain removal

In case the owner no longer wants to keep the domain, they can remove
the domain at any time using the domain delete command, making it
available to be registered again by anyone else.

The domain is also removed if the registration is not renewed. In
this case the domain is put in a status of serverHold, one week after
its expiration date, which means it stops being published.

If the registrar wants to keep the domain, they can opt to renew it
and the domain will be published again. Otherwise the domain is
removed.

5 - Resourcing plan

.UOL back-end registry will be fully outsourced to NIC.br.

The Registry System is built on current NIC.br infrastructure and
acquisition of new server hardware. This combined hardware system will
be used for all NIC.br new gTLDs operations and is detailed in
response to question 32.

Initial hardware and software configuration setup and service
maintenance for all NIC.br new gTLD operations will be trusted to the
personnel who currently run the .br Registry operations: network,
system and software engineer teams composed of 12 engineers, along
with NIC.br 24x7 Network Operations Center (NOC).

These setup and operational costs are distributed among all NIC.br new
gTLDs operations as detailed in each Financial Projections as
Operating (Technical Labor and Operation of SRS) and Capital (Hardware
and Software) Expenditures.






28. Abuse Prevention and Mitigation



.uol Registrant Data (WHOIS) Policy:

As a closed registry, .uol registrant data shall always be real and valid information of the organizations that register a .uol domain, which will be UBN INTERNET, Universo Online S.A. or an affiliate of Universo Online S.A. Persons cannot register domains on .uol.

All registrant data will be verified off-line prior to a domain registration being completed. If requested by UBN INTERNET the registrant shall provide certified documents and or updated data in order to maintain WHOIS accuracy. Failing to provide timely responses for documents or data update requests can cause suspension (defined as the removal of domain publication within the DNS system) or cancelation of the domain.

Registration implies agreeing with legally-binding responsibilities for the domain; such responsibilities cannot be transferred to a third party without transferring the domain itself and such transaction reflected in the WHOIS data. WHOIS privacy or proxy services are  not allowed and not recognized; domains registered in the name of an organization will be considered to belong to such organization. 

.uol Prevention of Abuse Policy:

ʺThe registrant agrees to use the .uol domain being registered or renewed only for lawful and non-abusive purposes, including respecting trademark rights of Universo Online S.A. for the UOL mark. 

 UBN INTERNET defines abuse as the bad, wrongful or excessive use of privileges or power including but not limited to:
- Botnet command and control (a command and control infrastructure to manage a group of infected computers that receives orders from unauthorized users(s) through the network) ;
- Child entrapment or abuse ;
- Distribution of child pornography ;
- Deployment of circular references within the Domain Name System (DNS) using resources of UBN INTERNET, Universo Online S.A., NIC.br and⁄or other Top Level Domains (TLDs) ;
- Fast flux hosting (rapidly changing DNS records in order to prevent detection or mitigation of an abuse);
- Phishing (unsolicited communication or Web page that poses as being from a known institution to trick users into disclosing personal, privileged or financial data);
- Sending unsolicited bulk messages thru electronic mail, forums, instant messaging, mobile messaging,  social networks or comment boxes ; 
- Theft of any online service ;
- Unlawful or fraudulent actions ;
- Willful distribution of malware (any kind of software that executes malicious action on a computer system, like virus, worms, bots, trojan horses and root kits).ʺ
ʺ


----------------------------------

Abuse handling procedures:


Abuse detection procedures will be available by the an e-mail box abuse@nic.uol to receive abuse complaints. All abuse complaints will be considered to be possible breaches of contract and evaluated by UBN INTERNET abuse desk, possibly referring cases to UBN INTERNET legal department.

Target service-level for abuse and take action complaints is to set a course of action within one business day for all complaints. Staffing for this system is already part of UBN INTERNET abuse desk. Abuse and take action complaints from law enforcement will be given priority and skip queues. 

-----------

.uol Take Action procedures:

ʺFor each abuse case one or more of these actions might apply:
- Remove DNS publication of the domain in cases where domain appears as only being used to exploit phishing, malware, bonnet command and control, fast-flux hosting, DNS circular references, child pornography distribution, child abuse and entrapment; 
- Notice of abusive case to registrant ;
- Notice of abusive case to registrar ;
- Notice of abusive case to hosting provider(s) ;
- Notice of abusive case to appropriate computer incident response team ;
- Notice of abusive case to appropriate law enforcement authorities. 

Preemptive measures like removing DNS publication will only be done to prevent further damages to the Internet community or endangered individuals and will have collateral damages of such actions assessed prior to reaching such a decision.ʺ


------------------------

.uol prevention of abusive transfer and⁄or cancellation:

All .uol domains wonʹt accept change of ownership or cancellation without authorization from proper UBN INTERNET corporate officials. 

-------------------

Measures for dealing with glue records: 
Internet Protocol (IP)  address is this context refer to both IPv4 or IPv6 regardless of IP protocol version

- Host records wonʹt be allowed outside of domain objects. Glue records are only allowed as domain attributes and only allowed to be in-zone glue records (i.e, ns.example.uol for a example.uol domain)
- When a domain is removed from publication all of its glue records are also removed, so no orphan glue records can exist. 
- When a domain is registered the supplied DNS servers are tested to validate proper authoritative response; the registration transaction requires previous DNS configuration. This prevents amplification attacks that could arise by setting DNS glue records to victim IP addresses. 
- If an IP address used to be a DNS server moves to a new delegated organization there might be undesirable traffic towards that address. Take action notices for such glue records, even they are not orphaned, will be accepted from the RIR(Regional Internet Registry) registered WHOIS contact for that address space. 
- As only in-zone non-orphan glue records are allowed, any evidence of a glue record being part of malicious conduct will be considered as malicious conduct of the domain it belongs to and will subject such a domain to anti-abuse or take action policies.  






29. Rights Protection Mechanisms



.uol rights protection mechanisms will encompass a series of proactive and reactive measures. On the proactive side, the fact that registrations need to be approved off-line prior to a domain registration being completed allows UBN Internet Ltda. (UBN) to validate both registrant data and to perform validation by UBN legal department that to the best of UBNʹs knowledge the domain does not violate rights that are recognized in the Brazilian juridisction (Brazil currently enforces Berne Convention, Nairobi Treaty, Paris Convention, Patent Cooperation Treaty, Phonograms Convention, Rome Convention, Strasbourg Agreement, UPOV Convention and WIPO Convention - TRIPS). At a minimum well-known marks that have notoriety will be taken into account while analyzing the registration request, but UBN reserves the right to further search available marks databases. 

During pre-launch phase, there will be a 30-day sunrise period where only Universo Online S.A or its affiliates will be allowed to register domains. During this sunrise period, the Trademark Clearing House sunrise services will be used and only organizations with ownership of a mark (which can be a Trademark Clearinghouse-validated word mark, a court-validated word mark or an specifically statute⁄treaty protected word) accompanied with sufficient data to document these rights, and representation that all provided information is true and correct. 

After launch, during the first 60 days that registrations are possible by all eligible .uol registrants (which would at that point still be limited to Universo Online S⁄A affiliates and will keep this way throughout the duration of .uol agreement), the Trademark Clearing House Trademark Claims services will be used to provide prospective registrants notice of the presence of a match on the Trademark Clearinghouse database, and to require that the prospective registrant acknowledges being notified, receiving, understanding and disclosing that to the best of the prospective registrant knowledge the registration and use of the requested domain name will not infringe  rights that were subject of the notice. 

Besides proactive rights protection mechanisms afore mentioned, post-registration rights protection mechanisms in .uol will include URS (Uniform Rapid Suspension) and PDDRP (Post-Delegation Dispute Resolution Procedure). URS and PDDRP shall be part of UBN registry agreement with ICANN, working with ICANN-appointed dispute resolution providers. In addition to such dispute resolution providers, every rights owner can initiate free of charge equivalent procedures with UBN legal department by use of the e-mail contacts urs@nic.uol and pddrp@nic.uol. UBN encourage rights owners to use these channels so mutually satisfactory solutions might be reached with less financial burden, although ICANN-appointed dispute resolution providers will still be available and determinations from them will be followed according to registry agreement. 

Resourcing for these protections mechanisms include technical resources of NIC.br (back-end registry provider for .uol) to connect to the Trademark Clearinghouse, which are part of the outsourced TLD operation contract,  financial resources of UBN to pay for the connection for the Trademark Clearinghouse, and the personnel resources of UBN legal staff. The very low volume of issues with such a restricted registry and the potential implications lead UBN to the decision of handling rights protections issues with its current staff of [ ] lawyers, with one of them assigned to this task in a non-exclusive capacity at any given time. 

Additional measures that also contribute to rights protection are the .uol registrant data (WHOIS) policy, prevention of abuse policy, abuse handling procedures, take action procedures, prevention of abusive transfer⁄cancelation and glue records management, detailed below. 

.uol Registrant Data (WHOIS) Policy:

As a restricted registry, .uol registrant data shall always be real and valid information of the organizations that register a .uol domain, which will be UBN INTERNET, Universo Online S.A. or an affiliate of Universo Online S.A. Persons cannot register domains on .uol.

All registrant data will be verified off-line prior to a domain registration being completed. If requested by UBN INTERNET the registrant shall provide certified documents and or updated data in order to maintain WHOIS accuracy. Failing to provide timely responses for documents or data update requests can cause suspension (defined as the removal of domain publication within the DNS system) or cancelation of the domain.

Registration implies agreeing with legally-binding responsibilities for the domain; such responsibilities cannot be transferred to a third party without transferring the domain itself and such transaction reflected in the WHOIS data. WHOIS privacy or proxy services are  not allowed and not recognized; domains registered in the name of an organization will be considered to belong to such person or organization. 

.uol Prevention of Abuse Policy:

ʺThe registrant agrees to use the .uol domain being registered or renewed only for lawful and non-abusive purposes, including respecting trademark rights of Universo Online S.A. for the UOL mark. 

 UBN INTERNET defines abuse as the bad, wrongful or excessive use of privileges or power including but not limited to:
- Botnet command and control (a command and control infrastructure to manage a group of infected computers that receives orders from unauthorized users(s) through the network) ;
- Child entrapment or abuse ;
- Distribution of child pornography ;
- Deployment of circular references within the Domain Name System (DNS) using resources of UBN INTERNET, Universo Online S.A., NIC.br and⁄or other Top Level Domains (TLDs) ;
- Fast flux hosting (rapidly changing DNS records in order to prevent detection or mitigation of an abuse);
- Phishing (unsolicited communication or Web page that poses as being from a known institution to trick users into disclosing personal, privileged or financial data);
- Sending unsolicited bulk messages thru electronic mail, forums, instant messaging, mobile messaging,  social networks or comment boxes ; 
- Theft of any online service ;
- Unlawful or fraudulent actions ;
- Willful distribution of malware (any kind of software that executes malicious action on a computer system, like virus, worms, bots, trojan horses and root kits).ʺ
ʺ


----------------------------------

Abuse handling procedures:


Abuse detection procedures will be available by the an e-mail box abuse@nic.uol to receive abuse complaints. All abuse complaints will be considered to be possible breaches of contract and evaluated by UBN INTERNET Information Security team, possibly referring cases to UBN INTERNET legal department.

Target service-level for abuse and take action complaints is to set a course of action within one business day for all complaints. Staffing for this system is already part of UBN INTERNET Information Security team. Abuse and take action complaints from law enforcement will be given priority and skip queues. 

-----------

.uol Take Action procedures:

ʺFor each abuse case one or more of these actions might apply:
- Remove DNS publication of the domain in cases where domain appears as only being used to exploit phishing, malware, bonnet command and control, fast-flux hosting, DNS circular references, child pornography distribution, child abuse and entrapment; 
- Notice of abusive case to registrant ;
- Notice of abusive case to registrar ;
- Notice of abusive case to hosting provider(s) ;
- Notice of abusive case to appropriate computer incident response team ;
- Notice of abusive case to appropriate law enforcement authorities. 

Preemptive measures like removing DNS publication will only be done to prevent further damages to the Internet community or endangered individuals and will have collateral damages of such actions assessed prior to reaching such a decision.ʺ


------------------------

.uol prevention of abusive transfer and⁄or cancellation:

All .uol domains wonʹt accept change of ownership or cancellation without authorization from proper UBN INTERNET corporate officials. 

-------------------

Measures for dealing with glue records: 
Internet Protocol (IP)  address is this context refer to both IPv4 or IPv6 regardless of IP protocol version

- Host records wonʹt be allowed outside of domain objects. Glue records are only allowed as domain attributes and only allowed to be in-zone glue records (i.e, ns.example.uol for a example.uol domain)
- When a domain is removed from publication all of its glue records are also removed, so no orphan glue records can exist. 
- When a domain is registered the supplied DNS servers are tested to validate proper authoritative response; the registration transaction requires previous DNS configuration. This prevents amplification attacks that could arise by setting DNS glue records to victim IP addresses. 
- If an IP address used to be a DNS server moves to a new delegated organization there might be undesirable traffic towards that address. Take action notices for such glue records, even they are not orphaned, will be accepted from the RIR(Regional Internet Registry) registered WHOIS contact for that address space. 
- As only in-zone non-orphan glue records are allowed, any evidence of a glue record being part of malicious conduct will be considered as malicious conduct of the domain it belongs to and will subject such a domain to anti-abuse or take action policies.  







30(a). Security Policy: Summary of the security policy for the proposed registry



A - Security Policy 

1 - Purpose 
  The purpose of this policy is to establish management direction, procedural requirements, and technical guidance to ensure the appropriate protection of data, servers, applications, network access, personnel access and systems about outsourced registry services by NIC.br (Núcleo de Informação e Coordenação do Ponto BR)

2 - Scope 
  This policy overview applies to all employees, contractors, consultants, temporaries, volunteers and other workers at NIC.br, including those workers affiliated with third parties who access NIC.br computer networks. Throughout this policy, the word ʺworkerʺ will be used to collectively refer to all such individuals. The policy also applies to all computer and data communication systems owned by or administered by NIC.br
  This policy must be extended to all NIC.br backup sites.

3 - Roles and Responsibilities
 
    The Information Security manager is responsible for establishing, maintaining, implementing, administering, and interpreting organization-wide information systems security policies, standards, guidelines, and procedures. 

    The Information Security Departmentʹs mission is to evaluate information security vulnerabilities and implement technologies, procedures, and  guidelines to ensure that appropriate level of confidentiality,  integrity, and availability of all information assets are maintained.
     
    Users are responsible for complying with this and all other NIC.br policies defining computer and network security measures. 

4 - System Access Control

    All computers permanently or intermittently connected on NIC.br networks and contain non-public information must have password access controls and servers and network equipments must be access using encrypted channel, from network restricted and secure and must reject any type of connection from Internet Network instead any public service. 

    Users must choose fixed passwords that are difficult to guess, passwords must not be related to a userʹs bio or personal life and must not be a word found in the dictionary or some other part of speech. Passwords must not be stored in readable form in batch files, or in other locations where unauthorized persons might discover them. Passwords must not be written down and left in a place where unauthorized persons might discover them. Every user must have a single unique user ID and a personal secret password to access NIC.br multi-user computers and networks. 

    Users must not store clear-text authentication credentials on portable computers, personal digital assistants, or smart phones. Likewise, these security parameters should never be stored anywhere on these devices unless they are in encrypted form.
    
    Users must be responsible for all activity performed with their personal user IDs and must not permit others to perform any activity with their user IDs, and they must not perform any activity with IDs belonging to other users.
    
    Workers must not use an electronic mail account assigned to another individual to either send or receive messages.

    Workers must not use NIC.br information systems to engage in hacking activities, but are not limited to gaining unauthorized access to any other information systems, damaging, altering, or disrupting the operations of any other information systems, and capturing or otherwise obtaining passwords, encryption keys, or any other access control mechanism that could permit unauthorized access. Workers who have been authorized to view information non-public must be permitted by Information Security Department.

    When a worker leaves any position with NIC.br, computer-resident files must be promptly reviewed by his or her immediate manager to reassign the workerʹs duties and specifically delegate responsibility for the files formerly in the workerʹs possession.

5 - Data Backups

    All files and messages stored on NIC.br systems are routinely copied to tape, disk, and other storage media and must be recoverable for potential examination at a later date by Systems Administrators and others designated by management and maintained on off-line data storage media wherever production computers are located.

    Essential business information and software backups must be stored in an environmentally protected and access-controlled site that is a sufficient distance away from the originating facility.

    Unless they have a closing mechanism that is triggered by a fire alarm, all areas where backup media is stored including, but not limited to, fireproof computer backup storage rooms, vaults, and cabinets must be kept fully closed when not in active use.

    Users must not copy software provided by NIC.br to any storage media, transfer such software to another computer, or disclose such software to outside parties without advance permission from their supervisor. Ordinary backup copies are an authorized exception to this policy.

    All media on which sensitive, valuable, or critical information is stored for periods longer than six months must not be subject to rapid degradation.

    Secret information that is no longer needed for business activities must be immediately destroyed with methods specified by the Information Security Department. Information which is non-public, must be placed in a designated locked destruction container within NIC.br offices and never placed in trash bins, recycle bins, or other publicly-accessible locations and when non-public NIC.br information is erased from a disk, tape, or other reusable data storage media, it must be followed by a repeated overwrite operation to obliterate the sensitive information.

6 - Monitoring 

    Systems must be monitored and information security events must be recorded.
    Operator logs and fault logging must be used to ensure information system problems are identified. 
    System monitoring must be used to check the effectiveness of controls adopted and to verify conformity to an access policy model.

    Audit logs recording user activities, exceptions, all production application systems that handle sensitive NIC.br information and information security events should be produced and kept for an agreed period to assist in future investigations and access control monitoring.
 
    All computer systems, servers and network equipment running NIC.br production application systems must include logs that record, at a minimum, user session activity including user IDs, successful or not logon date and time, logoff date and time, changes to critical application system files, changes to the privileges of users, and system start-ups and shut-downs. Users must be clearly informed about the actions that constitute security violations as well as informed that all such violations will be logged.

    To prevent the overwriting of system logs or the expansion of these logs to the point where they consume all available disk space, a formal log rotation and archival storage process must be employed for all multi-user production servers.
      
    Computerized logs containing security relevant events must be retained for an agreed period, during which time they must be secured such that they cannot be modified.

    Procedures for monitoring use of information processing facilities should be established and the results of the monitoring activities reviewed regularly.

    All user ID creation, deletion, privileged commands and privilege change activity performed by Systems Administrators and others with privileged user IDs must be securely logged.
 
    Computer operations staff or information security staff must review records reflecting security relevant events on all production multi-user machines in a periodic and timely manner.

    Tools for the monitoring or observation of computer user activities must not be used unless the involved users are notified that their work may be monitored or observed, exception involves use of the tools for investigations of suspected policy violations and⁄or criminal activity.
      
    All multi-user computers connected to the NIC.br internal network must always have the current time accurately reflected in their internal clocks.


7 - Network Security 
  
    Management design NIC.br communications networks so that no single point of failure could cause network services to be unavailable, so that critical communications may immediately be sent through multiple long distance carriers over physically diverse routes and all carrier must be oversized.

    Configurations and set-up parameters on all hosts attached to the NIC.br network must comply with in-house security policies and standards.

    All connections between NIC.br internal networks and the Internet, or any other publicly-accessible computer network, must include a firewall and related access controls approved by the Information Security Department.

    Remote management facilities for NIC.br firewalls must consistently employ session encryption, remote machine address restrictions, as well as a form of extended user authentication approved by the Information Security Manager and All NIC.br firewalls connecting to the Internet must be configured so that every Internet service is disabled by default, with only those services enabled that have been specifically approved by the Information Security Manager.

    Firewall configuration updates must be documented and notified to Information Security Department.

    Public Internet servers must be placed on sub nets, separate from internal NIC.br networks, and to which public traffic is restricted by routers and⁄or firewalls.

8 - Registry Updates

    Registry updates must be saved to a database system and must be periodically distributed to the authoritative name servers. To ensure integrity of data on each of the name servers, all zones transfers must use TSIG (Transaction SIGnature), which relies on a shared secret between the two parts of the transfer.
  Authoritative name servers must not accept any zone transfer nor notification that does not meet this requirement.

  All authoritative name servers must work independently from one another. All zone transfers must be originated from one single hidden master server, where the zone is generated.


9 - Physical access

    Access to every office, computer machine room, and other NIC.br work area containing sensitive information must be physically restricted to those people with a need to know. When not in use, sensitive information must always be protected from unauthorized disclosure and must be equipped with riot doors, fire doors, and other doors resistant to forcible entry, must be controlled by guards, receptionists, or other staff. During non-working hours areas containing sensitive information must lock-up all information.

    All NIC.br data center facilities, power supply facilities, corridors, and entry points including, but not limited to, primary & secondary entrances, maintenance entrance, emergency exits, and loading docks must be monitored by security cameras.
    
    Access points such as delivery and loading areas and other points where unauthorized persons may enter the premises must be controlled and, if possible, isolated from information processing facilities to avoid unauthorized access.

    Security cameras used on NIC.br premises must be placed so that they do not capture fixed passwords, telephone numbers, credit card numbers, encryption keys, or any other fixed security parameters. All exceptions must be approved, in advance, by the Physical Security Manager.

    When in NIC.br secure buildings or facilities, all persons must wear an identification badge on their outer garments so that both the picture and information on the badge are clearly visible to all people with whom the wearing converses and must present his or her badge to the badge reader before entering every controlled door within NIC.br premises.

    The Security Department must maintain records of the persons currently and previously inside NIC.br buildings and securely retain this information for agreed period.

    Visitors who do not need to perform maintenance on NIC.br equipment, or who do not absolutely need to be inside the Data Center or Information Systems Department, must not enter these areas.
  
    The main computer center must be staffed at all times by technically-competent staff 24 hours a day, seven days a week, 365 days a year.

    Telephone closets, network router and hub rooms, voice mail system rooms, and similar areas containing communications equipment must be kept locked at all times and not accessed by visitors without an authorized technical staff escort to monitor all work being performed.

    All multi-user production computer systems including, but not limited to, servers, firewalls, private branch exchange (PBX) systems, and voice mail systems must be physically located within a secure data center.

    Local management must provide and adequately maintain fire detection and suppression, power conditioning, air conditioning, humidity control, and other computing environment protection systems in every NIC.br computer center.

    NIC.br must segment its data processing centers into two distinct and physically isolated data centers, each able to handle all critical production information systems services. These data centers must not share the same local electric company substation or the same telephone company central office.

    All NIC.br computer centers must be equipped with fire, water, and physical intrusion alarm systems that automatically alert those who can take immediate action.

10 - During Employment

    Responsibility for information security on a day-to-day basis is every workerʹs duty. Specific responsibility for information security is NOT solely vested in the Information Security Department.
  
    Users must not accept any form of assistance to improve the security of their computers without first having the provider of this assistance approved by the NIC.br Information Security Department. This means that users must not accept offers of free consulting services, must not download free security software via the Internet, and must not employ free security posture evaluation web pages, unless the specific provider of the assistance has been previously approved.

    Sexual, ethnic, and racial harassment--including unwanted telephone calls, electronic mail, and internal mail--is strictly prohibited and is cause for disciplinary action including termination. Managers must make this policy clear to the workers in their group, as well as promptly investigate and rectify any alleged occurrences.

    As a condition of a continued working relationship with NIC.br, all workers must read, understand, and behave in accordance with the organizational code of conduct.

11 - Network Access Control
  
    All NIC.br internal data networks must be divided into security zones and Any wireless network must be isolated from registry network or any server used on registry process.

12 - Systems security
  
    All software updates must be made first on development environment before being applied on production servers.
    Security updates must be applied up to 48 hours after the release of the software update.

    Secure coding principles and practices must be used for all software developed or maintained by NIC.br.














© Internet Corporation For Assigned Names and Numbers.