4.  The Inverse Lookup Requirement

   The requirement for an inverse lookup capability, i.e., the ability
   to find a domain name given an address and, in principle, to find the
   owner of a record by any of its data elements, was recognized in RFC
   882.  The feature was identified as optional but carried forward into
   RFCs 1034 and 1035 but was explicitly deprecated by RFC 1034 for
   address-to-hostname lookup (although RFC 1035 uses exactly that type
   of lookup in an example).  Despite the discussion of inverted forms
   of the database in RFC 1035, inverse lookup has rarely, if ever, been
   implemented, at least in its general form.  The fundamental
   difficulties with inverse lookup in either the form described in RFC
   882 or the "in-addr.arpa" approach mentioned below are consistent
   with the problems described in fundamental papers on database
   management [Codd1970] but were not described in RFC 1035 or related
   contemporary IETF documents.

   It is interesting to speculate on how many of the current
   requirements to treat aliases as an integrated set of synonyms (e.g.,
   for variant handling) would have been addressed if inverse lookups
   could reliably produce the owners of CNAME records.

   At the same time, it was obviously important to have some mechanism
   for address-to-name resolution.  It was provided by PTR RRTYPE
   entries in the IN-ADDR.ARPA zone, with delegations on octet
   boundaries.  However, that approach required that information be
   maintained in parallel, in separate zones, for the name-to-address
   and address-to-name mappings.  That synchronization requirement for
   two copies of essentially the same data was another popular topic in
   the database management literature a decade or more before the DNS
   and, predictably, led to many inconsistencies and other failures.

   The introduction of Classless Inter-Domain Routing (CIDR) [RFC1518]
   and Provider-Dependent addresses made the situation even more
   difficult, because it was no longer possible to delegate the
   administration of reverse mapping records for small networks to the
   actual operators of those networks.  ISPs and other aggregators often
   had no incentive to maintain reverse mapping records consistent with
   network operator assignment of domain names.  A proposal to use
   binary labels to work around that issue [RFC2673] was abandoned
   somewhat over three years later [RFC6891].

   Independent of how much or little harm the absence of a general
   inverse lookup facility has caused and how effective the
   "in-addr.arpa" approach has been, inverse lookup remains a facility
   that was anticipated and known to be useful in the original DNS
   design but that has never been fully realized.

5.  Internet Scale, Function Support, and Incremental Deployment

   In addition to the stresses caused by the new functions, including
   those described in Section 3.13, incremental deployment of systems
   that utilize them means that some functions will work in some
   environments and not others.  This has been especially problematic
   with complex, multi-record, capabilities like DNSSEC that provide or
   require special validation mechanisms and with some EDNS(0)
   extensions [RFC6891] that require both the client and server to
   accept particular extensions.  When DNS functionality is required in
   embedded devices, deployment of new features across the entire
   Internet in a reasonable period of time is nearly impossible.

   If one were redesigning the DNS, one could imagine ways to address
   these issues that would make them slightly more tractable, and, of
   course, the features that are known to be necessary today could
   become part of the baseline, "mandatory to implement", specification.

6.  Searching and the DNS -- An Historical Note

   Some of the issues identified above might reasonably be addressed,
   not by changing the DNS itself but by changing our model of what it
   is about and how it is used.  Specifically, one key assumption when
   the DNS (and the host table system before it) was designed was that
   it was a naming system for network resources, not, e.g., digital
   content.  As such, exact matching was important, it was reasonable to
   have labels treated as mnemonics that did not necessarily have
   linguistic or semantic meaning except to those using them, and so on.
   A return to that model, presumably by having user-facing applications
   call on an intermediate layer to disambiguate user-friendly names and
   map them to DNS names (or network object locators more generally),
   would significantly reduce stress on the DNS and would also allow
   dealing with types of matching and similar or synonymous strings that
   cannot be handled algorithmically no matter how much DNS matching
   rules were altered.

   In some respects, search engines based on free-text analysis and
   linkages among information have come to serve many of the functions
   of such an intermediate layer.  Many studies and sources have pointed
   out that few users actually understand, much less care about, the
   distinction between a DNS name and a search term.  Recent versions of
   some web browsers have both recognized the failure of that
   distinction and reinforced it by eliminating the separation between
   "URL" and "search bar".

   It is worth noting that, while that "search" approach, or some other
   approach that abstracted and separated several of the issues
   identified in Section 3 from the DNS protocol and database
   themselves, it does not address all of them.  At least some elements
   of several of those issues, such as the synchronization ones
   described in Section 3.7 and the transport ones described in
   Section 3.15, are inherent in the DNS design, and, if we are not
   going to replace the DNS, we had best get used to them.

   In the early part of the last decade, the IETF engaged in some
   preliminary exploration of the intermediate-layer approach in the
   context of IDNs and what were then called "Internet keywords"
   [DNS-search].  While that exploratory effort met several times
   informally, it never became an organized IETF activity, largely
   because of the choice of what became the IDNA approach but also in
   part by signs that the "Internet keywords" efforts were beginning to
   fall apart.

   It may be time to reexamine intermediate-layer approaches.  If so,
   the effort should examine use of those approaches by appropriate
   user-facing applications that might be used to address some of the
   issues identified above.  The Internet and the DNS have changed
   considerably since the 2000-2003 period.  Several of those changes
   are discussed elsewhere in this document; others, including
   repurposing of the DNAME RRTYPE from support for transitions
   [RFC2672] to a general-purpose mechanism for aliases of subtrees
   [RFC6672] and the addition of over a thousand new TLDs
   [IANA-TLD-registry], are not but nonetheless are part of the context
   for intermediate-layer work that did not exist in 2003.

7.  Security Considerations

   A wide range of security issues related to both securing the DNS and
   also to abilities to use namespaces for nefarious purposes have
   arisen.  Issues of securing the DNS would obviously be essential to a
   replacement of the DNS.  Issues of preventing nefarious use of the
   namespace (e.g. use of the name that appears or disappears as a
   signal to bots) would appear to be harder to solve within the naming
   system.

8.  References

8.1.  Normative References

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
              <https://www.rfc-editor.org/info/rfc1034>.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
              November 1987, <https://www.rfc-editor.org/info/rfc1035>.

8.2.  Informative References

   [CACM-Homograph]
              Gabrilovich, E. and A. Gontmakher, "The Homograph Attack",
              Communications of the ACM, Volume 45, Issue 2, pp. 128,
              DOI 10.1145/503124.503156, February 2002,
              <http://www.cs.technion.ac.il/~gabr/papers/
              homograph_full.pdf>.

   [Cerf2017] Cerf, V., "Desirable Properties of Internet Identifiers",
              IEEE Internet Computing, Volume 21, Issue 6, pp. 63-64,
              DOI 10.1109/MIC.2017.4180839, November/December 2017.

   [Codd1970] Codd, E., "A Relational Model of Data for Large Shared
              Data Banks", Communications of the ACM, Volume 13, Issue
              6, pp. 377-387, DOI 10.1145/362384.362685, June 1970,
              <https://dl.acm.org/citation.cfm?id=362685>.

   [DNS-Aliases]
              Woolf, S., Lee, X., and J. Yao, "Problem Statement: DNS
              Resolution of Aliased Names", Work in Progress,
              draft-ietf-dnsext-aliasing-requirements-01, March 2011.

   [DNS-BNAME]
              Yao, J., Lee, X., and P. Vixie, "Bundled DNS Name
              Redirection", Work in Progress, draft-yao-dnsext-bname-06,
              May 2016.

   [DNS-search]
              IETF, "Internet Resource Name Search Service (IRNSS)",
              2003, <https://datatracker.ietf.org/wg/irnss/about/>.

   [Faltstrom-2004]
              Faltstrom, P. and R. Austein, "Design Choices When
              Expanding DNS", Work in Progress,
              draft-ymbk-dns-choices-00, May 2004.

   [Hoffman-DNS-JSON]
              Hoffman, P., "Representing DNS Messages in JSON", Work in
              Progress, draft-hoffman-dns-in-json-13, October 2017.

   [Hoffman-SimpleDNS-JSON]
              Hoffman, P., "Simple DNS Queries and Responses in JSON",
              Work in Progress, draft-hoffman-simplednsjson-01, November
              2017.

   [Huston2017a]
              Huston, G. and J. Silva Dama, "DNS Privacy", The Internet
              Protocol Journal, Vol. 20, No. 1, March 2017,
              <http://ipj.dreamhosters.com/wp-content/uploads/
              issues/2017/ipj20-1.pdf>.

   [Huston2017b]
              Huston, G., "The Root of the Domain Name System", The
              Internet Protocol Journal, Vol. 20, No. 2, pp. 15-25, June
              2017, <http://ipj.dreamhosters.com/wp-content/uploads/
              2017/08/ipj20-2.pdf>.

   [IANA-TLD-registry]
              Internet Assigned Numbers Authority (IANA), "Root Zone
              Database", <https://www.iana.org/domains/root/db>.

   [ICANN-VIP]
              ICANN, "IDN Variant Issues Project: Final Integrated
              Issues Report Published and Proposed Project Plan for Next
              Steps is Now Open for Public Comment", February 2012,
              <https://www.icann.org/news/announcement-2012-02-20-en>.

   [IETF-DBOUND]
              IETF, "Domain Boundaries (dbound)", 2017,
              <https://datatracker.ietf.org/wg/dbound/about/>.

   [Klensin-5891bis]
              Klensin, J. and A. Freytag, "Internationalized Domain
              Names in Applications (IDNA): Registry Restrictions and
              Recommendations", Work in Progress,
              draft-klensin-idna-rfc5891bis-01, September 2017.

   [Mockapetris-1988]
              Mockapetris, P. and K. Dunlap, "Development of the Domain
              Name System", SIGCOMM '88 Symposium, pp. 123-133,
              available from ISI Reprint Series, ISI/RS-88-219
              <ftp://ftp.isi.edu/isi-pubs/rs-88-219.pdf>,
              DOI 10.1145/52324.52338, August 1988,
              <http://dl.acm.org/citation.cfm?id=52338>.

   [NRC-Signposts]
              National Research Council, Signposts in Cyberspace: The
              Domain Name System and Internet Navigation,
              ISBN 0-309-54979-5, 2005, <https://www.nap.edu/
              catalog/11258/signposts-in-cyberspace-the-domain-name-
              system-and-internet-navigation>.

   [RFC0236]  Postel, J., "Standard host names", RFC 236,
              DOI 10.17487/RFC0236, September 1971,
              <https://www.rfc-editor.org/info/rfc236>.

   [RFC0247]  Karp, P., "Proffered set of standard host names", RFC 247,
              DOI 10.17487/RFC0247, October 1971,
              <https://www.rfc-editor.org/info/rfc247>.

   [RFC0799]  Mills, D., "Internet name domains", RFC 799,
              DOI 10.17487/RFC0799, September 1981,
              <https://www.rfc-editor.org/info/rfc799>.

   [RFC0810]  Feinler, E., Harrenstien, K., Su, Z., and V. White, "DoD
              Internet host table specification", RFC 810,
              DOI 10.17487/RFC0810, March 1982,
              <https://www.rfc-editor.org/info/rfc810>.

   [RFC0881]  Postel, J., "Domain names plan and schedule", RFC 881,
              DOI 10.17487/RFC0881, November 1983,
              <https://www.rfc-editor.org/info/rfc881>.

   [RFC0882]  Mockapetris, P., "Domain names: Concepts and facilities",
              RFC 882, DOI 10.17487/RFC0882, November 1983,
              <https://www.rfc-editor.org/info/rfc882>.

   [RFC0883]  Mockapetris, P., "Domain names: Implementation
              specification", RFC 883, DOI 10.17487/RFC0883, November
              1983, <https://www.rfc-editor.org/info/rfc883>.

   [RFC0952]  Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet
              host table specification", RFC 952, DOI 10.17487/RFC0952,
              October 1985, <https://www.rfc-editor.org/info/rfc952>.

   [RFC0953]  Harrenstien, K., Stahl, M., and E. Feinler, "Hostname
              Server", RFC 953, DOI 10.17487/RFC0953, October 1985,
              <https://www.rfc-editor.org/info/rfc953>.

   [RFC0974]  Partridge, C., "Mail routing and the domain system",
              STD 10, RFC 974, DOI 10.17487/RFC0974, January 1986,
              <https://www.rfc-editor.org/info/rfc974>.

   [RFC1123]  Braden, R., Ed., "Requirements for Internet Hosts -
              Application and Support", STD 3, RFC 1123,
              DOI 10.17487/RFC1123, October 1989,
              <https://www.rfc-editor.org/info/rfc1123>.

   [RFC1464]  Rosenbaum, R., "Using the Domain Name System To Store
              Arbitrary String Attributes", RFC 1464,
              DOI 10.17487/RFC1464, May 1993,
              <https://www.rfc-editor.org/info/rfc1464>.

   [RFC1518]  Rekhter, Y. and T. Li, "An Architecture for IP Address
              Allocation with CIDR", RFC 1518, DOI 10.17487/RFC1518,
              September 1993, <https://www.rfc-editor.org/info/rfc1518>.

   [RFC1591]  Postel, J., "Domain Name System Structure and Delegation",
              RFC 1591, DOI 10.17487/RFC1591, March 1994,
              <https://www.rfc-editor.org/info/rfc1591>.

   [RFC1996]  Vixie, P., "A Mechanism for Prompt Notification of Zone
              Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996,
              August 1996, <https://www.rfc-editor.org/info/rfc1996>.

   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
              RFC 2671, DOI 10.17487/RFC2671, August 1999,
              <https://www.rfc-editor.org/info/rfc2671>.

   [RFC2672]  Crawford, M., "Non-Terminal DNS Name Redirection",
              RFC 2672, DOI 10.17487/RFC2672, August 1999,
              <https://www.rfc-editor.org/info/rfc2672>.

   [RFC2673]  Crawford, M., "Binary Labels in the Domain Name System",
              RFC 2673, DOI 10.17487/RFC2673, August 1999,
              <https://www.rfc-editor.org/info/rfc2673>.

   [RFC3490]  Faltstrom, P., Hoffman, P., and A. Costello,
              "Internationalizing Domain Names in Applications (IDNA)",
              RFC 3490, DOI 10.17487/RFC3490, March 2003,
              <https://www.rfc-editor.org/info/rfc3490>.

   [RFC3491]  Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
              Profile for Internationalized Domain Names (IDN)",
              RFC 3491, DOI 10.17487/RFC3491, March 2003,
              <https://www.rfc-editor.org/info/rfc3491>.

   [RFC3596]  Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
              "DNS Extensions to Support IP Version 6", STD 88,
              RFC 3596, DOI 10.17487/RFC3596, October 2003,
              <https://www.rfc-editor.org/info/rfc3596>.

   [RFC3743]  Konishi, K., Huang, K., Qian, H., and Y. Ko, "Joint
              Engineering Team (JET) Guidelines for Internationalized
              Domain Names (IDN) Registration and Administration for
              Chinese, Japanese, and Korean", RFC 3743,
              DOI 10.17487/RFC3743, April 2004,
              <https://www.rfc-editor.org/info/rfc3743>.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, DOI 10.17487/RFC3986, January 2005,
              <https://www.rfc-editor.org/info/rfc3986>.

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements",
              RFC 4033, DOI 10.17487/RFC4033, March 2005,
              <https://www.rfc-editor.org/info/rfc4033>.

   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Resource Records for the DNS Security Extensions",
              RFC 4034, DOI 10.17487/RFC4034, March 2005,
              <https://www.rfc-editor.org/info/rfc4034>.

   [RFC4343]  Eastlake 3rd, D., "Domain Name System (DNS) Case
              Insensitivity Clarification", RFC 4343,
              DOI 10.17487/RFC4343, January 2006,
              <https://www.rfc-editor.org/info/rfc4343>.

   [RFC5890]  Klensin, J., "Internationalized Domain Names for
              Applications (IDNA): Definitions and Document Framework",
              RFC 5890, DOI 10.17487/RFC5890, August 2010,
              <https://www.rfc-editor.org/info/rfc5890>.

   [RFC5891]  Klensin, J., "Internationalized Domain Names in
              Applications (IDNA): Protocol", RFC 5891,
              DOI 10.17487/RFC5891, August 2010,
              <https://www.rfc-editor.org/info/rfc5891>.

   [RFC6672]  Rose, S. and W. Wijngaards, "DNAME Redirection in the
              DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012,
              <https://www.rfc-editor.org/info/rfc6672>.

   [RFC6761]  Cheshire, S. and M. Krochmal, "Special-Use Domain Names",
              RFC 6761, DOI 10.17487/RFC6761, February 2013,
              <https://www.rfc-editor.org/info/rfc6761>.

   [RFC6891]  Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
              for DNS (EDNS(0))", STD 75, RFC 6891,
              DOI 10.17487/RFC6891, April 2013,
              <https://www.rfc-editor.org/info/rfc6891>.

   [RFC6895]  Eastlake 3rd, D., "Domain Name System (DNS) IANA
              Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895,
              April 2013, <https://www.rfc-editor.org/info/rfc6895>.

   [RFC6912]  Sullivan, A., Thaler, D., Klensin, J., and O. Kolkman,
              "Principles for Unicode Code Point Inclusion in Labels in
              the DNS", RFC 6912, DOI 10.17487/RFC6912, April 2013,
              <https://www.rfc-editor.org/info/rfc6912>.

   [RFC7094]  McPherson, D., Oran, D., Thaler, D., and E. Osterweil,
              "Architectural Considerations of IP Anycast", RFC 7094,
              DOI 10.17487/RFC7094, January 2014,
              <https://www.rfc-editor.org/info/rfc7094>.

   [RFC7706]  Kumari, W. and P. Hoffman, "Decreasing Access Time to Root
              Servers by Running One on Loopback", RFC 7706,
              DOI 10.17487/RFC7706, November 2015,
              <https://www.rfc-editor.org/info/rfc7706>.

   [RFC7719]  Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
              Terminology", RFC 7719, DOI 10.17487/RFC7719, December
              2015, <https://www.rfc-editor.org/info/rfc7719>.

   [RFC7816]  Bortzmeyer, S., "DNS Query Name Minimisation to Improve
              Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016,
              <https://www.rfc-editor.org/info/rfc7816>.

   [RFC7858]  Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
              and P. Hoffman, "Specification for DNS over Transport
              Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
              2016, <https://www.rfc-editor.org/info/rfc7858>.

   [RFC7872]  Gont, F., Linkova, J., Chown, T., and W. Liu,
              "Observations on the Dropping of Packets with IPv6
              Extension Headers in the Real World", RFC 7872,
              DOI 10.17487/RFC7872, June 2016,
              <https://www.rfc-editor.org/info/rfc7872>.

   [RFC8244]  Lemon, T., Droms, R., and W. Kumari, "Special-Use Domain
              Names Problem Statement", RFC 8244, DOI 10.17487/RFC8244,
              October 2017, <https://www.rfc-editor.org/info/rfc8244>.

   [Sullivan-Class]
              Sullivan, A., "The DNS Is Not Classy: DNS Classes
              Considered Useless", Work in Progress,
              draft-sullivan-dns-class-useless-03, July 2016.

   [Unicode]  The Unicode Consortium, The Unicode Standard, Version
              9.0.0, (Mountain View, CA: The Unicode Consortium,
              2016. ISBN 978-1-936213-13-9),
              <http://www.unicode.org/versions/Unicode9.0.0/>.

   [Unicode-UAX15]
              Davis, M. and K. Whistler, "Unicode Standard Annex #15:
              Unicode Normalization Forms", February 2016,
              <http://unicode.org/reports/tr15/>.

   [Unicode-USA31]
              Davis, M., "Unicode Standard Annex #31: Unicode Identifier
              and Pattern Syntax", May 2016,
              <http://unicode.org/reports/tr31/>.

   [Vixie-20170704]
              Vixie, P., "Subject: Re: new DNS classes", message to
              the IETF dnsop mailing list, 4 July 2017,
              <https://www.ietf.org/mail-archive/web/ietf/current/
              msg103486.html>.

Acknowledgements

   Many of the concerns and ideas described in this document reflect
   conversations over a period of many years, some rooted in DNS
   "keyword" and "search" discussions that paralleled the development of
   IDNs.  Conversations with, or writings of, Rob Austein, Christine
   Borgman, Carolina Carvalho, Vint Cerf, Lyman Chapin, Nazli Choucri,
   Patrik Faltstrom, Geoff Huston, Xiaodong Lee, Karen Liu, Gervase
   Markham, Yaqub Mueller, Andrew Sullivan, Paul Twomey, Nico Williams,
   Suzanne Woolf, Jiankang Yao, other participants in the circa 2003
   "DNS Search" effort and in the ICANN SSAC Working Party on IDNs, and
   some others whose names were sadly forgotten, were particularly
   important to either the content of this document or the motivation
   for writing it even though they may not agree with the conclusions I
   have reached and bear no responsibility for them.

   Many of the subsections of Section 3 were extracted from comments
   first made in conjunction with recent email discussions.  Comments
   from Suzanne Woolf about an earlier draft version were particularly
   important as was material developed with suggestions from Patrik
   Faltstrom, especially Section 3.13.  Feedback and suggestions from
   several of the above and from Stephane Bortzmeyer, Tony Finch, Bob
   Harold, Warren Kumari, Craig Partridge, and George Sadowsky were
   extremely helpful for improving the clarity and accuracy of parts of
   the document, especially so for a broader audience.  Craig Partridge
   also contributed much of the material about queries for multiple
   types.  Geoff Huston made several useful comments and contributed
   most of Section 3.15, and Bill Manning pointed out some broader
   requirements about integrity of information and DNS management and
   operations.

   Special thanks are due to Karen Moore of the RFC Production Center
   for her efforts, patience, and persistence in preparing this document
   for publication, a process that raised far more issues that required
   careful discussion than usual.

Author's Address

   John C. Klensin
   1770 Massachusetts Ave, Ste 322
   Cambridge, MA  02140
   United States of America

   Phone: +1 617 245 1457
   Email: john-ietf@jck.com