idnits 2.17.1 draft-ietf-dnsop-dns-tcp-requirements-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 20, 2017) is 2501 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 2541 (Obsoleted by RFC 4641) -- Obsolete informational reference (is this intentional?): RFC 2671 (Obsoleted by RFC 6891) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Domain Name System Operations J. Kristoff 3 Internet-Draft DePaul University 4 Intended status: Best Current Practice D. Wessels 5 Expires: December 22, 2017 Verisign 6 June 20, 2017 8 DNS Transport over TCP - Operational Requirements 9 draft-ietf-dnsop-dns-tcp-requirements-00 11 Abstract 13 This document encourages the practice of permitting DNS messages to 14 be carried over TCP on the Internet. It also describes some of the 15 consequences of this behavior and the potential operational issues 16 that can arise when this best common practice is not upheld. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on December 22, 2017. 35 Copyright Notice 37 Copyright (c) 2017 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 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. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 54 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.1. Uneven Transport Usage and Preference . . . . . . . . . . 3 56 2.2. Waiting for Large Messages and Reliability . . . . . . . 3 57 2.3. EDNS0 . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.4. "Only Zone Tranfers Use TCP" . . . . . . . . . . . . . . 5 59 3. DNS over TCP Requirements . . . . . . . . . . . . . . . . . . 5 60 4. Network and System Considerations . . . . . . . . . . . . . . 6 61 5. DNS over TCP Filtering Risks . . . . . . . . . . . . . . . . 6 62 5.1. DNS Wedgie . . . . . . . . . . . . . . . . . . . . . . . 6 63 5.2. DNS Root Zone KSK Rollover . . . . . . . . . . . . . . . 6 64 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 66 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 67 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 69 9.2. Informative References . . . . . . . . . . . . . . . . . 8 70 Appendix A. Standards Related to DNS Transport over TCP . . . . 10 71 A.1. TODO - additional, relevant RFCs . . . . . . . . . . . . 10 72 A.2. IETF RFC 7477 - Child-to-Parent Synchronization in DNS . 11 73 A.3. IETF RFC 7766 - DNS Transport over TCP - Implementation 74 Requirements . . . . . . . . . . . . . . . . . . . . . . 11 75 A.4. IETF RFC 7828 - The edns-tcp-keepalive EDNS0 Option . . . 11 76 A.5. IETF RFC 7873 - Domain Name System (DNS) Cookies . . . . 11 77 A.6. IETF RFC 7901 - CHAIN Query Requests in DNS . . . . . . . 11 78 A.7. IETF RFC 8027 - DNSSEC Roadblock Avoidance . . . . . . . 12 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 81 1. Introduction 83 DNS messages may be delivered using UDP or TCP communications. While 84 most DNS transactions are carried over UDP, some operators have been 85 led to believe that any DNS over TCP traffic is unwanted or 86 unnecessary for general DNS operation. As usage and features have 87 evolved, TCP transport has become increasingly important for correct 88 and safe operation of the Internet DNS. Reflecting modern usage, the 89 DNS standards were recently updated to declare support for TCP is now 90 a required part of the DNS implementation specifications in 91 [RFC7766]. This document is the formal requirements equivalent for 92 the operational community, encouraging operators to ensure DNS over 93 TCP communications support is on par with DNS over UDP 94 communications. 96 1.1. Requirements Language 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in RFC 2119 [RFC2119]. 102 2. Background 104 2.1. Uneven Transport Usage and Preference 106 In the original suite of DNS specifications, [RFC1034] and [RFC1035] 107 clearly specified that DNS messages could be carried in either UDP or 108 TCP, but they also made clear a preference for UDP as the transport 109 for queries in the general case. As stated in [RFC1035]: 111 "While virtual circuits can be used for any DNS activity, 112 datagrams are preferred for queries due to their lower overhead 113 and better performance." 115 Another early, important, and influential document, [RFC1123], 116 detailed the preference for UDP more explicitly: 118 "DNS resolvers and recursive servers MUST support UDP, and SHOULD 119 support TCP, for sending (non-zone-transfer) queries." 121 and further stipulated: 123 A name server MAY limit the resources it devotes to TCP queries, 124 but it SHOULD NOT refuse to service a TCP query just because it 125 would have succeeded with UDP. 127 Culminating in [RFC1536], DNS over TCP came to be associated 128 primarily with the zone transfer mechanism, while most DNS queries 129 and responses were seen as the dominion of UDP. 131 2.2. Waiting for Large Messages and Reliability 133 As stipulated in the original specifications, DNS messages over UDP 134 were restricted to a 512-byte message size. However, even while 135 [RFC1123] made a clear preference for UDP, it foresaw DNS over TCP 136 becoming more popular in the future: 138 "[...] it is also clear that some new DNS record types defined in 139 the future will contain information exceeding the 512 byte limit 140 that applies to UDP, and hence will require TCP. 142 At least two new, widely anticipated developments were set to elevate 143 the need for DNS over TCP transactions. The first was dynamic 144 updates defined in [RFC2136] and the second was the set of extensions 145 collectively known as DNSSEC originally specified in [RFC2541]. The 146 former suggested "requestors who require an accurate response code 147 must use TCP", while the later warned "[...] larger keys increase the 148 size of KEY and SIG RRs. This increases the chance of DNS UDP packet 149 overflow and the possible necessity for using higher overhead TCP in 150 responses." 152 Yet defying some expectations, DNS over TCP remained little used in 153 real traffic across the Internet. Dynamic updates saw little 154 deployment between autonomous networks. Around the time DNSSEC was 155 first defined, another new feature affecting DNS over UDP helped 156 solidify its dominance for message transactions. 158 2.3. EDNS0 160 In 1999 the IETF published the Extension Mechanisms for DNS (EDNS0) 161 in [RFC2671]. This document standardized a way for communicating DNS 162 nodes to perform rudimentary capabilities negotiation. One such 163 capability written into the base specification and present in every 164 ENDS0 compatible message is the value of the maximum UDP payload size 165 the sender can support. This unsigned 16-bit field specifies in 166 bytes the maximum DNS MTU. In practice, typical values are a subset 167 of the 512 to 4096 byte range. EDNS0 was rapidly and widely deployed 168 over the next several years and numerous surveys have shown many 169 systems currently support larger UDP MTUs [CASTRO2010], [NETALYZR] 170 with EDNS0. 172 The natural effect of EDNS0 deployment meant large DNS messages would 173 be less reliant on TCP than they might otherwise have been. While a 174 nonneglible population of DNS systems lack EDNS0 or may still fall 175 back to TCP for some transactions, DNS over TCP transactions remain a 176 very small fraction of overall DNS traffic [VERISIGN]. Nevertheless, 177 some average increase in DNS message size, the continued development 178 of new DNS features and a denial of service mitigation technique (see 179 Section 8) have suggested that DNS over TCP transactions are as 180 important to the correct and safe operation of the Internet DNS as 181 ever, if not more so. Furthermore, there has been serious research 182 that has suggested connection-oriented DNS transactions may provide 183 security and privacy advantages over UDP transport [TDNS]. In fact, 184 [RFC7858], a Standards Track document is just this sort of 185 specification. Therefore, it might be desirable for network 186 operators to avoid artificially inhibiting the potential utility and 187 advances in the DNS such as these. 189 2.4. "Only Zone Tranfers Use TCP" 191 There are many in the DNS community who configure DNS over TCP 192 services and expect DNS over TCP transactions to occur without 193 interference. However there has also been a long held belief by some 194 operators, particularly for security-related reasons, that DNS over 195 TCP services should be purposely limited or not provided at all 196 [CHES94], [DJBDNS]. A popular meme has also held the imagination of 197 some that DNS over TCP is only ever used for zone transfers and is 198 generally unnecessary otherwise, with filtering all DNS over TCP 199 traffic even described as a best practice. 201 The position on restricting DNS over TCP had some justification given 202 that historic implementations of DNS nameservers provided very little 203 in the way of TCP connection management (for example see 204 Section 6.1.2 of [RFC7766] for more details). However modern 205 standards and implementations are moving to align with the more 206 sophisticated TCP management techniques employed by, for example, 207 HTTP(S) servers and load balancers. 209 3. DNS over TCP Requirements 211 Section 6.1.3.2 in [RFC1123] is updated: All general-purpose DNS 212 servers MUST be able to service both UDP and TCP queries. 214 o Authoritative servers MUST service TCP queries so that they do not 215 limit the size of responses to what fits in a single UDP packet. 217 o Recursive servers (or forwarders) MUST service TCP queries so that 218 they do not prevent large responses from a TCP-capable server from 219 reaching its TCP-capable clients. 221 Regarding the choice of limiting the resources a server devotes to 222 queries, Section 6.1.3.2 in [RFC1123] also says: 224 A name server MAY limit the resources it devotes to TCP queries, 225 but it SHOULD NOT refuse to service a TCP query just because it 226 would have succeeded with UDP. 228 This requirement is hereby updated: A name server MAY limit the the 229 resources it devotes to queries, but it MUST NOT refuse to service a 230 query just because it would have succeeded with another transport 231 protocol. 233 DNS over TCP filtering is considered harmful in the general case. 234 DNS resolver and server operators MUST provide DNS service over both 235 UDP and TCP transports. Likewise, network operators MUST allow DNS 236 service over both UDP and TCP transports. It must be acknowledged 237 that DNS over TCP service can pose operational challenges that are 238 not present when running DNS over UDP alone. However, it is the aim 239 of this document to argue that the potential damage incurred by 240 prohibiting DNS over TCP service is more detrimental to the continued 241 utility and success of the DNS than when its usage is allowed. 243 4. Network and System Considerations 245 TODO: refer to IETF RFC 7766 connection handling discussion, various 246 TCP hardening documents, network operator protocol and traffic best 247 practices, etc. 249 5. DNS over TCP Filtering Risks 251 Networks that filter DNS over TCP risk losing access to significant 252 or important pieces of the DNS name space. For a variety of reasons 253 a DNS answer may require a DNS over TCP query. This may include 254 large message sizes, lack of EDNS0 support, DDoS mitigation 255 techniques, or perhaps some future capability that is as yet 256 unforeseen will also demand TCP transport. 258 Even if any or all particular answers have consistently been returned 259 successfully with UDP in the past, this continued behavior cannot be 260 guaranteed when DNS messages are exchanged between autonomous 261 systems. Therefore, filtering of DNS over TCP is considered harmful 262 and contrary to the safe and successful operation of the Internet. 263 This section enumerates some of the known risks we know about at the 264 time of this writing when networks filter DNS over TCP. 266 5.1. DNS Wedgie 268 Networks that filter DNS over TCP may inadvertently cause problems 269 for third party resolvers as experienced by [TOYAMA]. If for 270 instance a resolver receives a truncated answer from a server, but if 271 when the resolver resends the query using TCP and the TCP response 272 never arrives, not only will full answer be unavailable, but the 273 resolver will incur the full extent of TCP retransmissions and time 274 outs. This situation might place extreme strain on resolver 275 resources. If the nunber and frequency of these truncated answers 276 are sufficiently high, we refer to the steady-state of lost resources 277 as a result a "DNS" wedgie". A DNS wedgie is often not easily or 278 completely mitigated by the affected DNS resolver operator. 280 5.2. DNS Root Zone KSK Rollover 282 Recent plans for a new root zone DNSSEC KSK have highlighted a 283 potential problem in retrieving the keys.[LEWIS] Some packets in the 284 KSK rollover process will be larger than 1280 bytes, the IPv6 minimum 285 MTU for links carrying IPv6 traffic.[RFC2460] While studies have 286 shown that problems due to fragment filtering or an inability to 287 generate and receive these larger messages are negible, any DNS 288 server that is unable to receive large DNS over UDP messages or 289 perform DNS over TCP may experience severe disruption of DNS service 290 if performing DNSSEC validation. 292 6. Acknowledgements 294 This document was initially motivated by feedback from students who 295 pointed out that they were hearing contradictory information about 296 filtering DNS over TCP messages. Thanks in particular to a teaching 297 colleague, JPL, who perhaps unknowingly encouraged the initial 298 research into the differences of what the community has historically 299 said and did. Thanks to all the NANOG 63 attendees who provided 300 feedback to an early talk on this subject. 302 The following individuals provided an array of feedback to help 303 improve this document: Sara Dickinson, Bob Harold, Tatuya Jinmei, and 304 Paul Hoffman. The authors are indebted to their contributions. Any 305 remaining errors or imperfections are the sole responsbility of the 306 document authors. 308 7. IANA Considerations 310 This memo includes no request to IANA. 312 8. Security Considerations 314 Ironically, returning truncated DNS over UDP answers in order to 315 induce a client query to switch to DNS over TCP has become a common 316 response to source address spoofed, DNS denial-of-service attacks 317 [RRL]. Historically, operators have been wary of TCP-based attacks, 318 but in recent years, UDP-based flooding attacks have proven to be the 319 most common protocol attack on the DNS. Nevertheless, a high rate of 320 short-lived DNS transactions over TCP may pose challenges. While 321 many operators have provided DNS over TCP service for many years 322 without duress, past experience is no guarantee of future success. 324 DNS over TCP is not unlike many other Internet TCP services. TCP 325 threats and many mitigation strategies have been well documented in a 326 series of documents such as [RFC4953], [RFC4987], [RFC5927], and 327 [RFC5961]. 329 9. References 331 9.1. Normative References 333 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 334 Requirement Levels", BCP 14, RFC 2119, 335 DOI 10.17487/RFC2119, March 1997, 336 . 338 9.2. Informative References 340 [CASTRO2010] 341 Castro, S., Zhang, M., John, W., Wessels, D., and k. 342 claffy, "Understanding and preparing for DNS evolution", 343 2010. 345 [CHES94] Cheswick, W. and S. Bellovin, "Firewalls and Internet 346 Security: Repelling the Wily Hacker", 1994. 348 [DJBDNS] D.J. Bernstein, "When are TCP queries sent?", 2002, 349 . 351 [LEWIS] Lewis, E., "2017 DNSSEC KSK Rollover", RIPE 74 Budapest, 352 Hungary, May 2017. 354 [NETALYZR] 355 Kreibich, C., Weaver, N., Nechaev, B., and V. Paxson, 356 "Netalyzr: Illuminating The Edge Network", 2010. 358 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 359 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 360 . 362 [RFC1035] Mockapetris, P., "Domain names - implementation and 363 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 364 November 1987, . 366 [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - 367 Application and Support", STD 3, RFC 1123, 368 DOI 10.17487/RFC1123, October 1989, 369 . 371 [RFC1536] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S. 372 Miller, "Common DNS Implementation Errors and Suggested 373 Fixes", RFC 1536, DOI 10.17487/RFC1536, October 1993, 374 . 376 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 377 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 378 RFC 2136, DOI 10.17487/RFC2136, April 1997, 379 . 381 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 382 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 383 December 1998, . 385 [RFC2541] Eastlake 3rd, D., "DNS Security Operational 386 Considerations", RFC 2541, DOI 10.17487/RFC2541, March 387 1999, . 389 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 390 RFC 2671, DOI 10.17487/RFC2671, August 1999, 391 . 393 [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", 394 RFC 4953, DOI 10.17487/RFC4953, July 2007, 395 . 397 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 398 Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, 399 . 401 [RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, 402 DOI 10.17487/RFC5927, July 2010, 403 . 405 [RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's 406 Robustness to Blind In-Window Attacks", RFC 5961, 407 DOI 10.17487/RFC5961, August 2010, 408 . 410 [RFC7477] Hardaker, W., "Child-to-Parent Synchronization in DNS", 411 RFC 7477, DOI 10.17487/RFC7477, March 2015, 412 . 414 [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and 415 D. Wessels, "DNS Transport over TCP - Implementation 416 Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, 417 . 419 [RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The 420 edns-tcp-keepalive EDNS0 Option", RFC 7828, 421 DOI 10.17487/RFC7828, April 2016, 422 . 424 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 425 and P. Hoffman, "Specification for DNS over Transport 426 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 427 2016, . 429 [RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS) 430 Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016, 431 . 433 [RFC7901] Wouters, P., "CHAIN Query Requests in DNS", RFC 7901, 434 DOI 10.17487/RFC7901, June 2016, 435 . 437 [RFC8027] Hardaker, W., Gudmundsson, O., and S. Krishnaswamy, 438 "DNSSEC Roadblock Avoidance", BCP 207, RFC 8027, 439 DOI 10.17487/RFC8027, November 2016, 440 . 442 [RRL] Vixie, P. and V. Schryver, "DNS Response Rate Limiting 443 (DNS RRL)", ISC-TN 2012-1 Draft1, April 2012. 445 [TDNS] Zhu, L., Heidemann, J., Wessels, D., Mankin, A., and N. 446 Somaiya, "Connection-oriented DNS to Improve Privacy and 447 Security", 2015. 449 [TOYAMA] Toyama, K., Ishibashi, K., Ishino, M., Yoshimura, C., and 450 K. Fujiwara, "DNS Anomalies and Their Impacts on DNS Cache 451 Servers", NANOG 32 Reston, VA USA, 2004. 453 [VERISIGN] 454 Thomas, M. and D. Wessels, "An Analysis of TCP Traffic in 455 Root Server DITL Data", DNS-OARC 2014 Fall Workshop Los 456 Angeles, 2014. 458 Appendix A. Standards Related to DNS Transport over TCP 460 This section enumerates all known IETF RFC documents that are 461 currently of status standard, informational, best common practice or 462 experimental and either implicitly or explicitly make assumptions or 463 statements about the use of TCP as a transport for the DNS germane to 464 this document. 466 A.1. TODO - additional, relevant RFCs 467 A.2. IETF RFC 7477 - Child-to-Parent Synchronization in DNS 469 This standards track document [RFC7477] specifies a RRType and 470 protocol to signal and synchronize NS, A, and AAAA resource record 471 changes from a child to parent zone. Since this protocol may require 472 multiple requests and responses, it recommends utilizing DNS over TCP 473 to ensure the conversation takes place between a consistent pair of 474 end nodes. 476 A.3. IETF RFC 7766 - DNS Transport over TCP - Implementation 477 Requirements 479 The standards track document [RFC7766] might be considered the direct 480 ancestor of this operational requirements document. The 481 implementation requirements document codifies mandatory support for 482 DNS over TCP in compliant DNS software. 484 A.4. IETF RFC 7828 - The edns-tcp-keepalive EDNS0 Option 486 This standards track document [RFC7828] defines an EDNS0 option to 487 negotiate an idle timeout value for long-lived DNS over TCP 488 connections. Consequently, this document is only applicable and 489 relevant to DNS over TCP sessions and between implementations that 490 support this option. 492 A.5. IETF RFC 7873 - Domain Name System (DNS) Cookies 494 This standards track document [RFC7873] describes an EDNS0 option to 495 provide additional protection against query and answer forgery. This 496 specification mentions DNS over TCP as a reasonable fallback 497 mechanism when DNS Cookies are not available. The specification does 498 make mention of DNS over TCP processing in two specific situations. 499 In one, when a server receives only a client cookie in a request, the 500 server should consider whether the request arrived over TCP and if 501 so, it should consider accepting TCP as sufficient to authenticate 502 the request and respond accordingly. In another, when a client 503 receives a BADCOOKIE reply using a fresh server cookie, the client 504 should retry using TCP as the transport. 506 A.6. IETF RFC 7901 - CHAIN Query Requests in DNS 508 This experimental specification [RFC7901] describes an EDNS0 option 509 that can be used by a security-aware validating resolver to request 510 and obtain a complete DNSSEC validation path for any single query. 511 This document requires the use of DNS over TCP or a source IP address 512 verified transport mechanism such as EDNS-COOKIE.[RFC7873] 514 A.7. IETF RFC 8027 - DNSSEC Roadblock Avoidance 516 This document [RFC8027] details observed problems with DNSSEC 517 deployment and mitigation techniques. Network traffic blocking and 518 restrictions, including DNS over TCP messages, are highlighted as one 519 reason for DNSSEC deployment issues. While this document suggests 520 these sorts of problems are due to "non-compliant infrastructure" and 521 is of type BCP, the scope of the document is limited to detection and 522 mitigation techniques to avoid so-called DNSSEC roadblocks. 524 Authors' Addresses 526 John Kristoff 527 DePaul University 528 Chicago, IL 60604 529 US 531 Phone: +1 312 493 0305 532 Email: jtk@depaul.edu 533 URI: https://aharp.iorc.depaul.edu 535 Duane Wessels 536 Verisign 537 12061 Bluemont Way 538 Reston, VA 20190 539 US 541 Phone: +1 703 948 3200 542 Email: dwessels@verisign.com 543 URI: http://verisigninc.com