forked from tlswg/dnssec-chain-extension
-
Notifications
You must be signed in to change notification settings - Fork 1
/
draft-ietf-tls-dnssec-chain-extension-04.xml
1067 lines (963 loc) · 43.3 KB
/
draft-ietf-tls-dnssec-chain-extension-04.xml
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
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc1035 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml">
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc4034 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4034.xml">
<!ENTITY rfc4035 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4035.xml">
<!ENTITY rfc5011 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5011.xml">
<!ENTITY rfc5246 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml">
<!ENTITY rfc5905 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5905.xml">
<!ENTITY rfc6066 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6066.xml">
<!ENTITY rfc6698 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6698.xml">
<!ENTITY rfc7120 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7120.xml">
<!ENTITY rfc7250 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7250.xml">
<!ENTITY rfc7633 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7633.xml">
<!ENTITY rfc7671 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7671.xml">
<!ENTITY rfc7672 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7672.xml">
<!ENTITY rfc7901 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7901.xml">
]>
<!-- To do: -->
<!-- state machine diagram for the verification section? -->
<!-- pseudocode -->
<!-- test vectors -->
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc strict="no"?>
<?rfc rfcedstyle="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<rfc docName="draft-ietf-tls-dnssec-chain-extension-04"
ipr="trust200902" category="std">
<front>
<title abbrev="TLS DNSSEC Chain Extension">
A DANE Record and DNSSEC Authentication Chain Extension for TLS
</title>
<author fullname="Melinda Shore" initials="M"
surname="Shore">
<organization>Fastly</organization>
<address>
<email>mshore@fastly.com</email>
</address>
</author>
<author fullname="Richard Barnes" initials="R"
surname="Barnes">
<organization>Mozilla</organization>
<address>
<email>rlb@ipv.sx</email>
</address>
</author>
<author fullname="Shumon Huque" initials="S"
surname="Huque">
<organization>Salesforce</organization>
<address>
<email>shuque@gmail.com</email>
</address>
</author>
<author fullname="Willem Toorop" initials="W"
surname="Toorop">
<organization>NLNet Labs</organization>
<address>
<email>willem@nlnetlabs.nl</email>
</address>
</author>
<date year="2017" />
<area>Security</area>
<workgroup>TLS</workgroup>
<abstract>
<t>
This draft describes a new TLS extension for
transport of a DNS record set serialized with the DNSSEC
signatures needed to authenticate that record set. The
intent of this proposal is to allow TLS clients to
perform DANE authentication of a TLS server
without needing to perform additional DNS
record lookups. It will typically not be used for
general DNSSEC validation of TLS endpoint names.
</t>
</abstract>
</front>
<middle>
<section title="Requirements Notation">
<t>The key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" in this document
are to be interpreted as described
in <xref target="RFC2119" />.</t>
</section>
<section title="Introduction">
<t>
This draft describes a new <xref target="RFC5246">TLS
</xref> extension
for transport of a DNS record set serialized with the
<xref target="RFC4034">DNSSEC signatures</xref> needed
to authenticate that record set. The intent of this
proposal is to allow TLS clients to perform DANE
Authentication <xref target="RFC6698" />
<xref target="RFC7671" /> of a TLS
server without performing
additional DNS record lookups and incurring the
associated latency penalty. It also provides the
ability to avoid potential problems with TLS clients
being unable to look up DANE records because of an
interfering or broken middlebox on the path between
the client and a DNS server. And lastly, it allows a
TLS client to validate DANE records itself without
necessarily needing access to a validating DNS resolver to which
it has a secure connection. It will typically not be
used for general DNSSEC validation of endpoint names,
but is more appropriate for validation of DANE TLSA records.
</t>
<t>
This mechanism is useful
for TLS applications that need to address the problems
described above, typically web browsers or VoIP and
XMPP applications. It may not be relevant for many other
applications. For example, SMTP MTAs are usually
located in data centers, may tolerate
extra DNS lookup latency, are on servers where it is
easier to provision a validating resolver, or are
less likely to experience traffic interference from
misconfigured middleboxes. Furthermore, SMTP MTAs usually
employ <xref target="RFC7672">Opportunistic Security</xref>,
in which the presence of the DNS TLSA records is used to determine
whether to enforce an authenticated TLS connection.
Hence DANE authentication of SMTP MTAs will typically not use
this mechanism.
</t>
<t>
The extension described here allows a TLS client to
request in the ClientHello message that the DNS authentication
chain be returned in the (extended) ServerHello message.
If the server is configured for DANE authentication, then
it performs the appropriate DNS queries, builds the authentication
chain, and returns it to the client. The
server will usually use a previously cached authentication chain, but
it will need to rebuild it periodically as described in
<xref target="sec_caching" />.
The client then authenticates the chain using a pre-configured
trust anchor.
</t>
<t>
This specification is based on Adam Langley's original
proposal for serializing DNSSEC authentication chains
and delivering them in an X.509 certificate extension
<xref target="I-D.agl-dane-serializechain" />. It modifies the approach by using
wire format DNS records in the serialized data (assuming
that the data will be prepared and consumed by a DNS-specific
library), and by using a TLS extension to deliver the data.
</t>
<t>
As described in the DANE specification <xref target="RFC6698" />
<xref target="RFC7671" />, this
procedure applies to the DANE authentication of X.509
certificates or raw public keys <xref target="RFC7250" />.
</t>
</section> <!-- introduction -->
<section title="DNSSEC Authentication Chain Extension">
<section title="Protocol, TLS 1.2">
<t>
A client MAY include an extension of type
"dnssec_chain" in the (extended) ClientHello. The
"extension_data" field of this extension MUST be
empty.
</t>
<t>
Servers receiving a "dnssec_chain" extension in the
ClientHello, and which are capable of being authenticated
via DANE, MAY return a serialized authentication chain
in the extended ServerHello message, using the format
described below. If a server is unable to return an
authentication chain, or does not wish to return an
authentication chain, it does not include a dnssec_chain
extension. As with all TLS extensions, if the server
does not support this extension it will not return any
authentication chain.
</t>
<t>
A client must not be able to force a server to
perform lookups on arbitrary domain names using this
mechanism. Therefore, a server MUST NOT construct
chains for domain names other than its own.
</t>
</section> <!-- protocol 1.2 -->
<section title="Protocol, TLS 1.3">
<t>
A client MAY include an extension of type
"dnssec_chain" in the ClientHello. The
"extension_data" field of this extension MUST be
empty.
</t>
<t>
Servers receiving a "dnssec_chain" extension in the
ClientHello, and which are capable of being authenticated
via DANE, SHOULD return a serialized authentication chain
in the Certificate message associated with the end
entity certificate being validated, using the format
described below. The authentication chain will be an
extension to the certificate_list to which the
certificate being authenticated belongs.
</t>
<t>
The extension protocol behavior otherwise follows that specified
for TLS version 1.2.
</t>
</section> <!-- protocol 1.3 -->
<section title="Raw Public Keys">
<t>
<xref target="RFC7250" /> specifies the use of raw
public keys for both server and client
authentication in TLS 1.2. It points out that in
cases where raw public keys are being used, code for
certificate path validation is not
required. However, DANE, when used in conjunction
with the dnssec_chain extension, provides a mechanism for
securely binding a raw public key to a named entity
in the DNS, and when using DANE for authentication a
raw key may be validated using a path chaining back
to a DNSSEC trust root. This has the added benefit
of mitigating an unknown key share attack, as
described in <xref target="I-D.barnes-dane-uks" />,
since it effectively augments the raw public key
with the server's name and provides a means to
commit both the server and the client to using that
binding.
</t>
<t>
The UKS attack is possible in situations in which
the association between a domain name and a public
key is not tightly bound, as in the case in DANE in
which a client either ignores the name in
certificate (as specified in <xref target="RFC7671"
/> or there is no attestation of trust outside of
the DNS. The vulnerability arises in the following
situations:
</t>
<t>
<list style="symbols">
<t>If the client does not verify the identity in the
server's certificate (as recommended in Section
5.1 of [RFC7671]), then an attacker can induce the
client to accept an unintended identity for the
server,
</t>
<t>If the client allows the use of raw public keys
in TLS, then it will not receive any
indication of the server's identity in the TLS
channel, and is thus unable to check that the
server's identity is as intended.
</t>
</list>
</t>
<t>The mechanism for conveying DNSSEC validation
chains described in this document results in a
commitment by both parties, via the TLS
handshake, to a domain name which has been validated
as belonging to the owner name.</t>
<t>The mechanism for encoding DNSSEC authentication
chains in a TLS extension, as described in this
document, is not limited to public keys encapsulated
in X.509 containers but MAY be applied to raw
public keys and other representations, as well.
</t>
</section>
<section title="DNSSEC Authentication Chain Data"
anchor="auth_chain_data">
<t>
The "extension_data" field of the "dnssec_chain" extension
MUST contain a DNSSEC Authentication Chain encoded in the
following form:
</t>
<figure>
<artwork>
opaque AuthenticationChain<0..2^16-1>
</artwork>
</figure>
<t>
The AuthenticationChain structure is composed of a sequence of
uncompressed wire format DNS resource record sets (RRset) and
corresponding signatures (RRSIG) records.
</t>
<t>
This sequence of native DNS wire format records enables easier
generation of the data structure on the server and easier
verification of the data on client by means of existing DNS library
functions. However this document describes the data structure
in sufficient detail that implementers if they desire can write
their own code to do this.
</t>
<t>
Each RRset in the chain is composed of a sequence of wire format
DNS resource records. The format of the resource record is
described in <xref target="RFC1035">RFC 1035</xref>, Section
3.2.1. The resource records SHOULD be presented in the canonical
form and ordering as described in
<xref target="RFC4034">RFC 4034</xref>.
</t>
<figure>
<artwork>
RR(i) = owner | type | class | TTL | RDATA length | RDATA
</artwork>
</figure>
<t>
RRs within the RRset MAY be ordered canonically, by treating
the RDATA portion of each RR as a left-justified unsigned
octet sequence in which the absence of an octet sorts before
a zero octet.
</t>
<t>
Each RRset in the sequence is followed by its associated
RRsig record.
The RRsig record is in DNS wire format as described in
<xref target="RFC4034">RFC 4034</xref>, Section 3.1. The
signature portion of the RDATA, as described in the same
section, is the following:
</t>
<figure>
<artwork>
signature = sign(RRSIG_RDATA | RR(1) | RR(2)... )
</artwork>
</figure>
<t>
where RRSIG_RDATA is the wire format of the RRSIG RDATA
fields with the Signer's Name field in canonical form and
the signature field excluded.
</t>
<t>
The first RRset in the chain MUST contain the TLSA record set
being presented. However, if the owner name of the TLSA record
set is an alias (CNAME or DNAME), then it MUST be preceded by the
chain of alias records needed to resolve it. DNAME chains should
omit unsigned CNAME records that may have been synthesized in the
response from a DNS resolver.
</t>
<t>
The subsequent RRsets MUST contain the full set
of DNS records needed to authenticate the TLSA record set from the
server's trust anchor. Typically this means a set of DNSKEY
and DS RRsets that cover all zones from the target zone containing
the TLSA record set to the trust anchor zone. The TLS client should
be prepared to receive this set of RRsets in any order.
</t>
<t>
Names that are aliased via CNAME and/or DNAME records may involve
multiple branches of the DNS tree. In this case, the authentication
chain structure needs to include DS and DNSKEY record sets that
cover all the necessary branches.
</t>
<t>
If the TLSA record set was synthesized by a DNS wildcard, the
chain must include the signed NSEC or NSEC3 records that prove
that there was no explicit match of the TLSA record name and no
closer wildcard match.
</t>
<t>
The final DNSKEY RRset in the authentication chain corresponds
to the trust anchor (typically the DNS root). This trust anchor
is also preconfigured in the TLS client, but including it in the
response from the server permits TLS clients to use the automated
trust anchor rollover mechanism defined in RFC 5011
<xref target="RFC5011" /> to update their configured trust anchor.
</t>
<t>
The following is an example of the records in the
AuthenticationChain structure for the HTTPS server at
www.example.com, where there are zone cuts at "com."
and "example.com." (record data are omitted here for brevity):
</t>
<figure>
<artwork>
_443._tcp.www.example.com. TLSA
RRSIG(_443._tcp.www.example.com. TLSA)
example.com. DNSKEY
RRSIG(example.com. DNSKEY)
example.com. DS
RRSIG(example.com. DS)
com. DNSKEY
RRSIG(com. DNSKEY)
com. DS
RRSIG(com. DS)
. DNSKEY
RRSIG(. DNSKEY)
</artwork>
</figure>
</section> <!-- authentication chain data -->
</section> <!-- dnssec authentication chain extension -->
<section title="Construction of Serialized Authentication Chains">
<t>
This section describes a possible procedure for the
server to use to build the serialized DNSSEC chain.
</t>
<t>When the goal is to perform DANE authentication
<xref target="RFC6698" /> <xref target="RFC7671" /> of the
server, the DNS record set to be
serialized is a TLSA record set corresponding to the
server's domain name, protocol, and port number.
</t>
<t>
The domain name of the server MUST be that included in
the TLS server_name extension <xref target="RFC6066"
/> when present. If the server_name extension is not
present, or if the server does not recognize the
provided name and wishes to proceed with the handshake
rather than to abort the connection, the server uses
the domain name associated with the server IP address
to which the connection has been established.
</t>
<t>
The TLSA record to be queried is constructed by prepending
the _port and _transport labels to the domain name as described
in <xref target="RFC6698" />, where "port" is the port number
associated with the TLS server. The transport is "tcp"
for TLS servers, and "udp" for DTLS servers. The port
number label is the left-most label, followed by the
transport, followed by the base domain name.
</t>
<t>
The components of the authentication chain are typically built by
starting at the target record set and its corresponding RRSIG.
Then traversing the DNS tree upwards towards the trust anchor
zone (normally the DNS root), for each zone cut, the DNSKEY and
DS RRsets and their signatures are added. However, see
<xref target="auth_chain_data" /> for specific processing needed for
aliases and wildcards. If DNS responses messages contain any
domain names utilizing name compression
<xref target="RFC1035"/>, then they must be uncompressed.
</t>
<t>
Newer DNS protocol enhancements, such as the <xref target="RFC7901">
EDNS Chain Query extension</xref> if supported, may offer easier ways
to obtain all of the chain data in one transaction with an upstream
DNSSEC aware recursive server.
</t>
</section> <!-- construction -->
<section title="Caching and Regeneration of the Authentication Chain"
anchor="sec_caching">
<t>
DNS records have Time To Live (TTL) parameters, and DNSSEC
signatures have validity periods (specifically signature expiration
times). After the TLS server constructs the serialized authentication
chain, it SHOULD cache and reuse it in multiple TLS connection
handshakes. However, it MUST refresh and rebuild the chain as TTLs
and signature validity periods dictate. A server implementation
could carefully track these parameters and requery component records
in the chain correspondingly. Alternatively, it could be configured
to rebuild the entire chain at some predefined periodic interval that
does not exceed the DNS TTLs or signature validity periods of the
component records in the chain.
</t>
</section>
<section title="Verification" anchor="sec_verification">
<t>
A TLS client making use of this specification, and
which receives a DNSSEC authentication chain extension
from a server, SHOULD use this information to perform
DANE authentication of the server. In
order to do this, it uses the mechanism specified by
the <xref target="RFC4035">DNSSEC protocol</xref>.
This mechanism is sometimes implemented in a DNSSEC
validation engine or library.
</t>
<!-- TODO: Add a precis of the algorithm here -->
<t>
If the authentication chain is
correctly verified, the client then performs DANE
authentication of the server according to the
DANE TLS protocol <xref target="RFC6698" />
<xref target="RFC7671" />.
</t>
</section> <!-- verification -->
<section title="Trust Anchor Maintenance" anchor="sec_trustmaint">
<t>
The trust anchor may change periodically, e.g. when the operator
of the trust anchor zone performs a DNSSEC key rollover. TLS
clients using this specification MUST implement a mechanism to
keep their trust anchors up to date. They could use the method
defined in <xref target="RFC5011" /> to perform trust anchor
updates inband in TLS, by tracking the introduction of new keys
seen in the trust anchor DNSKEY RRset. However, alternative
mechanisms external to TLS may also be utilized. Some operating systems
may have a system-wide service to maintain and keep the root trust
anchor up to date. In such cases, the TLS client application
could simply reference that as its trust anchor, periodically
checking whether it has changed. Some applications may prefer to
implement trust anchor updates as part of their automated software
updates.
</t>
</section> <!-- trust anchor maintenance -->
<section title="Mandating use of this extension" anchor="must_staple">
<t>
A TLS server certificate MAY mandate the use of this extension by means
of the X.509 TLS Feature Extension described in <xref target="RFC7633" />.
This X.509 certificate extension, when populated with the dnssec_chain
TLS extension identifier, indicates to the client that the server must
deliver the authentication chain when asked to do so. (The X.509 TLS
Feature Extension is the same mechanism used to deliver other mandatory
signals, such as OCSP "must staple" assertions.) Mandating this
extension for Raw Public Key authentication (where there are no X.509
certificates) could employ configuration mechanisms external to the
TLS protocol.
</t>
</section>
<section title="Security Considerations">
<t>
The security considerations of the normatively referenced RFCs
(1035, 4034, 4035, 5246, 6066, 6698, 7633, 7671) all pertain to
this extension. Since the server is delivering a chain of DNS
records and signatures to the client, it MUST rebuild the chain
in accordance with TTL and signature expiration of
the chain components as described in <xref target="sec_caching" />.
TLS clients need roughly accurate time in order to properly
authenticate these signatures. This could be achieved by running
a time synchronization protocol like NTP <xref target="RFC5905" />
or SNTP <xref target="RFC5905" />, which are already widely used
today. TLS clients MUST support a mechanism to track and rollover
the trust anchor key, or be able to avail themselves of a service
that does this, as described in <xref target="sec_trustmaint" />.
</t>
</section>
<section title="IANA Considerations">
<t>This extension requires the registration of a new
value in the TLS ExtensionsType registry. The value
requested from IANA is 53. If the draft is adopted by
the WG, the authors expect to make an early allocation
request as specified in <xref target="RFC7120" />.</t>
</section> <!-- iana considerations -->
<section title="Acknowledgments">
<t>
Many thanks to Adam Langley for laying the groundwork
for this extension. The original idea is his but our
acknowledgment in no way implies his endorsement.
This document also benefited from discussions with and
review from the following people: Viktor Dukhovni,
Daniel Kahn Gillmor, Jeff Hodges, Allison Mankin, Patrick McManus,
Rick van Rein,
Gowri Visweswaran, Duane Wessels, Nico Williams, and Paul Wouters.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc1035;
&rfc2119;
&rfc4034;
&rfc4035;
&rfc5246;
&rfc6066;
&rfc6698;
&rfc7633;
&rfc7671;
</references>
<references title="Informative References">
&rfc5011;
&rfc5905;
&rfc7120;
&rfc7250;
&rfc7672;
&rfc7901;
<?rfc include="reference.I-D.agl-dane-serializechain.xml"?>
<?rfc include="reference.I-D.draft-barnes-dane-uks-00.xml"?>
</references>
<section title="Updates from -01 and -02">
<t>
<list style="symbols">
<t>Editorial updates for style and consistency</t>
<t>Updated discussion of UKS attack</t>
</list>
</t>
</section>
<section title="Updates from -01">
<t>
<list style="symbols">
<t>Added TLS 1.3 support</t>
<t>Added section describing applicability to raw
public keys</t>
<t>Softened language about record order</t>
</list>
</t>
</section>
<section title="Updates from -00">
<t>
<list style="symbols">
<t>Edits based on comments from Rick van Rein</t>
<t>Warning about not overloading X.509 wildcards on
DNSSEC wildcards (from V. Dukhovny) </t>
<t>Added MUST include negative proof on
wildcards (from V. Dukhovny) </t>
<t>Removed "TODO" on allowing the server to deliver
only one signature per RRset</t>
<t>Added additional minor edits suggested by Viktor
Dukhovny</t>
</list>
</t>
</section> <!-- updates -->
<section title="Test vectors">
<t>
The provided test vectors will authenticate the certificate
used with https://example.com/, https://example.net/ and
https://example.org/ at the time of writing:
</t>
<figure>
<artwork>
-----BEGIN CERTIFICATE-----
MIIF8jCCBNqgAwIBAgIQDmTF+8I2reFLFyrrQceMsDANBgkqhkiG9w0BAQsFADBw
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3
d3cuZGlnaWNlcnQuY29tMS8wLQYDVQQDEyZEaWdpQ2VydCBTSEEyIEhpZ2ggQXNz
dXJhbmNlIFNlcnZlciBDQTAeFw0xNTExMDMwMDAwMDBaFw0xODExMjgxMjAwMDBa
MIGlMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEUMBIGA1UEBxML
TG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0aW9uIGZvciBB
c3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczETMBEGA1UECxMKVGVjaG5vbG9neTEY
MBYGA1UEAxMPd3d3LmV4YW1wbGUub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A
MIIBCgKCAQEAs0CWL2FjPiXBl61lRfvvE0KzLJmG9LWAC3bcBjgsH6NiVVo2dt6u
Xfzi5bTm7F3K7srfUBYkLO78mraM9qizrHoIeyofrV/n+pZZJauQsPjCPxMEJnRo
D8Z4KpWKX0LyDu1SputoI4nlQ/htEhtiQnuoBfNZxF7WxcxGwEsZuS1KcXIkHl5V
RJOreKFHTaXcB1qcZ/QRaBIv0yhxvK1yBTwWddT4cli6GfHcCe3xGMaSL328Fgs3
jYrvG29PueB6VJi/tbbPu6qTfwp/H1brqdjh29U52Bhb0fJkM9DWxCP/Cattcc7a
z8EXnCO+LK8vkhw/kAiJWPKx4RBvgy73nwIDAQABo4ICUDCCAkwwHwYDVR0jBBgw
FoAUUWj/kK8CB3U8zNllZGKiErhZcjswHQYDVR0OBBYEFKZPYB4fLdHn8SOgKpUW
5Oia6m5IMIGBBgNVHREEejB4gg93d3cuZXhhbXBsZS5vcmeCC2V4YW1wbGUuY29t
ggtleGFtcGxlLmVkdYILZXhhbXBsZS5uZXSCC2V4YW1wbGUub3Jngg93d3cuZXhh
bXBsZS5jb22CD3d3dy5leGFtcGxlLmVkdYIPd3d3LmV4YW1wbGUubmV0MA4GA1Ud
DwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwdQYDVR0f
BG4wbDA0oDKgMIYuaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL3NoYTItaGEtc2Vy
dmVyLWc0LmNybDA0oDKgMIYuaHR0cDovL2NybDQuZGlnaWNlcnQuY29tL3NoYTIt
aGEtc2VydmVyLWc0LmNybDBMBgNVHSAERTBDMDcGCWCGSAGG/WwBATAqMCgGCCsG
AQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMAgGBmeBDAECAjCB
gwYIKwYBBQUHAQEEdzB1MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2Vy
dC5jb20wTQYIKwYBBQUHMAKGQWh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9E
aWdpQ2VydFNIQTJIaWdoQXNzdXJhbmNlU2VydmVyQ0EuY3J0MAwGA1UdEwEB/wQC
MAAwDQYJKoZIhvcNAQELBQADggEBAISomhGn2L0LJn5SJHuyVZ3qMIlRCIdvqe0Q
6ls+C8ctRwRO3UU3x8q8OH+2ahxlQmpzdC5al4XQzJLiLjiJ2Q1p+hub8MFiMmVP
PZjb2tZm2ipWVuMRM+zgpRVM6nVJ9F3vFfUSHOb4/JsEIUvPY+d8/Krc+kPQwLvy
ieqRbcuFjmqfyPmUv1U9QoI4TQikpw7TZU0zYZANP4C/gj4Ry48/znmUaRvy2kvI
l7gRQ21qJTK5suoiYoYNo3J9T+pXPGU7Lydz/HwW+w0DpArtAaukI8aNX4ohFUKS
wDSiIIWIWJiJGbEeIO0TIFwEVWTOnbNl/faPXpk5IRXicapqiII=
-----END CERTIFICATE-----
</artwork>
</figure>
<t>For brevity and reproducability all DNS zones involved with the test vectors
are signed using a single key with algorithm 13: ECDSA Curve P-256 with SHA-256.</t>
<t>The test vectors are DNSSEC valid at June 1 2017, with the following root trust anchor:</t>
<figure>
<artwork>
. IN DS ( 47005 13 2 2eb6e9f2480126691594d649a5a613de3052e37861634
641bb568746f2ffc4d4 )
</artwork>
</figure>
<section title="_443._tcp.www.example.com">
<figure>
<artwork>
_443._tcp.www.example.com. 3600 IN TLSA ( 3 1 1
c66bef6a5c1a3e78b82016e13f314f3cc5fa25b1e52aab9adb9ec5989b165
ada )
_443._tcp.www.example.com. 3600 IN RRSIG ( TLSA 13 5 3600
20170616000000 20170526000000 1870 example.com.
GRsT6bcn3fokM5JMvHF0liq63N/kUX+CrZQZIr4GlFnMr/uoS4P1zOBwc0sft
Kd8NsZJAikRr4CpaXITYQMx1w== )
example.com. 3600 IN DNSKEY ( 257 3 13
JnA1XgyJTZz+psWvbrfUWLV6ULqIJyUS2CQdhUH9VK35bslWeJpRzrlxCUs7s
/TsSfZMaGWVvlsuieh5nHcXzA== ) ; Key ID = 1870
example.com. 3600 IN RRSIG ( DNSKEY 13 2 3600
20170616000000 20170526000000 1870 example.com.
sB6o0XXz7AXDWibruD75rllaHI1kOu4ftoXsKOPPArjflNlTPxrJsspN8ww9r
8q6DBlCdlRQvzD90UKZDIAqbA== )
example.com. 900 IN DS ( 1870 13 2
e9b533a049798e900b5c29c90cd25a986e8a44f319ac3cd302bafc08f5b81
e16 )
example.com. 900 IN RRSIG ( DS 13 2 900 20170605000000
20170529000000 18931 com.
rBV/16HTJBwmexByZq7WzYbB3EYaJ6MctpUSxuSNEpwDgzKkwIXzKECh5F5x3
5XxvbOdLIJAcxhRS1c2VITfMA== )
com. 900 IN DNSKEY ( 257 3 13
RbkcO+96XZmnp8jYIuM4lryAp3egQjSmBaSoiA7H76Tm0RLHPNPUxlVk+nQ0f
Ic3I8xfZDNw8Wa0Pe3/g2QA/w== ) ; Key ID = 18931
com. 900 IN RRSIG ( DNSKEY 13 1 900 20170605000000
20170529000000 18931 com.
wjCqnHNa5QcMrbuAnKIWBESMFtVjDldmd98udKPtg35V9ESD9SuNKtRJRdHYk
c6Nx3HLmhidf6dmt/Hi0ePBsQ== )
com. 86400 IN DS ( 18931 13 2
20f7a9db42d0e2042fbbb9f9ea015941202f9eabb94487e658c188e7bcb52
115 )
com. 86400 IN RRSIG ( DS 13 1 86400 20170612000000
20170530000000 47005 .
jPah4caFBSqhdt78YYhwFZn3ouKiWUKTH1t/nMB7tXzjorQJ50j1RMR23JVL+
jGGQccnLkQnUf7zednetSWalg== )
. 86400 IN DNSKEY ( 257 3 13
yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv
Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005
. 86400 IN RRSIG ( DNSKEY 13 0 86400 20170612000000
20170530000000 47005 .
tFldEx7SQI43PIzn1ib/oZTko+Q+gRuOLcALoSA0WQRh1yXSV1752p1n3imhK
8y3m+LZSLDSBHEocXIiRHWdFg== )
</artwork>
</figure>
<t>A hex dump of the wire format data of this content is:</t>
<figure>
<artwork>
0000: 04 5f 34 34 33 04 5f 74 63 70 03 77 77 77 07 65
0010: 78 61 6d 70 6c 65 03 63 6f 6d 00 00 34 00 01 00
0020: 00 0e 10 00 23 03 01 01 c6 6b ef 6a 5c 1a 3e 78
0030: b8 20 16 e1 3f 31 4f 3c c5 fa 25 b1 e5 2a ab 9a
0040: db 9e c5 98 9b 16 5a da 04 5f 34 34 33 04 5f 74
0050: 63 70 03 77 77 77 07 65 78 61 6d 70 6c 65 03 63
0060: 6f 6d 00 00 2e 00 01 00 00 0e 10 00 5f 00 34 0d
0070: 05 00 00 0e 10 59 43 1f 80 59 27 70 00 07 4e 07
0080: 65 78 61 6d 70 6c 65 03 63 6f 6d 00 7b be 85 af
0090: 63 08 fd be 6e eb 68 df 85 c2 58 e6 41 37 2f 68
00a0: 34 4f 4f ce 91 9c 4c b0 54 bb e5 31 cd 57 0c 57
00b0: cf 10 ce 33 13 29 7a b4 81 d9 10 d0 cf f3 32 c8
00c0: 24 e8 06 12 59 8c 58 c5 15 6e ae e1 07 65 78 61
00d0: 6d 70 6c 65 03 63 6f 6d 00 00 30 00 01 00 00 0e
00e0: 10 00 44 01 01 03 0d 26 70 35 5e 0c 89 4d 9c fe
00f0: a6 c5 af 6e b7 d4 58 b5 7a 50 ba 88 27 25 12 d8
0100: 24 1d 85 41 fd 54 ad f9 6e c9 56 78 9a 51 ce b9
0110: 71 09 4b 3b b3 f4 ec 49 f6 4c 68 65 95 be 5b 2e
0120: 89 e8 79 9c 77 17 cc 07 65 78 61 6d 70 6c 65 03
0130: 63 6f 6d 00 00 2e 00 01 00 00 0e 10 00 5f 00 30
0140: 0d 02 00 00 0e 10 59 43 1f 80 59 27 70 00 07 4e
0150: 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 db ce bb
0160: 5f 1c 4b f0 4e de 1e 36 f0 00 75 ae 79 f1 4e 7b
0170: 42 3b ff dc c0 04 b8 3c 5f 3a e7 ac a7 0c 47 0a
0180: a5 3d 70 95 28 d5 c9 65 5c 6f 7c ad 25 1e d2 77
0190: 00 2c 0a 9f f7 e9 19 a6 04 e9 cb 09 60 07 65 78
01a0: 61 6d 70 6c 65 03 63 6f 6d 00 00 2b 00 01 00 00
01b0: 03 84 00 24 07 4e 0d 02 e9 b5 33 a0 49 79 8e 90
01c0: 0b 5c 29 c9 0c d2 5a 98 6e 8a 44 f3 19 ac 3c d3
01d0: 02 ba fc 08 f5 b8 1e 16 07 65 78 61 6d 70 6c 65
01e0: 03 63 6f 6d 00 00 2e 00 01 00 00 03 84 00 57 00
01f0: 2b 0d 02 00 00 03 84 59 34 9f 00 59 2b 64 80 49
0200: f3 03 63 6f 6d 00 18 f3 6d 66 92 89 48 73 26 3a
0210: cd 1e 35 38 a3 97 07 1b ed de d6 14 db 16 f0 f5
0220: 62 27 20 c5 eb fa 66 ac a4 a7 8e 93 33 ca 62 42
0230: 91 7a 51 b5 15 3a 83 14 3a 80 a5 f2 b6 80 00 e5
0240: 6b 92 ba 37 ec 2d 03 63 6f 6d 00 00 30 00 01 00
0250: 00 03 84 00 44 01 01 03 0d 45 b9 1c 3b ef 7a 5d
0260: 99 a7 a7 c8 d8 22 e3 38 96 bc 80 a7 77 a0 42 34
0270: a6 05 a4 a8 88 0e c7 ef a4 e6 d1 12 c7 3c d3 d4
0280: c6 55 64 fa 74 34 7c 87 37 23 cc 5f 64 33 70 f1
0290: 66 b4 3d ed ff 83 64 00 ff 03 63 6f 6d 00 00 2e
02a0: 00 01 00 00 03 84 00 57 00 30 0d 01 00 00 03 84
02b0: 59 34 9f 00 59 2b 64 80 49 f3 03 63 6f 6d 00 8d
02c0: 21 46 95 a5 17 ab 10 0a 49 dd 25 d3 6b 7d 88 ab
02d0: 2b 18 c9 53 da f2 76 fd a5 82 b8 ea 14 cb 7c 25
02e0: 4a 36 4a f0 48 9b e6 a3 0d aa 5b 98 15 8e 64 12
02f0: bb 1b 6e 45 3f 03 00 88 3d 48 b7 0f 78 53 2b 03
0300: 63 6f 6d 00 00 2b 00 01 00 01 51 80 00 24 49 f3
0310: 0d 02 20 f7 a9 db 42 d0 e2 04 2f bb b9 f9 ea 01
0320: 59 41 20 2f 9e ab b9 44 87 e6 58 c1 88 e7 bc b5
0330: 21 15 03 63 6f 6d 00 00 2e 00 01 00 01 51 80 00
0340: 53 00 2b 0d 01 00 01 51 80 59 3d d9 80 59 2c b6
0350: 00 b7 9d 00 33 56 6b d8 e2 80 50 7a e6 cf 68 27
0360: bb 22 5c a7 aa 41 f1 36 94 1c ae 94 9c 3f da 98
0370: c5 0f 56 b8 26 c7 57 44 05 a3 a5 11 ef d9 77 b3
0380: 49 a9 50 8d 99 76 98 78 8e 4b 30 a8 70 51 63 09
0390: a2 b6 14 05 00 00 30 00 01 00 01 51 80 00 44 01
03a0: 01 03 0d ca f5 fe 54 d4 d4 8f 16 62 1a fb 6b d3
03b0: ad 21 55 ba cf 57 d1 fa ad 5b ac 42 d1 7d 94 8c
03c0: 42 17 36 d9 38 9c 4c 40 11 66 6e a9 5c f1 77 25
03d0: bd 0f a0 0c e5 e7 14 e4 ec 82 cf df ac c9 b1 c8
03e0: 63 ad 46 00 00 2e 00 01 00 01 51 80 00 53 00 30
03f0: 0d 00 00 01 51 80 59 3d d9 80 59 2c b6 00 b7 9d
0400: 00 2b 43 e5 99 de 8d bd e6 e1 f0 05 2d 16 a1 7a
0410: 79 15 42 da 47 da 2f 63 0e 46 ab 7d e3 7e 9b 8a
0420: 7d 25 e2 3f 18 bf 85 4c 17 b7 d5 3c 06 c8 18 bb
0430: bd 98 44 11 72 e3 18 bc 9d 99 88 e5 00 91 58 c8
0440: 47
</artwork>
</figure>
</section> <!-- _443._tcp.www.example.com -->
<section title="_25._tcp.example.com wildcard">
<figure>
<artwork>
_25._tcp.example.com. 3600 IN TLSA ( 3 1 1
c66bef6a5c1a3e78b82016e13f314f3cc5fa25b1e52aab9adb9ec5989b165
ada )
_25._tcp.example.com. 3600 IN RRSIG ( TLSA 13 3 3600
20170616000000 20170526000000 1870 example.com.
dVxm88Spko03MB4pLo+zijMup2nr1Ii65yPqB/cAR/1Zg41iXer7I2sGh9KfT
ExLJC6dUMDVFUfm+1rwb+ax8Q== )
*._tcp.example.com. 3600 IN NSEC (
_443._tcp.www.example.com. RRSIG NSEC TLSA )
*._tcp.example.com. 3600 IN RRSIG ( NSEC 13 3 3600
20170616000000 20170526000000 1870 example.com.
1lNaYYQ+FAG8YBVEx/026OGhVw5DjAyqBGrrLN9D12IZuLHtTQ4C9QPORP4na
GWNPgASvLyNR8MoN0oXV7tbnQ== )
example.com. 3600 IN DNSKEY ( 257 3 13
JnA1XgyJTZz+psWvbrfUWLV6ULqIJyUS2CQdhUH9VK35bslWeJpRzrlxCUs7s
/TsSfZMaGWVvlsuieh5nHcXzA== ) ; Key ID = 1870
example.com. 3600 IN RRSIG ( DNSKEY 13 2 3600
20170616000000 20170526000000 1870 example.com.
sB6o0XXz7AXDWibruD75rllaHI1kOu4ftoXsKOPPArjflNlTPxrJsspN8ww9r
8q6DBlCdlRQvzD90UKZDIAqbA== )
example.com. 900 IN DS ( 1870 13 2
e9b533a049798e900b5c29c90cd25a986e8a44f319ac3cd302bafc08f5b81
e16 )
example.com. 900 IN RRSIG ( DS 13 2 900 20170605000000
20170529000000 18931 com.
rBV/16HTJBwmexByZq7WzYbB3EYaJ6MctpUSxuSNEpwDgzKkwIXzKECh5F5x3
5XxvbOdLIJAcxhRS1c2VITfMA== )
com. 900 IN DNSKEY ( 257 3 13
RbkcO+96XZmnp8jYIuM4lryAp3egQjSmBaSoiA7H76Tm0RLHPNPUxlVk+nQ0f
Ic3I8xfZDNw8Wa0Pe3/g2QA/w== ) ; Key ID = 18931
com. 900 IN RRSIG ( DNSKEY 13 1 900 20170605000000
20170529000000 18931 com.
wjCqnHNa5QcMrbuAnKIWBESMFtVjDldmd98udKPtg35V9ESD9SuNKtRJRdHYk
c6Nx3HLmhidf6dmt/Hi0ePBsQ== )
com. 86400 IN DS ( 18931 13 2
20f7a9db42d0e2042fbbb9f9ea015941202f9eabb94487e658c188e7bcb52
115 )
com. 86400 IN RRSIG ( DS 13 1 86400 20170612000000
20170530000000 47005 .
jPah4caFBSqhdt78YYhwFZn3ouKiWUKTH1t/nMB7tXzjorQJ50j1RMR23JVL+
jGGQccnLkQnUf7zednetSWalg== )
. 86400 IN DNSKEY ( 257 3 13
yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv
Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005
. 86400 IN RRSIG ( DNSKEY 13 0 86400 20170612000000
20170530000000 47005 .
tFldEx7SQI43PIzn1ib/oZTko+Q+gRuOLcALoSA0WQRh1yXSV1752p1n3imhK
8y3m+LZSLDSBHEocXIiRHWdFg== )
</artwork>
</figure>
</section> <!-- _25._tcp.example.com wildcard -->
<section title="_443._tcp.www.example.org CNAME">
<figure>
<artwork>
_443._tcp.www.example.org. 3600 IN CNAME (
dane311.example.org. )
_443._tcp.www.example.org. 3600 IN RRSIG ( CNAME 13 5 3600
20170616000000 20170526000000 44384 example.org.
DN+UMxh5TWL1u6Mc6ScWMU5R9C+qqIOSH4hqQmiPWhvSg0lFd71g43UqtdmBT
VRUbhk/f9WC8Fy5D0gE5lUcyA== )
dane311.example.org. 3600 IN TLSA ( 3 1 1
c66bef6a5c1a3e78b82016e13f314f3cc5fa25b1e52aab9adb9ec5989b165
ada )
dane311.example.org. 3600 IN RRSIG ( TLSA 13 3 3600
20170616000000 20170526000000 44384 example.org.
HJx59dAMQgvJSYBYtixzfodup5KRUzJ1SlRUrFJkGZz6PkpfuFdtpZwPN1vw9
SyvXq7WqRD46aaCMwR4ApUJ+w== )
example.org. 3600 IN DNSKEY ( 257 3 13
uspaqp17jsMTX6AWVgmbog/3Sttz+9ANFUWLn6qKUHr0BOqRuChQWj8jyYUUr
Wy9txxesNQ9MkO4LUrFght1LQ== ) ; Key ID = 44384
example.org. 3600 IN RRSIG ( DNSKEY 13 2 3600
20170616000000 20170526000000 44384 example.org.
MPTpfbVvPBXmh2Z4fgjy2GMgcJ8RYpXeOBOBidJDglLh4XQAiFOT6YpGRR5ig
tQGINd6gKVYdRSsEtXe1K8zxg== )
example.org. 900 IN DS ( 44384 13 2
ec307e2efc8f0117ed96ab48a513c8003e1d9121f1ff11a08b4cdd348d090
aa6 )
example.org. 900 IN RRSIG ( DS 13 2 900 20170615000000
20170525000000 12651 org.
MA3pxiap702Hvc81diwZDcRzLrkKssVzzTqCiJJoZFeNq40GuCOVGgEc+w6aq
SVgkgFJrhJISei/kvIZTx8ftw== )
org. 900 IN DNSKEY ( 257 3 13
0SZfoe8Yx+eoaGgyAGEeJax/ZBV1AuG+/smcOgRm+F6doNlgc3lddcM1MbTvJ
HTjK6Fvy8W6yZ+cAptn8sQheg== ) ; Key ID = 12651
org. 900 IN RRSIG ( DNSKEY 13 1 900 20170615000000
20170525000000 12651 org.
o4L9nBQo8KXF0a7D5268U+Bq8SuW/aePtyuSfvQvP79nN/mzh9P11CsT/opmW
kg0u6pqaG9KE1T37jloes8J8w== )
org. 86400 IN DS ( 12651 13 2
3979a51f98bbf219fcaf4a4176e766dfa8f9db5c24a75743eb1e704b97a9f
abc )
org. 86400 IN RRSIG ( DS 13 1 86400 20170612000000
20170530000000 47005 .
Mi1c7QrpHnl1MSLJTrq/WM0V0DQKwFPGaMFmHHwm8Yb/b934CUHMXU0dR+cLT
hakZNz37edtwPxKKOzZQ6pYUw== )
. 86400 IN DNSKEY ( 257 3 13
yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv
Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005
. 86400 IN RRSIG ( DNSKEY 13 0 86400 20170612000000
20170530000000 47005 .
tFldEx7SQI43PIzn1ib/oZTko+Q+gRuOLcALoSA0WQRh1yXSV1752p1n3imhK
8y3m+LZSLDSBHEocXIiRHWdFg== )
</artwork>
</figure>
</section> <!-- _443._tcp.www.example.org CNAME -->
<section title="_443._tcp.www.example.net DNAME">
<figure>
<artwork>
example.net. 3600 IN DNAME example.com.
example.net. 3600 IN RRSIG ( DNAME 13 2 3600 20170616000000
20170526000000 48085 example.net.
sTl9oxvpd7KxOZ9e5suevha7Fr+zPc3a0pWEUfjFE5v9Umu5js/vcp1i6hdqy
tQ2WXEQDsHeEjw9stupvMJkkg== )
_443._tcp.www.example.net. 3600 IN CNAME (
_443._tcp.www.example.com. )
_443._tcp.www.example.com. 3600 IN TLSA ( 3 1 1
c66bef6a5c1a3e78b82016e13f314f3cc5fa25b1e52aab9adb9ec5989b165
ada )
_443._tcp.www.example.com. 3600 IN RRSIG ( TLSA 13 5 3600
20170616000000 20170526000000 1870 example.com.
GRsT6bcn3fokM5JMvHF0liq63N/kUX+CrZQZIr4GlFnMr/uoS4P1zOBwc0sft
Kd8NsZJAikRr4CpaXITYQMx1w== )
example.net. 3600 IN DNSKEY ( 257 3 13
X9GHpJcS7bqKVEsLiVAbddHUHTZqqBbVa3mzIQmdp+5cTJk7qDazwH68Kts8d
9MvN55HddWgsmeRhgzePz6hMg== ) ; Key ID = 48085