The test tool takes a list of zone names as input and performs a series of tests for certain security artifacts in the zone or particular services. The majority of these tests are based on DNS queries. The results of the tests are broken down by service (e.g. DNS, email, etc.) with multiple tests per service. The individual tests and presentation of results are detailed below. For each service column, the results are given as a collection of values defined below. In the example below, the "example4.gov" zone is lame meaning that a delegation is found in the parent zone (i.e. .gov), but no servers could be reached.
This monitor is similar to the NIST Fed IPv6 Deployment Monitor in that some of the same security artifacts are being measured (especially DNSSEC). However, the HAD monitor is focused on services and not the interfaces those services utilize. Therefore, the results appear different for similar sounding tests. Some of the tests are different than the NIST IPv6 monitor, such as tests for the use of TLS/SSL for web, etc.
The input for the .gov test results page comes from the list of Executive Branch zones hosted on data.gov. Administrators can contact the the HAD admins to ask to be included in the measurement and add any other zones that may not currently be included.
The tests are broken down by service. Currently the services tested for each zone are DNS (DNSSEC), email authentication and web (HTTP/HTTPS). The presentation of the results may change to improve readability or provide more information, but the underlying tests will not change.
The first column gives the results of measuring DNSSEC deployment for a give zone. The results of the DNSSEC tests is given as a simple "Yes/No" with a status that gives the basic, observable information about the zone. The HAD monitor uses a validating resolver configured with the public key for the root zone (".") and sends a query for the DNSKEY RR for each zone. The response (and validation result) of this query can tell a client a lot about the DNSSEC status of a given zone. The possible values are:
The second set of tests gives the results of measuring various email authentication techniques that store some information in the DNS. The current technologies being measured are SPF usage, DMARC usage, and TLS certificates for mail servers stored in TLSA (or CERT) RR's in the DNS. Like the DNSSEC test above, the monitor sends a series of queries for relevant RRTypes to see if the given email technology is in use. For SPF, both the SPF and TXT RRTypes are queried. For DMARC, a query for a TXT RR with the name "_dmarc.zonename is sent, according to the naming convention contained in the DMARC specification. DKIM requires some input from the zone under test (see our request for DKIM information. Tests for TLSA and CERT RRTypes are done for the mail servers identified in the MX RRset (if present) in the zone. So mail receivers are checked, not mail senders (yet). The individual tests and result values are: