.beats TLD
Terms and Policies that apply to the .beats Top-Level Domain.
Terms & Policies
For any inquiries related to the .Beats TLD, including to report the abusive use of .Beats domain names, please contact the Apple Legal Department by one of the means listed below:
Email: btld@apple.com
Or, also by mail at:
Beats TLD Counsel
1 Infinite Loop
MS 169-3IPL
Cupertino, CA 95014
USA
Beats provides the highest quality headphones, speakers, and other audio equipment under the trusted Beats name, and so has introduced an entirely new generation to the possibilities of premium sound entertainment. Beats is working to enhance this quality, trust, and innovation to its online presence with the use of its .Beats top-level domain (TLD). In the future, when customers see a .Beats email and visit a .Beats website, they will know they are interacting with a genuine Beats property.
In order to facilitate the authenticity of the .Beats online experience, Beats will allow only Beats, its affiliated companies, or authorized trademark licensees to register and use domain names that end in .Beats for bona fide Beats-related purposes. Beats has implemented a strict internal registration process to ensure only authorized personnel can register and use .Beats domain names and regularly monitors the use of registered domain names to ensure they are being used for legitimate purposes.
Beats takes the abusive use of domain names seriously. Abusive domain name use creates security and stability issues for all users of the Internet. As the registry operator for .Beats, Beats is committed to prevent, rapidly identify and/or resolve identified abuse uses of any .BEATS domain name.
While abuse can take many forms, Beats defines abusive use of a .Beats domain as the wrong or excessive use of power, position or ability in connection with that domain name, and includes, without limitation, the following uses of that domain name:
- Spam: The use of electronic messaging systems to send unsolicited bulk messages. The term applies to e-mail spam and similar abuses such as instant messaging spam, mobile messaging spam, and the spamming of Web sites and Internet forums. An example, for purposes of illustration, would be the use of email in denial-of-service attacks.
- Phishing: The use of counterfeit Web pages that are designed to trick recipients into divulging sensitive data such as usernames, passwords, or financial data.
- Pharming: The redirecting of unknowing users to fraudulent sites or services, typically through DNS hijacking or poisoning.
- Willful distribution of malware: The dissemination of software designed to infiltrate or damage a computer system without the owner’s informed consent. Examples include, without limitation, computer viruses, worms, key loggers, and Trojan horses.
- Fast flux hosting: Use of fast-flux techniques to disguise the location of Web sites or other Internet services, or to avoid detection and mitigation efforts, or to host illegal activities. Fast-flux techniques use DNS to frequently change the location on the Internet to which the domain name of an Internet host or name server resolves. Fast flux hosting may be used only with prior permission of Public Interest Registry.
- Botnet command and control: Services run on a domain name that are used to control a collection of compromised computers or “zombies,” or to direct denial-of-service attacks (DDoS attacks).
- Distribution of child pornography.
- Illegal Access to Other Computers or Networks: Illegally accessing computers, accounts, or networks belonging to another party, or attempting to penetrate security measures of another individual’s system (often known as “hacking”). Also, any activity that might be used as a precursor to an attempted system penetration (e.g., port scan, stealth scan, or other information gathering activity).
- Online sale or distribution of illegal pharmaceuticals.
- Other illegal or fraudulent actions.
Beats prohibits the use of .Beats domain names for any of the following abusive uses descripted above. Beats thus reserves the right to deny, cancel or transfer any domain name registration or transaction, or place any domain name(s) on registry lock, hold or similar status, that it deems necessary, in its discretion; (1) to protect the integrity and stability of the registry; (2) to comply with any applicable laws, government rules or requirements, requests of law enforcement, or any dispute resolution process; (3) to avoid any liability, civil or criminal, on the part of Beats, as well as its affiliates, subsidiaries, officers, directors, and employees; (4) per the terms of the registration agreement or (5) to correct mistakes made by Beats or any registrar in connection with a domain name registration. Beats also reserves the right to place upon registry lock, hold or similar status a domain name during resolution of a dispute concerning that domain name.
Abuse contact and procedures for handling abuse complaints
Beats has established an abuse contact to help facilitate the review, evaluation and resolution of abuse and malicious complaints in a rapid manner.
The abuse contact can best be reached by email at: btld@apple.com
Or, also by mail at:
Apple Inc.
c/o .Beats Abuse Contact
1 Infinite Loop
MS 169-3IPL
Cupertino, CA 95014
USA
For tracking purposes, Beats will utilize a ticketing system with which all complaints will be tracked internally. The reporter will be provided with the ticket reference identifier for potential follow-up.
Under certain circumstances, Beats provides access to the zone file data through ICANN’s Centralized Zone Data Service (CZDS) for its .Beats TLD.
As a result, Beats provides this CZDS Access Policy to describe how we grant access to our zone file data and when we could revoke such access.
Requests for zone file access
All requests to access the zone file for the .Beats TLD must be submitted by the requester through ICANN’s CZDS found at the following link https://czds.icann.org.
Credentialing requirements
In order to grant access to the zone file for .Beats, ICANN will require all requesters to agree to the Terms & Condititions of the Centralized Zone Data Service, which is available for review here: https://czdap.icann.org/en/terms/terms-and-conditions-1.
Beats will also request through the Centralized Zone Data Service that each requester provides the reason for which they seek access, the steps it will take to protect against unauthorized access to, use of, or disclosure of the data to any third party, and information sufficient to correctly identify and locate the requester and ensure that the requester is likely to comply with this CZDS Access Policy.
Beats’ strives to complete its review of access requests within thirty (30) business days.
Rejection or revocation of access
ICANN or Beats may reject the request for access to the Centralized Zone Data Service of any requester that does not satisfy the credentialing requirements.
In addition Beats may reject the request for access where Beats reasonably believes that the requester:
- Will likely use the data for unlawful or abusive purposes, or otherwise not use the data in compliance with all applicable laws and regulations;
- Will likely use the data to harass, annoy, interrupt, disrupt, or interfere in the normal business operations of any registrant, including Beats;
- Will likely use the data for marketing purposes;
- Will likely distribute the data to any other party without the express prior written consent of Beats;
- Will likely not take all reasonable steps to protect against unauthorized access to, use of, or disclosure of the data to any third party;
- Will likely use the data in a way that threatens the operational stability and security of the Internet; and/or
- Will likely use the data in a manner that otherwise contravenes the spirt of this CZDS Access Policy.
Beats may terminate any requester’s access to the data at any time and without notice, and accordingly deny any requester access to the data, for any reason, including but not limited to a requester’s failure to comply with any provision of this CZDS Access Policy or the Terms & Condititions of the Centralized Zone Data Service.
Term of use
Where approved, a requester will be provided access to the zone file for a term of ninety (90) days. Upon the end of the 90-day term, the requester must apply to to renew their grant of access.
1. INTRODUCTION
1.1. Overview
Beats will sign its .Beats zone files implementing Domain Name System Security Extensions (DNSSEC). The purpose of this DNSSEC Practice Statement (DPS) is to describe the critical security controls and procedures that Beats will implement through its Back End Service Provider Afilias for key material storage, access and usage for its own keys and secure acceptance of registrants’ public-key material so as to provide a means for Internet stakeholders to evaluate the strength and security of the DNSSEC chain of trust for domain names within the .Beats TLD. This DPS does not apply to other domain names owned, registered, or used by Beats. This document was created using the format described in RFC 6841.
1.2. Document name and identification
This document comprises the practices utilized by Afilias, the Back End Service Provider for the .Beats TLD, to operate DNS zones as it relates to the DNSSEC for the .Beats TLD.
1.3. Community and Applicability
This section describes the various “stakeholders” of the functionality provided by the DNSSEC and the signed .Beats TLD.
1.3.1. The TLD Registry
For the .Beats TLD Registry, Beats operates as the registry operator (RO) and Afilias operates as the Back End Service Provider (BESP), where Afilias operates and performs the functions of maintaining the TLD’s zone on behalf of Beats.
As the BESP, Afilias will perform the following functions for the .Beats TLD:
- Generate the Key Signing Keys (KSK) for the zone.
- Generate the Zone Signing Keys (ZSK) for the zone.
- Sign the ZSK using the KSK.
- Sign the relevant Resource Records of the zone using the ZSK.
- Update the ZSK and KSK as needed.
- Send Delegation Signer (DS) Resource records to ICANN for inclusion into the root zone.
- Receive DS Resource Records from accredited registrars, and update the zone accordingly.
- Update the WHOIS information accordingly.
1.3.2. Accredited Registrars
Registrars that are accredited by Beats to register domain names within .Beats are required to make changes to the zone using one of two mechanisms: (1) via EPP, or (2) via a Web Administration Tool. The Web Administration Tool is an Afilias-provided front-end to EPP, so, in effect, all changes to the registry are made via EPP. For DNSSEC, registrars are expected to maintain Delegation Signer (DS) records with Afilias on behalf of their registrants.
1.3.3. Registrants
Registrants of .Beats domain names are responsible for ensuring that their second level domain zones are properly signed and maintained. They must also generate and upload DS records for their signed zones to their registrar (who, in turn, sends these to Afilias).
1.4. Specification Administration
1.4.1. Specification Administration Organization
Afilias maintains this specification on behalf of the .Beats TLD registry.
1.4.2. Contact Information
Questions or concerns regarding this DPS, or the operation of a signed TLD should be sent to the Afilias Customer Support Center. They can be reached via:
Phone: +1 416.646.3306
Email: support@afilias.info
1.4.3. Specification Change Procedures
The DPS is reviewed periodically and updated as appropriate.
All changes are reviewed by Afilias’ operations and security teams and submitted to Beats’s and Afilias’ TLD and BESP management for approval. Once accepted, procedures are updated, and appropriate personnel are trained on any new or changed practice. Once all preparatory work has been completed, the DPS is published and becomes effective as of its publication.
2. PUBLICATION AND REPOSITORIES
2.1. Repositories
Afilias manages the DPS repositories and its availability mechanisms, and Beats publishes the DPS at http://afilias.info/dps.
2.2. Publication of Key Signing Keys
The “chain of trust” is maintained for the .Beats TLD zone by having Afilias send DS records to ICANN for inclusion in the root zone delegation of the TLD. These DS records correspond to at least one active KSK in the zone. As such, no publication of an additional trust anchor is required.
3. Operatiional Requirements
3.1. Meaning of Domain Names
Policies regarding restrictions on domain names within the .Beats zone are specified by Beats, and can be found under the section “Registration Policy for .BEATS” at https://www.beatsbydre.com/company/tld.
3.2. Identification and Authentication of Child Zone Manager
Beats provides express permission to Afilias to permit DNSSEC for child zones in the .Beats TLD. Only registrars (on behalf of their registrants) are permitted to activate DNSSEC for a child zone. To activate DNSSEC, a registrar must submit a Delegation Signer (DS) record either via the Web Administration Tool, or via EPP (according to RFC 5910).
For EPP, each registrar has unique credentials to access the .Beats TLD registry, which are verified by Afilias before EPP transactions of any kind can be conducted. For the Web Administration Tool, certificates are used to uniquely identify each registrar.
3.3. Registration of Delegation Signer (DS) Resource Records
DS records are sent to Afilias by the registrar via EPP (specifically, according to RFC 5910). Once submitted to Afilias, the WHOIS data is changed, and the zone changes are automatically propagated out to the DNS infrastructure.
3.4. Method to Prove Possession of Private Key
It is the responsibility of the accredited registrar to ensure the integrity of the data submitted to Afilias. There is no requirement that a corresponding DNSKEY already be published in a zone before a DS record is submitted to the parent. This makes proof of possession of a private key unpredictable.
Afilias therefore does not perform any tests to prove possession of a private key.
3.5. Removal of DS Record
3.5.1. Who Can Request Removal
Only the sponsoring registrar for a domain name can add, change, or delete DS records for that domain name. Registrars must provide an Auth-Info code to verify any change for this domain name.
3.5.2. Procedure For Removal Request
DS records are removed using the appropriate EPP command, as specified by RFC 5910. Only the sponsoring registrar can request a DS record be removed, and then only if they include the correct Auth-Info code.
3.5.3. Emergency Removal Request
Because this is facilitated via EPP, and the system is updated continuously, there is no additional procedure required for an emergency removal request.
4. FACILITY, MANAGEMENT AND OPERATIONAL CONTROLS
4.1. Physical Controls
Afilias uses two geographically separate sites located in different countries that are not part of its offices to provide redundant and backup DNSSEC services for the .Beats TLD. Both sites are physically protected environments that deter, prevent, and detect unauthorized use of, access to, and disclosure of sensitive information and systems. Both facilities limit access to authorized personnel. Visitors are only permitted by escort from Authorized personnel, and for a specific purpose (such as hardware repair by a technician).
Both facilities provide redundant and backup power, air conditioning, and fire suppression and protection services. Reasonable precautions have been taken to minimize the impact of water exposure to Afilias systems.
Media with sensitive information is stored within Afilias facilities with appropriate physical and logical access controls designed to limit access to authorized personnel.
Sensitive documents, materials, and media are shredded or rendered unreadable before disposal.
Afilias performs routine backups of critical system data and maintains an off-site backup with a bonded third party storage facility.
4.2. Procedural Controls
Afilias provides at least two operational teams with access to and responsibility for the DNSSEC signer systems for the .Beats TLD. Each team member holds a part of the password necessary to grant access to the signer systems. Any task performed on a signer system requires an authorized representative from each team to be present.
4.3. Personal Controls
Afilias requires that all personnel taking part in a trusted role such as providing DNSSEC services have to have been working for Afilias for at least one year and must have the qualifications necessary for the job role.
Afilias provides training to all personnel upon hire as well as requisite training needed to perform job responsibilities. Refresher training and updates are provided as needed. Personnel and rotated and replaced as needed.
In limited circumstances, contractors may be permitted to occupy a trusted role. Any such contractor is required to meet the same criteria applied to an Afilias employee in a comparable position.
Afilias provides all employees with the materials and documentation necessary to perform their job responsibilities.
4.4. Audit Logging Procedures
All key life cycle events for domains within the .Beats TLD, including but not limited to generation, activation, rollover, destruction, and use, whether successful or unsuccessful, are logged with a system that includes mechanisms to protect the log files from unauthorized viewing, modification, deletion, or other tampering.
Access to Afilias’ physical facilities is logged by the facility and the log is only accessible to authorized personnel.
Afilias monitors all log entries for alerts based on irregularities and incidents. The Afilias security team reviews all audit logs at least weekly for suspicious or unusual activity.
4.5. Compromise and Disaster Recovery
In the event of a key compromise or disaster of its DNSSEC services for the .Beats TLD, Afilias’ incident response team would be notified. The response team has documented procedures for investigation, escalation, and response. The team is responsible for assessing the situation, developing an action plan, and implementing the action plan with approval from executive management.
Afilias maintains redundant facilities to ensure immediate availability of a disaster recovery site should one site become unavailable. Key data is cloned, encrypted, and sent to a hot spare in the same facility, and to two spares in the redundant facility. The ability to encrypt and decrypt the key data resides entirely within each system's High Security Module, and exists nowhere external to the signing systems.
4.6. Entity termination
Afilias has adopted a DNSSEC termination plan in the event that the roles and responsibilities of the signing services must transition to other entities. Afilias will coordinate with Beats and all required parties in order to execute the transition in a secure and transparent manner.
5. TECHNICAL SECURITY CONTROLS
5.1. Key Pair Generation and Installation
All key pairs are generated on the signer systems according to parameters set by Afilias’ operational team. The signer systems meet the requirements of FIPS 140-2 level 3. The public key is automatically inserted in the TLD zone file as a DNSKEY resource record as part of the signing process. A DS record is made available for submission to the parent (root) zone.
The signer system maintains the separation of the KSK from the ZSK and manages the use of each key pair as appropriate. Each key is used for only one zone.
5.2. Private Key Protection and Cryptographic Module Engineering Controls
All signing systems are FIPS 140-2 level 3 certified. No unencrypted access to the private key is permitted. Access to the signer system is specified in the Procedural and Personnel Control sections. Multiple redundant signing systems are maintained. The systems include a mechanism to backup key pairs and other operational parameters to each other in a secure manner. Private keys are not otherwise backed up, escrowed, or archived. When a private key is deactivated it is destroyed by the signing system.
A trusted team has the authority to create, activate, and deactivate key pairs, and executes the responsibility according to documented policies and procedures.
5.3. Computer Security Controls
Afilias ensures that the systems maintaining key software and data files are trustworthy systems secure from unauthorized access. In addition, Afilias limits access to production servers to those individuals with a valid business reason for such access. General application users do not have accounts on production servers.
5.4. Network Security Controls
The signing systems are placed in Afilias’ production systems, which are logically separated from all other systems. Use of normal network security mechanisms such as firewalls mitigate intrusion threats; only restricted role users are allowed access to production systems, and their work is logged.
5.5. Timestamping
The signer systems securely synchronize their system clocks with a trusted time source inside the Afilias network.
5.6. Life Cycle Technical Controls
DNSSEC applications developed and implemented by Afilias conform to its development and change management procedures. All software is traceable using version control systems. Software updates in production are part of a package update mechanism, controlled via restricted role access and updated via automated recipes. All updates and patches are subject to complete verification prior to deployment.
Afilias uses a third-party solution on its signer systems, where updates are tested in a secure lab environment prior to deployment.
6. ZONE SIGNING
6.1. Key Lengths and Algorithms
Key Signing Key:
Afilias uses a key length of 2048 bits with RSA as the generation algorithm.
Zone Signing Key:
Afilias uses a key length of 1024 bits with RSA as the generation algorithm.
6.2. Authenticated Denial of Existence
Authenticated denial of existence will be provided through the use of NSEC3 records as specified in RFC 5155.5.5.
6.3. Signature Format
SHA1, using RSA.
6.4. Zone Signing Key Roll-Over
Afilias will roll the ZSK with a pre-publishing scheme as described in RFC 4641, section 4.2.1.1. ZSK rollover is carried out once a month.
6.5. Key Signing Key Roll-Over
Afilias will roll the KSK with a double-signing scheme as described in RFC 4641, section 4.2.1.2. There are no planned KSK rollover frequencies defined at this time.
6.6. Signature Life-Time and Re-signing Frequency
Zones are signed once every 8 or 9 days (4 times a month), with a signature life-time of 20 days. Jitter is introduced to avoid presumptive attacks during signing.
6.7. Verification of Zone Signing Key Set
Verification of the zone signing key set is performed by validating the public key data contained in the Key Signing Record.
6.8. Verification of Resource Records
All RRset signatures are verified prior to publication.
6.9. Resources Records Time-To-Live
DNSKey: 15 minutes
NSEC3: SOA minimum (24 hours)
Delegation Signer (DS): 24 hours
RRSIG: varies depending on the RR covered
7. COMPLIANCE AUDIT
7.1. Frequency of entity compliance audit
Afilias intends to conduct compliance audits related to its general DNSSEC services at least biennially.
7.2. Identity/qualifications of auditor
The auditor of Afilias’ compliance audits will be an entity who is proficient in the technologies they are auditing, and are independent from Afilias.
7.3. Auditor's Relationship to Audited Party
Auditors must be independent to Afilias.
7.4. Topics Covered by Audit
Environmental, network and software controls, operations, key management practices and operations.
7.5. Actions taken as a result of deficiency
Any gaps identified in the audit will result in the creation of an action map, which lists what actions are necessary for the resolution of each gap. Afilias’ management will design and implement mitigating steps to close the gaps identified.
7.6. Communication of Results
Afilias will provide results upon request by contacting the Afilias Customer Support Center. They can be reached via:
Phone: +1 416.646.3306
Email: support@afilias.info
8. LEGAL MATTERS
This DPS is to be construed in accordance with and governed by the internal laws of Ireland without giving effect to any choice of law rule that would cause the application of the laws of any jurisdiction other than the internal laws of Ireland.
The following material shall be considered confidential:
- Private keys
- Information necessary to retrieve/recover private keys
- Disaster recovery plans (DRPs)
- Any operational details relevant to the management and administration of DNS keys, including but not limited to network, software, hardware details.
Beats and Afilias do not implicitly or explicitly provide any warranty, and have no legal responsibility for any procedure or function within this DPS. Beats and Afilias shall not be liable for any financial damages or losses arising from the use of keys, or any other liabilities. All legal questions or concerns should be sent to btld@apple.com.