1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<title>DNSViz</title>
</head>
<body>
<h2><img src="images/logo-220x100.png" alt="DNSViz - DNS visualization" /></a></h2>
<ul>
<li><a href="#zones">Zones</a></li>
<li><a href="#delegations">Delegations</a></li>
<li><a href="#rrsets">RRsets</a></li>
<li><a href="#negative-responses">Negative Responses</a></li>
<li><a href="#dnskey-rrs">DNSKEY RRs</a></li>
<li><a href="#ds-rrs">DS RRs</a></li>
<li><a href="#nsecnsec3-rrs">NSEC/NSEC3 RRs</a></li>
<li><a href="#rrsigs">RRSIGs</a></li>
<li><a href="#wildcards">Wildcards</a></li>
<li><a href="#node-status">Node Status</a></li>
<li><a href="#warnings-errors">Warnings and Errors</a></li>
</ul>
<h4><a name="zones">Zones</a></h4>
<table>
<tr><td><img src="images/zone.png" alt="Zone" />
</td><td><p>Nodes in DNSViz are clustered by the
<strong>zone</strong> 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.</p></td></tr>
</table>
<h4><a name="delegations">Delegations</a></h4>
<table>
<tr><td><img src="images/delegation.png"
alt="Delegation" /></td><td><p>Thick lines between zones denote
<strong>delegations</strong> of namespace from one zone to another, as
indicated by the presence of NS (name server) resource records (RRs)
for the delegated namespace.</p><p>In this example, the black, solid
line indicates a standard, <strong>insecure</strong> delegation (i.e.,
sans DNSSEC). Other possible delegation statuses are described in the
following entries.</p></td></tr>
<tr><td><img src="images/delegation-lame.png"
alt="Lame delegation" /></td><td><p>If the designated name servers for a
zone cannot not be properly resolved or if the servers do not properly
respond to queries, then the delegation is considered
<strong>lame</strong> and is represented by a dashed, yellow
line.</p></td></tr>
<tr><td><img src="images/delegation-incomplete.png"
alt="Incomplete delegation" /></td><td><p>If the delegation is
<strong>incomplete</strong>, as indicated by the presence of NS records
in the zone itself but not in its parent zone, then the delegation is
represented by a dashed, yellow line.</p></td></tr>
<tr><td><img src="images/delegation-secure.png"
alt="Secure delegation" /></td><td><p>If the delegation is
<strong>secure</strong> by DNSSEC standards, then then the delegation
is represented by a solid, blue line.</p></td></tr>
<tr><td><img src="images/delegation-bogus.png"
alt="Bogus delegation" /></td><td><p>If the delegation is
<strong>bogus</strong> by DNSSEC standards, then then the delegation
is represented by a dashed, red line.</p></td></tr>
</table>
<h4><a name="rrsets">RRsets</a></h4>
<table>
<tr><td><img src="images/rrset.png"
alt="RRset" /></td><td><p><strong>Resource record sets
(RRsets)</strong> returned in the response (usually in the answer
section) are represented as rectangular nodes with rounded corners.
Among the most common record types are SOA (start of authority), A
(IPv4 address), AAAA (IPv6 address), MX (mail exchange), and CNAME
(canonical name).</p><p>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.</p></td></tr>
<tr><td><img src="images/alias.png"
alt="Alias" /></td><td><p><strong>Aliases</strong> resulting from
CNAME RRs are represented by a black edge from one RRset (with the
<strong>alias name</strong>) to another (with the <strong>canonical
name</strong>).</p></td></tr>
<tr><td><img src="images/dname.png"
alt="DNAME" /></td><td><p>A DNAME RR is used to alias an entire
namespace into another. DNAME responses include synthesized CNAME RRs
for the aliasing directed by the DNAME RR.</p><p>DNAME records are
shown in DNSViz with their respective CNAME records. A solid, blue
line between DNAME node and CNAME node indicates that the DNAME
expansion was valid.</p></td></tr>
<tr><td><img src="images/dname-invalid.png"
alt="Invalid DNAME" /></td><td><p> A solid, red line between DNAME node
and CNAME node indicates that the DNAME expansion was
invalid.</p></td></tr>
</table>
<h4><a name="negative-responses">Negative Responses</a></h4>
<table>
<tr><td><img src="images/nxdomain.png" alt="NXDOMAIN" /></td>
<td><p>If the response to a query is a <strong>name error
(NXDOMAIN)</strong>, this negative response is represented by a
rectangular node with diagonals drawn at each corner, and with a dashed
border, lighter in color. A node representing the SOA RR returned in
the negative response (if any) is also
included.</p></td></tr>
<tr><td><img src="images/nodata.png" alt="NO DATA" /></td>
<td><p>If the response to a query has a <strong>NOERROR status but
contains no answer data (NO DATA) for the type</strong>, this
negative response is represented by a rectangular node with rounded
corners, and with a dashed border, lighter in color. A node
representing the SOA RR returned in the negative response (if any) is
also included.</p></td></tr>
</table>
<h4><a name="dnskey-rrs">DNSKEY RRs</a></h4>
<table>
<tr><td><img src="images/dnskey.png"
alt="DNSKEY" /></td><td><p><strong>DNSKEY</strong> RRs
include public key and meta information to enable resolvers to validate
signatures made by the corresponding private keys.</p><p>In DNSViz,
each DNSKEY RR is represented as an elliptical node in the zone
to which it belongs.</p><p>The DNSKEY RR for the <span
class="domain">example.com</span> zone has <strong>algorithm</strong>
8 (RSA/SHA-256) and <strong>key tag</strong> 12345, both of are used to
identify the DNSKEY. Each DNSKEY node is decorated based on the
attributes of the corresponding DNSKEY RR, as described in the
following entries.</p></td></tr>
<tr><td><img src="images/dnskey-sep.png"
alt="DNSKEY with SEP bit" /></td><td><p>A gray fill indicates that the
<strong>Secure Entry Point (SEP)</strong> bit is set in the
<strong>flags</strong> field of the DNSKEY RR.</p><p> This bit is
typically used to designate a DNSKEY for usage as a <strong>key signing
key (KSK)</strong>, a DNSKEY that is used to sign the DNSKEY RRset of
a zone, providing a secure entry point into a zone via DS RRs or a
trust anchor at the resolver.</p></td></tr>
<tr><td><img src="images/dnskey-revoke.png"
alt="DNSKEY with revoke bit" /></td><td><p>A thick border indicates
that the <strong>revoke</strong> bit is set in the
<strong>flags</strong> field of the DNSKEY RR.</p><p>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.</p></td></tr>
<tr><td><img src="images/dnskey-trust-anchor.png"
alt="DNSKEY designated as trust anchor" /></td><td><p>A double border
indicates that the DNSKEY has been designated as a <strong>trust
anchor</strong>.</p><p>A trust anchor must be self-signing (i.e., used
to sign the DNSKEY RRset).</p></td></tr>
</table>
<h4><a name="ds-rrs">DS RRs</a></h4>
<table>
<tr><td><img src="images/ds.png" alt="DS" />
</td><td><p><strong>DS</strong> (delegation signer) RRs exist
in the parent of a signed zone to establish a SEP into the zone. Each
DS RR specifies an algorithm and key tag corresponding to a DNSKEY RR
in the signed zone and includes a cryptographic hash of that DNSKEY
RR.</p><p>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
<span class="domain">example.com</span> has algorithm 8 and key tag
12345, and maps to the corresponding DNSKEY RR with digest algorithms 1
(SHA1) and 2 (SHA-256).</p><p>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
<span class="domain">example.com</span>. However, other circumstances
may exist, which are shown in the following entries.</p></td></tr>
<tr><td><img src="images/ds-invalid-digest.png"
alt="DS with invalid digest" /></td><td><p>A solid red line from DS to
DNSKEY indicates that a DNSKEY exists matching the algorithm and key
tag of the DS RR, but <strong>the digest of the DNSKEY in the DS RR
does not match</strong>.</p></td></tr>
<tr><td><img src="images/ds-nodnskey.png"
alt="DS with no matching DNSKEY" /></td><td><p>A dashed gray line from
DS to a DNSKEY with a dashed gray border indicates that <strong>no
DNSKEY matching the algorithm and key tag</strong> of the DS RR
exists in the child zone.</p><p>Extraneous DS RRs in a parent zone do
not, in and of themselves, constitute an error. For example, sometimes
they are deliberately pre-published before their corresponding DNSKEYs,
as part of a key rollover. However, for every DNSSEC
<strong>algorithm</strong> 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.</p></td></tr>
<tr><td><img src="images/ds-pre-revoke.png"
alt="DS matching DNSKEY prior to its revocation" /></td><td><p>A
special case of a DS with no matching DNSKEY is when <strong>the DS
matched a DNSKEY prior to its revocation</strong>, but the
ramifications are the same as if it didn't match any DNSKEY. The line
is simply drawn to help identify the cause of the otherwise
non-existent DNSKEY.</p><p>In the example at the left the key tag of
the DS records isn't actually 54321; rather, 54321 is the new key tag
resulting from having set the revoke bit in the DNSKEY
RR.</p></td></tr>
<tr><td><img src="images/ds-unknown-alg.png"
alt="DS with unknown digest algorithm" /></td><td><p>When the algorithm
and key tag of a DS RR match those of a DNSKEY RR, but <strong>the
digest algorithm is unknown or unsupported</strong>, then the line
between DS and DNSKEY is yellow. In the example at the left digest
algorithm 19 is unknown.</p></td></tr>
<tr><td><img src="images/ds-invalid.png"
alt="DS with invalid digest" /></td><td><p>When <strong>the use of a DS
corresponding to a DNSKEY is invalid</strong>, independent of the
correctness of its digest, the line between DS and DNSKEY is red and
dashed. An example scenario is when the DNSKEY has the revoke bit set,
which is disallowed by RFC 5011.</p></td></tr>
</table>
<h4><a name="nsecnsec3-rrs">NSEC/NSEC3 RRs</a></h4>
<table>
<tr><td><img src="images/nsec.png" alt="NSEC" />
<img src="images/nsec3.png" alt="NSEC3" /></td>
<td><p>NSEC and NSEC3 RRs are
used within DNSSEC to prove the legitimacy of a negative response
(i.e., NXDOMAIN or NO DATA) using <strong>authenticated denial of
existence</strong> or <strong>hashed authenticated denial of
existence</strong>, respectively.</p><p>In DNSViz the NSEC or NSEC3
RR(s) returned by a server to authenticate a negative response are
represented by a rectangular node with several compartments. The
bottom compartment is labeled with either NSEC or NSEC3, depending on
the type of record. Each compartment on the top row represents an
NSEC or NSEC3 record in the set--there will be between one and
three.</p>
<p>An edge extends from the NSEC or NSEC3 node to the
corresponding negative response, as in the figure to the left. If the
edge is solid blue, then the NSEC or NSEC3 RRs returned prove the
validity of the negative response.</p></td></tr>
<tr><td><img src="images/nsec-ds.png"
alt="NSEC covering DS" /></td><td><p>A special case of NSEC/NSEC3 RRs is
that in which they serve to prove the non-existence of Delegation
Signer (DS) records. The proof of absence of DS records constitutes an
<strong>insecure delegation</strong>, in which any trust at the parent
zone does not propagate to the child zone.</p><p>The NSEC/NSEC3 proof
involving DS records is graphically represented with an edge from the
NSEC/NSEC3 node to the box representing the child zone.</p></td></tr>
<tr><td><img src="images/nsec3-optout.png"
alt="NSEC3" /></td><td><p>The <strong>opt-out</strong> flag is set
in NSEC3 RRs to indicate that their presence is only sufficient to
prove insecure delegations (i.e., lack of DS records) and nothing more.
Thus, a name error (NXDOMAIN) response, for example, cannot be securely
proven when the NSEC3 uses opt-out.</p><p>NSEC3 records with the
opt-out flag set are colored with a gray background.</p></td></tr>
<tr><td><img src="images/nsec-invalid.png"
alt="Invalid NSEC" /></td><td><p>A solid
red edge from the NSEC or NSEC3 node to the negative response indicates
that the NSEC or NSEC3 RRs included in in the response do not prove the
validity of the negative response.</p></td></tr>
</table>
<h4><a name="rrsigs">RRSIGs</a></h4>
<table>
<tr><td><img src="images/rrsig-rrset.png"
alt="RRSIG" /></td><td><p>Each <strong>RRSIG</strong> 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.</p><p>In
DNSViz RRSIGs are represented as directed edges from the DNSKEY that
made the signature to the RRset that was signed. The edges in the
example denote RRSIGs made by the <span
class="domain">example.com</span> DNSKEY with algorithm 8 and key tag
12345, which cover the <span
class="domain">example.com</span>/A RRset.</p></td></tr>
<tr><td><img src="images/rrsig-rrset-invalid-sig.png"
alt="RRSIG with bogus signature" /></td><td><p>A solid red edge
indicates an RRSIG in which the cryptographic signature is
<strong>invalid</strong>.</p></td></tr>
<tr><td><img src="images/rrsig-rrset-expired.png"
alt="Expired or premature RRSIG" /></td><td><p>A solid purple edge
indicates that an RRSIG is invalid because it is outside its
<strong>validity period</strong>, as defined by the
<strong>inception</strong> and <strong>expiration</strong> date fields
in the RRSIG RR.</p></td></tr>
<tr><td><img src="images/rrsig-rrset-nodnskey.png"
alt="RRSIG with no matching DNSKEY" /></td><td><p>A dashed gray line stemming from a DNSKEY
with a dashed gray border indicates that <strong>no DNSKEY matching the
algorithm and key tag</strong> of the RRSIG RR could be found in the
DNSKEY RRset (or the DNSKEY RRset could not be
retrieved).</p><p>Extraneous RRSIG RRs do not, in and of themselves,
constitute an error. For example, sometimes they are deliberately
pre-published before their corresponding DNSKEYs, as part of an
algorithm rollover. However, every RRset must be covered by RRSIGs for
every <strong>algorithm</strong> in the DNSKEY RRset, as per RFC
4035.</p></td></tr>
<tr><td><img src="images/rrsig-rrset-pre-revoke.png"
alt="RRSIG matching DNSKEY prior to its revocation" /></td><td><p>A special case of an RRSIG with no
matching DNSKEY is when <strong>the RRSIG matched a DNSKEY prior to its
revocation</strong>, but the ramifications are the same as if it
didn't match any DNSKEY. The line is simply drawn to help identify the
cause of the otherwise non-existent DNSKEY.</p><p>In the example at the
left the key tag of the RRSIG RR isn't actually 12345; rather, 12345 is
the new key tag resulting from having set the revoke bit in the DNSKEY
RR.</p></td></tr>
<tr><td><img src="images/rrsig-rrset-unknown-alg.png"
alt="DNSKEY with unknown algorithm" /></td><td><p>When the algorithm and key tag of an RRSIG RR
match those of a DNSKEY RR, but <strong>the cryptographic algorithm
associated with the RRSIG is unknown or unsupported</strong>, then
the line stemming from the DNSKEY is yellow. In the example at the
left algorithm 22 is unknown.</p></td></tr>
<tr><td><img src="images/rrsig-rrset-invalid.png"
alt="Invalid DS" /></td><td><p>When <strong>an RRSIG is
invalid</strong>, independent of the correctness of its temporal
validity period and its cryptographic signature, the line stemming from
the DNSKEY is red and dashed. Example scenarios might be when the
DNSKEY has the revoke bit set or when the <strong>signer</strong> field
in the RRSIG RR does not match the name of the zone apex. Such
scenarios are disallowed by RFCs 5011 and 4035,
respectively.</p></td></tr>
<tr><td><img src="images/rrsig-dnskey.png"
alt="RRSIG covering a DNSKEY RRset" /></td><td><p>Just like other
RRsets, a DNSKEY RRset is signed as an RRset, which comprises all the
collective DNSKEY RRs at the zone apex. Because each DNSKEY RR is
represented as a node in DNSViz, a single RRSIG covering the DNSKEY
RRset is represented by edges drawn from the node representing the
signing DNSKEY to the nodes representing every DNSKEY RR in the
set.</p><p>In the example at the left, the <span
class="domain">example.com</span>/DNSKEY RRset is comprised of the three
DNSKEY nodes shown, and the blue edges going to each of them collectively
represent a single RRSIG corresponding to the key with algorithm 8 and
key tag 54321.</p></td></tr>
<tr><td><img src="images/rrsig-dnskey-redundant.png"
alt="RRSIG covering a DNSKEY RRset, with redundant edges" /></td><td><p>In some DNSSEC
implementations, multiple DNSKEYs sign the DNSKEY RRset, even though
only a subset are designated to provide secure entry into the zone
(e.g., via matching DS records in the parent zone). While there is
nothing inherently wrong with this configuration, graphically
representing such scenarios can be visually complex because of the
cycles and redundancy created in the graph.</p></td></tr>
<tr><td><img src="images/rrsig-dnskey-pruned.png"
alt="RRSIG covering a DNSKEY RRset, with redundant edges pruned" /></td><td><p>In order to represent
trust propagation in a simplified fashion, eliminating graphic
redundancies, DNSViz exhibits the following behavior. For
<strong>every</strong> DNSKEY signing the DNSKEY RRset, a self-directed
edge is added to the node, indicating that the DNSKEY is
<strong>self-signing</strong>. Additionally, if the DNSKEY is
designated as a <strong>(SEP)</strong> into the zone, then edges are
drawn from its node to nodes representing all other DNSKEY RRs in the
DNSKEY RRset.</p><p>If there is no true SEP, (e.g., no DS RRs in the
parent zone), then SEP(s) are inferred based on their signing role
(e.g., siging DNSKEY RRset or other RRsets) and properties (e.g., SEP
bit).</p></td></tr>
<tr><td><img src="images/rrsig-ds.png"
alt="RRSIG covering a DS RRset" /></td><td><p>Like the DNSKEY
RRset, a single DS RRset might be represented as several different
nodes. As such a single RRSIG covering the DS RRset is represented by
edges drawn from the node representing the signing DNSKEY to the nodes
representing every DS RR in the set.</p><p>In the example at the left,
the <span class="domain">example.com</span>/DS RRset is comprised of
both DS nodes shown, and the blue edges going to both of them
collectively represent a single RRSIG corresponding to the key with
algorithm 8 and key tag 12345.</p></td></tr>
<tr><td><img src="images/rrsig-nsec.png"
alt="RRSIGs covering NSEC RRsets" /></td><td><p>Because an NSEC or
NSEC3 node represents one or more RRsets and at least one RRSIG per
RRset is anticipated, multiple RRSIG edges will be drawn from DNSKEY
to NSEC or NSEC3 nodes, each pointing to the respective compartment
corresponding to the NSEC or NSEC3 record.</p></td></tr>
</table>
<h4><a name="wildcards">Wildcards</a></h4>
<table>
<tr><td><img src="images/wildcard.png"
alt="Wildcard" /></td><td><p>When the RRSIG covering an RRset has a
labels field with value greater than the number of labels in the name,
it is indicative that the resulting RRset was formed by a wildcard
expansion. The server must additionally include an NSEC or NSEC3 proof
that the name to which the wildcard is expanded does not
exist.</p><p>DNSViz represents wildcards by displaying both the
wildcard RRset and the NSEC or NSEC3 proof. In the example at the left,
the RRset <span class="domain">foobar.example.com</span> resulted from
the wildcard expansion of <span class="domain">*.example.com</span>.</p></td></tr>
</table>
<h4><a name="node-status">Node Status</a></h4>
<table>
<tr><td><img src="images/nodes-secure.png"
alt="Secure nodes" /></td><td><p>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: <strong>secure</strong>,
<strong>bogus</strong>, or <strong>insecure</strong>. 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).</p><p>Nodes with blue
outline indicate that they are <strong>secure</strong>, that there is
an unbroken chain of trust from anchor to RRset.</p></td></tr>
<tr><td><img src="images/nodes-bogus.png"
alt="Bogus nodes" /></td><td><p>Nodes with red outline indicate that
they are <strong>bogus</strong>, that the chain of trust from an anchor
has been broken.</p></td></tr>
<tr><td><img src="images/nsec-partial-bogus.png"
alt="NSEC nodes that are partially bogus" /></td><td><p>Because the NSEC and
NSEC3 nodes often represent multiple NSEC or NSEC3 RRs, it is
possible that a proper subset of the RRs are secure, while others in
the set are not (e.g., missing or expired RRSIG). In this case, the
outline of the compartments representing secure NSEC or NSEC3 RRs
will be colored blue, while the others will be red. Because the
status of the collective set of NSEC and NSEC3 RRs is dependent on
the status of all the individual NSEC and NSEC3 RRs, the greater node
is only colored blue if all the compartments are colored
blue.</p></td></tr>
<tr><td><img src="images/nodes-insecure.png"
alt="Insecure nodes" /></td><td><p>Nodes with black outline indicate
that they are <strong>insecure</strong>, 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.</p></td></tr>
</table>
<h4><a name="warnings-errors">Warnings and Errors</a></h4>
<table>
<tr><td><img src="images/nodes-warnings.png"
alt="Nodes with warnings" /></td><td><p>If one or more warnings are
detected with the data represented by a node in the graph, then a
warning icon is displayed in the node.</p></td></tr>
<tr><td><img src="images/edges-warnings.png"
alt="Edges with warnings" /></td><td><p>Similarly, the warning icon is
displayed alongside edges whose represented data has
warnings.</p></td></tr>
<tr><td><img src="images/zone-warnings.png"
alt="Zone with warnings" /></td><td><p>The warning icon is also
displayed within the cluster representing a zone if there are
zone-related warnings.</p></td></tr>
<tr><td><img src="images/nodes-errors.png"
alt="Nodes with errors" /></td><td><p>If one or more errors (more
severe than warnings) are detected with the data represented by a node
in the graph, then an error icon is displayed in the
node.</p></td></tr>
<tr><td><img src="images/edges-errors.png"
alt="Edges with errors" /></td><td><p>Similarly, the error icon is
displayed alongside edges whose represented data has
errors.</p></td></tr>
<tr><td><img src="images/zone-errors.png"
alt="Zone with errors" /></td><td><p>The error icon is also displayed
within the cluster representing a zone if there are zone-related
errors.</p></td></tr>
<tr><td><img src="images/response-warning.png"
alt="Response warning" /></td><td><p>A warning icon with an italicized
label denotes a warning for a response that isn't represented
elsewhere in the graph, such as a referral with the authoritative
answer flag set.</p></td></tr>
<tr><td><img src="images/response-error.png"
alt="Response error" /></td><td><p>An error icon with an italicized
label denotes a response error, e.g., due to timeout, malformed response,
or invalid RCODE.</p></td></tr>
</table>
</body>
</html>
|
