1.1 Threats to underlying infrastructure
1.1.1.1 Registry business failure
1.1.1.1.1 As with any business, registry operators must properly manage financial assets, funding and cash flow or face potential financial failure. Businesses and entities interested in entering the registry market should study the examples set by current registry operators in order to understand the business of domain names. Business failure examples include bankruptcy, buy-out, loss of funding, liquidation, management failure, marketing failure, litigation-related or induced failure or termination of payment processing capability
1.1.1.1.2 Failure modes - vulnerabilities
1.1.1.1.2.1 Marketing Failure
1.1.1.1.2.2 Litigation-related Failure
1.1.1.1.2.3 Termination of payment processing capability
1.1.1.1.2.4 General Business Failure
1.1.1.1.3 Palage White Paper (http://forum.icann.org/lists/new-gtld-questions/msg00006.html ) recommendations -- mitigation
1.1.1.1.3.1 All registry operators be required to operate on the current EPP standard
1.1.1.1.3.2 ICANN listed as direct beneficiary of data escrow agreement, with active script verification and periodic download
1.1.1.1.3.3 ICANN access to zone files
1.1.1.1.3.4 Education on existence and function of Auth Codes
1.1.1.1.3.5 Bonding requirement
1.1.1.1.3.6 Discussion of "thick" vs "thin" registries
1.1.1.2 Registrar business failure
1.1.2.1 A system failure -- resulting from a hardware or software failure, or configuration error -- could disrupt any or all the services a registrar or registry operator provides. A system failure is likely to be a temporary failure.
1.1.2.2 Applications-cluster processor fails
1.1.2.3 EPP/RRP server processor fails
1.1.2.4 Web server processor fails
1.1.2.5 Database server processor fails
1.1.2.6 Database disk drive fails
1.1.2.8 Authentication server fails
1.1.2.9 Whois-cluster processor fails
1.1.2.10 Billing and collections server fails
1.1.2.11 Internet or VPN link fails
1.1.2.12 Router or firewall fails
1.1.2.13 Physical site becomes inoperable for more than 24 hours
1.1.2.14 Both the primary and secondary data centers become inoperable
1.1.2.15 Operating system or application software fails
1.1.2.16 Operating system configuration errors
1.1.2.17 security system configuration errors
1.1.2.18 Name, web, database, and transaction server configuration errors
1.1.3 Government interventions
1.1.3.1 Regulatory-imposed shutdown
1.1.3.1.1 A court, government or government agency could attempt to order a registry operator to halt its operations.
1.1.3.2 Government Seizure of Registry Operator
1.1.3.2.1 A government could assume control over a registry operator, either through seizure of registry operations or nationalization of operations. Re-delegation of ccTLDs from individuals to government agencies provide examples of government assumption of control over registry operations. Re-delegation of a registry should include measures to ensure stable transition of registry operations.
1.1.3.3.1 State-sponsored
1.1.4.1 Government Takeover/Coup
1.1.4.1.1 A change of government by takeover, revolution or coup could lead to instability or failure for a registry operator. Political instability has not to date had a direct impact on registry operations, but direct intervention by governments into registry operations could occur in the future.
1.1.4.2.1 Acts of war/terror
1.1.4.3 Facility security
1.1.4.4.1 A natural disaster may have a devastating financial impact on a registry, even if it has a well-developed registry failover plan. This is particularly in the case where a nation is unable to cover the costs of rebuilding key infrastructure needed to maintain registry operations.
1.1.4.4.2.1 A strong earthquake could cause a temporary failure for a registry. A registry located in an earthquake-prone location should have contingency plans in place to ensure continuity of operations.
1.1.4.4.3.1 Hurricane Katrina (23-31 August 2005) is estimated to be responsible for over $75 billion USD in damages. When Hurricane Katrina hit New Orleans 27-30 August 2005, it caused a temporary failure to ICANN-accredited registrar Intercosmos Media Group. Intercosmos was able to avoid a prolonged outage because it had a plan for the backup of critical registrar resources. Although Intercosmos is a registrar, it may serve as an example for registries facing potential disaster scenarios.
1.1.4.4.4.1 While no registries are currently located in a tsunami-danger zone, future registry operators in tsunami-prone areas should have contingency plans in place to ensure the stability of registry operations.
1.1.4.4.5 Blackout/Energy Failure
1.1.4.4.5.1 In the future, a similar large-scale power outage could impact registry operators that have not implemented protections against localized outages at registry operations centers.
1.1.4.4.6 Snowstorm/blizzard/ice-storm
1.1.4.5 Physical disasters
1.1.5 Depletion of IPv4 address pool -- SAC 12
1.1.5.1 Routing table growth
1.1.5.2 Route fragmentation
1.1.6 Fragmentation of the root -- SAC 9
1.1.6.1 Alternate DNS roots
1.1.6.2 Root scaling (SAC 46)
1.1.6.3 Intentional or accidental results of DNS blocking (SAC 50)
1.2.1.1 SSAC DDOS Advisory -- SAC 8
1.2.1.2 Securing the edge -- SAC 4
1.2.1.3.1 On 6 February 2007, a distributed denial of service attack affected six of the thirteen root servers that form the foundation of the Internet. A factsheet on the attack is available at http://www.icann.org/announcements/factsheet-dns-attack-08mar07.pdf. The use of Anycast (http://en.wikipedia.org/wiki/Anycast) by root server operators helped prevent a major disruption to Internet operations.
1.2.1.3.2 In March 2006, a distributed denial of service attack was launched on a number of root servers, registrars and registry operators. The attacks temporarily impacted accredited registrars in Germany and in the United States. http://www.macworld.com/news/2006/04/04/network/index.php and http://www.pcworld.com/article/id,125554-page,1-c,applicationbugs/article.html. Combined, the registrars had approximately 8,000,000 domain names under management (approximately 11.5% of active domain name registrations as of 11 May 2006).
1.2.1.3.3 On 31 March 2006, ICANN's SSAC released an advisory on DNS Distributed Denial of Service Attacks (see http://www.icann.org/committees/security/dns-ddos-advisory-31mar06.pdf). The advisory made a number of recommendations for Root and TLD Name Server Operators. These recommendations could also be employed by the registry operators.
1.2.1.4.1.1 Cyber activists use DDoS to shut down the servers and networks of political, religious, and corporate organizations.
1.2.1.4.1.2 Nations in conflict use crowd sourced denial of service attacks to shut off access to critical web sites in a show of force but also to silence a vocal critic in conjunction with an invasion.
1.2.1.4.2.1 Cyber criminals attempt to extort cash payments from their targets with the threat of shutting down their business.
1.2.1.4.2.2 Small businesses have been known to hire botnets, collections of compromised computers, to shut down a competitor.
1.2.1.4.3.1 Cyber activists
1.2.1.4.3.3 Cyber criminals
1.2.1.4.3.4 Small businesses
1.2.1.6 owner of a web site may not own the DNS server that provides the critical function of pointing at the web site.
1.2.1.7 Denial of service amplifier (RFC 3833)
1.2.1.7.1 Open recursive servers (SAC 8)
1.2.1.7.2 Packet fragmentation (SAC 8)
1.2.1.7.3 Source address validation (SAC 8)
1.2.1.7.4 Reflection attacks
1.2.2 Packet Interception
1.2.2.1 Man in the middle
1.2.2.2 Eavesdropping combined with spoofed responses
1.2.2.3 ID Guessing and Query Prediction
1.2.2.3.1 Generate packets which match the transport protocol parameters, predict ID based on previous traffic, etc.
1.2.3 Recursive vs authoritative nameserver attacks
1.2.4 Authority or authentication compromise
1.2.5 Domain name hijacking/theft - SAC 7
1.2.5.1 Domain hijacking refers to the wrongful taking of control of a domain name from the rightful name holder.
1.2.6 Registrar impersonation phishing attacks -- SAC 28
1.2.6.1.1 Phishers exploit many forms of email correspondence that merchants or financial businesses send to customers2. Registrars also use electronic mail for many types of domain name registration-related correspondence, including:
1.2.6.1.1.1 • Domain name renewal notices • Domain name order confirmations • Registration request confirmations • Domain information modification confirmations • WHOIS data accuracy reminders • Notices of domain name expiry or cancellation • Promotions, advertising for (new) services and features
1.2.6.1.2 Phishers exploit the fact that registrars rely on email correspondence. By impersonating (spoofing) a registrar in a phishing attack, the phisher is able to lure a registrar’s customer to a bogus copy of the registrar’s customer login page, where the customer may unwittingly disclose account credentials to the attacker. These credentials provide the phisher with unauthorized access to a domain name management account.
1.2.6.2 Objectives (SAC 28)
1.2.6.2.1 Domain name hijacking
1.2.6.2.2 Gain control of "trusted" providers of MX -- for spamming
1.2.6.2.3 Web-site spoofing -- by using hijacked A and AAAA records
1.2.6.2.4 Business disruption
1.2.7 Data poisoning (MITM, Cache)
1.2.7.1 Cache poisoning attacks
1.2.7.2 Name Chaining (RFC 3833)
1.2.7.2.1 Subset of "cache poisoning" attacks. Redirect a victims query to a location of the attacker's choosing. CNAME, NS and DNAME record types are most vulnerable. Victim issues query, attacker injects response, attacker's response injects data into victim's cache.
1.2.7.3 Betrayal by Trusted Server (RFC 3833)
1.2.7.3.1 Another variant of packet interception. Attack via the server trusted by a stub client. Accidentally (misconfigured) or maliciously delivers answers that are not what the user would expect.
1.2.8.1 The process of building a diagram, or footprint, of a DNS infrastructure by capturing DNS zone data such as domain names, computer names, and IP addresses for sensitive network resources. DNS domain and computer names often indicate the function or location of domains and computers.
1.2.8.1.1 source - Microsoft Tech net http://technet.microsoft.com/en-us/library/cc776225%28WS.10%29.aspx
1.2.9.1 SSAC advisory on fast flux hosting and DNS -- SAC 25
1.2.9.1.1.1 "Fast flux" is an evasion technique that cyber-criminals and Internet miscreants use to evade identification and to frustrate law enforcement and anticrime efforts aimed at locating and shutting down web sites used for illegal purposes. Fast flux hosting supports a wide variety of cyber-crime activities (fraud, identity theft, online scams) and is considered one of the most serious threats to online activities today. One variant of fast flux hosting, "double flux", exploits the domain name registration and name resolution services.
1.2.9.2 GNSO Fast Flux working group
1.2.9.2.1 Link to final report http://gnso.icann.org/issues/fast-flux-hosting/fast-flux-final-report-06aug09-en.pdf
1.2.10 IDN attacks (lookalike characters etc. for standard exploitation techniques)
1.2.10.1 Display and usage of internationalized registration data: support for characters from local languages or scripts (SAC 37)
1.2.11 Authenticated Denial of Domain Name (RFC 3833)
1.2.11.1 Question is whether there is a requirement for authenticating the non-existence of a name.
1.2.12 Gain control of account user/password
1.2.12.2.1 Guess, phish or apply social engineering techniques on a weak point of contact
1.2.12.2.2 Block delivery of email notifications to targeted registrants by altering DNS configuration
1.2.12.3.1 Prevent access to domain portfolio
1.2.12.3.1.1 Registration verification
1.2.12.3.1.2 Improve password-based authentication system
1.2.12.3.1.3 Register a PC or IP address from which to administer an account
1.2.12.3.1.4 Multi-factor authentication
1.2.12.3.1.5 Challenge systems
1.2.12.3.1.6 Per-domain access controls
1.2.12.3.1.7 Multiple, unique points of contact
1.2.12.3.1.8 Change notifications or confirmations
1.2.12.3.1.8.1 SAC 40 Finding (7) Registration service providers rely more heavily on unconfirmed email to deliver security-related correspondence (e.g., change notifications) than email delivery assurance and security characteristics merit. Attackers often defeat this method of correspondence by preventing email delivery when they modify the DNS configuration of domains through compromised registration accounts. Offering customers choices of alternative contact media or extending notification services to include some form of confirmation of receipt could reduce or mitigate the risk of exploitation or misuse of domain names and name resolution services associated with those names.
1.2.12.3.1.9 Multi-recipient notifications
1.2.12.3.1.10 Multiple delivery methods for critical correspondence
1.2.12.3.1.11 Domain name points of contact considerations
1.2.12.3.1.11.1 Use separate identities for registrant, technical, administrative and billing contacts
1.2.12.3.1.11.1.1 Identifying multiple points of contact offers an organization some protection in situations where a single contact is provided for all roles and that contact ceases to be employed by an organization, or in a circumstance where the only identified contact is not available to resolve a problem or respond to a reported abuse of the domain name. Distinct points of contact also offer some diversity in managing domain names. Each of these contacts can represent departments or divisions in an organization that are responsible for some aspect of domain name management. For example, while legal staff or an IP&T department may be best suited to manage the registrant role, IT may be best suited to manage the technical role, corporate communications may be best suited to manage the administrative role, and finance best suited to manage the billing role.
1.2.12.3.1.11.2 Incorporate registrar email correspondence into domain management
1.2.12.3.1.11.2.1 Ask your registrar for a list of correspondence routinely issued by email, and consult with your registrar to determine which of your email contacts is used for routine correspondence. Use your email system to route correspondence to the organization’s point of contact that is responsible for responding to or taking action. For example, consider whether you can route registrar email correspondence so that your technical contact receives DNS configuration change notices, your legal department receives renewal and WHOIS accuracy notices, etc.21
1.2.12.3.1.11.3 Identify domain name registration points of contact by role
1.2.12.3.1.11.3.1 In cases where a domain name is registered to an organization (business entity), consider creating points of contact that do not create a relationship between any natural person or employee. This action may help an organization avoid disputes over ownership of a domain.
1.2.12.3.1.11.4 Add diversity to email contacts to reduce single points of failure or attack
1.2.12.3.1.11.4.1 Access to all the domains in a domain name registration account is commonly granted through a single user account. This access also allows an attacker to modify contact and DNS configuration information for all domains managed through the user account. Thus, if Example Networks, Inc. manages the domains example.net, example.com, and example.biz from the same domain name registration account and that account is compromised, the attacker can alter DNS and block delivery of mail to all of these domains.
1.2.12.3.1.11.5 Keep key email accounts secure
1.2.12.3.1.11.5.1 Email is an important component of registrant- registrar communication. Key email accounts receive registrar notifications and registration account password reset/recovery messages and thus should only be accessed by authorized parties. Maintain the security of key email accounts by strengthening client authentication. Use encryption (TLS extensions for SMTP) to protect mail client-server communications from eavesdropping. Maintain secure operations at the mail server that hosts key email accounts as well. For example, mail servers that host key email accounts should be Internet standards compliant. Consider adopting some form of email reputation, data integrity or authentication system and follow best sender, forwarding, and antispam practices published by such organizations as the Messaging Anti-Abuse Working Group (MAAWG)22 and the Anti-Phishing Working Group (APWG)23 so that your mail servers will not be reported to spam blacklists.
1.2.12.3.1.11.6 Improve change control and coordination
1.2.12.3.1.11.6.1 Large organizations often implement resource management to deal with changes in personnel or equipment to domain registrations that must be coordinated across departments or business units. These are characterized as “add, drop, change” processes. Domain name management shares characteristics with such resource management structures. Organizations should consider the value of using registrar correspondence to trigger intra-organizational activity. For example, an organization may want to have the technical contact for a domain name notify all departments whose system configurations include name servers upon receipt of a confirmation email from a registrar when a change to DNS name servers for the domain is made. Organizations should consider the value of implementing measures to notify registrant, technical, or administrative contacts when changes are made to any contact or configuration information for any domain name registered by the organization.
1.2.12.3.1.11.7 Maintain accurate external contacts
1.2.12.3.1.11.7.1 The SSAC encourages registrants to catalog points of contact information for registrars where they have domain registration accounts and make these available to all internal and contracted parties who are involved in domain name management. Registrar points of contact of particular interest for registrants include any contact that may assist the registrant in a business, operational or security matter. The list may include general information contacts, false WHOIS and abuse contacts, and (where applicable) internal contacts responsible for your account portfolio, abuse, spam, etc.
1.2.12.3.1.12 Protection against unauthorized access
1.2.12.3.1.12.1 Protect account credentials
1.2.12.3.1.12.1.1 Maintain a list of authorized contacts for each domain registration account;
1.2.12.3.1.12.1.2 2. Advise authorized contacts that they are responsible for keeping secret the account credentials for domain registration accounts, and that they must not disclose or share passwords;
1.2.12.3.1.12.1.3 3. Identify measures authorized contacts must take should they discover that credentials have been disclosed;
1.2.12.3.1.12.1.4 4. Authorized contacts must compose passwords used to access a registration account using applicable organizational policies and commonly recognized best practices for composition (e.g., length and complexity), re-use, and longevity;14
1.2.12.3.1.12.1.5 5. Alternatively, if the registrar supports a form of multi-factor authentication (e.g., a hardware or software token), authorized contacts must keep the token safe from loss, damage, or unauthorized use;
1.2.12.3.1.12.1.6 6. Use different credentials for each account;
1.2.12.3.1.12.1.7 7. Partition particularly sensitive or important domain registrations into an account whose credentials are held by more senior personnel;
1.2.12.3.1.12.1.8 8. Securely escrow all registration account credentials;
1.2.12.3.1.12.1.9 9. Define and implement a recovery process with detailed auditing;
1.2.12.3.1.12.1.10 10. Define the circumstances where recovery is permitted, who has authority to recover credentials from escrow, and who is to be notified when escrowed credentials are accessed;
1.2.12.3.1.12.1.11 11. Changes in personnel authorized as contacts for a registrar account should cause new credentials to be created and old credentials to be revoked. (This may require coordination with a registrar, i.e., in cases where the registrant intends to change the user account identifier.); and
1.2.12.3.1.12.1.12 12. Employee resource management processes such as employee termination and employee transfer should be modified to check if the employee has domain registration account access. The processes could be modeled after similar checks for employee access to other assets, such as financial accounts.
1.2.12.3.1.12.2 Take advantage of routine correspondence from registrars
1.2.12.3.1.12.2.1 Use domain name renewal notifications to trigger a review or renewal action by staff responsible for Intellectual Property and Trademark matters, marketing, or generally any group that should decide whether to renew or allow a registration to expire.
1.2.12.3.1.12.2.2 2. Use WHOIS accuracy reporting obligation notifications to trigger action by staff to review and then confirm or update the registration information that must be publicly accessible via WHOIS services.
1.2.12.3.1.12.2.3 3. Use configuration change notifications to trigger checks by technical staff to verify that the changes are authorized and correct. Registrars may issue change notifications for any of the following events:
1.2.12.3.1.12.2.3.1 Domain name servers. Unauthorized or erroneous additions, deletions or changes to the list of domain name servers (or the IP addresses registered for those servers) that resolve the subdomains (labels) of a domain can result in disruption of service and should be confirmed by staff responsible for managing the organization’s DNS.
1.2.12.3.1.12.2.3.2 b. Contact information. Changes to registrant, administrative, or technical contact information should be confirmed to prevent attempts to divert ownership or correspondence away from authorized representatives of the organization.
1.2.12.3.1.12.2.3.3 c. Changes to domain status at registry. Registrars and registries coordinate the state (status) of a domain name in a registry using provisioning protocols.16 Registrars publish the status of a domain via WHOIS. Changes to domain status should be confirmed to assure that the domain is in the organization’s desired operational state.
1.2.12.3.1.12.2.3.4 d. Changes to domain status at registrar. Certain registrars allow domain- specific settings (e.g. private registration, domain forwarding, autorenew) that are held at the registrar. Changes to these services can have both long-term and short-term impact and therefore changes should be confirmed.
1.2.12.3.1.12.2.4 4. Use notifications regarding changes to or pending expiration of credit card or other payment methods and associated billing information to trigger checks by accounting personnel to ensure that changes are authorized and correct, needed payments are scheduled, and scheduled payments are not declined.
1.2.12.3.1.12.2.5 5. Designate a responsible party for each notification or have the notification trigger the creation of a ticket in a ticketing system. Such measures ensure that no notifications are ignored or are not responded to in the necessary or appropriate timeframe.
1.2.12.3.1.12.2.6 6. Define required responses and establish a clear SLA for each response to each type of event.
1.2.12.3.1.12.2.7 7. In order to protect email delivery against disruption attacks, contact email addresses for a domain should be assigned to mail servers named outside that domain and registration account. For example, if the domain example.net is managed through an account A at registrar X, use email addresses assigned from a different domain (example.biz) managed through an account B (and possibly at registrar Y). This measure prevents an attacker who succeeds in compromising a domain account from preventing delivery of notification emails by altering DNS configuration for a domain.
1.2.12.3.1.12.3 Maintain documentation to "prove registration"
1.2.12.3.1.12.3.1 Suggested documentation includes:
1.2.12.3.1.12.3.2 • Copies of registration records;
1.2.12.3.1.12.3.3 • Billing records, especially ones that show payments have been made;
1.2.12.3.1.12.3.4 • Logs, archives, or financial transactions that associate a domain name with content that you, the rightful registrant, published.
1.2.12.3.1.12.3.5 • Telephone directories (Yellow Pages), marketing material, etc. that contain advertising that associates you, the registrant, with the domain name;
1.2.12.3.1.12.3.6 • Correspondence to you from registrars and ICANN that mentions the domain name; and
1.2.12.3.1.12.3.7 • Legal documents, tax filings, government-issued IDs, business tax notices, etc. that associate you, the registrant, with the domain name.
1.2.12.3.1.13 Engaging the customer
1.2.12.3.1.13.1 Identify multiple domain account points of contact
1.2.12.3.1.13.2 • Include point of contact information administration in the Employee Resource Management process to assure that when a terminated employee’s credentials are rescinded, all domain registration point of contact information associated with that employee is changed as well.
1.2.12.3.1.13.3 • Impose a password change policy. • Periodically verify contacts. • Proactively monitor domain name registration.
1.2.12.3.1.13.4 • Assign email addresses for all registration points of contact from a different domain than the registered domain name. (Some registrants may want to create multiple domain registration accounts as an additional safeguard.)
1.2.12.3.1.13.5 • Treat transfer attempts as a security event (check and re-check).
1.2.12.3.1.13.6 • Use a separate domain for registration contact email accounts from domains used for other business purposes. For example, assign email addresses for example.info’s points of contact from example.net.
1.2.12.3.1.13.7 • Create role accounts: e.g., domainadmincontact@example.com, domainregistrantcontact@example.biz, domaintechnicalcontact@example.net. (Note that when role accounts are used, periodic checks of such accounts are strongly recommended to confirm that the role account is monitored by registrant staff without interruption due to personnel, administrative or operational changes within the organization.)
1.2.12.3.1.13.8 • Alias multiple recipients for a role account for notifications. Use this form of mail explosion to provide “blanket delivery” for critical registrar correspondence to increase the likelihood that the correspondence is received and processed in a timely manner.
1.2.12.3.1.14 Inform the customer
1.2.12.3.1.14.1 Recommendation SAC007-(8): Registrars should improve registrant awareness of the threats of domain name hijacking and registrant impersonation and fraud, and emphasize the need for registrants to keep registration information accurate. Registrars should also inform registrants of the availability and purpose of the Registrar-Lock, and encourage its use. Registrars should further inform registrants of the purpose of authorization mechanisms (EPP authInfo), and should develop recommended practices for registrants to protect their domains, including routine monitoring of domain name status, and timely and accurate maintenance of contact and authentication information.
1.2.12.3.1.15 Measures from prior SSAC reports
1.2.12.3.1.15.1 Use a unique EPP authInfo code value for each registered domain name
1.2.12.3.1.15.2 Establish a uniform default setting of domain locks across registrars.
1.2.12.3.1.15.3 Investigate additional methods to improve accuracy of registrant records.
1.2.12.3.1.15.4 Collect emergency point of contact information from registrants, registrars, and resellers for parties who are suited to assist in responding to an urgent restoration of domain name incident.
1.2.12.3.1.15.5 Consider measures to improve authentication and authorization used in all registrar business processes.
1.2.12.3.1.15.6 Protect registrant information that can be used to facilitate fraud and impersonation, and theft of a domain name.
1.2.12.3.1.15.7 Improve auditing of resellers’ compliance with record keeping requirements.
1.2.12.3.1.15.8 Ensure that resellers understand record keeping requirements of registrars (and ICANN), and improve compliance with these requirements.
1.2.12.3.1.15.9 Provide clear and readily accessible information to registrants regarding domain locking and domain name protection measures offered by registrars.
1.2.13 Malicious or unintentional (erroneous) alteration of DNS configuration information SAC 44
1.2.13.1 Maliciously introduced changes to the DNS name server configuration information associated with a domain name may result in the resolution of the domain name to an IP address(es) other than the address(es) the domain registrant intended. Such changes can result in the loss or disruption of the registrant’s Internet services (e.g., web or email) or the intentional and malicious redirection of visitors away from the registrant’s intended servers to an attacker’s servers, which may host defacement, phishing or other malicious or criminal activities.7 Lack of coordination or administrative error can introduce changes to DNS name server configuration information with the similar consequences as malicious alteration. Such changes can result in the loss or disruption of the registrant’s Internet applications or services, or could expose the registrant’s organization to attack.8
1.2.13.2.1 Protecting DNS configuration information from abuse
1.2.13.2.1.1 Require multi-factor authentication for DNS configuration changes.
1.2.13.2.1.2 Require confirmations of change from multiple contacts using email, possibly via media other than email.
1.2.13.2.1.3 Deliver notifications to multiple contacts when changes performed.
1.2.13.2.1.4 Monitor DNS changes for anomalies or abuse.
1.2.13.2.1.5 Reduce scope of the authority of a given account
1.2.13.2.1.5.1 SAC 40 Finding (6) Commonly, once a user is authenticated at a registration account portal or login, the user (or imposter) has global privileges and can modify contact information as well as DNS configuration information. Making granular access controls available to customers as an optional service – in particular, the ability to limit the type of actions each point of contact is able to perform with regard to changing contact and DNS configuration information and authorizing transfers – could reduce or mitigate the risk of exploitation or misuse of domain names and name resolution services associated with those names.
1.2.13.2.1.5.2 Use separate identities for registrant, technical, administrative and billing contacts
1.2.13.2.1.5.2.1 Identifying multiple points of contact offers an organization some protection in situations where a single contact is provided for all roles and that contact ceases to be employed by an organization, or in a circumstance where the only identified contact is not available to resolve a problem or respond to a reported abuse of the domain name. Distinct points of contact also offer some diversity in managing domain names. Each of these contacts can represent departments or divisions in an organization that are responsible for some aspect of domain name management. For example, while legal staff or an IP&T department may be best suited to manage the registrant role, IT may be best suited to manage the technical role, corporate communications may be best suited to manage the administrative role, and finance best suited to manage the billing role.
1.2.13.2.1.5.3 Identify domain name registration points of contact by role
1.2.13.2.1.5.3.1 In cases where a domain name is registered to an organization (business entity), consider creating points of contact that do not create a relationship between any natural person or employee. This action may help an organization avoid disputes over ownership of a domain.
1.2.13.2.1.5.4 Add diversity to email contacts to reduce single points of failure or attack
1.2.13.2.1.5.4.1 Access to all the domains in a domain name registration account is commonly granted through a single user account. This access also allows an attacker to modify contact and DNS configuration information for all domains managed through the user account. Thus, if Example Networks, Inc. manages the domains example.net, example.com, and example.biz from the same domain name registration account and that account is compromised, the attacker can alter DNS and block delivery of mail to all of these domains.
1.2.13.2.1.6 Protect account credentials
1.2.13.2.1.6.1 Maintain a list of authorized contacts for each domain registration account;
1.2.13.2.1.6.2 2. Advise authorized contacts that they are responsible for keeping secret the account credentials for domain registration accounts, and that they must not disclose or share passwords;
1.2.13.2.1.6.3 3. Identify measures authorized contacts must take should they discover that credentials have been disclosed;
1.2.13.2.1.6.4 4. Authorized contacts must compose passwords used to access a registration account using applicable organizational policies and commonly recognized best practices for composition (e.g., length and complexity), re-use, and longevity;14
1.2.13.2.1.6.5 5. Alternatively, if the registrar supports a form of multi-factor authentication (e.g., a hardware or software token), authorized contacts must keep the token safe from loss, damage, or unauthorized use;
1.2.13.2.1.6.6 6. Use different credentials for each account;
1.2.13.2.1.6.7 7. Partition particularly sensitive or important domain registrations into an account whose credentials are held by more senior personnel;
1.2.13.2.1.6.8 8. Securely escrow all registration account credentials;
1.2.13.2.1.6.9 9. Define and implement a recovery process with detailed auditing;
1.2.13.2.1.6.10 10. Define the circumstances where recovery is permitted, who has authority to recover credentials from escrow, and who is to be notified when escrowed credentials are accessed;
1.2.13.2.1.6.11 11. Changes in personnel authorized as contacts for a registrar account should cause new credentials to be created and old credentials to be revoked. (This may require coordination with a registrar, i.e., in cases where the registrant intends to change the user account identifier.); and
1.2.13.2.1.6.12 12. Employee resource management processes such as employee termination and employee transfer should be modified to check if the employee has domain registration account access. The processes could be modeled after similar checks for employee access to other assets, such as financial accounts.
1.2.13.2.1.6.13 Incorporate registrar email correspondence into domain management
1.2.13.2.1.6.13.1 Ask your registrar for a list of correspondence routinely issued by email, and consult with your registrar to determine which of your email contacts is used for routine correspondence. Use your email system to route correspondence to the organization’s point of contact that is responsible for responding to or taking action. For example, consider whether you can route registrar email correspondence so that your technical contact receives DNS configuration change notices, your legal department receives renewal and WHOIS accuracy notices, etc.21
1.2.13.2.1.6.14 Keep key email accounts secure
1.2.13.2.1.6.14.1 Email is an important component of registrant- registrar communication. Key email accounts receive registrar notifications and registration account password reset/recovery messages and thus should only be accessed by authorized parties. Maintain the security of key email accounts by strengthening client authentication. Use encryption (TLS extensions for SMTP) to protect mail client-server communications from eavesdropping. Maintain secure operations at the mail server that hosts key email accounts as well. For example, mail servers that host key email accounts should be Internet standards compliant. Consider adopting some form of email reputation, data integrity or authentication system and follow best sender, forwarding, and antispam practices published by such organizations as the Messaging Anti-Abuse Working Group (MAAWG)22 and the Anti-Phishing Working Group (APWG)23 so that your mail servers will not be reported to spam blacklists.
1.2.13.2.1.6.15 Maintain accurate external contacts
1.2.13.2.1.6.15.1 The SSAC encourages registrants to catalog points of contact information for registrars where they have domain registration accounts and make these available to all internal and contracted parties who are involved in domain name management. Registrar points of contact of particular interest for registrants include any contact that may assist the registrant in a business, operational or security matter. The list may include general information contacts, false WHOIS and abuse contacts, and (where applicable) internal contacts responsible for your account portfolio, abuse, spam, etc.
1.2.13.2.1.7 Take advantage of routine correspondence from registrars
1.2.13.2.1.7.1 Use domain name renewal notifications to trigger a review or renewal action by staff responsible for Intellectual Property and Trademark matters, marketing, or generally any group that should decide whether to renew or allow a registration to expire.
1.2.13.2.1.7.2 2. Use WHOIS accuracy reporting obligation notifications to trigger action by staff to review and then confirm or update the registration information that must be publicly accessible via WHOIS services.
1.2.13.2.1.7.3 3. Use configuration change notifications to trigger checks by technical staff to verify that the changes are authorized and correct. Registrars may issue change notifications for any of the following events:
1.2.13.2.1.7.3.1 Domain name servers. Unauthorized or erroneous additions, deletions or changes to the list of domain name servers (or the IP addresses registered for those servers) that resolve the subdomains (labels) of a domain can result in disruption of service and should be confirmed by staff responsible for managing the organization’s DNS.
1.2.13.2.1.7.3.2 b. Contact information. Changes to registrant, administrative, or technical contact information should be confirmed to prevent attempts to divert ownership or correspondence away from authorized representatives of the organization.
1.2.13.2.1.7.3.3 c. Changes to domain status at registry. Registrars and registries coordinate the state (status) of a domain name in a registry using provisioning protocols.16 Registrars publish the status of a domain via WHOIS. Changes to domain status should be confirmed to assure that the domain is in the organization’s desired operational state.
1.2.13.2.1.7.3.4 d. Changes to domain status at registrar. Certain registrars allow domain- specific settings (e.g. private registration, domain forwarding, autorenew) that are held at the registrar. Changes to these services can have both long-term and short-term impact and therefore changes should be confirmed.
1.2.13.2.1.7.4 4. Use notifications regarding changes to or pending expiration of credit card or other payment methods and associated billing information to trigger checks by accounting personnel to ensure that changes are authorized and correct, needed payments are scheduled, and scheduled payments are not declined.
1.2.13.2.1.7.5 5. Designate a responsible party for each notification or have the notification trigger the creation of a ticket in a ticketing system. Such measures ensure that no notifications are ignored or are not responded to in the necessary or appropriate timeframe.
1.2.13.2.1.7.6 6. Define required responses and establish a clear SLA for each response to each type of event.
1.2.13.2.1.7.7 7. In order to protect email delivery against disruption attacks, contact email addresses for a domain should be assigned to mail servers named outside that domain and registration account. For example, if the domain example.net is managed through an account A at registrar X, use email addresses assigned from a different domain (example.biz) managed through an account B (and possibly at registrar Y). This measure prevents an attacker who succeeds in compromising a domain account from preventing delivery of notification emails by altering DNS configuration for a domain.
1.2.13.2.1.8 Maintain documentation to "prove registration"
1.2.13.2.1.8.1 Suggested documentation includes:
1.2.13.2.1.8.2 • Copies of registration records;
1.2.13.2.1.8.3 • Billing records, especially ones that show payments have been made;
1.2.13.2.1.8.4 • Logs, archives, or financial transactions that associate a domain name with content that you, the rightful registrant, published.
1.2.13.2.1.8.5 • Telephone directories (Yellow Pages), marketing material, etc. that contain advertising that associates you, the registrant, with the domain name;
1.2.13.2.1.8.6 • Correspondence to you from registrars and ICANN that mentions the domain name; and
1.2.13.2.1.8.7 • Legal documents, tax filings, government-issued IDs, business tax notices, etc. that associate you, the registrant, with the domain name.
1.2.13.2.1.9 Improve change control and coordination
1.2.13.2.1.9.1 Large organizations often implement resource management to deal with changes in personnel or equipment to domain registrations that must be coordinated across departments or business units. These are characterized as “add, drop, change” processes. Domain name management shares characteristics with such resource management structures. Organizations should consider the value of using registrar correspondence to trigger intra-organizational activity. For example, an organization may want to have the technical contact for a domain name notify all departments whose system configurations include name servers upon receipt of a confirmation email from a registrar when a change to DNS name servers for the domain is made. Organizations should consider the value of implementing measures to notify registrant, technical, or administrative contacts when changes are made to any contact or configuration information for any domain name registered by the organization.
1.2.13.2.2 Measures to detect or prevent unauthorized change activity
1.2.13.2.2.1.1 Routine monitoring to detect, isolate, and identify suspicious or anomalous behavior is a common, proactive best practice across networking and security disciplines.
1.2.13.2.2.2 Monitoring for WHOIS change activity
1.2.13.2.2.2.1 Organizations and individuals should consider measures to routinely monitor registration information for all registered domains.
1.2.13.2.2.2.2 Compare the results against the registration data you expect to find. In particular, and for each domain name you have registered, ask the following questions:
1.2.13.2.2.2.2.1 • Does the date indicated as the last date on which the registration was modified match the date you most recently made an authorized change to your registration?
1.2.13.2.2.2.2.2 • Are the data returned in WHOIS responses for registrant, technical, and administrative contacts for this domain name complete and accurate (i.e., the data are exactly what you intended to be published)?
1.2.13.2.2.2.2.3 • Are the names servers listed in the registration record the exact list of name servers that provide authoritative name service for your organization?
1.2.13.2.2.2.2.4 • Is the sponsoring registrar the registrar with whom you do business for this domain name?
1.2.13.2.2.2.2.5 • Is the status of the domain what you expect it to be? (Refer to section 7.3 Setting and Monitoring Domain Status.)
1.2.13.2.2.2.2.6 • Do the creation and expiration dates for the domain registration match the dates you registered the domain and the date on which your current registration expires?
1.2.13.2.2.2.2.7 • Is the DNSSEC signing information correct? (Refer to section 6.2 DNSSEC Support Considerations.)
1.2.13.2.2.2.3 Inaccuracies or omissions in the data returned from one or more WHOIS services merit immediate action. Organizations can model this action after other problem resolution or incident responses your organization uses and should take into consideration factors that justify escalating the event from a trouble report to an incident.
1.2.13.2.2.3 Monitoring DNS change activity
1.2.13.2.2.3.1 Organizations and individuals should consider measures to routinely monitor the operational status and zone data published by authoritative name servers for all registered domains.
1.2.13.2.2.3.1.1 The objectives of this monitoring activity are to assure that name service for each domain name registered by your organization remains configured as you intended it to be and returns complete and accurate data in accordance with DNS standards and best practices.
1.2.13.2.2.3.2 Confirmation activities
1.2.13.2.2.3.2.1 Are the name servers identified in the WHOIS response for the domain name the complete and accurate set of name servers that your organization has identified as providing authoritative name service for the domain?
1.2.13.2.2.3.2.2 Are the name servers published in the TLD zone file for the domain name the complete and accurate set of name servers that your organization has identified as providing authoritative name service for the domain?
1.2.13.2.2.3.2.3 Are the name servers operational (e.g., do the hosts respond to a ping or simple DNS query)? Are they performing as expected?
1.2.13.2.2.3.2.4 Are all the name servers secured (hardened against known attacks)? Are all software (OS, name server) packages current with respect to approved versions (e.g., tested and approved by your technical staff), released hot fixes and patches?
1.2.13.2.2.3.2.5 Are the name servers responding in manners consistent with your baseline correct configuration?
1.2.13.2.2.3.2.6 Do all the name servers that provide authoritative name service for the domain return complete and correct zone data for all formulations of DNS queries against the zone?
1.2.13.2.2.4 Setting and monitoring domain status (domain locks)
1.2.13.2.2.4.1 Registrar status codes
1.2.13.2.2.4.1.1 Certain registrars permit registrants to control one or more registrar (client) status codes. The following status codes, also known as registrar locks, are of particular importance to registrants:
1.2.13.2.2.4.1.1.1 clientTransferProhibited. When set, the registry will not allow a registrar to accept a transfer of the domain name away from the sponsoring registrar. Certain registrars automatically keep the clientTransferProhibited status set on domain names and registrants use a third party authorization process between the “transfer-from” registrar, the “transfer-to” registrars and the registry to protect against unauthorized transfers.
1.2.13.2.2.4.1.1.2 clientUpdateProhibited. When set, the registry will not make changes to the registration details of the domain name. Certain registrars automatically unlock and re-lock this status when a registrant has successfully logged into a domain account. Other registrars allow registrants to unlock and re-lock this status through a domain management interface.
1.2.13.2.2.4.1.1.3 clientDeleteProhibited. When set, the registry will reject requests to delete a domain name from the registry.
1.2.13.2.2.4.1.2 The SSAC encourages registrants to make certain that clientTransferProhibited is set to prevent unauthorized or unintended transfer of a domain away from the rightful registrant to a different party (e.g., a hijacker).
1.2.13.2.2.4.1.3 SSAC also encourages registrants to make certain that clientUpdateProhibited is set to prevent changes to registration contact or DNS configuration information without first unlocking this status.
1.2.13.2.2.4.1.4 Many registrars issue notifications when certain client status codes are modified. These notifications are extremely important because they may forewarn registrants of unauthorized registration account access.
1.2.13.2.2.4.2 Registry status codes
1.2.13.2.2.4.2.1 Certain registrars and registries work cooperatively to offer registrants the ability to add server status codes (registry locks) as an additional layer of protection beyond client status codes.
1.2.13.2.2.4.2.2 We encourage you to consider setting registry locks as a complement to registrar locks for a second level of security against unauthorized transfer, deletion or change of registration information associated with your domain names.
1.2.14 Malicious or unintentional (erroneous) alteration of contact information SAC 44
1.2.14.1 Whether by error or as a result of an attack, changes to the contact configuration information associated with a domain name may result in:
1.2.14.2 a. The unauthorized transfer or wrongful taking of control of a domain name from the rightful name holder (domain name hijacking);9
1.2.14.3 b. Disruption of delivery of registrar correspondence to the domain name registrant or authorized administrators (e.g., non-delivery of email correspondence because the email address points to a non-deliverable recipient or an invalid domain);
1.2.14.4 c. The filing of a report of WHOIS inaccuracy against the registrant which could lead to an suspension or deletion of the domain name, or a report that falsely or incorrectly associates a domain with an abuse and causes a suspension of the domain; and
1.2.14.5 d. The deletion of a domain name registration by the unauthorized party (or in general, the unauthorized alteration of any domain setting accessible via a registrar’s domain account management tools, including renewal options, domain locks, etc.). Such malice or error can cause a disruption of name service, malicious name resolution, or loss of the registration of the domain name itself.
1.3.1.1 IPv6 -- Spammers hopping from IP to IP -- causing huge numbers of lookups -- volume related threats (perhaps unintentional) -- also may break normal DNS caching (whicha assumes repeated requests for the same thing)
1.3.1.2 Issues around reverse DNS for SMTP servers
1.3.1.4 Collateral damage
1.3.2 Registration abuse -- front-running
1.3.2.2 Issue statement - SAC 22
1.3.2.2.1 This Advisory considers the opportunity for a party with some form of insider informa- tion to track an Internet user’s preference for registering a domain name and preemptive- ly register that name. SSAC likens this activity to front running in stock and commodities markets and calls this behavior domain name front running. In the domain name indus- try, insider information would be information gathered from the monitoring of one or more attempts by an Internet user to check the availability of a domain name.
1.3.3 Registration abuse -- cybersquatting
1.3.4 WHOIS abuse -- harvesting WHOIS data for spam
1.3.4.2 Issue statement - SAC 3
1.3.4.2.1 It is widely believed that the Whois data is a source of email addresses for the delivery of SPAM and other unsolicited and otherwise unwanted email messages. Consequently, many Registrars have started offering their Whois data in random formats to deter harvesting. This is unfortunate because a common format is necessary to ensure that the data is readily accessible and understandable when it is needed. We must encourage not only the use of a common format but the development of mechanisms to prevent the harvesting and mining of Whois data.
1.3.5 WHOIS abuse -- harvesting personal contact information from domain name registration records -- SAC 14