About the DNSSEC/DANE measurement survey

The survey is the brainchild of Viktor Dukhovni <ietf-dane@dukhovni.org>, a coauthor of RFC7672 which defines DANE for SMTP, and the developer DANE implementations in Postfix, Exim and OpenSSL. Hosting for the survey is generously supported by USC's Information Sciences Institute. Wes Hardaker (USC/ISI) summarizes the results of Viktor's data collection efforts and produces the graphs found on the main statistics page.

We believe that the survey is for the benefit of both you and the Internet. We scan the Internet for DNSSEC and DANE related growth and problems, letting operators (like you) know when we detect problems. To achieve this goal, we ask that SMTP connections from the survey not be blocked.

Scanning OPT-OUT information: we scan both DNS records and DANE/TLS/SMTP servers from the dnssec-stats.ant.isi.edu host. If you wish to be added to our Out-Out list for your domain name(s) or IP address(es), please contact ant-dnssec-operators@ant.isi.edu and include the IP addresses and/or names that you wish to be added to the opt-out list.

Purpose

The purpose of the survey is to promote DANE adoption by:

• Publicising statistics that document the growth of DANE and DNSSEC adoption, promoting further adoption and use of best-practice parameters.
• Identifying systems where DANE is inadvertently misconfigured, and notifying their postmasters. This helps to avoid prolonged degradation of inbound email to the domain with bad TLSA records.
• Also DANE adoption can only grow if any published TLSA records are correct for the vast majority of domains which published them.

The survey runs once per day. It checks the status of each DNSSEC-signed domain delegated from a parent domain on the Mozilla public-suffix list (generally just the top-level domain of a given organization). Domains internal to organizations are not included.

Data Collected

The DNS data collected includes:

• The DS RRset from the parent domain
• The DNSKEY RRset of the given domain
• The MX RRset of the given domain
• The A and AAAA records of each MX host, retrieved just once per MX hostname, regardless of the number of domains that share the same MX host.
• Any SMTP TLSA records (_25._tcp.) of MX hosts whose A records are DNSSEC signed, also retrieved at most once per host.

If an MX host does have TLSA records, then an SMTP connection is made to each IP address of the MX host, and a STARTTLS handshake is performed (assuming STARTTLS is offered, as it needs to be for a host with published TLSA records).

The certificate chain is then compared with the TLSA records, and if all goes well, for all the MX hosts, the domain is counted as one of the successful deployments reported in the aggregate statistics.

If, on the other hand, one or more of the MX hosts with TLSA records fails to offer or rejects STARTTLS, or presents a certificate chain that does not match its TLSA records, then reasonable effort is made to find technical contacts for the domain, and a notice is sent to those contacts detailing the problems found.

In the majority of cases, each SMTP server will see at most one connection per IP address per day, provided it has TLSA records under just one name.

If an SMTP server has multiple names with associated TLSA records, then it potentially also has multiple certificate chains (selected via SNI). Connection de-duplication is therefore by name, and so SMTP servers known under more than one name may see more than one connection per IP per day. At present, in the worst case, this still yields a modest number of connections per IP, spread out over a few hours.