High Assurance Domain Monitor
Test Descriptions

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.

example1.gov Agency One Signed(Good) NS Yes Yes Yes TLSA Yes No None
example2.gov Agency Two No No DKIM? No No No Yes Yes TLSA
example3.gov Agency Three Signed(Island) SPF Yes No Yes CERT No Yes CERT
example4.gov Agency Four - - DKIM? - - - - - -

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.

Test Methodologies

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.

DNS Security Extensions (DNSSEC)

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:

  • Signed DNSKEY and RRSIG RR's found at the zone apex. With (Good) full validation chain up to the root zone, (Island): unable to determine as no chain exists up to parent zone, or (Bad): Validation error.
  • No DNSSEC RR's not found.
  • - DNS zone unreachable (DNS error).

Email Authentication

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:

  • SPF Usage: [SPF] Present (an SPF or TXT RR was found), [No] No SPF or TXT RR found, [NS] SPF or TXT RR found, and states that no mail should originate from the zone).
  • DKIM Usage: [Yes] A mail server with a DKIM exists in the zone, [No] Mail server found without a DKIM, [DKIM?] Need additional information in order to perform the check.
  • DMARC Usage: [Yes] A DMARC RR found for the zone, [No] No DMARC RR found in the zone.
  • SMTP over TLS: [Yes] The mail server for the zone claims to offer TLS (i.e. STARTTLS) for message exchange. [No] The mail server for the zone does not list STARTTLS as an option. [N/A] No receiving mail server is found for the zone.
  • TLS Support: [TLSA] A TLSA RR was found for a mail server, [CERT] A CERT RR was found for a mail server, [CAA] A CAA RR was found for the mail server, [STS] A TXT RR signalling that SMTP-STS is used was found, [-] Neither RR found or no mail servers found for the zone.