One document matched: draft-chapin-additional-reserved-tlds-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC1034 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1034.xml">
<!ENTITY RFC1035 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml">
<!ENTITY RFC1591 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1591.xml">
<!ENTITY RFC2606 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2606.xml">
<!ENTITY RFC6761 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6761.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-chapin-additional-reserved-tlds-02" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="Additional Reserved TLDs">Additional Reserved Top Level Domains</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Lyman Chapin"
initials="L." role="editor"
surname="Chapin">
<organization>Interisle Consulting Group</organization>
<address>
<postal>
<street>125A Magazine Street</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
<country>UK</country>
</postal>
<phone>+1 617 686 2527</phone>
<email>lyman@interisle.net</email>
</address>
</author>
<author fullname="Mark McFadden"
initials="M." role="editor"
surname="McFadden">
<organization>InterConnect Communications Ltd</organization>
<address>
<postal>
<street>Merlin House; Station Road</street>
<city>Chepstow</city>
<region>Monmouthshire</region>
<code>NP16 5PB</code>
<country>UK</country>
</postal>
<phone>+44 7792 276 904</phone>
<email>markmcfadden@icc-uk.com</email>
</address>
</author>
<date month="March" year="2015" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>IETF</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>DNS</keyword>
<keyword>reserved</keyword>
<keyword>localdomain</keyword>
<keyword>domain</keyword>
<keyword>localdomain</keyword>
<keyword>lan</keyword>
<keyword>home</keyword>
<keyword>corp</keyword>
<keyword>mail</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>The Internet Domain Name System (DNS) defines a tree of names starting with root, ".", immediately below which are top level domain (TLD) names such as ".com" and ".us". In June 1999 <xref target="RFC2606" /> reserved a small number of TLD names for use in documentation examples, private testing, experiments, and other circumstances in which it is desirable to avoid conflict with current or future actual TLD names in the DNS.</t>
<t>There has been significant evolution of Internet engineering and operation practices since <xref target="RFC2606" /> was published. In February 2013 <xref target="RFC6761" /> defined criteria and procedures for reserving a domain name for special use, and established an IANA registry for such names. This document reserves three domain name labels for special use in accordance with the criteria and procedures of <xref target="RFC6761" />: home, corp, and mail.</t>
<t>It is important to note that TLD names may be reserved, in other contexts, for policy, political, or other reasons that are distinct from the IETF's concern with Internet engineering and operations. This document reserves TLD names only for operational and engineering reasons. </t>
</abstract>
</front>
<middle>
<section title="Introduction" anchor="intro">
<t>The Internet Domain Name System is documented in <xref target="RFC1034" />, <xref target="RFC1035" />, <xref target="RFC1591" /> and numerous additional Requests for Comment. It defines a tree of names starting with root, ".", immediately below which are top level domain names such as ".com" and ".us". Below top level domain names there are normally additional levels of names.</t>
<t><xref target="RFC2606" /> reserves a small number of TLD names which can be used for private testing of existing DNS related code, examples in documentation, DNS related experimentation, invalid DNS names, or other similar uses without fear of conflicts with current or future actual top-level domain names in the global DNS. <xref target="RFC2606" /> also notes that the Internet Assigned Numbers Authority (IANA) reserves the label "example" at the second level below the TLDs .com, .net, and .org.</t>
<t>Since <xref target="RFC2606" /> was published in 1999, Internet engineering and operation practices have evolved in ways that led to the publication in February 2013 of <xref target="RFC6761" />, which defined criteria and procedures for reserving a domain name for special use and established an IANA registry to which additional reserved special use names might be added as new requirements arose.</t>
<t>This document follows <xref target="RFC6761" /> to add three reserved top-level domain name labels to the IANA special-use names registry. It is prompted by the impending advent of new TLDs which might, in the absence of the reservations for which this document provides, introduce TLD labels that could create engineering and operational problems for root server operators and other DNS infrastructure providers.</t>
<t>It is important to note that TLD names may be reserved, in other contexts, for policy, political, or other reasons that are distinct from the IETF's concern with Internet engineering and operations. This document reserves TLD names only for operational and engineering reasons.</t>
</section>
<section title="Requirements Language" anchor="require">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <xref target="RFC2119" />.</t>
<t>In this document, these words will appear with that interpretation only when in ALL CAPS. Lower case uses of these words are not to be interpreted as carrying <xref target="RFC2119" /> significance.</t>
</section>
<section title="New top-level domain name reservations" anchor="rationale">
<t>In its report <xref target="SAC045" /> of a quantitative study of queries to the DNS root servers entitled "Invalid Top Level Domain Queries at the Root Level of the Domain Name System" <xref target="SAC045" /> ICANN's Security and Stability Advisory Committee "calls attention to the potential problems that may arise should a new TLD applicant use a string that has been seen with measurable (and meaningful) frequency in a query for resolution by the root system and the root system has previously generated a response."</t>
<t>Of particular concern is the case in which a string "has been queried and a root name server has responded to the query with a non-existent domain (NXDOMAIN) result, i.e., the string has not been delegated but has been queried." <xref target="SAC045" /> reports the results of a CAIDA measurement study <xref target="RSSAC_DNS" /> which found that "NXDOMAIN responses account for more than 25 percent of the total responses from root name servers observed in the study, and the top ten such strings account for 10 percent of the total query load."</t>
<t><xref target="SAC045" /> describes in detail the engineering and operational problems that would ensue from the delegation, as new valid TLD names, of previously invalid labels that have frequently appeared in queries to the root: "If the [new TLD label] were to be approved and the TLD included in the root zone, queries to the root level of the DNS for a string that hitherto returned NXDOMAIN would begin to return positive responses containing name servers of the new TLD."</t>
<t>Recommendation (2) of <xref target="SAC045" /> calls for the community to develop principles for "prohibiting the delegation of strings in addition to those already identified in <xref target="RFC2606" />." As the first step in that process, based on the data reported by <xref target="SAC045" />, this document adds to the list of names that may not be used for top-level domains the following labels:</t>
<t><list style="symbols">
<t>home</t>
<t>corp</t>
</list></t>
<t>These two top-level domain labels are to be added to the "Special-Use Domain Names" registry created by <xref target="RFC6761" />, as described in the IANA Considerations section of this document.</t>
<t>In addition, <xref target="SAC062" /> describes the risks associated with delegating a name in the root of the public DNS that is also used in privately defined namespaces (in which it is also syntactically valid). Users, software, or other functions in the private domain may confuse the private and public instances of the same name. This risk, referred to as "name collision," results in potential harm to enterprise networks that use previously undelegated names at the root of a private namespace when the name is delegated in the public root.</t>
<t>Research conducted by Interisle Consulting Group <xref target="INTERISLE" /> indicates that another name, in addition to those identified by <xref target="SAC045" />, presents a particularly high risk of name collision. This document therefore also adds the following string to the "Special-Use Domain Names" registry:</t>
<t><list style="symbols">
<t>mail</t>
</list></t>
<t>Further resesarch, conducted by JAS Advisors on behalf of ICANN <xref target="JAS_MITIGATION" /> shows that the names .corp, .home and .mail are clear and significant risks for name collision. In that report the following recommendation is made: "The TLDs .corp, .home, and .mail be permanently reserved for internal use and receive RFC 1918-like protection/treatment, potentially via RFC 6761."</t>
<t>The three names that are reserved by this document are those on which all three studies (by SSAC, Interisle and JAS Advisors) agree.</t>
</section>
<section title="Security Considerations" anchor="securcon">
<t>The name reservations specified in this document are intended to reduce the risk of harmful collision between names that are in well-established common use as TLDs in private namespaces and syntactically identical names that could otherwise be delegated as TLDs in the global DNS.</t>
<t>The security concerns associated with name collision are well presented in <xref target="SAC045" />, <xref target="SAC062" />, the Interisle report <xref target="INTERISLE" />, and the ICANN report "Name Collision Identification and Mitigation for IT Professionals" <xref target="ICANN_MITIGATION" />.</t>
</section>
<section title="IANA Considerations" anchor="ianacons">
<t>This document specifies three new labels to be added to the "Special-Use Domain Names" registry maintained by IANA pursuant to <xref target="RFC6761" />. The labels are to be added to the registry in the following way:</t>
<figure align="center" anchor="iana_list">
<preamble></preamble>
<artwork align="left"><![CDATA[
Name Reference
----------------+---------------
home [ RFC-to-be ]
corp [ RFC-to-be ]
mail [ RFC-to-be ]
]]></artwork>
</figure>
<section title="Domain Name Reservation Considerations for home">
<section title="Users">
<t>Are human users expected to recognize these names as special and use them differently? In what way?</t>
<t>The reservations provided in this document are intended to reduce spurious queries at the root of the DNS and avoid potential collisions between resolutions of names in private name spaces and the public DNS. Users do not have to know that these names are special.</t>
</section>
<section title="Application Software">
<t>Are writers of application software expected to make their software recognize these names as special and treat them differently? In what way? (For example, if a human user enters such a name, should the application software reject it with an error message?)</t>
<t>These names are being added to the Special-Use Domain Name registry, in part, because some application software implementations have long used these names for special purposes in private networks. Developers of new applications do not need to filter or test for the names. Instead, the intent is to reserve the names for local use and avoid unnecessary queries in the public DNS.</t>
</section>
<section title="Name Resolution APSs and Libraries">
<t>Are writers of name resolution APIs and libraries expected to make their software recognize these names as special and treat them differently? If so, how?</t>
<t>Authors of name resolution APIs and libraries SHOULD restrict these names to local resolution and SHOULD NOT allow queries for strings that use these Special-Use Domain Names to be forwarded to the public DNS for resolution.</t>
</section>
<section title="Caching DNS Servers">
<t>Are developers of caching domain name servers expected to make their implementations recognize these names as special and treat them differently? If so, how?</t>
<t>Authors of caching domain name server software SHOULD restrict these names to local resolution and SHOULD NOT allow queries for strings that use these Special-Use Domain Names to be forwarded to the public DNS for resolution.</t>
</section>
<section title="Authoritative DNS Servers">
<t>Are developers of authoritative domain name servers expected to make their implementations recognize these names as special and treat them differently? If so, how?</t>
<t>Authors of authoritative domain name server software SHOULD restrict these names to local resolution and SHOULD NOT allow queries for strings that use these Special-Use Domain Names to be forwarded to the public DNS for resolution.</t>
</section>
<section title="DNS Server Operators">
<t>Does this reserved Special-Use Domain Name have any potential impact on DNS server operators? If they try to configure their authoritative DNS server as authoritative for this reserved name, will compliant name server software reject it as invalid? Do DNS server operators need to know about that and understand why? Even if the name server software doesn't prevent them from using this reserved name, are there other ways that it may not work as expected, of which the DNS server operator should be aware?</t>
<t>The intent of the reservations in this IANA Considerations section is to prevent spurious and potentially problematic queries from appearing in the public DNS. DNS server operators SHOULD always treat strings with the Special-Use Domain Names in section 5 as names for local resolution.</t>
<t>Since these strings are intended to have local use, it is quite possible that DNS operators would configure an authoritative DNS server as authoritative for these reserved names in a private network. This would be consistent with the goal of having these names resolved locally rather than on the public Internet. Compliant name server software MUST NOT reject these names as invalid. Instead, name server software SHOULD allow for local resolution of the name and SHOULD NOT transmit a query for resolution into the public DNS.</t>
</section>
<section title="DNS Registries/Registrars">
<t>How should DNS Registries/Registrars treat requests to register this reserved domain name? Should such requests be denied? Should such requests be allowed, but only to a specially-designated entity? (For example, the name "www.example.org" is reserved for documentation examples and is not available for registration; however, the name is in fact registered; and there is even a web site at that name, which states circularly that the name is reserved for use in documentation and cannot be registered!)</t>
<t>Requests to register any names added to the Special-Use Domain Name registry as part of the IANA Considerations section of this document MUST be denied.</t>
</section>
</section>
<section title="Domain Name Reservation Considerations for corp">
<section title="Users">
<t>Are human users expected to recognize these names as special and use them differently? In what way?</t>
<t>The reservations provided in this document are intended to reduce spurious queries at the root of the DNS and avoid potential collisions between resolutions of names in private name spaces and the public DNS. Users do not have to know that these names are special.</t>
</section>
<section title="Application Software">
<t>Are writers of application software expected to make their software recognize these names as special and treat them differently? In what way? (For example, if a human user enters such a name, should the application software reject it with an error message?)</t>
<t>These names are being added to the Special-Use Domain Name registry, in part, because some application software implementations have long used these names for special purposes in private networks. Developers of new applications do not need to filter or test for the names. Instead, the intent is to reserve the names for local use and avoid unnecessary queries in the public DNS.</t>
</section>
<section title="Name Resolution APSs and Libraries">
<t>Are writers of name resolution APIs and libraries expected to make their software recognize these names as special and treat them differently? If so, how?</t>
<t>Authors of name resolution APIs and libraries SHOULD restrict these names to local resolution and SHOULD NOT allow queries for strings that use these Special-Use Domain Names to be forwarded to the public DNS for resolution.</t>
</section>
<section title="Caching DNS Servers">
<t>Are developers of caching domain name servers expected to make their implementations recognize these names as special and treat them differently? If so, how?</t>
<t>Authors of caching domain name server software SHOULD restrict these names to local resolution and SHOULD NOT allow queries for strings that use these Special-Use Domain Names to be forwarded to the public DNS for resolution.</t>
</section>
<section title="Authoritative DNS Servers">
<t>Are developers of authoritative domain name servers expected to make their implementations recognize these names as special and treat them differently? If so, how?</t>
<t>Authors of authoritative domain name server software SHOULD restrict these names to local resolution and SHOULD NOT allow queries for strings that use these Special-Use Domain Names to be forwarded to the public DNS for resolution.</t>
</section>
<section title="DNS Server Operators">
<t>Does this reserved Special-Use Domain Name have any potential impact on DNS server operators? If they try to configure their authoritative DNS server as authoritative for this reserved name, will compliant name server software reject it as invalid? Do DNS server operators need to know about that and understand why? Even if the name server software doesn't prevent them from using this reserved name, are there other ways that it may not work as expected, of which the DNS server operator should be aware?</t>
<t>The intent of the reservations in this IANA Considerations section is to prevent spurious and potentially problematic queries from appearing in the public DNS. DNS server operators SHOULD always treat strings with the Special-Use Domain Names in section 5 as names for local resolution.</t>
<t>Since these strings are intended to have local use, it is quite possible that DNS operators would configure an authoritative DNS server as authoritative for these reserved names in a private network. This would be consistent with the goal of having these names resolved locally rather than on the public Internet. Compliant name server software MUST NOT reject these names as invalid. Instead, name server software SHOULD allow for local resolution of the name and SHOULD NOT transmit a query for resolution into the public DNS.</t>
</section>
<section title="DNS Registries/Registrars">
<t>How should DNS Registries/Registrars treat requests to register this reserved domain name? Should such requests be denied? Should such requests be allowed, but only to a specially-designated entity? (For example, the name "www.example.org" is reserved for documentation examples and is not available for registration; however, the name is in fact registered; and there is even a web site at that name, which states circularly that the name is reserved for use in documentation and cannot be registered!)</t>
<t>Requests to register any names added to the Special-Use Domain Name registry as part of the IANA Considerations section of this document MUST be denied.</t>
</section>
</section>
<section title="Domain Name Reservation Considerations for mail">
<section title="Users">
<t>Are human users expected to recognize these names as special and use them differently? In what way?</t>
<t>The reservations provided in this document are intended to reduce spurious queries at the root of the DNS and avoid potential collisions between resolutions of names in private name spaces and the public DNS. Users do not have to know that these names are special.</t>
</section>
<section title="Application Software">
<t>Are writers of application software expected to make their software recognize these names as special and treat them differently? In what way? (For example, if a human user enters such a name, should the application software reject it with an error message?)</t>
<t>These names are being added to the Special-Use Domain Name registry, in part, because some application software implementations have long used these names for special purposes in private networks. Developers of new applications do not need to filter or test for the names. Instead, the intent is to reserve the names for local use and avoid unnecessary queries in the public DNS.</t>
</section>
<section title="Name Resolution APSs and Libraries">
<t>Are writers of name resolution APIs and libraries expected to make their software recognize these names as special and treat them differently? If so, how?</t>
<t>Authors of name resolution APIs and libraries SHOULD restrict these names to local resolution and SHOULD NOT allow queries for strings that use these Special-Use Domain Names to be forwarded to the public DNS for resolution.</t>
</section>
<section title="Caching DNS Servers">
<t>Are developers of caching domain name servers expected to make their implementations recognize these names as special and treat them differently? If so, how?</t>
<t>Authors of caching domain name server software SHOULD restrict these names to local resolution and SHOULD NOT allow queries for strings that use these Special-Use Domain Names to be forwarded to the public DNS for resolution.</t>
</section>
<section title="Authoritative DNS Servers">
<t>Are developers of authoritative domain name servers expected to make their implementations recognize these names as special and treat them differently? If so, how?</t>
<t>Authors of authoritative domain name server software SHOULD restrict these names to local resolution and SHOULD NOT allow queries for strings that use these Special-Use Domain Names to be forwarded to the public DNS for resolution.</t>
</section>
<section title="DNS Server Operators">
<t>Does this reserved Special-Use Domain Name have any potential impact on DNS server operators? If they try to configure their authoritative DNS server as authoritative for this reserved name, will compliant name server software reject it as invalid? Do DNS server operators need to know about that and understand why? Even if the name server software doesn't prevent them from using this reserved name, are there other ways that it may not work as expected, of which the DNS server operator should be aware?</t>
<t>The intent of the reservations in this IANA Considerations section is to prevent spurious and potentially problematic queries from appearing in the public DNS. DNS server operators SHOULD always treat strings with the Special-Use Domain Names in section 5 as names for local resolution.</t>
<t>Since these strings are intended to have local use, it is quite possible that DNS operators would configure an authoritative DNS server as authoritative for these reserved names in a private network. This would be consistent with the goal of having these names resolved locally rather than on the public Internet. Compliant name server software MUST NOT reject these names as invalid. Instead, name server software SHOULD allow for local resolution of the name and SHOULD NOT transmit a query for resolution into the public DNS.</t>
</section>
<section title="DNS Registries/Registrars">
<t>How should DNS Registries/Registrars treat requests to register this reserved domain name? Should such requests be denied? Should such requests be allowed, but only to a specially-designated entity? (For example, the name "www.example.org" is reserved for documentation examples and is not available for registration; however, the name is in fact registered; and there is even a web site at that name, which states circularly that the name is reserved for use in documentation and cannot be registered!)</t>
<t>Requests to register any names added to the Special-Use Domain Name registry as part of the IANA Considerations section of this document MUST be denied.</t>
</section>
</section>
</section>
<section title="References" anchor="refs">
</section>
<section title="Acknowledgments" anchor="acks">
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC1034;
&RFC1035;
&RFC1591;
&RFC2119;
&RFC2606;
&RFC6761;
</references>
<references title="Informative References">
<reference anchor="SAC045" target="http://www.icann.org/en/committees/security/sac045.pdf">
<front>
<title>Invalid Top Level Domain Queries at the Root Level of the Domain Name System</title>
<author>
<organization abbrev="SSAC">ICANN Security and Stability Advisory Committee</organization>
</author>
<date year="2010" month="December" />
</front>
</reference>
<reference anchor="SAC062" target="http://www.icann.org/en/groups/ssac/documents/sac-062-en.pdf">
<front>
<title>SSAC Advisory Concerning the Mitigation of Name Collision Risk</title>
<author>
<organization abbrev="SSAC">ICANN Security and Stability Advisory Committee</organization>
</author>
<date year="2013" month="November" />
</front>
</reference>
<reference anchor="RSSAC_DNS" target="http://www.caida.org/publications/presentations/2009/rssac_dns/rssac_dns.pdf">
<front>
<title>DNS Research Update from CAIDA Status and Recent Experiences</title>
<author initials="kc" surname="claffy" fullname="kc claffy">
<organization>CAIDA</organization>
</author>
<date year="2009" month="March" />
</front>
</reference>
<reference anchor="INTERISLE" target="http://www.icann.org/en/about/staff/security/ssr/name-collision-02aug13-en.pdf">
<front>
<title>Name Collision in the DNS</title>
<author initials="L" surname="Chapin" fullname="Lyman Chapin">
<organization>Interisle Consulting Group</organization>
</author>
<date year="2013" month="August" />
</front>
</reference>
<reference anchor="ICANN_MITIGATION" target="http://www.icann.org/en/about/staff/security/ssr/name-collision-mitigation-05dec13-en.pdf">
<front>
<title>Guide to Name Collision Identification and Mitigation for IT Professionals</title>
<author>
<organization abbrev="ICANN">Internet Corporation for Assigned Names and Numbers</organization>
</author>
<date year="2013" month="August" />
</front>
</reference>
<reference anchor="JAS_MITIGATION" target="https://www.icann.org/en/about/staff/security/ssr/name-collision-mitigation-26feb14-en.pdf">
<front>
<title>Mitigating the Risk of DNS Namespace Collisions</title>
<author>
<organization abbrev="ICANN">Internet Corporation for Assigned Names and Numbers</organization>
</author>
<date year="2014" month="February" />
</front>
</reference>
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-24 07:01:36 |