DNSViz

Nodes in DNSViz are clustered by the zone to which the represented information belongs. Each zone is labeled with the name of the zone origin and the time at which the zone was last analyzed.

DNSKEY resource records (RRs) are included in zone data, so resolvers can validate signatures made by the corresponding private keys. These signatures are returned in DNSSEC responses accompanying DNS data.

In DNSViz, each DNSKEY RR is represented as a single DNSKEY node in the zone cluster to which it belongs. The DNSKEY RR for the example.com zone has algorithm 5 (RSA/SHA-1) and key tag 12345, both of are used to identify the DNSKEY. Each DNSKEY node is decorated based on the attributes and roles of the corresponding DNSKEY RR, as described in the following entries.

A dashed border indicates that the DNSKEY is published only. That is, the DNSKEY is not being used in any signing capacity.

Publishing a DNSKEY before it is actively used to sign data is a common for maintenance mechanisms such as key rollovers, as documented in RFC 4641.

A gray fill indicates that the SEP (secure entry point) bit is set in the flags field of the DNSKEY RR.

This bit typically designates a DNSKEY for usage as a key signing key (KSK), a DNSKEY that is only used to sign the DNSKEY RRset of a zone and provides secure entry to a zone via DS RRs or a trust anchor at the resolver.

A thick border indicates that the revoke bit is set in the flags field of the DNSKEY RR.

Resolvers which implement the trust anchor rollover procedures documented in RFC 5011 recognize the revoke bit as a signal that the DNSKEY should no longer be used as a trust anchor by the resolver. For a DNSKEY to be properly revoked, it must also be self-signing (i.e., used to sign the DNSKEY RRset), which proves that the revocation was made by a party that has access to the private key.

A double border indicates that the DNSKEY is being used by DNSViz as a trust anchor.

By default DNSViz uses the the KSKs for the root zone and the DNSSEC Look-aside Validation (DLV) registry provided by Internet Systems Consortium (ISC) as the exclusive trust anchors. Either of these may be de-selected, and any arbitrary DNSKEYs may be configured as trust anchors in the free-form options field.

If a yellow warning symbol appears in the DNSKEY node, it is because one or more authoritative servers have a path MTU (PMTU) problem. Such servers are attempting unsuccessfully to send a payload larger than what that of which they are capable.

If a red warning symbol appears in the DNSKEY node, it is because the DNSKEY RR is not being returned from one or more responsive authoritative servers. This may be because the servers are out of sync or because the server implementation(s) do not support the DNSKEY RR type.

DS (delegation signer) RRs exist in the parent of a signed zone to establish secure entry into the zone. If a DNSKEY is registered in the ISC DLV registry, then the node is displayed as a DLV RR in the dlv.isc.org zone, though the behavior is the same as if it were a DS in the parent zone.

In DNSViz DS RRs with the same DNSKEY algorithm and key tag are typically displayed as a single node since they usually correspond to the same DNSKEY RR with different digest algorithms. The DS for example.com has algorithm 5 and key tag 12345, and maps to the corresponding DNSKEY RR with digest algorithms 1 (SHA1) and 2 (SHA-256).

In this example, the blue color of the arrow pointing from DS to DNSKEY indicates that the digest contained in each of the DS RRs is valid, and corresponds to an existing DNSKEY in example.com. However, other circumstances may exist, which are shown in the following entries.

A dashed red line from DS to DNSKEY indicates that a DNSKEY exists matching the algorithm and key tag of the DS RR, but the digest of the DNSKEY in the DS RR does not match.

A dashed yellow line from DS to a DNSKEY also filled with yellow indicates that no DNSKEY matching the algorithm and key tag of the DS RR exists in the child zone.

Extraneous DS RRs in a parent zone do not necessarily constitute an error. Sometimes they are deliberately pre-published before their corresponding DNSKEYs, as part of a KSK rollover, as documented in RFC 4641. However, for every DNSSEC algorithm in the DS RRset for the child zone, a matching DNSKEY must be used to sign the DNSKEY RRset in the child zone, as per RFC 4035.

If a red warning symbol appears in the DS node, it is because the DS RR is not being returned from one or more responsive authoritative servers. This may be because the servers are out of sync or because the server implementation(s) do not support the DS RR type.

If a there are no DS RRs for child zone in the zone's signed parent, that constitutes an insecure delegation, meaning that there is no secure link for authenticating the child zone given trust at the parent zone. However, a resolver must be able to prove the insecure delegation, that is, that no DS RRs exist for the child zone. This is done with RRs of type NSEC or NSEC3, for authenticated denial of existence or hashed authenticated denial of existence, respectively.

In DNSViz the NSEC or NSEC3 RR(s) returned by a server authoritative for the parent zone to prove that DS RRs for the child zone do not exist are represented by a single Ndiamond-shaped node, labeled with either NSEC or NSEC3, depending on which method the zone is signed with. An edge extends from the NSEC or NSEC3 node to the child zone. If the edge is solid blue, then the NSEC or NSEC3 RRs returned are sufficient to prove that DS RRs do not exist for the child zone.

A solid red edge from the NSEC or NSEC3 node to the child zone indicates that the NSEC or NSEC3 RRs provided by the servers authoritative for the parent zone are insufficient to prove that DS RRs for the child zone do not exist.

If an NSEC or NSEC3 node is filled with red, then no servers are providing any NSEC or NSEC3 RRs to prove the non-existence of DS RRs.

If a red warning symbol appears in the NSEC or NSEC3 node, it is because the NSEC or NSEC3 RR(s) are not being returned from one or more responsive authoritative servers. This may be because the server implementation(s) do not support DNSSEC or do not support NSEC3. For example, NSEC3 is not implemented in versions of ISC BIND prior to 9.6.

RRsets are represented as rectangles with rounded corners. At the moment this includes SOA, A, AAAA, MX, and CNAME RR types.

RRsets that are specific to DNSSEC, such as the DNSKEY, DS, RRSIG, NSEC and NSEC3 RR types, are represented as other node types, as specified elsewhere in this guide.

Aliases are represented by a black edge from one RRset (the alias) to another (the target).

Each RRSIG RR contains the cryptographic signature made by a DNSKEY over an RRset. Using the DNSKEY with the same algorithm and key tag as the RRSIG, the RRset which was signed, and the RRSIG itself, a resolver may determine the correctness of the signature and authenticate the RRset.

In DNSViz RRSIGs are represented as directed edges from the DNSKEY which made the signature to the RRset that was signed. The edges in the example denote RRSIGs made by the example.com DNSKEY with algorithm 5 and key tag 12345, which cover the following (from left to right): the example.com/SOA RRset; and the NSEC RRset(s) proving non-existence of DS RRs for some child zone; and the DS RRset for a (different) child zone.

The color and style of RRSIGs is also significant. A blue edge indicates a valid RRSIG. Other configurations are shown in the following entries.

Just like other RRsets, a DNSKEY RRset is signed as an RRset, which comprises all the collective DNSKEY RRs at the zone apex. In some DNSSEC implementations, multiple DNSKEYs sign the DNSKEY RRset, even though only a subset is designated as a secure entry point into the zone, matching DS records in the parent zone. Such DNSKEYs often have the SEP bit set, but it is not required.

Rather than create a mesh of edges between all DNSKEY nodes that sign the DNSKEY RRset, DNSViz does the following. For every DNSKEY signing the DNSKEY RRset, a self-directed edge is added to the node, indicating that the DNSKEY is self-signing. Additionally, if the DNSKEY provides a secure entry point into the zone, then edges are drawn from it to other DNSKEYs to illustrate the chain of trust. If there is no secure entry point, then edges are drawn from DNSKEYs with the SEP bit set to other DNSKEYs.

A solid red edge indicates an RRSIG in which the cryptographic signature is bogus.

A solid purple edge indicates that an RRSIG is invalid because it is outside its validity period, defined by inception and expiration date fields in the RRSIG RR.

A dashed red edge indicates that either an RRSIG is not returned by one or more authoritative servers or that the RRSIG is an invalid match. If authoritative servers are not returning RRSIGs appropriately, it may be because their server implementations do not support DNSSEC or it is not enabled in their configurations

An invalid match may be because the signer field in the RRSIG does not match the name of the zone apex or because the RRSIG was made by a DNSKEY with the revoke bit set. These are disallowed by RFCs 4035 and 5011, respectively.

A dashed yellow edge indicates that the DNSKEY corresponding to the algorithm and key tag in an RRSIG was not found, so the correctness of the RRSIG cannot be verified. This doesn't necessarily indicate an error; as long as there are RRSIGs which can be validated, then extraneous RRSIGs are simply ignored. Also, there are situations when RRSIGs must be published to prime caches prior to publishing the corresponding DNSKEYs, such as with an algorithm rollover, as documented in RFC 4641-bis.

Beginning at the DNSKEYs designated as trust anchors, DNSViz traverses the nodes and edges in the graph to classify each node as having one of three DNSSEC statuses, depending on the status of the RRset which it represents: secure, bogus, or insecure. In DNSViz, node status is indicated by the color of the nodes (Note that there isn't always a one-to-one mapping between node and RRset, but the node status will be consistent among all nodes comprising an RRset. An example is the DNSKEY nodes for a zone, which all have the same status even though the DNSKEY RRset is split among different nodes).

Nodes with blue outline indicate that they are secure, that there is an unbroken chain of trust from anchor to RRset.

Nodes with red outline indicate that they are bogus, that the chain of trust from an anchor has been broken.

Nodes with black outline indicate that they are insecure, that no chain of trust exists; if any anchors exist then an insecure delegation is demonstrated to prove that no chain should exist from the anchors. This is equivalent to DNS without DNSSEC.