ICANN New gTLD Application

New gTLD Application Submitted to ICANN by: Núcleo de Informação e Coordenação do Ponto BR - NIC.br

String: bom

Originally Posted: 13 June 2012

Application ID: 1-1119-71934


Applicant Information


1. Full legal name

Núcleo de Informação e Coordenação do Ponto BR - NIC.br

2. Address of the principal place of business

Av Nacoes Unidas 11541
7o. andar
Sao Paulo Sao Paulo 04578000
BR

3. Phone number

+55 11 5509 3500

4. Fax number

+55 11 5509 3501

5. If applicable, website or URL

http:⁄⁄www.nic.br

Primary Contact


6(a). Name

Mr. Rubens Henrique Kuhl Junior

6(b). Title

Product Marketing Manager

6(c). Address


6(d). Phone Number

+55 11 5509 3559

6(e). Fax Number

+55 11 5509 3501

6(f). Email Address

rhkuhl@registro.br

Secondary Contact


7(a). Name

Mr. Frederico Augusto de Carvalho Neves

7(b). Title

Chief Technology Officer

7(c). Address


7(d). Phone Number

+55 11 5509 3505

7(e). Fax Number

+55 11 5509 3501

7(f). Email Address

facneves@registro.br

Proof of Legal Establishment


8(a). Legal form of the Applicant

Not-for-profit Association

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

Brazilian Law No. 9790 of 23⁄03⁄1999 about non-profit private organizations and New Brazilian Civil Code of 2002

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.


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

Alexandre Annenberg NettoBoard member
ANTONIO ALBERTO VALENTE TAVARESChairman of the board
AUGUSTO CÉSAR GADELHA VIEIRABoard member
MARCELO BECHARA DE SOUZA HOBAIKABoard member
Marcelo Fernandes CostaBoard member
NELSON SIMÕES DA SILVABoard member
Rogério Santanna dos SantosBoard member

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

Demi GetschkoChief Executive Officer
Frederico Augusto de Carvalho NevesChief Technology Officer
Milton Kaoru KashiwakuraChief Research Officer
Ricardo NarchiChief Financial Officer

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


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.

bom

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.


We have a positive thinking of life. For us the weather is beautiful even when it rains, people should be always happy and the human being in harmony with the nature… For us the glass is always half full! This is because we always look to the good side of the life and this good side is what we want to promote in the new generic top level domain .bom*.

Everything that you could think about has a good side when aggregated with bom (good) word. A simple man can be excellent as a good man, another person can be have quality in if has a good health or a news can be extreme favorable when it comes as a good news. Indeed, the applications for bom*⁄good can be infinities.

Spreading the .bom (good) across the web we will contribute to a better Internet. We will promote everything what is good… Good food, good shoes, good living and even good brands. The .bom (good) domain will be a prefix of those good products, services and, why not, styles.

.bom (good) will be the new naming standard in Brazil (or other lusophone countries for everything we and our clients find good.

* Bom is the Portuguese translation for ʺGoodʺ.

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

With the .bom gTLD we plan to identify the products, services and websites that has something good in the positive thinking way of life.

Our clients can request a domain .bom registration and promote its ʺgood goodsʺ whether they are products, services or messages. Of course, what is good for one is not good to another, but the self promotion of .bom (good) should be really good for the mainstream.

As NIC.br is a frequently consulted organization by the media and itʹs domain registration website for .br ranks #59 in Alexaʹs ranking for Brazil, publicity will be used to reach out to the intended audiences to help .bom achieve recognition as the way to say something is good.

.bom will be standing on the shoulders of the .br registry, carrying its widely known reputation and service-levels that made it the registry of choice of the vast majority of brazilian Internet presence.

Registration will be open to all law-abiding citizens or organizations to perform lawful and non-abusive activities using such domains, with registrations periods from 1 to 10 years.

As registrants identities will be disclosed thru WHOIS interfaces, contact information for persons will be abridged in the results to protect their privacy. Contact information for organizations will be published in full.

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

After sunrise periods, when auctions will determine registrants of high demand names, .bom will operate on a first-come⁄first-serve model. Abuse response and rights protection mechanisms, as described in more detail in other parts of this application, will be in place in order to keep .bom a truly good part of the Internet namespace.

Advantageous pricing will be offered for multiple years registration, with additional years costing from 90% to 80% of a single-year registration.

Although we target a stable pricing model, we reserve the right to change prices (either up or down) following registry agreement requirements such as providing advance communication of pricing changes.

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 .BOM 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 Tranport 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 〈ND_GTLD〉.zone.tar.

Registry Operator shall provide bulk access to the zone files for the
.BOM 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. An IDN domain is
mapped to an ASCII string removing diacritical marks in order to
consider IDN and ASCII domains for equivalence. Equivalent domains can
only be registered by the same registrant in order to avoid homograph
attacks.

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


5. Provision of status information relating to the zone, registration
and WHOIS servers for the .BOM 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 .BOM 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 .BOM 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

.BOM registry functions will be performed by NIC.br own internal
systems based on its current .br operation, with some added resources
to operate new gTLDs.

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

.BOM registry functions will be performed by NIC.br own internal
systems based on its current .br operation, with some added resources
to operate new gTLDs.

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


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

4.1.2 Response format:

Domain Name: example.BOM
Domain ID: d-123-tld
Whois Server: whois.nic.BOM
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.BOM
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.BOM
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.BOM
Name server: ns1.exampleregistrar.BOM
Name server check status: 2012-01-10 AA
Name server last AA status: 2012-01-10
Name server: ns2.exampleregistrar.BOM
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.BOM

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.BOM
Registrar Whois Server: whois.exampleregistrar.BOM
Registrar URL: http:⁄⁄www.exampleregistrar.BOM
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.BOM


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

.BOM registry functions will be performed by NIC.br own internal
systems based on its current .br operation, with some added resources
to operate new gTLDs.

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. The
registrar is charged for the domain creation.

Add grace period is complaint with RFC3915 and is of 5 days from the
domain creation. During this period, the registrar can request to
cancel up to 5% of the registered domains in that period. In those
cases the registrar will be refunded 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.


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.

If the registrar doesnʹt have enough credit the domain is not renewed.

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 registrar doesnʹt have enough credit
or if itʹs 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.

The redemption grace period is compliant with RFC3915 and is of 5 days
counted from the date of the domain removal. During this period, the
registrar can request to recover the domain at no cost.

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

.BOM registry functions will be performed by NIC.br own internal
systems based on its current .br operation, with some added resources
to operate new gTLDs.

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

For domain transactions made through registrars, the following clauses shall be part of the registry-registrar agreement and stipulate mandatory specifications to be shown to the registrant and to be agreed to by the registrant. 

.BOM Registrant Data (WHOIS) Policy:

ʺThe registrant shall provide and update the required personal data and⁄or business data so they always reflect real and valid information. Use of false, invalid, incorrect or data belonging to a third party can invalidate the contract and incur cancelation of the domain, besides law-defined penalties and liabilities. If requested by ʺNúcleo de Informação e Coordenação do Ponto BR - NIC.brʺ, either directly or through a registrar, the registrant shall provide certified documents and or update 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.

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 (individual) or CNPJ (organization). This document must also be valid according to the brazilian
internal revenue service.

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. Domains registered in the name of a person or an organization will be considered to belong to such person or organization, so registrants need to carefully consider if proxy services could bring ownership risks to them. ʺ



.BOM Prevention of Abuse Policy:

ʺThe registrant agrees to use the .BOM domain being registered or renewed only for lawful and non-abusive purposes.
NIC.br 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 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 include:
- An e-mail box abuse@nic.BOM to receive abuse complaints ;
- A web form to receive abuse or take action complaints ;
- An optional anonymized web form to receive take action complaints that can be verified by NIC.br with no corroboration ;
- Automated analysis of malware and phishing URL feeds including both public sources and association sources. NIC.br, thru its security area called CERT.br, is a member of the Anti-Phishing Working Group (APWG); the SpamPots project; the brazilian honeypot consortium organizations; FIRST (Forum of Incident Response and Security Teams) and a few research projects with brazilian universities. Results of automated analysis or information gathering generate abuse cases that will be dealt manually.
- A ticketing system to integrate, measure the service-level and manage the complaints from all three ways above.

Target service-level for abuse and take action complaints is to set a course of action within 30 minutes for 50% of the complaints, up to 8 hours for 75% of the complaints and up to 24 hours for 99% of the complaints. Staffing for this system will include at least 1 full-time employee (registry security officer) and operation center analysts for coverage during the night shifts and will be shared among all TLDs (Top-Level Domains) managed by NIC.br, including but not limited to .BOM and .br. Abuse and take action complaints from law enforcement will be given priority and skip queues.

-----------

.BOM Take Action procedures:

ʺAs soon an abuse issue is found, in all cases an administrative procedure will be started to verify documentation of the registrant if none has been received before. For each 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.ʺ


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

.BOM prevention of abusive transfer and⁄or cancellation:

Transfer tokens will be required to perform domain transfers; registrars will be encouraged to validate the transfer or cancellation through secondary channels. Frequent occurrence of abusive transfer and⁄or cancellations at an specific registrar can trigger a compliance investigation by NIC.br and sending of an informative notice to ICANNʹs compliance area .

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

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.BOM for a example.BOM 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; DNS delegation requires previous authoritative 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


During pre-launch phase, there will be one 30-day sunrise period (ʺ.BOM sunrise 1ʺ) where 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, will be allowed to pre-register a .BOM domain. Possible conflicts where more than one rights holder to an specific mark pre-register a domain will be resolved on a first-come⁄first-serve basis.

After sunrise 1, .BOM will be taken into production status so the next registration phases can benefit of the Trademark Clearing House Claims services.

A sunrise period ((ʺ.BOM sunrise 2ʺ) where owners of .br domains registered prior to April 29 2012 can pre-register a matching .BOM domain will be provided. Possible conflicts as .br registrations occur on the third-level (so there is the possibility of example.com.br and example.net.br owners wanting example.BOM)will be resolved by letting only the oldest active registration on the .br that matches the name being registered to benefit of this sunrise period.

ʺ.BOM sunrise 3ʺ will be open to all registrants to provide level-playing opportunities in bidding for generic words. Every domain name that receives a bid will be added to a public list showing domain names and current number of bids so everyone else can also bid for that name.


Sunrise 2 and sunrise 3 will add for a period of at least 60 days. During such sunrises, 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 on the rights that were subject of the notice.

Post-registration rights protection mechanisms in .BOM will include URS (Uniform Rapid Suspension), UDRP (Uniform Domain-dispute Resolution Policy) and PDDRP (Post-Delegation Dispute Resolution Procedure). URS, UDRP and PDDRP shall be part of ʺNúcleo de Informação e Coordenação do Ponto BR - NIC.brʺ registry agreement with ICANN, working with ICANN-appointed dispute resolution providers.

Resourcing for these protections mechanisms include technical resources of NIC.br to connect to the Trademark Clearinghouse, financial resources of NIC.br to pay for the connection for the Trademark Clearinghouse, and the personnel resources of NIC.br legal staff.

Additional measures that also contribute to rights protection are the .BOM 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.

.BOM Registrant Data (WHOIS) Policy:

ʺThe registrant shall provide and update the required personal data and⁄or business data so they always reflect real and valid information. Use of false, invalid, incorrect or data belonging to a third party can invalidate the contract and incur cancelation of the domain, besides law-defined penalties and liabilities. If requested by ʺNúcleo de Informação e Coordenação do Ponto BR - NIC.brʺ, either directly or through a registrar, the registrant shall provide certified documents and or update 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.

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 (individual) or CNPJ (organization). This document must also be valid according to the brazilian
internal revenue service.

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. Domains registered in the name of a person or an organization will be considered to belong to such person or organization, so registrants need to carefully consider if proxy services could bring ownership risks to them. ʺ



.BOM Prevention of Abuse Policy:

ʺThe registrant agrees to use the .BOM domain being registered or renewed only for lawful and non-abusive purposes.
NIC.br 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 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 include:
- An e-mail box abuse@nic.BOM to receive abuse complaints ;
- A web form to receive abuse or take action complaints ;
- An optional anonymized web form to receive take action complaints that can be verified by NIC.br with no corroboration ;
- Automated analysis of malware and phishing URL feeds including both public sources and association sources. NIC.br, thru its security area called CERT.br, is a member of the Anti-Phishing Working Group (APWG); the SpamPots project; the brazilian honeypot consortium organizations; FIRST (Forum of Incident Response and Security Teams) and a few research projects with brazilian universities. Results of automated analysis or information gathering generate abuse cases that will be dealt manually.
- A ticketing system to integrate, measure the service-level and manage the complaints from all three ways above.

Target service-level for abuse and take action complaints is to set a course of action within 30 minutes for 50% of the complaints, up to 8 hours for 75% of the complaints and up to 24 hours for 99% of the complaints. Staffing for this system will include at least 3 full-time employees (1 registry security officer and 2 registry security shift analysts) and will be shared among all TLDs (Top-Level Domains) managed by NIC.br, including but not limited to .BOM and .br. Abuse and take action complaints from law enforcement will be given priority and skip queues.

-----------

.BOM Take Action procedures:

ʺAs soon an abuse issue is found, in all cases an administrative procedure will be started to verify documentation of the registrant if none has been received before. For each 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.ʺ


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

.BOM prevention of abusive transfer and⁄or cancellation:

Transfer tokens will be required to perform domain transfers; registrars will be encouraged to validate the transfer or cancellation through secondary channels. Frequent occurrence of abusive transfer and⁄or cancellations at an specific registrar can trigger a compliance investigation by NIC.br and sending of an informative notice to ICANNʹs compliance area .

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

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.BOM for a example.BOM 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; DNS delegation requires previous authoritative 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 registry procedure for 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.