idnits 2.17.1 draft-trammell-inip-pins-04.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 (September 20, 2017) is 2400 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-dprive-dns-over-tls' is defined on line 583, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-dprive-dnsodtls' is defined on line 589, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Trammell 3 Internet-Draft ETH Zurich 4 Intended status: Informational September 20, 2017 5 Expires: March 24, 2018 7 Properties of an Ideal Naming Service 8 draft-trammell-inip-pins-04 10 Abstract 12 This document specifies a set of necessary functions and desirable 13 properties of an ideal system for resolving names to addresses and 14 associated information for establishing communication associations in 15 the Internet. For each property, it briefly explains the rationale 16 behind it, and how the property is or could be met with the present 17 Domain Name System. It is intended to start a discussion within the 18 IAB's Names and Identifiers program about gaps between the present 19 reality of DNS and the naming service the Internet needs by returning 20 to first principles. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on March 24, 2018. 39 Copyright Notice 41 Copyright (c) 2017 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Query Interface . . . . . . . . . . . . . . . . . . . . . . . 4 59 3.1. Name to Address . . . . . . . . . . . . . . . . . . . . . 4 60 3.2. Address to Name . . . . . . . . . . . . . . . . . . . . . 4 61 3.3. Name to Name . . . . . . . . . . . . . . . . . . . . . . 4 62 3.4. Name to Auxiliary Information . . . . . . . . . . . . . . 5 63 3.5. Name/Address to Auxiliary Information . . . . . . . . . . 5 64 4. Authority Interface . . . . . . . . . . . . . . . . . . . . . 5 65 5. Properties . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 5.1. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 5 67 5.1.1. Meaningfulness . . . . . . . . . . . . . . . . . . . 5 68 5.1.2. Distinguishability . . . . . . . . . . . . . . . . . 6 69 5.1.3. Minimal Structure . . . . . . . . . . . . . . . . . . 6 70 5.2. Authority . . . . . . . . . . . . . . . . . . . . . . . . 6 71 5.2.1. Federation of Authority . . . . . . . . . . . . . . . 6 72 5.2.2. Uniqueness of Authority . . . . . . . . . . . . . . . 6 73 5.2.3. Transparency of Authority . . . . . . . . . . . . . . 7 74 5.2.4. Revocability of Authority . . . . . . . . . . . . . . 7 75 5.2.5. Consensus on Root of Authority . . . . . . . . . . . 7 76 5.3. Authenticity . . . . . . . . . . . . . . . . . . . . . . 7 77 5.3.1. Authenticity of Delegation . . . . . . . . . . . . . 7 78 5.3.2. Authenticity of Response . . . . . . . . . . . . . . 8 79 5.3.3. Authenticity of Negative Response . . . . . . . . . . 8 80 5.4. Consistency . . . . . . . . . . . . . . . . . . . . . . . 8 81 5.4.1. Dynamic Consistency . . . . . . . . . . . . . . . . . 8 82 5.4.2. Explicit Inconsistency . . . . . . . . . . . . . . . 8 83 5.4.3. Global Invariance . . . . . . . . . . . . . . . . . . 9 84 5.5. Performance Properties . . . . . . . . . . . . . . . . . 9 85 5.5.1. Availability . . . . . . . . . . . . . . . . . . . . 9 86 5.5.2. Lookup Latency . . . . . . . . . . . . . . . . . . . 10 87 5.5.3. Bandwidth Efficiency . . . . . . . . . . . . . . . . 10 88 5.5.4. Query Linkability . . . . . . . . . . . . . . . . . . 10 89 5.5.5. Explicit Tradeoff . . . . . . . . . . . . . . . . . . 10 90 5.6. Trust in Infrastructure . . . . . . . . . . . . . . . . . 11 91 6. Observations . . . . . . . . . . . . . . . . . . . . . . . . 11 92 6.1. Delegation and redirection are separate operations . . . 11 93 6.2. Queries and assertion contexts are presently implicit . . 11 94 6.3. Unicode alone may not be sufficient for distinguishable 95 names . . . . . . . . . . . . . . . . . . . . . . . . . . 12 96 6.4. Implicit inconsistency makes global invariance 97 challenging to verify . . . . . . . . . . . . . . . . . . 12 98 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 99 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 100 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 101 10. Informative References . . . . . . . . . . . . . . . . . . . 13 102 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 104 1. Introduction 106 The Internet's Domain Name System (DNS) [RFC1035] is an excellent 107 illustration of the advantages of the decentralized architecture that 108 have made the Internet able to scale to its present size. However, 109 the choices made in the evolution of the DNS since its initial design 110 are only one path through the design space of Internet-scale naming 111 services. Many other naming services have been proposed, though none 112 has been remotely as successful for general- purpose use in the 113 Internet. 115 This document returns to first principles, to determine the 116 dimensions of the design space of desirable properties of an 117 Internet-scale naming service. It is a work in progress, intended to 118 start a discussion within the IAB's Names and Identifiers program 119 about gaps between the present reality of DNS and the naming service 120 the Internet needs. 122 Section 3 and Section 4 define the set of operations a naming service 123 should provide for queriers and authorities, Section 5 defines a set 124 of desirable properties of the provision of this service, and 125 Section 6 examines implications of these properties. 127 2. Terminology 129 The following capitalized terms are defined and used in this 130 document: 132 o Subject: A name, address, or name-address pair about which the 133 naming service can answer queries 135 o Association: A mapping between a Subject and information about 136 that Subject 138 o Authority: An entity that has the right to determine which 139 Associations exist within its namespace 141 o Delegation: An Association that indicates that an Authority has 142 given the right to make assertions about the Associations within 143 the part of a namespace identified by a Subject to a subordinate 144 Authority. 146 3. Query Interface 148 At its core, a naming service must provide a few basic functions for 149 queriers, associating a Subject of a query with information about 150 that subject. The information available from a naming service is 151 that which is necessary for a querier to establish a connection with 152 some other entity in the Internet, given a name identifying it. 154 3.1. Name to Address 156 Given a Subject name, the naming service returns a set of addresses 157 associated with that name, if such an association exists, where the 158 association is determined by the authority for that name. Names may 159 be associated with addresses in one or more address families (e.g. 160 IP version 4, IP version 6). A querier may specify which address 161 families it is interested in receiving addresses for, and the naming 162 system treats all address families equally. 164 This mapping is implemented in the DNS protocol via the A and AAAA 165 RRTYPES. 167 3.2. Address to Name 169 Given an Subject address, the naming service returns a set of names 170 associated with that address, if such an association exists, where 171 the association is determined by the authority for that address. 173 This mapping is implemented in the DNS protocol via the PTR RRTYPE. 174 IPv4 mappings exist within the in-addr.arpa. zone, and IPv6 mappings 175 in the ip6.arpa. zone. This mechanism has the disadvantage that 176 delegations in IPv4 only happen on octet (8-bit) boundaries, and in 177 IPv6 only happen on hex digit (4-bit) boundaries, which make 178 delegations on other prefixes operationally difficult. 180 3.3. Name to Name 182 Given a Subject name, the naming service returns a set of object 183 names associated with that name, if such an association exists, where 184 the association is determined by the authority for the subject name. 186 This mapping is implemented in the DNS protocol via the CNAME RRTYPE. 187 CNAME does not allow the association of multiple object names with a 188 single subject, and CNAME may not combine with other RRTYPEs (e.g. 189 NS, MX) arbitrarily. 191 3.4. Name to Auxiliary Information 193 Given a Subject name, the naming service returns other auxiliary 194 information associated with that name that is useful for establishing 195 communication over the Internet with the entities associated with 196 that name. 198 Most of the other RRTYPES in the DNS protocol implement these sort of 199 mappings. 201 3.5. Name/Address to Auxiliary Information 203 As a name might be associated with more than one address, auxiliary 204 information as above may be associated with a name/address pair, as 205 opposed to just with a name. 207 This mapping is not presently supported by the DNS protocol. 209 4. Authority Interface 211 The query interface is not the only interface to the naming service: 212 the interface a naming service presents to an Authority allows 213 updates to the set of Associations and Delegations in that 214 Authority's namespace. Updates consist of additions of, changes to, 215 and deletions of Associations and Delegations. In the present DNS, 216 this interface consists of the publication of a new zone file with an 217 incremented version number, but other authority interfaces are 218 possible. 220 5. Properties 222 The following properties are desirable in a naming service providing 223 the functions in Section 3 and Section 4. 225 5.1. Semantics 227 Since the point of a naming service is to replace network-layer 228 identifiers with more useful identifiers for humans (whether end 229 users, software developers, or network administrators), the Subject 230 names the naming service can provide must meet two semantic criteria: 232 5.1.1. Meaningfulness 234 A naming service must provide the ability to name objects that its 235 human users find more meaningful than the objects themselves. 237 5.1.2. Distinguishability 239 A naming service must make it possible to guarantee that two 240 different names are easily distinguishable from each other by its 241 human users. 243 5.1.3. Minimal Structure 245 A naming service should impose as little structure on the names it 246 supports as practical in order to be universally applicable. Naming 247 services that impose a given organizational structure on the names 248 expressible using the service will not translate well to societies 249 where that organizational structure is not prevalent. 251 5.2. Authority 253 Every Association among names, addresses, and auxiliary data is 254 subject to some Authority: an entity which has the right to determine 255 which Associations and Subjects exist in its namespace. The 256 following are properties of Authorities in our ideal naming service: 258 5.2.1. Federation of Authority 260 An Authority can delegate some part of its namespace to some other 261 subordinate Authority. This property allows the naming service to 262 scale to the size of the Internet, and leads to a tree-structured 263 namespace, where each Delegation is itself identified with a Subject 264 at a given level in the namespace. 266 In the DNS protocol, this federation of authority is implemented 267 through delegation using the NS RRTYPE, redirecting queries to 268 subordinate authorities recursively to the final authority. When 269 DNSSEC is used, the DS RRTYPE is used to verify this delegation. 271 5.2.2. Uniqueness of Authority 273 For a given Subject, there is a single Authority that has the right 274 to determine the Associations and/or Delegations for that subject. 275 The unitary authority for the root of the namespace tree may be 276 special, though; see Section 5.2.5. 278 In the DNS protocol as deployed, unitary authority is approximated by 279 the entity identified by the SOA RRTYPE. The existence of 280 registrars, which use the Extensible Provisioning Protocol (EPP) 281 [RFC5730] to modify entries in the zones under the authority of a 282 top-level domain registry, complicates this somewhat. 284 5.2.3. Transparency of Authority 286 A querier can determine the identity of the Authority for a given 287 Association. An Authority cannot delegate its rights or 288 responsibilities with respect to a subject without that Delegation 289 being exposed to the querier. 291 In DNS, the authoritative name server(s) to which a query is 292 delegated via the NS RRTYPE are known. However, we note that in the 293 case of authorities which delegate the ability to write to the zone 294 to other entities (i.e., the registry-registrar relationship), the 295 current DNS provides no facility for a querier to understand on whose 296 behalf an authoritative assertion is being made; this information is 297 instead available via WHOIS. To our knowledge, no present DNS name 298 servers use WHOIS information retrieved out of band to make policy 299 decisions. 301 5.2.4. Revocability of Authority 303 An ideal naming service allows the revocation and replacement of an 304 authority at any level in the namespace, and supports the revocation 305 and replacement of authorities with minimal operational disruption. 307 The current DNS allows the replacement of any level of delegation 308 except the root through changes to the appropriate NS and DS records. 309 Authority revocation in this case is as consistent as any other 310 change to the DNS. 312 5.2.5. Consensus on Root of Authority 314 Authority at the top level of the namespace tree is delegated 315 according to a process such that there is universal agreement 316 throughout the Internet as to the subordinates of those Delegations. 318 5.3. Authenticity 320 A querier must be able to verify that the answers that it gets from 321 the naming service are authentic. 323 5.3.1. Authenticity of Delegation 325 Given a Delegation from a superordinate to a subordinate Authority, a 326 querier can verify that the superordinate Authority authorized the 327 Delegation. 329 Authenticity of delegation in DNS is provided by DNSSEC [RFC4033]. 331 5.3.2. Authenticity of Response 333 The authenticity of every answer is verifiable by the querier. The 334 querier can confirm that the Association returned in the answer is 335 correct according to the Authority for the Subject of the query. 337 Authenticity of response in DNS is provided by DNSSEC. 339 5.3.3. Authenticity of Negative Response 341 Some queries will yield no answer, because no such Association 342 exists. In this case, the querier can confirm that the Authority for 343 the Subject of the query asserts this lack of Association. 345 Authenticity of negative response in DNS is provided by DNSSEC. 347 5.4. Consistency 349 Consistency in a naming service is important. The naming service 350 should provide the most globally consistent view possible of the set 351 of associations that exist at a given point in time, within the 352 limits of latency and bandwidth tradeoffs. 354 5.4.1. Dynamic Consistency 356 When an Authority makes changes to an Association, every query for a 357 given Subject returns either the new valid result or a previously 358 valid result, with known and/or predictable bounds on "how 359 previously". Given that additions of, changes to, and deletions of 360 associations may have different operational causes, different bounds 361 may apply to different operations. 363 The time-to-live (TTL) on a resource record in DNS provides a 364 mechanism for expiring old resource records. We note that this 365 mechanism makes additions to the system propagate faster than changes 366 and deletions, which may not be a desirable property. However, as no 367 context information is explicitly available in DNS, the DNS cannot be 368 said to be dynamically consistent, as different implicitly 369 inconsistent views of an association may be persistent. 371 5.4.2. Explicit Inconsistency 373 Some techniques require giving different answers to different 374 queries, even in the absence of changes: the stable state of the 375 namespace is not globally consistent. This inconsistency should be 376 explicit: a querier can know that an answer might be dependent on its 377 identity, network location, or other factors. 379 One example of such desirable inconsistency is the common practice of 380 "split horizon" DNS, where an organization makes internal names 381 available on its own network, but only the names of externally- 382 visible subjects available to the Internet at large. 384 Another is the common practice of DNS-based content distribution, in 385 which an authoritative name server gives different answers for the 386 same query depending on the network location from which the query was 387 received, or depending on the subnet in which the end client 388 originating a query is located (via the EDNS Client Subnet extension 389 {RFC7871}}). Such inconsistency based on client identity or network 390 address may increase query linkability (see Section 5.5.4). 392 These forms of inconsistency are implicit, not explicit, in the 393 current DNS. We note that while DNS can be deployed to allow 394 essentially unlimited kinds of inconsistency in its responses, there 395 is no protocol support for a query to express the kind of consistency 396 it desires, or for a response to explicitly note that it is 397 inconsistent. [RFC7871] does allow a querier to note that it would 398 specifically like the view of the state of the namespace offered to a 399 certain part of the network, and as such can be seen as inchoate 400 support for this property. 402 5.4.3. Global Invariance 404 An Association which is not intended to be explicitly inconsistent by 405 the Authority issuing it must return the same result for every Query 406 for it, regardless of the identity or location of the querier. 408 This property is not provided by DNS, as it depends on the robust 409 support on the Explicit Inconsistency property above. Examples of 410 global invariance failures include geofencing and DNS-based 411 censorship ordered by a local jurisdiction. 413 5.5. Performance Properties 415 A naming service must provide appropriate performance guarantees to 416 its clients. As these properties deal with the operational 417 parameters of the naming service, interesting tradeoffs are available 418 among them, both at design time as well as at run time (on which see 419 Section 5.5.5). 421 5.5.1. Availability 423 The naming service as a whole is resilient to failures of individual 424 nodes providing the naming service, as well as to failures of links 425 among them. Intentional prevention of successful, authenticated 426 query by an adversary should be as hard as practical. 428 The DNS protocol was designed to be highly available through the use 429 of secondary nameservers. Operational practices (e.g. anycast 430 deployment) also increase the availability of DNS as currently 431 deployed. 433 5.5.2. Lookup Latency 435 The time for the entire process of looking up a name and other 436 necessary associated data from the point of view of the querier, 437 amortized over all queries for all connections, should not 438 significantly impact connection setup or resumption latency. 440 5.5.3. Bandwidth Efficiency 442 The bandwidth cost for looking up a name and other associated data 443 necessary for establishing communication with a given Subject, from 444 the point of view of the querier, amortized over all queries for all 445 connections, should not significantly impact total bandwidth demand 446 for an application. 448 5.5.4. Query Linkability 450 It should be costly for an adversary to monitor the infrastructure in 451 order to link specific queries to specific queriers. 453 DNS over TLS [RFC7858] and DNS over DTLS [RFC8094] provide this 454 property between a querier and a recursive resolver; mixing by the 455 recursive helps with mitigating upstream linkability. 457 5.5.5. Explicit Tradeoff 459 A querier should be able to indicate the desire for a benefit with 460 respect to one performance property by accepting a tradeoff in 461 another, including: 463 o Reduced latency for reduced dynamic consistency 465 o Increased dynamic consistency for increased latency 467 o Reduced request linkability for increased latency and/or reduced 468 dynamic consistency 470 o Reduced aggregate bandwidth use for increased latency and/or 471 reduced dynamic consistency 473 There is no support for explicit tradeoffs in performance properties 474 available to clients in the present DNS. 476 5.6. Trust in Infrastructure 478 A querier should not need to trust any entity other than the 479 authority as to the correctness of association information provided 480 by the naming service. Specifically, the querier should not need to 481 trust any intermediary of infrastructure between itself and the 482 authority, other than that under its own control. 484 DNS provides this property with DNSSEC. However, the lack of 485 mandatory DNSSEC, and the lack of a viable transition strategy to 486 mandatory DNSSEC, means that trust in infrastructure will remain 487 necessary for DNS even with large scale DNSSEC deployment. 489 6. Observations 491 On a cursory examination, many of the properties of our ideal name 492 service can be met, or could be met, by the present DNS protocol or 493 extensions thereto. We note that there are further possibilities for 494 the future evolution of naming services meeting these properties. 495 This section contains random observations that might inform future 496 work. 498 6.1. Delegation and redirection are separate operations 500 Any system which can provide the authenticity properties in 501 Section 5.3 is freed from one of the design characteristics of the 502 present domain name system: the requirement to bind a zone of 503 authority to a specific set of authoritative servers. Since the 504 authenticity of delegation must be a protected by a chain of 505 signatures back to the root of authority, the location within the 506 infrastructure where an authoritative mapping "lives" is no longer 507 bound to a specific name server. While the present design of DNS 508 does have its own scalability advantages, this implication allows a 509 much larger design space to be explored for future name service work, 510 as a Delegation need not always be implemented via redirection to 511 another name server. 513 6.2. Queries and assertion contexts are presently implicit 515 Much of the difficulty with explicit inconsistency (Section 5.4.2) 516 derives from the fact that assertions and queries about subjects 517 exist within a context: .local names on the local network (whether 518 link or site local), split-DNS names within the context of the 519 "inside" side of the recursive resolver, DNS geographic load 520 balancing within the geographic context of the client. Because DNS 521 provides no protocol-level support for expressing these contexts, 522 they remain implicit. 524 We note that protocol-level support for this context explicit could 525 point toward solutions for a variety of problems in currently 526 deployed naming services, from generalized solutions with privacy/ 527 efficiency tradeoffs ({RFC7871}} aside), to explicit redirection to 528 alternate naming resolution for "special" names [RFC6761]. 530 6.3. Unicode alone may not be sufficient for distinguishable names 532 Allowing names to be encoded in Unicode goes a long way toward 533 meeting the meaningfulness property (see Section 5.1.1) for the 534 majority of speakers of human languages. However, as noted by the 535 Internet Architecture Board (see [IAB-UNICODE7]) and discussed at the 536 Locale-free Unicode Identifiers (LUCID) BoF at IETF 92 in Dallas in 537 March 2015 (see [LUCID]), it is not in the general case sufficient 538 for distinguishability (see Section 5.1.2). An ideal naming service 539 may therefore have to supplement Unicode by providing runtime support 540 for disambiguation of queries and assertions where the results may be 541 indistinguishable. 543 6.4. Implicit inconsistency makes global invariance challenging to 544 verify 546 DNS does not provide a generalized form of explicit inconsistency, so 547 efforts to verify global invariance, or rather, to discover 548 Associations for which global invariance does not hold, are 549 necessarily effort-intensive and dynamic. For example, the Open 550 Observatory of Network Interference performs DNS consistency checking 551 from multiple volunteer vantage points for a set of targeted (i.e., 552 likely to be globally variant) domain names; see 553 https://ooni.torproject.org/nettest/dns-consistency/ 555 7. IANA Considerations 557 This document has no actions for IANA. 559 8. Security Considerations 561 Protocols implementing name resolution systems that meet these ideal 562 properties will have to consider tradeoffs, especially with respect 563 to privacy (Section 5.5.4) versus performance, as in Section 5.5.5. 564 Many properties are security and privacy relevant. All the 565 properties in Section 5.3 must hold for a client to be able to trust 566 that assertions about a name are as intended by the authority for 567 that name. Section 5.1.2 specifies a property which, when it does 568 not hold, may be exploitable for phishing attacks, and Section 5.2.3 569 specifies a property which may ease operational defense against 570 malware abuse of the naming system. 572 9. Acknowledgments 574 This document is, in part, an output of design work on naming 575 services at the Network Security Group at ETH Zurich. Thanks to the 576 group, including Daniele Asoni, Steve Matsumoto, and Stephen Shirley, 577 for discussions leading to this document. Thanks as well to Ted 578 Hardie, Wendy Selzter, Andrew Sullivan, and Suzanne Woolf for input 579 and feedback. 581 10. Informative References 583 [I-D.ietf-dprive-dns-over-tls] 584 Zi, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 585 and P. Hoffman, "Specification for DNS over TLS", draft- 586 ietf-dprive-dns-over-tls-09 (work in progress), March 587 2016. 589 [I-D.ietf-dprive-dnsodtls] 590 Reddy, T., Wing, D., and P. Patil, "Specification for DNS 591 over Datagram Transport Layer Security (DTLS)", draft- 592 ietf-dprive-dnsodtls-15 (work in progress), December 2016. 594 [IAB-UNICODE7] 595 IAB, ., "IAB Statement on Identifiers and Unicode 7.0.0", 596 n.d., . 600 [LUCID] Freytag, A. and A. Sullivan, "LUCID problem (slides, IETF 601 92 LUCID BoF)", n.d., 602 . 605 [RFC1035] Mockapetris, P., "Domain names - implementation and 606 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 607 November 1987, . 609 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 610 Rose, "DNS Security Introduction and Requirements", 611 RFC 4033, DOI 10.17487/RFC4033, March 2005, 612 . 614 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 615 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 616 . 618 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 619 RFC 6761, DOI 10.17487/RFC6761, February 2013, 620 . 622 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 623 and P. Hoffman, "Specification for DNS over Transport 624 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 625 2016, . 627 [RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. 628 Kumari, "Client Subnet in DNS Queries", RFC 7871, 629 DOI 10.17487/RFC7871, May 2016, 630 . 632 [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram 633 Transport Layer Security (DTLS)", RFC 8094, 634 DOI 10.17487/RFC8094, February 2017, 635 . 637 Author's Address 639 Brian Trammell 640 ETH Zurich 641 Universitaetstrasse 6 642 Zurich 8092 643 Switzerland 645 Email: ietf@trammell.ch