| < draft-ietf-dnsop-alt-tld-02.txt | draft-ietf-dnsop-alt-tld-03.txt > | |||
|---|---|---|---|---|
| dnsop W. Kumari | dnsop W. Kumari | |||
| Internet-Draft Google | Internet-Draft Google | |||
| Intended status: Informational A. Sullivan | Intended status: Informational A. Sullivan | |||
| Expires: March 16, 2016 Dyn | Expires: April 2, 2016 Dyn | |||
| September 13, 2015 | September 30, 2015 | |||
| The ALT Special Use Top Level Domain | The ALT Special Use Top Level Domain | |||
| draft-ietf-dnsop-alt-tld-02 | draft-ietf-dnsop-alt-tld-03 | |||
| Abstract | Abstract | |||
| This document reserves a string (ALT) to be used as a TLD label in | This document reserves a string (ALT) to be used as a TLD label in | |||
| non-DNS contexts or for names that have no meaning in a global | non-DNS contexts or for names that have no meaning in a global | |||
| context. It also provides advice and guidance to developers | context. It also provides advice and guidance to developers | |||
| developing alternate namespaces. | developing alternate namespaces. | |||
| [ Ed note: This document lives in GitHub at: | [ Ed note: This document lives in GitHub at: | |||
| https://github.com/wkumari/draft-wkumari-dnsop-alt-tld . Issues and | https://github.com/wkumari/draft-wkumari-dnsop-alt-tld . Issues and | |||
| skipping to change at page 1, line 38 ¶ | skipping to change at page 1, line 38 ¶ | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on March 16, 2016. | This Internet-Draft will expire on April 2, 2016. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2015 IETF Trust and the persons identified as the | Copyright (c) 2015 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
| (http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
| publication of this document. Please review these documents | publication of this document. Please review these documents | |||
| skipping to change at page 2, line 49 ¶ | skipping to change at page 2, line 49 ¶ | |||
| 1.1. Requirements notation | 1.1. Requirements notation | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
| document are to be interpreted as described in [RFC2119]. | document are to be interpreted as described in [RFC2119]. | |||
| 1.2. Terminology | 1.2. Terminology | |||
| This document assumes familiarity with DNS terms and concepts. | This document assumes familiarity with DNS terms and concepts. | |||
| Please see [RFC1034] for background and concepts. | Please see [RFC1034] for background and concepts, and | |||
| [I-D.ietf-dnsop-dns-terminology] for terminology. | ||||
| o DNS name: Domain names that are intended to be used with DNS | ||||
| resolution, either in the global DNS or in some other context | ||||
| o DNS context: The namespace anchored at the globally-unique DNS | o DNS context: The namespace anchored at the globally-unique DNS | |||
| root. This is the namespace or context that "normal" DNS uses. | root. This is the namespace or context that "normal" DNS uses. | |||
| o non-DNS context: Any other (alternate) namespace. | o non-DNS context: Any other (alternate) namespace. | |||
| o pseudo-TLD: A label that appears in a fully-qualified domain name | o pseudo-TLD: A label that appears in a fully-qualified domain name | |||
| in the position of a TLD, but which is not registered in the | in the position of a TLD, but which is not registered in the | |||
| global DNS. | global DNS. | |||
| skipping to change at page 7, line 26 ¶ | skipping to change at page 7, line 26 ¶ | |||
| 5. Authoritative DNS servers SHOULD recognize these names as special | 5. Authoritative DNS servers SHOULD recognize these names as special | |||
| and SHOULD, by default, generate immediate negative responses for | and SHOULD, by default, generate immediate negative responses for | |||
| all such queries, unless explicitly configured by the | all such queries, unless explicitly configured by the | |||
| administrator to give positive answers for private-address | administrator to give positive answers for private-address | |||
| reverse-mapping names. | reverse-mapping names. | |||
| 6. DNS server operators SHOULD be aware that queries for names | 6. DNS server operators SHOULD be aware that queries for names | |||
| ending in .alt are not DNS names, and were leaked into the DNS | ending in .alt are not DNS names, and were leaked into the DNS | |||
| context (for example, by a missing browser plugin). This | context (for example, by a missing browser plugin). This | |||
| information may be useful for support or debuggung purposes. | information may be useful for support or debugging purposes. | |||
| 7. DNS Registries/Registrars MUST NOT grant requests to register | 7. DNS Registries/Registrars MUST NOT grant requests to register | |||
| "alt" names in the normal way to any person or entity. These | "alt" names in the normal way to any person or entity. These | |||
| "alt" names are defined by protocol specification to be | "alt" names are defined by protocol specification to be | |||
| nonexistent, and they fall outside the set of names available for | nonexistent, and they fall outside the set of names available for | |||
| allocation by registries/registrars. | allocation by registries/registrars. | |||
| 5. Security Considerations | 5. Security Considerations | |||
| One of the motivations for the creation of the alt pseudo-TLD is that | One of the motivations for the creation of the alt pseudo-TLD is that | |||
| skipping to change at page 7, line 48 ¶ | skipping to change at page 7, line 48 ¶ | |||
| unexpected takeover if the manager of the root name space decides to | unexpected takeover if the manager of the root name space decides to | |||
| delegate the unmanaged label. | delegate the unmanaged label. | |||
| The unmanaged and "registration not required" nature of labels | The unmanaged and "registration not required" nature of labels | |||
| beneath .alt provides the opportunity for an attacker to re-use the | beneath .alt provides the opportunity for an attacker to re-use the | |||
| chosen label and thereby possibly compromise applications dependent | chosen label and thereby possibly compromise applications dependent | |||
| on the special host name. | on the special host name. | |||
| 6. Acknowledgements | 6. Acknowledgements | |||
| The authors understand that there is much politics surrounding the | ||||
| delegation of a new TLD and thank the ICANN liaison in advance. | ||||
| We would also like to thank Joe Abley, Mark Andrews, Marc Blanchet, | We would also like to thank Joe Abley, Mark Andrews, Marc Blanchet, | |||
| John Bond, Stephane Bortzmeyer, David Cake, David Conrad, Patrik | John Bond, Stephane Bortzmeyer, David Cake, David Conrad, Patrik | |||
| Faltstrom, Olafur Gudmundsson, Paul Hoffman, Joel Jaeggli, Ted Lemon, | Faltstrom, Olafur Gudmundsson, Paul Hoffman, Joel Jaeggli, Ted Lemon, | |||
| Edward Lewis, George Michaelson, Ed Pascoe, Arturo Servin, and Paul | Edward Lewis, George Michaelson, Ed Pascoe, Arturo Servin, and Paul | |||
| Vixie for feedback. | Vixie for feedback. | |||
| 7. Normative References | 7. Normative References | |||
| [I-D.ietf-dnsop-dns-terminology] | ||||
| Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS | ||||
| Terminology", draft-ietf-dnsop-dns-terminology-05 (work in | ||||
| progress), September 2015. | ||||
| [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", | [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", | |||
| STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, | STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, | |||
| <http://www.rfc-editor.org/info/rfc1034>. | <http://www.rfc-editor.org/info/rfc1034>. | |||
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
| Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ | Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ | |||
| RFC2119, March 1997, | RFC2119, March 1997, | |||
| <http://www.rfc-editor.org/info/rfc2119>. | <http://www.rfc-editor.org/info/rfc2119>. | |||
| [RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163, RFC | [RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163, RFC | |||
| skipping to change at page 8, line 31 ¶ | skipping to change at page 8, line 33 ¶ | |||
| <http://www.rfc-editor.org/info/rfc6303>. | <http://www.rfc-editor.org/info/rfc6303>. | |||
| [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", | [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", | |||
| RFC 6761, DOI 10.17487/RFC6761, February 2013, | RFC 6761, DOI 10.17487/RFC6761, February 2013, | |||
| <http://www.rfc-editor.org/info/rfc6761>. | <http://www.rfc-editor.org/info/rfc6761>. | |||
| Appendix A. Changes / Author Notes. | Appendix A. Changes / Author Notes. | |||
| [RFC Editor: Please remove this section before publication ] | [RFC Editor: Please remove this section before publication ] | |||
| From -02 to -03: | ||||
| o Incorporate suggestions from Stephane and Paul Hoffman. | ||||
| From -01 to -02: | From -01 to -02: | |||
| o Merged a bunch of changes from Paul Hoffman. Thanks for sending a | o Merged a bunch of changes from Paul Hoffman. Thanks for sending a | |||
| git pull. | git pull. | |||
| From -00 to 01: | From -00 to 01: | |||
| o Removed the "delegated to new style AS112 servers" text -this was | o Removed the "delegated to new style AS112 servers" text -this was | |||
| legacy from the omnicient AS112 days. (Joe Abley) | legacy from the omnicient AS112 days. (Joe Abley) | |||
| End of changes. 8 change blocks. | ||||
| 9 lines changed or deleted | 19 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||