Applicant Information

Does or will this RSP have a publicly verifiable, 3rd party certification (e.g. ISO 27001) held directly by the organization and relevant to the registry services under application?

Yes

Does or will this RSP have processes and controls to manage physical access to infrastructure and systems, including building access controls, security cameras and/or other sensors, physical environmental monitoring and safety equipment, and alarm systems related to the physical infrastructure?

Yes

Does or will this RSP have processes and controls to manage non-physical access to infrastructure, including network access from both internal systems and external Internet systems, intrusion detection systems, security information and event management systems, network firewalls, network segmentation and isolation, user identification and authentication, and authorization schemes?

Yes

Does or will this RSP have processes and controls pertaining to the selection of vendors and equipment suppliers, management and maintenance of assets while in use, procurement of assets, and safe disposal of assets?

Yes

Does or will this RSP routinely renew and keep safe all cryptographic material necessary for the operation of the RSP?

Yes

Does or will this RSP secure (e.g. encryption, tamper detection, etc…) at-rest data relevant to the operation of the RSP, including but not limited to DNSSEC if applicable?

Yes

Does or will this RSP secure (e.g. encryption, tamper detection, etc…) in-transit data relevant to the operation of the RSP, including but not limited to DNSSEC if applicable?

Yes

If applicable, does or will this RSP have security controls for data in virtualized environments, including controls relevant to both on-premises or private virtualization environments as well as public clouds, network isolation, memory isolation, process isolation, and hypervisor access controls?

Yes

Does or will this RSP have a senior executive primarily in charge of and responsible for security?

Yes

Does or will this RSP conduct background checks, both initial and on-going, of personnel and vendors relevant to the registry services under application?

Yes

Describe the solutions and mitigations to be used to thwart Distributed Denial of Service (DDOS) attacks against the authoritative DNS services.

First, when we do anycast, we try to keep the traffic local as much as possible, advertising the service on IXPs only or in case of BGP transit using communities available from the upstream provider. Let's call them "anycast servers" and they advertise more specific prefixes only. Besides the anycast servers we also have groups of servers in bigger setups (clusters) advertising less specific prefixes like /23 covering all the DFZ. The key is a spare DNS and routing wildcard setup where we can advertise any prefix present in our delegation zone and answer queries. In this spare setup we have our DDoS tools. So in a DDoS scenario (that exceeds local capacity) for one or more servers in our delegation, we advertise the more specific prefix related to it from the spare setup, attracting most of the attack and then we can use the mitigation tools to scrub the traffic and answer what we really need to. We use both local and cloud mitigation tools. The 'local' and 'cloud' mitigation tools are defined as 'local scrubbing hardware' and 'external scrubbing service', respectively. The external scrubbing service is operated by a major provider that maintains more than 15 global scrubbing centers, offering massive mitigation capacity to absorb large volumetric floods. Since DNS services are not always scrubbed by default, we need to activate them manually. The DDoS mitigation techniques require manual intervention by our staff. We have on-call, 24/7 system administrators available, as well as a dedicated 24/7 NOC/SOC team for continuous monitoring and tier 1 actions. We don't have automated actions deployed to mitigate DDoS. Our monitoring is able to identify abnormalities in query rate by Qtypes, answer rate by Rcodes, volumetric traffic and service status as well.

Does or will this RSP comply with BCP 38?

Yes

Does or will this RSP implement routing security of some nature, such as automated route filters, RPKI route origin validation, or other operational practices defined by the Internet Society and Global Cyber Alliance's Mutually Agreed Norms for Routing Security (MANRS)?

Yes

Does or will this RSP have documented, regular, and active practices for the maintenance of hardware relevant to the registry services under application?

Yes

Does or will this RSP have documented, regular, and active practices for the maintenance, upgrading, and patching of software relevant to the registry services under application?

Yes

Does or will this RSP have documented, regular, and active practices for the lifecycle of hardware relevant to the registry services under application?

Yes

Does or will this RSP have documented, regular, and active practices for the secure development of software?

Yes

Does or will this RSP have documented contingency plans for extraordinary scenarios regarding the maintenance of hardware relevant to the registry services under application?

Yes

Does or will this RSP have documented contingency plans for extraordinary scenarios regarding the maintenance, upgrading, and patching of software relevant to the registry services under application?

Yes

Does or will this RSP have documented contingency plans for extraordinary scenarios regarding the lifecycle of hardware relevant to the registry services under application?

Yes

Does or will this RSP have documented contingency plans for extraordinary scenarios regarding the development of software?

Yes

Does or will this RSP use Infrastructure-as-Code (IaC) to manage all systems relevant to operation of the registry services under application?

Yes

Does or will this RSP use automated orchestration to manage all systems relevant to the operation of the registry services under application?

Yes

Describe the methods resiliency for DNS, including the use of anycast, primary and secondary DNS authoritative servers, and hidden DNS zone transfer servers.

Name server infrastructure will take advantage of the current .br Registry's server geographic diversity as shown in [DNS.3.3-diagram1]. It's composed of 6 independent nameservers [a-f].dns.br with Global Anycast Clusters located in 6 different cities: São Paulo - BR, Fortaleza - BR, Brasília - BR, Fremont - US, Frankfurt - DE, and Naju - KR, each with its own IP blocks and ASNs as listed below: * a.dns.br (São Paulo, BR): AS53035, 200.219.148.0/24, 2001:12f8:6::/47 * b.dns.br (Fortaleza, BR): AS10906, 200.189.41.0/24, 2001:12f8:8::/47 * c.dns.br (Brasília, BR): AS11284, 200.192.232.0/24, 2001:12f8:a::/47 * d.dns.br (Fremont, US): AS11644, 200.219.154.0/24, 2001:12f8:4::/47 * e.dns.br (Frankfurt, DE): AS12136, 200.229.248.0/24, 2001:12f8:2::/47 * f.dns.br (Naju, KR): AS14650, 200.219.159.0/24, 2001:12f8:c::/47 Each cluster is composed of 8 hosts, across which the load of client requests is distributed by a router in a hardware based load balancing scheme leveraging ECMP routing with at least 10 Gbps upstream capacity. The purpouse of these redundant cluster is to garantee global BGP reachability. In addition, all nameservers have Anycast Nodes, using shared unicast address - as described in RFC 3258, - 51 instances in total, operated in other 38 locations. These anycast nodes are placed 4 in North America, 36 in South America, 8 in Europe and 3 in Asia with very diverse BGP network topology. Each anycast node is connected through at least a 1Gbps link. Anycast nodes at each point serve all the same zone, and annouces the same prefixes via BGP, so client queries always reach the nearest available server. BGP reconvergence automatically reroutes traffic to alternate closest topological instance, acording to his BGP selection preference, in the event of a site or link failure, maintaining almost uninterrupted DNS resolution. There is also two spare clusters of 6 hosts, with similar hardware configuration of the global anycast clusters, located one in São Paulo and one in the US. If any of the 6 global clusters becomes unavailable due to maintenance, service failure, or any other event, these spare clusters can be set to take over the functions of unavailable node by the measure of a single BGP announcement. The spare DNS cluster is kept synchronized with the hidden master for the zone. All BGP transit arrangements are already in place and ready to be used as needed.

Does or will this RSP have at least two Tier III (as defined here: https://uptimeinstitute.com/tiers) or equivalent data centers having no inter-dependencies for DNS zone distribution?

Yes

Does or will this RSP have at least two Tier III or equivalent data centers having no inter-dependencies for global DNS anycast service?

Yes

Does or will this RSP have enough coverage of DNS service to accommodate failures of any DNS point-of-presence to maintain minimum Service Level Requirements?

Yes

Does or will this RSP implement RFC 1034 (“DOMAIN NAMES - CONCEPTS AND FACILITIES”)?

Yes

Does or will this RSP implement RFC 1035 (“DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION”)?

Yes

Does or will this RSP implement RFC 1123 (“Requirements for Internet Hosts -- Application and Support”)?

Yes

Does or will this RSP implement RFC 1982 (“Serial Number Arithmetic”)?

Yes

Does or will this RSP implement RFC 2181 (“Clarifications to the DNS Specification”)?

Yes

Does or will this RSP implement RFC 3226 (“DNSSEC and IPv6 A6 aware server/resolver message size requirements”)?

Yes

Does or will this RSP implement RFC 3596 (“DNS Extensions to Support IP Version 6”)?

Yes

Does or will this RSP implement RFC 3597 (“Handling of Unknown DNS Resource Record (RR) Types”)?

Yes

Does or will this RSP implement RFC 4343 (“Domain Name System (DNS) Case Insensitivity Clarification”)?

Yes

Does or will this RSP implement RFC 6891 (“Extension Mechanisms for DNS (EDNS(0)))”?

Yes

Does or will this RSP implement RFC 7766 (“DNS Transport over TCP - Implementation Requirements”)?

Yes

Does or will this RSP implement RFC 5001 (“DNS Name Server Identifier (NSID) Option”)?

Yes

Does or will this RSP operate DNS service according to RFC 6168 (“Requirements for Management of Name Servers for the DNS”)?

Yes

Does or will this RSP operate DNS service according to RFC 8906 (“A Common Operational Problem in DNS Servers: Failure to Communicate”)?

Yes

Does or will this RSP operate DNS service according to RFC 9199 (“Considerations for Large Authoritative DNS Server Operators”)?

Yes

Does or will this RSP operate DNS service according to RFC 9210 (“DNS Transport over TCP - Operational Requirements”)?

Yes

Does or will this RSP meet the standards established in the Service Level Agreements defined in Specification 10 of the ICANN Registry Agreement (version 2024) with regard to DNS?

Yes

Does or will this RSP compartmentalize (e.g. virtualization) the DNS service in such a manner that each compartment (e.g. containers, virtual machines, physical machines) is dedicated to DNS (excluding system services such as monitoring, remote access and NTP)?

Yes

Does or will this RSP monitor all unique DNS servers of all anycast nodes?

Yes

Does or will this RSP operate authoritative DNS servers according to the IANA Technical Requirements for Authoritative Name Servers (https://www.iana.org/help/nameserver-requirements)?

Yes

Does or will this RSP meet the standards established in Specification 10 of the ICANN Registry Agreement (version 2024) with regard to DNS and IPv4?

Yes

Does or will this RSP meet the standards established in Specification 10 of the ICANN Registry Agreement (version 2024) with regard to DNS and IPv6?

Yes

Does or will this RSP regularly exercise DNS Service continuity actions?

Yes

Does or will this RSP be capable of transferring all applicable operations to another RSP as defined by the Material Subcontracting Arrangement Technical Questions?

Yes

Does or will this RSP participate in coordinated Emergency Back-end Registry Operator (EBERO) transitions, including but not limited to maintaining the DNSSEC chain of trust, of hosted gTLDs when the business relationship of this RSP and the Registry Operator is not in good standing?

Yes

Does or will this RSP monitor for faults inside its own network?

Yes

Does or will this RSP monitor for faults from a point outside any of its own networks?

Yes

Does or will this RSP have documented processes for aggregation and triage of faults?

Yes

Does or will this RSP have documented processes to mitigate faults once detected?

Yes

Does or will this RSP have processes to minimize faults during maintenance of systems, including both automated processes and manual change control processes?

Yes

Does or will this RSP have personnel capable of reacting to and mitigating faults 24 hours per day of every day of every year of service?

Yes

Provide documentation regarding any RSP functions currently being served for any gTLD, the domain names of the gTLDs, and all service disruptions for each gTLD in the past six months, where a service disruption is defined by Specification 10 of the ICANN Registry Agreement (2024).

NIC.br serves Main, DNS, DNSSEC and IDN functions for .rio, .globo, .uol, .bom and .final. There was no service disruption in the last six months.