1 Internet Engineering Task Force (IETF) W. Hardaker
2 Request for Comments: 8027 USC/ISI
3 BCP: 207 O. Gudmundsson
4 Category: Best Current Practice CloudFlare
5 ISSN: 2070-1721 S. Krishnaswamy
6 Parsons
7 November 2016
8
9
10 DNSSEC Roadblock Avoidance
11
12 Abstract
13
14 This document describes problems that a Validating DNS resolver,
15 stub-resolver, or application might run into within a non-compliant
16 infrastructure. It outlines potential detection and mitigation
17 techniques. The scope of the document is to create a shared approach
18 to detect and overcome network issues that a DNSSEC software/system
19 may face.
20
21 Status of This Memo
22
23 This memo documents an Internet Best Current Practice.
24
25 This document is a product of the Internet Engineering Task Force
26 (IETF). It represents the consensus of the IETF community. It has
27 received public review and has been approved for publication by the
28 Internet Engineering Steering Group (IESG). Further information on
29 BCPs is available in Section 2 of RFC 7841.
30
31 Information about the current status of this document, any errata,
32 and how to provide feedback on it may be obtained at
33 http://www.rfc-editor.org/info/rfc8027.
34
35 Copyright Notice
36
37 Copyright (c) 2016 IETF Trust and the persons identified as the
38 document authors. All rights reserved.
39
40 This document is subject to BCP 78 and the IETF Trust's Legal
41 Provisions Relating to IETF Documents
42 (http://trustee.ietf.org/license-info) in effect on the date of
43 publication of this document. Please review these documents
44 carefully, as they describe your rights and restrictions with respect
45 to this document. Code Components extracted from this document must
46 include Simplified BSD License text as described in Section 4.e of
47 the Trust Legal Provisions and are provided without warranty as
48 described in the Simplified BSD License.
49
50
51
52 Hardaker, et al. Best Current Practice [Page 1]
53 RFC 8027 DNSSEC Roadblock Avoidance November 2016
54
55
56 Table of Contents
57
58 1. Introduction ....................................................3
59 1.1. Notation ...................................................3
60 1.2. Background .................................................3
61 1.3. Implementation Experiences .................................4
62 1.3.1. Test Zone Implementation ............................4
63 2. Goals ...........................................................4
64 3. Detecting DNSSEC Non-compliance .................................5
65 3.1. Determining DNSSEC Support in Recursive Resolvers ..........5
66 3.1.1. Supports UDP Answers ................................6
67 3.1.2. Supports TCP Answers ................................6
68 3.1.3. Supports EDNS0 ......................................6
69 3.1.4. Supports the DO Bit .................................7
70 3.1.5. Supports the AD Bit DNSKEY Algorithms 5 and/or 8 ....7
71 3.1.6. Returns RRSIG for Signed Answer .....................7
72 3.1.7. Supports Querying for DNSKEY Records ................8
73 3.1.8. Supports Querying for DS Records ....................8
74 3.1.9. Supports Negative Answers with NSEC Records .........8
75 3.1.10. Supports Negative Answers with NSEC3 Records .......9
76 3.1.11. Supports Queries Where DNAME Records Lead
77 to an Answer .......................................9
78 3.1.12. Permissive DNSSEC .................................10
79 3.1.13. Supports Unknown RRtypes ..........................10
80 3.2. Direct Network Queries ....................................10
81 3.2.1. Support for Remote UDP over Port 53 ................10
82 3.2.2. Support for Remote UDP with Fragmentation ..........11
83 3.2.3. Support for Outbound TCP over Port 53 ..............11
84 3.3. Support for DNSKEY and DS Combinations ....................11
85 4. Aggregating the Results ........................................12
86 4.1. Resolver Capability Description ...........................12
87 5. Roadblock Avoidance ............................................13
88 5.1. Partial Resolver Usage ....................................16
89 5.1.1. Known Insecure Lookups .............................16
90 5.1.2. Partial NSEC/NSEC3 Support .........................16
91 6. Start-Up and Network Connectivity Issues .......................16
92 6.1. What to Do ................................................17
93 7. Quick Test .....................................................17
94 7.1. Test Negative Answers Algorithm 5 .........................17
95 7.2. Test Algorithm 8 ..........................................18
96 7.3. Test Algorithm 13 .........................................18
97 7.4. Fails When DNSSEC Does Not Validate .......................18
98 8. Security Considerations ........................................18
99 9. Normative References ...........................................18
100 Acknowledgments ...................................................19
101 Authors' Addresses ................................................19
102
103
104
105
106
107 Hardaker, et al. Best Current Practice [Page 2]
108 RFC 8027 DNSSEC Roadblock Avoidance November 2016
109
110
111 1. Introduction
112
113 This document describes problems observable during DNSSEC ([RFC4034]
114 [RFC4035]) deployment that derive from non-compliant infrastructure.
115 It poses potential detection and mitigation techniques.
116
117 1.1. Notation
118
119 In this document, a "Host Validator" can either be a validating stub-
120 resolver, such as a library that an application has linked in, or a
121 validating resolver daemon running on the same machine. It may or
122 may not be trying to use upstream caching resolvers during its own
123 resolution process; both cases are covered by the tests defined in
124 this document.
125
126 The sub-variant of this is a "Validating Forwarding Resolver", which
127 is a resolver that is configured to use upstream Resolvers when
128 possible. A Validating Forwarding Resolver also needs to perform the
129 tests outlined in this document before using an upstream recursive
130 resolver.
131
132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
134 document are to be interpreted as described in [RFC2119].
135
136 1.2. Background
137
138 Deployment of DNSSEC validation is hampered by network components
139 that make it difficult or sometimes impossible for validating
140 resolvers to effectively obtain the DNSSEC data they need. This can
141 occur for many different reasons including, but not limited to, the
142 following:
143
144 o Recursive resolvers and DNS proxies [RFC5625] not being fully
145 DNSSEC compliant
146
147 o Resolvers not being DNSSEC aware
148
149 o "Middleboxes" actively blocking, modifying, and/or restricting
150 outbound traffic to the DNS port (53) either UDP and/or TCP
151
152 o In-path network components not allowing UDP fragments
153
154 This document talks about ways that a Host Validator can detect the
155 state of the network it is attached to, and ways to hopefully
156 circumvent the problems associated with the network defects it
157 discovers. The tests described in this document may be performed on
158 any validating resolver to detect and prevent problems. While these
159
160
161
162 Hardaker, et al. Best Current Practice [Page 3]
163 RFC 8027 DNSSEC Roadblock Avoidance November 2016
164
165
166 recommendations are mainly aimed at Host Validators, it is prudent to
167 perform these tests from regular validating resolvers, just to make
168 sure things work.
169
170 There are situations where a host cannot talk directly to a Resolver;
171 the tests below cannot address how to overcome that, and inconsistent
172 results can be seen in such cases. This can happen, for instance,
173 when there are DNS proxies/forwarders between the user and the actual
174 resolvers.
175
176 1.3. Implementation Experiences
177
178 Multiple lessons learned from multiple implementations led to the
179 development of this document, including (in alphabetical order)
180 DNSSEC-Tools' DNSSEC-Check, DNSSEC_Resolver_Check, dnssec-trigger,
181 and FCC_Grade.
182
183 Detecting lack of support for specified Domain Name System Key
184 (DNSKEY) algorithms and Delegation Signer (DS) digest algorithms is
185 outside the scope of this document, but the document provides
186 information on how to do that. See the sample test tool:
187 <https://github.com/ogud/DNSSEC_ALG_Check>.
188
189 This document does describe compliance tests for algorithms 5, 7, and
190 13 with DS digest algorithms 1 and 2.
191
192 1.3.1. Test Zone Implementation
193
194 In this document, the "test.example.com" domain is used to refer to
195 DNS records that contain test records that have known DNSSEC
196 properties associated with them. For example, the "badsign-
197 a.test.example.com" domain is used below to refer to a DNS A record
198 where the signatures published for it are invalid (i.e., they are
199 "bad signatures" that should cause a validation failure).
200
201 At the time of this publication, the "test.dnssec-tools.org" domain
202 implements all of these test records. Thus, it may be possible to
203 replace "test.example.com" in this document with "test.dnssec-
204 tools.org" when performing real-world tests.
205
206 2. Goals
207
208 This document is intended to show how a Host Validator can detect the
209 capabilities of a recursive resolver and work around any problems
210 that could potentially affect DNSSEC resolution. This enables the
211 Host Validator to make use of the caching functionality of the
212 recursive resolver, which is desirable in that it decreases network
213 traffic and improves response times.
214
215
216
217 Hardaker, et al. Best Current Practice [Page 4]
218 RFC 8027 DNSSEC Roadblock Avoidance November 2016
219
220
221 A Host Validator has two choices: it can wait to determine that it
222 has problems with a recursive resolver based on the results that it
223 is getting from real-world queries issued to it or it can proactively
224 test for problems (Section 3) to build a workaround list ahead of
225 time (Section 5). There are pros and cons to both of these paths
226 that are application specific, and this document does not attempt to
227 provide guidance about whether proactive tests should or should not
228 be used. Either way, DNSSEC roadblock avoidance techniques ought to
229 be used when needed and if possible.
230
231 Note: Besides being useful for Host Validators, the same tests can be
232 used for a recursive resolver to check if its upstream connections
233 hinder DNSSEC validation.
234
235 3. Detecting DNSSEC Non-compliance
236
237 This section outlines tests that a validator should perform in order
238 to test certain features of the surrounding network. A resolver
239 should perform these tests when first starting but MAY also perform
240 these tests when it has detected network changes (e.g., address
241 changes, network reattachment, or etc.).
242
243 Note: When performing these tests against an address, we make the
244 following assumption about that address: it is a unicast address or
245 an anycast [RFC4786] cluster where all servers have identical
246 configuration and connectivity.
247
248 Note: When performing these tests, we also assume that the path is
249 clear of "DNS-interfering" middleboxes, like firewalls, proxies, or
250 forwarders. The presence of such infrastructure can easily make a
251 recursive resolver appear to be functioning improperly. It is beyond
252 the scope of the document as how to work around such interference,
253 although the tests defined in this document may indicate when such
254 misbehaving middleware is causing interference.
255
256 Note: This document specifies two sets of tests to perform: a
257 comprehensive one and a fast one. The fast one will detect most
258 common problems; thus, if the fast one passes, then the comprehensive
259 one MAY be considered passed as well.
260
261 3.1. Determining DNSSEC Support in Recursive Resolvers
262
263 Ideally, a Host Validator can make use of the caching present in
264 recursive resolvers. This section discusses the tests that a
265 recursive resolver MUST pass in order to be fully usable as a DNS
266 cache.
267
268
269
270
271
272 Hardaker, et al. Best Current Practice [Page 5]
273 RFC 8027 DNSSEC Roadblock Avoidance November 2016
274
275
276 Unless stated otherwise:
277
278 o all of the following tests SHOULD have the Recursion Desired (RD)
279 flag set when sending out a query and queries SHOULD be sent over
280 UDP.
281
282 o the tests MUST NOT have the DNSSEC OK (DO) bit set or utilize any
283 of the other DNSSEC-related requirements, like Extension
284 Mechanisms for DNS (EDNS0).
285
286 The tests are designed to check for support of one feature at a time.
287
288 3.1.1. Supports UDP Answers
289
290 Purpose: This tests basic DNS-over-UDP functionality to a resolver.
291
292 Test: A DNS request is sent to the resolver under test for an A
293 record for a known existing domain, such as good-a.test.example.com.
294
295 SUCCESS: A DNS response was received that contains an A record in the
296 answer section. (The data itself does not need to be checked.)
297
298 Note: An implementation MAY chose not to perform the rest of the
299 tests if this test fails, as it is highly unlikely that the resolver
300 under test will pass any of the remaining tests.
301
302 3.1.2. Supports TCP Answers
303
304 Purpose: This tests basic TCP functionality to a resolver.
305
306 Test: A DNS request is sent over TCP to the resolver under test for
307 an A record for a known existing domain, such as good-
308 a.test.example.com.
309
310 SUCCESS: A DNS response was received that contains an A record in the
311 answer section. (The data itself does not need to be checked.)
312
313 3.1.3. Supports EDNS0
314
315 Purpose: Test whether a resolver properly supports the EDNS0
316 extension option.
317
318 Prerequisite: Supports UDP or TCP.
319
320 Test: Send a request to the resolver under test for an A record for a
321 known existing domain, such as good-a.test.example.com, with an EDNS0
322 OPT record in the additional section.
323
324
325
326
327 Hardaker, et al. Best Current Practice [Page 6]
328 RFC 8027 DNSSEC Roadblock Avoidance November 2016
329
330
331 SUCCESS: A DNS response was received that contains an EDNS0 option
332 with version number 0.
333
334 3.1.4. Supports the DO Bit
335
336 Purpose: This tests whether a resolver has minimal support of the DO
337 bit.
338
339 Prerequisite: Supports EDNS0.
340
341 Test: Send a request to the resolver under test for an A record for a
342 known existing domain, such as good-a.test.example.com. Set the DO
343 bit in the outgoing query.
344
345 SUCCESS: A DNS response was received that contains the DO bit set.
346
347 Note: This only tests that the resolver set the DO bit in the
348 response. Later tests will determine if the DO bit was actually made
349 use of. Some resolvers successfully pass this test because they
350 simply copy the unknown flags into the response. These resolvers
351 will fail the later tests.
352
353 3.1.5. Supports the AD Bit DNSKEY Algorithms 5 and/or 8
354
355 Purpose: This tests whether the resolver is a validating resolver.
356
357 Prerequisite: Supports the DO bit.
358
359 Test: Send requests to the resolver under test for an A record for a
360 known existing domain in a DNSSEC-signed zone that is verifiable to a
361 configured trust anchor, such as good-a.test.example.com using the
362 root's published DNSKEY or DS record as a trust anchor. Set the DO
363 bit in the outgoing query. This test should be done twice: once for
364 a zone that contains algorithm 5 (RSASHA1) and again for algorithm 8
365 (RSASHA256).
366
367 SUCCESS: A DNS response was received that contains the Authentic Data
368 (AD) bit set for algorithm 5 (RSASHA1).
369
370 BONUS: The AD bit is set for a resolver that supports algorithm 8
371 (RSASHA256).
372
373 3.1.6. Returns RRSIG for Signed Answer
374
375 Purpose: This tests whether a resolver will properly return Resource
376 Record Signature (RRSIG) records when the DO bit is set.
377
378 Prerequisite: Supports the DO bit.
379
380
381
382 Hardaker, et al. Best Current Practice [Page 7]
383 RFC 8027 DNSSEC Roadblock Avoidance November 2016
384
385
386 Test: Send a request to the resolver under test for an A record for a
387 known existing domain in a DNSSEC-signed zone, such as good-
388 a.test.example.com. Set the DO bit in the outgoing query.
389
390 SUCCESS: A DNS response was received that contains at least one RRSIG
391 record.
392
393 3.1.7. Supports Querying for DNSKEY Records
394
395 Purpose: This tests whether a resolver can query for and receive a
396 DNSKEY record from a signed zone.
397
398 Prerequisite: Supports the DO bit.
399
400 Test: Send a request to the resolver under test for a DNSKEY record
401 that is known to exist in a signed zone, such as test.example.com/
402 DNSKEY. Set the DO bit in the outgoing query.
403
404 SUCCESS: A DNS response was received that contains a DNSKEY record in
405 the answer section.
406
407 Note: Some DNSKEY Resource Record Sets (RRsets) are large and, if the
408 network path has problems with large answers, this query may result
409 in either a false positive or a false negative. In general, the
410 DNSKEY queried for should be small enough to fit into a 1220-byte
411 answer to avoid a false negative result when TCP is disabled.
412 However, querying many zones will result in answers greater than 1220
413 bytes, so DNS over TCP MUST be available for DNSSEC use in general.
414
415 3.1.8. Supports Querying for DS Records
416
417 Purpose: This tests whether a resolver can query for and receive a DS
418 record from a signed zone.
419
420 Prerequisite: Supports the DO bit.
421
422 Test: Send a request to the resolver under test for a DS record that
423 is known to exist in a signed zone, such as test.example.com/DS. Set
424 the DO bit in the outgoing query.
425
426 SUCCESS: A DNS response was received that contains a DS record in the
427 answer section.
428
429 3.1.9. Supports Negative Answers with NSEC Records
430
431 Purpose: This tests whether a resolver properly returns NextSECure
432 (NSEC) records for a nonexisting domain in a DNSSEC-signed zone.
433
434
435
436
437 Hardaker, et al. Best Current Practice [Page 8]
438 RFC 8027 DNSSEC Roadblock Avoidance November 2016
439
440
441 Prerequisite: Supports the DO bit.
442
443 Test: Send a request to the resolver under test for an A record that
444 is known to not exist in an NSEC-signed zone, such as
445 nonexistent.test.example.com. Set the DO bit in the outgoing query.
446
447 SUCCESS: A DNS response was received that contains an NSEC record.
448
449 Note: The query issued in this test MUST be sent to an NSEC-signed
450 zone. Getting back appropriate NSEC3 records does not indicate a
451 failure, but a bad test.
452
453 3.1.10. Supports Negative Answers with NSEC3 Records
454
455 Purpose: This tests whether a resolver properly returns NSEC3 records
456 ([RFC5155]) for a nonexisting domain in a DNSSEC-signed zone.
457
458 Prerequisite: Supports the DO bit.
459
460 Test: Send a request to the resolver under test for an A record that
461 is known to be nonexistent in a zone signed using NSEC3, such as
462 nonexistent.nsec3-ns.test.example.com. Set the DO bit in the
463 outgoing query.
464
465 SUCCESS: A DNS response was received that contains an NSEC3 record.
466
467 Bonus: If the AD bit is set, this validator supports algorithm 7
468 (RSASHA1-NSEC3-SHA1).
469
470 Note: The query issued in this test MUST be sent to an NSEC3-signed
471 zone. Getting back appropriate NSEC records does not indicate a
472 failure, but a bad test.
473
474 3.1.11. Supports Queries Where DNAME Records Lead to an Answer
475
476 Purpose: This tests whether a resolver can query for an A record in a
477 zone with a known DNAME referral for the record's parent.
478
479 Test: Send a request to the resolver under test for an A record that
480 is known to exist in a signed zone within a DNAME-referral child
481 zone, such as good-a.dname-good-ns.test.example.com.
482
483 SUCCESS: A DNS response was received that contains a DNAME in the
484 answer section. An RRSIG MUST also be received in the answer section
485 that covers the DNAME record.
486
487
488
489
490
491
492 Hardaker, et al. Best Current Practice [Page 9]
493 RFC 8027 DNSSEC Roadblock Avoidance November 2016
494
495
496 3.1.12. Permissive DNSSEC
497
498 Purpose: To see if a validating resolver is ignoring DNSSEC
499 validation failures.
500
501 Prerequisite: Supports the AD bit.
502
503 Test: Ask for data from a broken DNSSEC delegation, such as badsign-
504 a.test.example.com.
505
506 SUCCESS: A reply was received with the Rcode set to SERVFAIL.
507
The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.
This RFC is included in the DNS RFCs annotation project whose home page is here.
508 3.1.13. Supports Unknown RRtypes
509
510 Purpose: Some DNS Resolvers/gateways only support some Resource
511 Record Types (RRtypes). This causes problems for applications that
512 need recently defined types.
513
514 Prerequisite: Supports UDP or TCP.
515
516 Test: Send a request for a recently defined type or an unknown type
517 in the 20000-22000 range, that resolves to a server that will return
518 an answer for all types, such as alltypes.example.com (a server today
519 that supports this is alltypes.res.dnssecready.org).
520
521 SUCCESS: A DNS response was retrieved that contains the type
522 requested in the answer section.
523
524 3.2. Direct Network Queries
525
526 If needed, a Host Validator may need to make direct queries to
527 authoritative servers or known Open Recursive Resolvers in order to
528 collect data. To do that, a number of key network features MUST be
529 functional.
530
531 3.2.1. Support for Remote UDP over Port 53
532
533 Purpose: This tests basic UDP functionality to outside the local
534 network.
535
536 Test: A DNS request is sent to a known distant authoritative server
537 for a record known to be within that server's authoritative data.
538 Example: send a query to the address of ns1.test.example.com for the
539 good-a.test.example.com/A record.
540
541 SUCCESS: A DNS response was received that contains an A record in the
542 answer section.
543
544
545
546
547 Hardaker, et al. Best Current Practice [Page 10]
548 RFC 8027 DNSSEC Roadblock Avoidance November 2016
549
550
551 Note: An implementation can use the local resolvers for determining
552 the address of the name server that is authoritative for the given
553 zone. The recursive bit MAY be set for this request, but it does not
554 need to be.
555
556 3.2.2. Support for Remote UDP with Fragmentation
557
558 Purpose: This tests if the local network can receive fragmented UDP
559 answers.
560
561 Prerequisite: Local UDP traffic > 1500 bytes in size is possible.
562
563 Test: A DNS request is sent over UDP to a known distant DNS address
564 asking for a record that has an answer larger than 2000 bytes. For
565 example, send a query for the test.example.com/DNSKEY record with the
566 DO bit set in the outgoing query.
567
568 SUCCESS: A DNS response was received that contains the large answer.
569
570 Note: A failure in getting large answers over UDP is not a serious
571 problem if TCP is working.
572
573 3.2.3. Support for Outbound TCP over Port 53
574
575 Purpose: This tests basic TCP functionality to outside the local
576 network.
577
578 Test: A DNS request is sent over TCP to a known distant authoritative
579 server for a record known to be within that server's authoritative
580 data. Example: send a query to the address of ns1.test.example.com
581 for the good-a.test.example.com/A record.
582
583 SUCCESS: A DNS response was received that contains an A record in the
584 answer section.
585
586 Note: An implementation can use the local resolvers for determining
587 the address of the name server that is authoritative for the given
588 zone. The recursive bit MAY be set for this request, but it does not
589 need to be.
590
591 3.3. Support for DNSKEY and DS Combinations
592
593 Purpose: This test can check what algorithm combinations are
594 supported.
595
596 Prerequisite: Supports the AD bit for Algorithms 5 and/or 8.
597
598
599
600
601
602 Hardaker, et al. Best Current Practice [Page 11]
603 RFC 8027 DNSSEC Roadblock Avoidance November 2016
604
605
606 Test: A DNS request is sent over UDP to the resolver under test for a
607 known combination of the DS algorithm number (N) and DNSKEY algorithm
608 number (M) of the example form ds-N.alg-M-nsec.test.example.com.
609 Examples:
610
611 ds-2.alg-13-nsec.test.example.com TXT
612 or
613 ds-4.alg-13-nsec3.test.example.com TXT
614
615 SUCCESS: A DNS response is received with the AD bit set and with a
616 matching record type in the answer section.
617
618 Note: For algorithms 6 and 7, NSEC is not defined; thus, a query for
619 alg-M-nsec3 is required. Similarly, NSEC3 is not defined for
620 algorithms 1, 3, and 5. Furthermore, algorithms 2, 4, 9, and 11 do
621 not currently have definitions for signed zones.
622
623 4. Aggregating the Results
624
625 Some conclusions can be drawn from the results of the above tests in
626 an "aggregated" form. This section defines some labels to assign to
627 a resolver under test given the results of the tests run against
628 them.
629
630 4.1. Resolver Capability Description
631
632 This section will group and label certain common results.
633
634 Resolvers are classified into the following broad behaviors:
635
636 Validator: The resolver passes all DNSSEC tests and had the AD bit
637 appropriately set.
638
639 DNSSEC-Aware: The resolver passes all DNSSEC tests, but it does not
640 appropriately set the AD bit on answers, indicating it is not
641 validating. A Host Validator will function fine using this
642 resolver as a forwarder.
643
644 Non-DNSSEC-Capable: The resolver is not DNSSEC-aware and will make
645 it hard for a Host Validator to operate behind it. It MAY be
646 usable to query for data that is in known insecure sections of the
647 DNS tree.
648
649 Not a DNS Resolver: This is an improperly behaving resolver and
650 should not be used at all.
651
652
653
654
655
656
657 Hardaker, et al. Best Current Practice [Page 12]
658 RFC 8027 DNSSEC Roadblock Avoidance November 2016
659
660
661 While it would be great if all resolvers fell cleanly into one of the
662 broad categories above, that is not the case. For that reason, it is
663 necessary to augment the classification with a more descriptive
664 result. This is done by adding the word "Partial" in front of
665 Validator/DNSSEC-aware classifications, followed by sub-descriptors
666 of what is not working.
667
668 Unknown: Failed the unknown test
669
670 DNAME: Failed the DNAME test
671
672 NSEC3: Failed the NSEC3 test
673
674 TCP: TCP not available
675
676 SlowBig: UDP is size limited, but TCP fallback works
677
678 NoBig: TCP not available and UDP is size limited
679
680 Permissive: Passes data known to fail validation
681
682 5. Roadblock Avoidance
683
684 The goal of this document is to tie the above tests and aggregations
685 to avoidance practices; however, the document does not specify
686 exactly how to do that.
687
688 Once we have determined what level of support is available in the
689 network, we can determine what must be done in order to effectively
690 act as a validating resolver. This section discusses some of the
691 options available given the results from the previous sections.
692
693 The general fallback approach can be described by the following
694 sequence:
695
696 If the resolver is labeled as "Validator" or "DNSSEC-aware":
697
698 Send queries through this resolver and perform local
699 validation on the results.
700
701 If validation fails, try the next resolver.
702
703 Else, if the resolver is labeled "Not a DNS Resolver" or
704 "Non-DNSSEC-capable":
705
706 Mark it as unusable and try the next resolver.
707
708
709
710
711
712 Hardaker, et al. Best Current Practice [Page 13]
713 RFC 8027 DNSSEC Roadblock Avoidance November 2016
714
715
716 Else if no more resolvers are configured and if direct queries
717 are supported:
718
719 1. Try iterating from the Root.
720
721 2. If the answer is SECURE/BOGUS:
722 Return the result of the iteration.
723
724 3. If the answer is INSECURE:
725 Re-query "Non-DNSSEC-capable" servers and return
726 answers from them without the AD bit set to the client.
727
728 This will increase the likelihood that split-view unsigned
729 answers are found.
730
731 Else:
732
733 Return an error code and log a failure.
734
735
736 While attempting resolution through a particular recursive name
737 server with a particular transport method that worked, any transport-
738 specific parameters MUST be remembered in order to avoid any
739 unnecessary fallback attempts.
740
741 Transport-specific parameters MUST also be remembered for each
742 authoritative name server that is queried while performing an
743 iterative mode lookup.
744
745 Any transport settings that are remembered for a particular name
746 server MUST be periodically refreshed; they should also be refreshed
747 when an error is encountered as described below.
748
749 For a stub resolver, problems with the name server can manifest
750 themselves under the following types of error conditions:
751
752 o No Response, error response, or missing DNSSEC metadata
753
754 o Illegal Response: An illegal response is received, which prevents
755 the validator from fetching all the necessary records required for
756 constructing an authentication chain. This could result when
757 referral loops are encountered, when any of the antecedent zone
758 delegations are lame, when aliases are erroneously followed for
759 certain RRtypes (such as Start of Authority (SOA), DNSKEYs, or DS
760 records), or when resource records for certain types (e.g., DS)
761 are returned from a zone that is not authoritative for such
762 records.
763
764
765
766
767 Hardaker, et al. Best Current Practice [Page 14]
768 RFC 8027 DNSSEC Roadblock Avoidance November 2016
769
770
771 o Bogus Response: A Bogus Response is received, when the
772 cryptographic assertions in the authentication chain do not
773 validate properly.
774
775 For each of the above error conditions, a validator MAY adopt the
776 following dynamic fallback technique, preferring a particular
777 approach if it is known to work for a given name server or zone from
778 previous attempts.
779
780 o No response, error response, or missing DNSSEC metadata:
781
782 * Retry with different EDNS0 sizes (4096, 1492, or None).
783
784 * Retry with TCP only.
785
786 * Perform an iterative query starting from the Root if the
787 previous error was returned from a lookup that had recursion
788 enabled.
789
790 * Retry using an alternative transport method, if this
791 alternative method is known (configured) to be supported by the
792 name server in question.
793
794 o Illegal Response
795
796 * Perform an iterative query starting from the Root if the
797 previous error was returned from a lookup that had recursion
798 enabled.
799
800 * Check if any of the antecedent zones up to the closest
801 configured trust anchor are Insecure.
802
803 o Bogus Response
804
805 * Perform an iterative query starting from the Root if the
806 previous error was returned from a lookup that had recursion
807 enabled.
808
809 For each fallback technique, attempts to reach multiple potential
810 name servers should be skewed such that the next name server is tried
811 when the previous one returns an error or a timeout is reached.
812
813 The validator SHOULD remember, in its zone-specific fallback cache,
814 any broken behavior identified for a particular zone for a duration
815 of that zone's SOA-negative TTL.
816
817
818
819
820
821
822 Hardaker, et al. Best Current Practice [Page 15]
823 RFC 8027 DNSSEC Roadblock Avoidance November 2016
824
825
826 The validator MAY place name servers that exhibit broken behavior
827 into a blacklist and bypass these name servers for all zones that
828 they are authoritative for. The validator MUST time out entries in
829 this name server blacklist periodically, where this interval could be
830 set to be the same as the DNSSEC BAD cache default TTL.
831
832 5.1. Partial Resolver Usage
833
834 It may be possible to use Non-DNSSEC-Capable caching resolvers in
835 careful ways if maximum optimization is desired. This section
836 describes some of the advanced techniques that could be implemented
837 to use a resolver in at least a minimal way. Most of the time, this
838 would be unnecessary; the exception being the case where none of the
839 resolvers are fully compliant and, thus, the choice would be to use
840 them at least minimally or not at all (and no caching benefits would
841 be available).
842
843 5.1.1. Known Insecure Lookups
844
845 If a resolver is Non-DNSSEC-Capable but a section of the DNS tree has
846 been determined to be Insecure [RFC4035], then queries to this
847 section of the tree MAY be sent through the Non-DNSSEC-Capable
848 caching resolver.
849
850 5.1.2. Partial NSEC/NSEC3 Support
851
852 Resolvers that understand DNSSEC generally, and understand NSEC but
853 not NSEC3, are partially usable. These resolvers generally also lack
854 support for unknown types, rendering them mostly useless and to be
855 avoided.
856
857 6. Start-Up and Network Connectivity Issues
858
859 A number of scenarios will produce either short-term or long-term
860 connectivity issues with respect to DNSSEC validation. Consider the
861 following cases:
862
863 Time Synchronization: Time synchronization problems can occur when
864 a device has been off for a period of time and the clock is no
865 longer in close synchronization with "real time" or when a device
866 always has the clock set to the same time during start-up. This
867 will cause problems when the device needs to resolve its source of
868 time synchronization, such as "ntp.example.com".
869
870 Changing Network Properties: A newly established network
871 connection may change state shortly after an HTTP-based paywall
872 authentication system has been used. This is especially common in
873 hotel, airport, and coffee-shop networks where DNSSEC, validation,
874
875
876
877 Hardaker, et al. Best Current Practice [Page 16]
878 RFC 8027 DNSSEC Roadblock Avoidance November 2016
879
880
881 and even DNS are not functional until the user proceeds through a
882 series of forced web pages used to enable their network. The
883 tests in Section 3 will produce very different results before and
884 after the network authorization has succeeded. APIs exist on many
885 operating systems to detect initial network device status changes,
886 such as right after DHCP has finished, but few (none?) exist to
887 detect that authentication through a paywall has succeeded.
888
889 There are only two choices when situations like this happen:
890
891 Continue to perform DNSSEC processing, which will likely result in
892 all DNS requests failing. This is the most secure route, but
893 causes the most operational grief for users.
894
895 Turn off DNSSEC support until the network proves to be usable.
896 This allows the user to continue using the network, at the cost of
897 security. It also allows for a denial-of-service attack if a man-
898 in-the-middle can convince a device that DNSSEC is impossible.
899
900 6.1. What to Do
901
902 If the Host Validator detects that DNSSEC resolution is not possible,
903 it SHOULD log the event and/or SHOULD report an error to the user.
904 In the case where there is no user, no reporting can be performed;
905 thus, the device MAY have a policy of action, like continue or fail.
906 Until middleboxes allow DNSSEC-protected information to traverse them
907 consistently, software implementations may need to offer this choice
908 to let users pick the security level they require. Note that
909 continuing without DNSSEC protection in the absence of a notification
910 or report could lead to situations where users assume a level of
911 security that does not exist.
912
913 7. Quick Test
914
915 The quick tests defined below make the assumption that the questions
916 to be asked are of a real resolver; and the only real question is:
917 "How complete is the DNSSEC support?". This quick test has been
918 implemented in a few programs developed at IETF hackathons at IETF 93
919 and IETF 94. The programs use a common grading method. For each
920 question that returns an expected answer, the resolver gets a point.
921 If the AD bit is set as expected, the resolver gets a second point.
922
923 7.1. Test Negative Answers Algorithm 5
924
925 Query: realy-doesnotexist.test.example.com. A
926
927 Answer: RCODE= NXDOMAIN, Empty Answer, Authority: NSEC-proof
928
929
930
931
932 Hardaker, et al. Best Current Practice [Page 17]
933 RFC 8027 DNSSEC Roadblock Avoidance November 2016
934
935
936 7.2. Test Algorithm 8
937
938 Query: alg-8-nsec3.test.example.com. SOA
939
940 Answer: RCODE= 0, Answer: SOA record
941
942 7.3. Test Algorithm 13
943
944 Query: alg-13-nsec.test.example.com. SOA
945
946 Answer: RCODE= 0, Answer: SOA record
947
948 7.4. Fails When DNSSEC Does Not Validate
949
950 Query: dnssec-failed.test.example.com. SOA
951
952 Answer: RCODE= SERVFAIL, empty answer, and authority, AD=0
953
954 8. Security Considerations
955
956 This document discusses problems that may occur while deploying the
957 DNSSEC protocol. It describes what may be possible to help detect
958 and mitigate these problems. Following the outlined suggestions will
959 result in a more secure DNSSEC-operational environment than if DNSSEC
960 was simply disabled.
961
962 9. Normative References
963
964 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
965 Requirement Levels", BCP 14, RFC 2119,
966 DOI 10.17487/RFC2119, March 1997,
967 <http://www.rfc-editor.org/info/rfc2119>.
968
969 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
970 Rose, "Resource Records for the DNS Security Extensions",
971 RFC 4034, DOI 10.17487/RFC4034, March 2005,
972 <http://www.rfc-editor.org/info/rfc4034>.
973
974 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
975 Rose, "Protocol Modifications for the DNS Security
976 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
977 <http://www.rfc-editor.org/info/rfc4035>.
978
979 [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast
980 Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786,
981 December 2006, <http://www.rfc-editor.org/info/rfc4786>.
982
983
984
985
986
987 Hardaker, et al. Best Current Practice [Page 18]
988 RFC 8027 DNSSEC Roadblock Avoidance November 2016
989
990
991 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
992 Security (DNSSEC) Hashed Authenticated Denial of
993 Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008,
994 <http://www.rfc-editor.org/info/rfc5155>.
995
996 [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines",
997 BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009,
998 <http://www.rfc-editor.org/info/rfc5625>.
999
1000 Acknowledgments
1001
1002 We thank the IESG and DNSOP working group members for their extensive
1003 comments and suggestions.
1004
1005 Authors' Addresses
1006
1007 Wes Hardaker
1008 USC/ISI
1009 P.O. Box 382
1010 Davis, CA 95617
1011 United States of America
1012
1013 Email: ietf@hardakers.net
1014
1015
1016 Olafur Gudmundsson
1017 CloudFlare
1018 San Francisco, CA 94107
1019 United States of America
1020
1021 Email: olafur+ietf@cloudflare.com
1022
1023
1024 Suresh Krishnaswamy
1025 Parsons
1026 7110 Samuel Morse Dr
1027 Columbia, MD 21046
1028 United States of America
1029
1030 Email: suresh@tislabs.com
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042 Hardaker, et al. Best Current Practice [Page 19]
1043
(a server today that supports this is alltypes.res.dnssecready.org).
[No text]
The domain name was deleted in 2015... Relying on it was noted in https://www.mail-archive.com/dnsop@ietf.org/msg12129.html If someone wants to reactivate the service, I just reserved the domain. I wlll of course redirect/transfer/whatever it gratis.