1.1 Threats on the underlying infrastructure. May include:
1.1.1 TLD and registrar failure
1.1.2.1 Natural disasters
1.1.3 Authority or authentication compromise
1.1.4 Government interventions
1.1.5.2 Facility security
1.1.6 External events (non Internet protocol events?)
1.1.6.1 Acts of war/terror
1.1.6.3 Physical disasters
1.2.1 Cache poisoning attacks
1.2.2 Recursive vs authoritative nameserver attacks
1.2.8 Gain control of account user/password
1.2.8.1 Guess, phish or apply social engineering techniques on a weak point of contact
1.2.8.2 Block delivery of email notifications to targeted registrants by altering DNS configuration
1.2.9 IDN attacks (lookalike characters etc. for standard exploitation techniques)
1.2.10.2 Hacking/penetration
1.2.10.3 Data poisoning (MITM, Cache)
1.2.11 Reflection attacks
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.4.2 Alternate DNS roots
2.1.1 Informality of some processes
2.2 Managerial choices/issues
2.2.1 Lack of visibility and understanding by decision-makers
2.2.2 Inadequate funding (for infrastructure, training, etc.)
2.2.3 registrar automation patterns/behaviors
2.2.4 inadequate assessment of risks associated with loss of control of domains/registrar-accounts
2.2.5 Customers are unfamiliar with registration protection measures
2.2.6 Registrars have different target markets and service models
2.2.7 Not following best practices
2.2.7.1 Prevent access to domain portfolio
2.2.7.1.1 Registration verification
2.2.7.1.2 Improve password-based authentication system
2.2.7.1.3 Register a PC or IP address from which to administer an account
2.2.7.1.4 Multi-factor authentication
2.2.7.1.5 Challenge systems
2.2.7.1.6 Per-domain access controls
2.2.7.1.7 Multiple, unique points of contact
2.2.7.1.8 Change notifications or confirmations
2.2.7.1.9 Multi-recipient notifications
2.2.7.1.10 Multiple delivery methods for critical correspondence
2.2.7.1.11 Engaging the customer
2.2.7.1.11.1 Identify multiple domain account points of contact
2.2.7.1.11.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.
2.2.7.1.11.3 • Impose a password change policy. • Periodically verify contacts. • Proactively monitor domain name registration.
2.2.7.1.11.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.)
2.2.7.1.11.5 • Treat transfer attempts as a security event (check and re-check).
2.2.7.1.11.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.
2.2.7.1.11.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.)
2.2.7.1.11.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.
2.2.7.1.12 Inform the customer
2.2.7.1.13 Measures from prior SSAC reports
2.2.7.1.13.1 Use a unique EPP authInfo code value for each registered domain name
2.2.7.1.13.2 Establish a uniform default setting of domain locks across registrars.
2.2.7.1.13.3 Investigate additional methods to improve accuracy of registrant records.
2.2.7.1.13.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.
2.2.7.1.13.5 Consider measures to improve authentication and authorization used in all registrar business processes.
2.2.7.1.13.6 Protect registrant information that can be used to facilitate fraud and impersonation, and theft of a domain name.
2.2.7.1.13.7 Improve auditing of resellers’ compliance with record keeping requirements.
2.2.7.1.13.8 Ensure that resellers understand record keeping requirements of registrars (and ICANN), and improve compliance with these requirements.
2.2.7.1.13.9 Provide clear and readily accessible information to registrants regarding domain locking and domain name protection measures offered by registrars.
2.2.7.2 Protecting DNS configuration information from abuse
2.2.7.2.1 Require multi-factor authentication for DNS configuration changes.
2.2.7.2.2 Require confirmations of change from multiple contacts using email, possibly via media other than email.
2.2.7.2.3 Deliver notifications to multiple contacts when changes performed.
2.2.7.2.4 Monitor DNS changes for anomalies or abuse.
2.2.7.3 Lack of ongoing attention/review of security practices -- making decisions at one time, but not going back to review those choices
2.2.7.3.1 Example -- Finding (2) While there are a large number of registrars that offer consumer-focused domain name registration services, and a smaller number of registrars and “brand management” organizations that offer security services to high-profile, highly targeted domain name holders (typically as part of an overall brand equity protection service), SSAC notes that “pure play, secure” registration service providers are rare, in part due to the fact that evaluating security measures does not play as prominent a role in customer decisions when choosing a registrar as it should. SAC 40
2.3 Implementation errors (hardware and software)
2.5 Single point of failure
2.5.6 Infrastructure (electricity, fiber, etc.)
2.5.7 Email is the preferred (often only) method by which registrars attempt to notify a registrant of account activity
2.5.8 Access/ability to modify contact/DNS configuration to all domains in a registration account is commonly granted through a single user account and password
2.6 Supporting infrastructure (insufficient SLA's, support, etc)
2.7 Homogeneity (software, hardware, etc) -- small gene pool, one vulnerability could have broad impact
2.8 Poor design (hardware and software)
2.9 Vulnerability of DNS software, OS, etc.
2.9.1 registrar automation patterns/behaviors
2.11 Content provisioning exposure -- eg Akemi -- if credentials leak, there's broad exposure -- registrar account credentials
2.13 DNSSEC private key exposure
2.14.2 Geo-political groups
3.1.1 Threats that leverage the DNS
3.1.2 Threats against the underlying infrastructure
3.2.1 Attacks on the protocol layer below the DNS
3.4.1 so the several recent papers by eff, zhang and others on isp monitizing synthetic return/content modification
3.4.2 No single authoritative DNS (eg alternate root-servers) , lack of DNS response integrity
3.4.3 alternate root, strings appearing in other configurations not supported in the global root
3.4.4 Possible extensions of carrier-grade NAT
3.5 Question from the group: "What is the perspective of threat description?"
3.5.1 RFC - 3833 -- user, app, OS, ISP, DNS, registrar, registrant, registry -- threat analysis to the domain name system
3.5.3 Registrant <--> Registrar) Compromised credentials (Phishing, Key logger, social engineering, a.o.)
3.5.4 Registrar <--> Regisrty) Compromised credentials, DDOS
3.5.5 Registry <--> DNS) DDOS
3.5.6 DNS <--> End user) Spoofing, poisoning
3.5.7 ALL) MIM (Man in the middle)
4.1.1.1 Leverage the DNS and unique identifiers (such as botnets, denial of service attacks, social engineering attacks) for fraud, malicious conduct or route-hijacking attacks
4.3.1 The process to restore DNS information can take a long time even when unauthorized modification of DNS information is discovered quickly
4.5 Possible Recommendations
4.5.1 ICANN develops catalog of registry, registrar and registrant security services
4.5.1.1.1 Possibility of painting a roadmap for bad actors
4.5.1.1.1.1.1 Keep the list confidential
4.5.1.1.1.1.2 List only entities that are secure -- provides a less accurate target for attackers
4.5.1.2.1 Improves decision-making on the part of registrants
4.5.1.2.1.1 Finding (1) Differences exist among registrars as to their vulnerability to attack and the degree of protection they provide against attacks on domain accounts. Many domain registrants do not appear to have sufficient information to assess the extent to which a registrar is able to protect its domain accounts from attack and DNS configurations from malicious alteration. SAC 40
4.5.1.2.1.2 Finding (3) Registrars could make more information about their security services available to allow customers to make informed decisions. Voluntarily submitting operations to an independent security audit and publicizing successful outcomes of such audits would allow customers to choose a registrar based on security requirements as well as cost and other ancillary features (such as web and DNS hosting). SAC 40
5.1.1 SAC 40 Measures to Protect Domain Registration Services Against Exploitation or Misuse
5.1.1.1 http://www.icann.org/en/committees/security/sac040.pdf
5.1.1.2.1 high value names
5.1.1.2.2 registrar automation patterns/behaviors
5.1.1.2.3 inadequate assessment of risks associated with loss of control of domains/registrar-accounts
5.1.1.2.4 Email is the preferred (often only) method by which registrars attempt to notify a registrant of account activity
5.1.1.2.5 Access/ability to modify contact/DNS configuration to all domains in a registration account is commonly granted through a single user account and password
5.1.1.2.6 Customers are unfamiliar with registration protection measures
5.1.1.2.7 Registrars have different target markets and service models
5.1.1.2.8 The process to restore DNS information can take a long time even when unauthorized modification of DNS information is discovered quickly
5.1.1.3 attacks against domain name registration accounts
5.1.1.3.3 ICANN, PhotoBucket, RedTube
5.1.1.4.1.1 Gain control of account user/password
5.1.1.4.1.2 Guess, phish or apply social engineering techniques on a weak point of contact
5.1.1.4.1.3 Block delivery of email notifications to targeted registrants by altering DNS configuration
5.1.1.5.1 Prevent access to domain portfolio
5.1.1.5.1.1 Registration verification
5.1.1.5.1.2 Improve password-based authentication system
5.1.1.5.1.3 Register a PC or IP address from which to administer an account
5.1.1.5.1.4 Multi-factor authentication
5.1.1.5.1.5 Challenge systems
5.1.1.5.1.6 Per-domain access controls
5.1.1.5.1.7 Multiple, unique points of contact
5.1.1.5.1.8 Change notifications or confirmations
5.1.1.5.1.9 Multi-recipient notifications
5.1.1.5.1.10 Multiple delivery methods for critical correspondence
5.1.1.5.1.11 Engaging the customer
5.1.1.5.1.11.1 Identify multiple domain account points of contact
5.1.1.5.1.11.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.
5.1.1.5.1.11.3 • Impose a password change policy. • Periodically verify contacts. • Proactively monitor domain name registration.
5.1.1.5.1.11.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.)
5.1.1.5.1.11.5 • Treat transfer attempts as a security event (check and re-check).
5.1.1.5.1.11.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.
5.1.1.5.1.11.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.)
5.1.1.5.1.11.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.
5.1.1.5.1.12 Inform the customer
5.1.1.5.1.13 Measures from prior SSAC reports
5.1.1.5.1.13.1 Use a unique EPP authInfo code value for each registered domain name
5.1.1.5.1.13.2 Establish a uniform default setting of domain locks across registrars.
5.1.1.5.1.13.3 Investigate additional methods to improve accuracy of registrant records.
5.1.1.5.1.13.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.
5.1.1.5.1.13.5 Consider measures to improve authentication and authorization used in all registrar business processes.
5.1.1.5.1.13.6 Protect registrant information that can be used to facilitate fraud and impersonation, and theft of a domain name.
5.1.1.5.1.13.7 Improve auditing of resellers’ compliance with record keeping requirements.
5.1.1.5.1.13.8 Ensure that resellers understand record keeping requirements of registrars (and ICANN), and improve compliance with these requirements.
5.1.1.5.1.13.9 Provide clear and readily accessible information to registrants regarding domain locking and domain name protection measures offered by registrars.
5.1.1.5.2 Protecting DNS configuration information from abuse
5.1.1.5.2.1 Require multi-factor authentication for DNS configuration changes.
5.1.1.5.2.2 Require confirmations of change from multiple contacts using email, possibly via media other than email.
5.1.1.5.2.3 Deliver notifications to multiple contacts when changes performed.
5.1.1.5.2.4 Monitor DNS changes for anomalies or abuse.
5.1.1.6.1 Finding (1) Differences exist among registrars as to their vulnerability to attack and the degree of protection they provide against attacks on domain accounts. Many domain registrants do not appear to have sufficient information to assess the extent to which a registrar is able to protect its domain accounts from attack and DNS configurations from malicious alteration.
5.1.1.6.2 Finding (2) While there are a large number of registrars that offer consumer-focused domain name registration services, and a smaller number of registrars and “brand management” organizations that offer security services to high-profile, highly targeted domain name holders (typically as part of an overall brand equity protection service), SSAC notes that “pure play, secure” registration service providers are rare, in part due to the fact that evaluating security measures does not play as prominent a role in customer decisions when choosing a registrar as it should.
5.1.1.6.3 Finding (3) Registrars could make more information about their security services available to allow customers to make informed decisions. Voluntarily submitting operations to an independent security audit and publicizing successful outcomes of such audits would allow customers to choose a registrar based on security requirements as well as cost and other ancillary features (such as web and DNS hosting).
5.1.1.6.4 Finding (4) Registrar services (and registrants) place greater confidence on the single factor authentication for login to accounts than the method merits. This authentication method has been repeatedly circumvented using various forms of social engineering, brute force attacks, and other techniques.
5.1.1.6.5 Finding (5) Attackers target DNS configuration when they succeed in compromising a domain registration account. Due to the distributed nature of the DNS, the effects of altering DNS configuration information persist beyond recovery and mitigation efforts by registrars. Malicious or incorrect DNS information can persist in locations throughout the Internet for the full duration of the TTL value associated with the altered DNS resource record(s). Attackers may alter the TTL specifically for this purpose.
5.1.1.6.6 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.
5.1.1.6.7 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.
5.1.1.7.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.
5.1.1.7.2 Recommendation (1) Registrars are encouraged to offer stronger levels of protection against domain name registration service exploitation or misuse for customers who want or need them. Measures enumerated in this report can be offered as optional services to customers, individually or bundled.
5.1.1.7.3 Recommendation (2) Registrars should expand existing FAQs and education programs they offer to registrants to include security awareness. Registrars should make information concerning the services they offer to protect domain registration accounts more accessible to customers so that they can make informed decisions regarding protective measures when they choose a registrar.
5.1.1.7.4 Recommendation (3) Registrars should consider the value of voluntarily having an independent security audit performed on their operations as a component of their security due diligence.
5.1.1.7.5 Recommendation (4) ICANN and registrars should study whether registration services would generally improve and registrants would benefit from having an approved independent third party that will, at the request of a registrar, perform a security audit based on a prescribed set of security measures. ICANN would distinguish registrars that voluntarily satisfy the benchmarks of this security audit through a trusted security mark program that is implemented in a manner similar to the way that SSL certificate issuing authorities provide trust marks or seals for web site operators who satisfy that authority’s security criteria.
5.1.2 SAC 44 A Registrant's Guide to Protecting Domain Name Registration Accounts
5.1.2.1 http://www.icann.org/en/committees/security/sac044.pdf
5.1.2.2.1 Unauthorized access to domain registration account
5.1.2.2.1.1 Malicious or unintentional (erroneous) alteration of DNS configuration information
5.1.2.2.1.1.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
5.1.2.2.1.2 Malicious or unintentional (erroneous) alteration of contact information
5.1.2.2.1.2.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:
5.1.2.2.1.2.2 a. The unauthorized transfer or wrongful taking of control of a domain name from the rightful name holder (domain name hijacking);9
5.1.2.2.1.2.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);
5.1.2.2.1.2.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
5.1.2.2.1.2.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.
5.1.2.2.2 Failure to renew a domain name registration
5.1.2.2.2.1 A renewal lapse occurs when, by choice or oversight, a registrant allows a domain name registration to expire. A different party may register the domain name after the expiration of relevant grace periods. In some cases, the activities of the new registrant may prove harmful to the interests of the registrant who permitted the registration to expire.10 In other cases, the registrant may lose the domain name and be forced to find another domain name (thereby absorbing the costs of switching to a new domain name) or to pursue a potentially costly and time- consuming dispute resolution process to regain control of the domain name.
5.1.2.2.3 Non-renewal of a domain name associated with a DNS Name Server
5.1.2.2.3.1 Problems may arise when the registrant of a domain name A uses a DNS name server in domain B for domain name resolution, and the registrant of domain name B accidentally or intentionally allows its domain name registration to expire. In circumstances where coordination across well-intentioned parties is lost, the expected resolution of domain A may be interrupted or may become unpredictable due to A’s dependence on the name server in domain B; in other circumstances, a new registrant of domain B may configure domain A's DNS information for malicious purposes, including phishing attacks, email interception, and redirection of Internet users to different websites with different and possibly harmful content.11 While domain A can be restored to proper function by updating the registry with a new name server (perhaps on domain A or C), this can present operational challenges to accomplish in the extreme short term.
5.1.2.2.4 Registration abuse -- front-running
5.1.2.2.5 Registration abuse -- cybersquatting
5.1.2.3 Risk Management and domain names
5.1.2.3.1 Identify the value of an asset (tangible or intangible);
5.1.2.3.2 • List the ways in which that value is threatened (loss, theft, misuse);
5.1.2.3.3 • Determine how the threat can be realized, i.e., what makes the domain name vulnerable to attack or exploitation;
5.1.2.3.4 • Determine the probability or risk that each threat poses;
5.1.2.3.5 • Determine how the risk can be mitigated or reduced;
5.1.2.3.6 • Determine the cost of mitigating or reducing the risk to an acceptable level of risk and cost; and
5.1.2.3.7 • Determine the appropriate budget/priority and implement risk mitigation or reduction.
5.1.2.4 Measures to protect domain registrar account compromise
5.1.2.4.1 Protection against unauthorized access
5.1.2.4.1.1 Protect account credentials
5.1.2.4.1.1.1 Maintain a list of authorized contacts for each domain registration account;
5.1.2.4.1.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;
5.1.2.4.1.1.3 3. Identify measures authorized contacts must take should they discover that credentials have been disclosed;
5.1.2.4.1.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
5.1.2.4.1.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;
5.1.2.4.1.1.6 6. Use different credentials for each account;
5.1.2.4.1.1.7 7. Partition particularly sensitive or important domain registrations into an account whose credentials are held by more senior personnel;
5.1.2.4.1.1.8 8. Securely escrow all registration account credentials;
5.1.2.4.1.1.9 9. Define and implement a recovery process with detailed auditing;
5.1.2.4.1.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;
5.1.2.4.1.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
5.1.2.4.1.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.
5.1.2.4.1.2 Take advantage of routine correspondence from registrars
5.1.2.4.1.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.
5.1.2.4.1.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.
5.1.2.4.1.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:
5.1.2.4.1.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.
5.1.2.4.1.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.
5.1.2.4.1.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.
5.1.2.4.1.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.
5.1.2.4.1.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.
5.1.2.4.1.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.
5.1.2.4.1.2.6 6. Define required responses and establish a clear SLA for each response to each type of event.
5.1.2.4.1.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.
5.1.2.4.1.3 Maintain documentation to "prove registration"
5.1.2.4.1.3.1 Suggested documentation includes:
5.1.2.4.1.3.2 • Copies of registration records;
5.1.2.4.1.3.3 • Billing records, especially ones that show payments have been made;
5.1.2.4.1.3.4 • Logs, archives, or financial transactions that associate a domain name with content that you, the rightful registrant, published.
5.1.2.4.1.3.5 • Telephone directories (Yellow Pages), marketing material, etc. that contain advertising that associates you, the registrant, with the domain name;
5.1.2.4.1.3.6 • Correspondence to you from registrars and ICANN that mentions the domain name; and
5.1.2.4.1.3.7 • Legal documents, tax filings, government-issued IDs, business tax notices, etc. that associate you, the registrant, with the domain name.
5.1.2.4.2 Domain name points of contact considerations
5.1.2.4.2.1 Use separate identities for registrant, technical, administrative and billing contacts
5.1.2.4.2.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.
5.1.2.4.2.2 Incorporate registrar email correspondence into domain management
5.1.2.4.2.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
5.1.2.4.2.3 Identify domain name registration points of contact by role
5.1.2.4.2.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.
5.1.2.4.2.4 Add diversity to email contacts to reduce single points of failure or attack
5.1.2.4.2.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.
5.1.2.4.2.5 Keep key email accounts secure
5.1.2.4.2.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.
5.1.2.4.2.6 Improve change control and coordination
5.1.2.4.2.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.
5.1.2.4.2.7 Maintain accurate external contacts
5.1.2.4.2.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.
5.1.2.5 DNS hosting considerations
5.1.2.5.1 Zone data management considerations
5.1.2.5.2 DNSSEC support considerations
5.1.2.6 Measures to detect of prevent unauthorized change activity
5.1.2.6.1 Monitoring for WHOIS change activity
5.1.2.6.2 Monitoring DNS change activity
5.1.2.6.3 Setting and monitoring domain status (domain locks)
5.1.2.7 Considerations when choosing a domain registration service provider
5.1.2.8 Registry considerations
5.2 RFC - 3833 -- user, app, OS, ISP, DNS, registrar, registrant, registry -- threat analysis to the domain name system - http://www.ietf.org/rfc/rfc3833.txt
5.2.1.1 Packet Interception
5.2.1.1.1 Man in the middle, eavesdropping combined with spoofed responses that beat the real response back to the resolver, etc
5.2.1.2 ID Guessing and Query Prediction
5.2.1.2.1 Generate packets which match the transport protocol parameters, predict ID based on previous traffic, etc.
5.2.1.3.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.
5.2.1.4 Betrayal by Trusted Server
5.2.1.4.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.
5.2.1.5 Denial of Service
5.2.1.6 Denial of service amplifier
5.2.1.7 Authenticated Denial of Domain Names
5.2.1.7.1 Question is whether there is a requirement for authenticating the non-existence of a name.
5.2.2 Weaknesses of DNSSEC (vulnerabilities?)
5.2.2.1 Configuration errors -- DNSSEC is complex to implement, trivial zone-configuration errors can cause serious problems for resolvers and error-reporting capabilities leave something to be desired.
5.2.2.3 Increased load, due to increased packet size as a result of DNSSEC
5.2.2.4 Increased response-time -- also due to increased packet size which increases bandwidth and processor load
5.2.2.5 Hierarchical trust model -- similar to the broader vulnerability introduced by a hierarchical trust model, compromises of zones in between root and a particular target name can damage the integrity of DNSSEC's ability to protect the integrity of the data owned by that target name.
5.2.2.6 Key rollover -- hard to do, with attendant vulnerability
5.2.2.7 Requirement for time-synchronization -- in order to determine whether keys have expired.
5.2.2.8 Wildcard RRs in a zone - complicates authentication, inherently more complex
5.2.3 Securing DNS Dynamic Update
5.2.4 Securing DNS Zone Replication