1: Zone – Name Servers
To ensure name server (NS) host names are secure, the NS records are published within the parent zone of .Insurance.
2: Zone – DNSSEC
- Migrating DNS without disrupting DNSSEC
- Please contact compliance@fTLD.com with questions.
- The following cryptographic algorithms are excluded from use
- SHA1 digest in DS, CDS, and SSHFP records
- RSASHA1 for DNSKEY and CDNSKEY records
- For organizations that outsource DNSSEC management and/or domain management, they must ensure their vendor is able to successfully generate keys, sign their zones, generate and upload the DS records and manage key rollovers. A variety of vendors including web hosting companies, registrars, and DNS providers will have offerings that can comply with this DNSSEC requirement.
3: Encryption – Certificate Requirement
- As .Insurance is on the HSTS preload list, domains that are not secured with a TLS certificate (i.e. HTTPS) will not be accessible via browsers following this list (e.g., Google Chrome). As a global HSTS security policy becomes increasingly common, additional browsers are expected to block sites that are not HTTPS compliant.
4: Encryption – Secure Connections
To provide enhanced security for .Insurance website and email, fTLD requires the following encryption settings:
- Web Connections: TLS v1.2 or greater must be implemented and TLS v1.0 must be disabled. TLS v1.3 is recommended.
- Server-to-Server Email: For domains sending or receiving email, TLS v1.2 or greater must be offered. Earlier versions of TLS/SSL are permitted.
- Other Services: TLS v1.2 or greater must be implemented and TLS v1.0 must be disabled.
- RFC 5746 must be implemented (preventing a known man-in-the-middle attack).
The following non-exhaustive list of cipher suite components (authentication, encryption, message authentication code and key exchange algorithms) are excluded from use in-zone and in the generation of TLS certificates:
Anon, DES, 3DES, FIPS, GOST 28147-89, IDEA, SEED, WITH_SEED, MD5, NULL, SHA (SHA1), RC4, EXPORT, EXPORT1024 and SRP.
Cipher Block Chaining (CBC) Encryption: fTLD recommends excluding CBC cipher suite components from use where feasible due to known vulnerabilities. Registrants can confirm their TLS web connection encryption with a public tool such as: https://www.ssllabs.com/ssltest/index.html.
In 2013, researchers demonstrated a timing attack against several TLS implementations using the CBC encryption algorithm. Additionally, the CBC mode is vulnerable to plain-text attacks in TLS v1.0, SSL 3.0 and lower. A fix has been introduced with TLS v1.2 in the form of the GCM mode which is not vulnerable to the BEAST attack. GCM should be preferred over CBC and search for CBC here: https://ciphersuite.info/ to learn more.
TLS Encryption on Ports for Web Services
Only high encryption ciphers should be used; low and medium ciphers, which are equal to or less than 128 bits, must be disabled.
Ensure the server for your domain is using the appropriate TLS versions on ports for web services by implementing STARTTLS. Any ports not offering services should be closed. The following is a list of the ports tested:
| 21 | FTP |
| 22 | SSH |
| 23 | FTP |
| 25 | SMTP |
| 80 | HTTP |
| 110 | POP |
| 143 | IMAP |
| 389 | LDAP |
| 443 | HTTPS |
| 500 | ISAKMP |
| 513 | rlogin |
| 514 | rcmd |
| 587 | SMTP |
| 636 | LDAPS |
| 993 | IMAPS |
| 995 | POP3S |
| 989 | FTPS |
| 990 | FTPS |
Traffic should be encrypted as the default option. Services in .Insurance should always attempt to have transmission encrypted. Defaulting back to plaintext for transmission should only occur in extraordinary cases: for instance, sending emails to legacy domains. STARTTLS should always be attempted before falling back to clear text. It should be noted email is not analogous to web traffic. All modern browsers support strong encryption; web servers should never downgrade to an unencrypted HTTP connection.
5: Email Authentication
Registrants that have met requirements 1 and 2 must publish a valid Domain-based Message Authentication, Reporting and Conformance (DMARC) record whether or not the domain is used to send email. To check your email authentication records, we recommend EasyDMARC’s domain scanner tool.
If a vendor sends email on your behalf, they must comply with requirement 4: Encryption.
For a domain not used for sending email: Registrants must publish a DMARC record with a reject mail receiver policy (p=reject). It is also recommended, as a best practice, to add an SPF record that authorizes no organizations to send on your behalf, i.e.,: “v=spf1 -all” as this identifies that the domain isn’t active for email.
For a domain used to send email: Registrants must publish a DMARC record with a reject mail receiver policy (p=reject), except during the implementation phase of email as described below*.
In addition, Registrants must publish an Sender Policy Framework Record (SPF). While publishing a DomainKeys Identified Mail Record (DKIM) is not required, publishing both SPF and DKIM records creates additional security for your email channel and is therefore recommended.
It is also recommended that DMARC records specify strict identifier alignment for SPF and DKIM (if applicable) via the adkim and aspf tags. Also, for DMARC records published at an organizational domain level to set an appropriate sp: tag.
*When deploying DMARC during the implementation phase of email capabilities, Registrants may temporarily use a “none” (p=none) or “quarantine” (p=quarantine) mail receiver policy, but must change the policy to reject for ongoing operations within 90 days of deployment.
Tip: Ensure that your organization’s incoming mail service provider/server is properly configured for DMARC and this is on top of having properly formed DMARC and SPF records. For common mail service providers like Gmail, Microsoft Outlook (for inbound email only), and Yahoo!, they do this for you. If you use Microsoft Outlook with a custom domain or an on-premise Exchange server, you’ll need to manually implement DMARC for your outbound mail (learn more about this here).
SPF Practical Limitation (10 DNS Lookup Maximum)
A single SPF record can contain a maximum of 10 DNS lookups to see if you’ve authorized a particular IP address to send mail on your behalf. This practical limitation should be observed to ensure timely delivery of email messages and favorable inbox ratings. There are several ways to avoid this limitation such as:
- Make use of subdomains as each is afforded its own 10 lookup max
- Use separate email address (e.g., corporate, marketing)
- Send mail from different domains and/or IP addresses
- See: Best Practices for reducing/avoiding too many lookups