One document matched: draft-howard-isp-ip6rdns-02.xml
<?xml version="1.0" encoding="us-ascii"?>
<!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 RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.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' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="3"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<rfc category="info" docName="draft-howard-isp-ip6rdns-02" ipr="pre5378Trust200902"
obsoletes="" submissionType="IETF" updates="" xml:lang="en">
<!-- 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>
<title abbrev="Reverse DNS in IPv6 for ISPs">Reverse DNS in IPv6 for
Internet Service Providers</title>
<author fullname="Lee Howard" initials="L" role="" surname="Howard">
<organization>Time Warner Cable</organization>
<address>
<postal>
<street>13820 Sunrise Valley Drive</street>
<!-- Reorder these if your country does things differently -->
<city>Herndon</city>
<region>VA</region>
<code>20171</code>
<country>US</country>
</postal>
<email>lee.howard@twcable.com</email>
</address>
</author>
<author fullname="Alain Durand" initials="A" surname="Durand">
<organization>Comcast</organization>
<address>
<postal>
<street>1 Comcast center</street>
<city>Philadelphia</city>
<region>PA</region>
<code>19103</code>
<country>US</country>
</postal>
<phone></phone>
<email>alain_durand@cable.comcast.com</email>
</address>
</author>
<date month="March" year="2010" />
<!-- Meta-data Declarations -->
<area>Operations and Management</area>
<workgroup>Internet Engineering Task Force</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>ipv6 rdns</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>In IPv4, Internet Service Providers (ISPs) commonly provide
IN-ADDR.ARPA. information for their customers by prepopulating the zone
with one PTR record for every available address. This practice does not
scale in IPv6. This document analyzes different approaches for ISPs to
manage the ip6.arpa zone for IPv6 address space assigned to many
customers.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction" toc="default">
<t>Best practice <xref format="default" pageno="false"
target="RFC1033"></xref> is that "Every Internet-reachable host should
have a name" <xref format="default" pageno="false"
target="RFC1912"></xref> that is recorded with a PTR resource record in
the IN-ADDR.ARPA zone. Many network services perform a PTR lookup on the
source address of incoming packets before performing services.</t>
<t>Some of the most common uses for reverse DNS include:</t>
<t><list style="symbols">
<t>Building trust. An administrator who spends time and effort
properly maintaining DNS records might be assumed to spend time and
effort on other maintenance, so the network might be more
trustworthy.</t>
<t>Validating other data. Information from reverse DNS may be
compared to information higher in the stack (for instance, mail
originator), with a lower trustworthiness if they are
dissimilar.</t>
<t>Some degree of location information can often be inferred, since
most administrators create reverse zones corresponding to
aggregation points, which often correspond with geographical areas.
This information is useful for geolocation services and for law
enforacement.</t>
</list></t>
<t>Individual Internet users in the residential or consumer scale,
including small and home businesses, are constantly joining or moving on
the Internet. For large Internet service providers who serve residential
users, maintenance of individual PTR records for is often impractical.
Administrators of ISPs should evaluate methods for responding to reverse
DNS queries in IPv6.</t>
<section title="Reverse DNS in IPv4" toc="default">
<t>Internet service providers (ISPs) that provide access to many
residential users typically assign one or a few IPv4 addresses to each
of those users, and populate an IN-ADDR.ARPA zone with one PTR record
for every IPv4 address. Some ISPs also configure forward zones with
matching A records, so that lookups match. For instance, if an ISP
Example.com aggregated 192.0.2.0/24 at a network hub in Anytown in the
province of AnyWhere, the reverse zone might look like:</t>
<t><list hangIndent="6" style="hanging">
<t>1.2.0.192.IN-ADDR-ARPA. IN PTR
1.user.anytown.AW.example.com.</t>
<t>2.2.0.192.IN-ADDR-ARPA. IN PTR
2.user.anytown.AW.example.com.</t>
<t>3.2.0.192.IN-ADDR-ARPA. IN PTR
3.user.anytown.AW.example.com.</t>
<t>.</t>
<t>.</t>
<t>.</t>
<t>254.2.0.192.IN-ADDR-ARPA. IN PTR
254.user.anytown.AW.example.com.</t>
</list></t>
<t>The conscientious Example.com might then also have a zone:<list
hangIndent="6" style="hanging">
<t>1.user.anytown.AW.example.com. IN A 1.2.0.192.IN-ADDR-ARPA.</t>
<t>2.user.anytown.AW.example.com. IN A 2.2.0.192.IN-ADDR-ARPA.</t>
<t>3.user.anytown.AW.example.com. IN A 3.2.0.192.IN-ADDR-ARPA.</t>
<t>.</t>
<t>.</t>
<t>.</t>
<t>254.user.anytown.AW.example.com. IN A
254.2.0.192.IN-ADDR-ARPA.</t>
</list></t>
<t>Many ISPs generate PTR records for all IP addresses used for
customers, and many create the matching A record.</t>
</section>
<section title="Reverse DNS Considerations in IPv6" toc="default">
<t>The length of individual addresses makes manual zone entries
cumbersome. A sample entry for 2001:db8:f00::0012:34ff:fe56:789a might
be:</t>
<t><list hangIndent="6" style="hanging">
<t>a.9.8.7.6.5.e.f.f.f.4.3.2.1.0.0.0.0.0.0.0.0.f.0.8.b.d.0.1.0.0.2.IP6.ARPA.
IN PTR 1.user.anytown.AW.example.com.</t>
</list></t>
<t>Since 2^^96 possible addresses could be configured in the
2001:db8:f00/48 zone alone, it is impractical to write a zone with
every possible address entered. If 1000 entries could be written per
second, the zone would still not be complete after two quintillion
years.</t>
<t>Furthermore, since the 64 bits in the host portion of the address
are frequently assigned using SLAAC <xref format="default"
pageno="false" target="RFC4826"></xref> when the host comes online, it
is not possible to know which addresses may be in use ahead of
time.</t>
<t><xref format="default" pageno="false" target="RFC1912"></xref> is
an informational document that says "PTR records must point back to a
valid A record" and further that the administrator should "Make sure
your PTR and A records match." <xref format="default" pageno="false"
target="RFC1912"></xref> DNS administrators of residential ISPs should
consider how to follow this advice for AAAA and PTR RRs in the
residential ISP.</t>
</section>
</section>
<section title="Alternatives in IPv6" toc="default">
<t>Several options existing for providing reverse DNS in IPv6. All of
these options also exist for IPv4, but the scaling problem is much less
severe in IPv4. Each option should be evaluated for its scaling ability,
its compliance with existing standards and best practices, and its
availability in common systems.</t>
<section title="No Response" toc="default">
<t>Some ISP DNS administrators may choose to provide only a NXDOMAIN
response to PTR queries for subscriber addresses. Providing no data in
response to PTR queries does not satisfy the expectation in <xref
format="default" pageno="false" target="RFC1912"></xref> for entries
to match. Users of services which are dependent on a successful lookup
will have a poor experience. DNS administrators should consider the
uses described above and the number of services affecting the number
of users when evaluating this option.</t>
</section>
<section title="Wildcard match" toc="default">
<t>The use of wildcards in the DNS is described in <xref
format="default" pageno="false" target="RFC4592"></xref>, and their
use in IPv6 reverse DNS is described in <xref format="default"
pageno="false" target="RFC4472"></xref>. Use of a wildcard may lead to
unpredictable results if other records exist in the zone.
Administrators considering use of wildcards for PTR records in IPv6
should determine whether the wildcard will match all records and
subdomains of the zone.</t>
<t>Consider a PTR lookup on 2001:db8:f00:1234:0012:34ff:fe56:789a
against the following entries:</t>
<t><list hangIndent="6">
<t>*.4.3.2.1.0.0.f.0.8.b.d.f.0.1.0.0.2.ip6.arpa. IN PTR
1.user.anytown.AW.example.com.</t>
<t>a.9.8.7.6.5.e.f.f.f.4.3.2.1.0.0.4.3.2.1.0.0.f.0.8.b.d.0.1.0.0.2.ip6.arpa.
IN PTR mail.user.anytown.AW.example.com.</t>
<t>2.1.0.0.4.3.2.1.0.0.f.0.8.b.d.0.1.0.0.2.ip6.arpa. IN NS
ns.user.anytown.AW.example.com.</t>
</list></t>
<t>The administrator should determine what response would be returned
for such a query. While recording all possible addresses is not
scalable, it may be possible to record a wildcard entry for each
prefix assigned to a customer. Consider also that "inclusion of
wildcard NS RRSets in a zone is discouraged, but not barred." <xref
format="default" pageno="false" target="RFC4035"></xref></t>
<t>This solution generally scales well. However, since the response
will match any address in the wildcard range (/48, /56, /64, etc.), a
forward DNS lookup on that response given will not be able to return
the same hostname. This method therefore fails the expectation in
<xref format="default" pageno="false" target="RFC1912"></xref> for
forward and reverse to match. DNSsec <xref format="default"
pageno="false" target="RFC4035"></xref> scalability is limited to
signing the wildcard zone, which may be satisfactory.</t>
</section>
<section title="Dynamic DNS" toc="default">
<t>One way to ensure forward and reverse records match is for hosts to
update DNS servers dynamically, once interface configuration (whether
SLAAC, DHCPv6, or other means) is complete, as described in <xref
format="default" pageno="false" target="RFC4472"></xref>. Hosts would
need to provide both AAAA and PTR updates, and would need to know
which servers would accept the information.</t>
<t>This option should scale as well or as poorly as IPv4 dynamic DNS
does. Dynamic DNS may not scale effectively in large ISP networks
which have no single master name server. The ISP's DNS system may
provide a point for Denial of Service attacks, including many
attempted dDNS updates. Accepting updates only from authenticated
sources may mitigate this risk, but only if authentication itself does
not require excessive overhead. No authentication of dynamic DNS
updates is inherently provided; implementers should consider use of
DNSsec <xref format="default" pageno="false" target="RFC2535"></xref>,
or at least ingress filtering so updates are only accepted from
customer address space from internal network interfaces. UDP is
allowed per <xref format="default" pageno="false"
target="RFC2136"></xref> so transmission control is not assured,
though the host should expect an ERROR or NOERROR message from the
server <xref format="default" pageno="false" target="RFC2136"></xref>;
TCP provides transmission control, but the updating host would need to
be configured to use TCP.</t>
<t>Administrators should consider what domain will contain the
records, and who will provide the names. If subscribers provide
hostnames, they may provide inappropriate strings. Consider
"ihate.example.com" or "badword.customer.example.com" or
"celebrityname.committed.illegal.acts.example.com."</t>
<section title="Dynamic DNS from Individual Hosts" toc="default">
<t>In the simplest case, a residential user will have a single host
connected to the ISP. Since the typical residential user cannot
configure IPv6 addresses and resolving name servers on their hosts,
the ISP should provide address information conventionally (i.e.,
their normal combination of RAs, SLAAC, DHCP, etc.), and should
provide a DNS Recursive Name Server and Domain Search List via
DHCPv6 as described in <xref format="default" pageno="false"
target="RFC3646"></xref>. In determining its Fully Qualified Domain
Name, hosts typically use a domain from the Domain Search List. This
is an overloading of the parameter; multiple domains could be
listed, since hosts may need to search for unqualified names in
multiple domains, without necessarily being a member of those
domains. Administrators should consider whether the domain search
list actually provides an appropriate DNS suffix(es) when
considering use of this option. For purposes of dynamic DNS, the
host would concatenate its local hostname (e.g., "hostname") plus
the domain(s) in the Domain Search List (e.g.,
"customer.example.com"), as in "hostname.customer.example.com."</t>
<t>Once it learns its address, and has a resolving name server, the
host must perform an SOA lookup on the ip6.arpa record to be added,
to find the owner, which will lead to the NS record. Several
recursive lookups may be required to find the longest prefix which
has been delegated. The DNS administrator must designate the Primary
Master Server for the longest match required. Once found, the host
sends dynamic AAAA and PTR updates using the concatenation defined
above ("hostname.customer.example.com").</t>
<t>In order to use this alternative, hosts must be configured to use
dynamic DNS. This is not default behavior for many hosts, which is
an inhibitor for the large ISP.</t>
</section>
<section title="Dynamic DNS through Residential Gateways"
toc="default">
<t>Residential customers may have a gateway, which may provide
DHCPv6 service to hosts from a delegated prefix. ISPs should provide
a DNS Recursive Name Server and Domain Search List to the gateway,
as described above and in <xref format="default" pageno="false"
target="RFC3646"></xref>. There are two options for how the gateway
uses this information. The first option is for the gateway to
respond to DHCPv6 requests with the same DNS Recursive Name Server
and Domain Search List provided by the ISP. The alternate option is
for the gateway to relay dynamic DNS updates from hosts to the
servers and domain provided by the ISP. Host behavior is unchanged;
they should provide updates to the ISP's servers as described
above.</t>
</section>
<section anchor="dDNSdelg" title="Dynamic DNS Delegations"
toc="default">
<t>An ISP may delegate authority for a subdomain such as
"customer12345.anytown.AW.customer.example.com" or
"customer12345.example.com" to the customer's gateway. Each domain
thus delegated must be unique within the DNS. The ISP may also then
delegate the ip6.arpa zone for the prefix delegated to the customer,
as in (for 2001:db8:f00::/48) "0.0.f.0.8.b.d.0.1.0.0.2.ip6.arpa."
Then the customer could provide updates to their own gateway, with
forward and reverse. However, individual hosts connected directly to
the ISP rarely have the capability to run DNS for themselves;
therefore, an ISP can only delegate to customers with gateways
capable of being authoritative name servers. If a device requests a
DHCPv6 Prefix Delegation, that may be considered a reasonably
reliable indicator that it is a gateway, rather than an individual
host. It is not necessarily an indicator that the gateway is capable
of providing DNS services, and therefore cannot be relied upon as a
way to test whether this option is feasible.</t>
<t>If the customer's gateway is the name server, it provides its own
information to hosts on the network, as normally done for enterprise
networks, and as described in <xref format="default" pageno="false"
target="RFC2136"></xref>.</t>
<t>An ISP may elect to provide authoritative responses as a
secondary server to the customer's primary server.</t>
<t>To implement this alternative, users' residential gateways must
be capable of acting as authoritative name servers capable of
dynamic DNS updates.</t>
</section>
<section title="Generate Dynamic Records " toc="default">
<t>An ISP's name server that receives a dynamic forward or reverse
DNS update may create a matching entry. Since a host capable of
updating one is generally capable of updating the other, this should
not be required, but redundant record creation will ensure a record
exists. ISPs implementing this method should check whether a record
already exists before accepting or creating updates.</t>
<t>This method is also dependent on hosts being capable of providing
dynamic DNS updates, which is not default behavior for many
hosts.</t>
</section>
<section title="Populate from DHCP Server" toc="default">
<t>A ISP's DHCPv6 server may populate the forward and reverse zones
when the DHCP request is received, if the request contains enough
information.<xref format="default" pageno="false"
target="RFC4702"></xref></t>
<t>However, this method will only work for a single host address;
the ISP's DHCP server would not have enough information to update
all records for a prefix delegation. If the zone authority is
delegated to a home gateway which used this method, the gateway
could update records for residential hosts. To implement this
alternative, users' residential gateways must support the FQDN DHCP
option. </t>
</section>
</section>
<section title="Delegate DNS " toc="default">
<t>For customers who are able to run their own DNS servers, such as
commercial customers, often the best option is to delegate the reverse
DNS zone to them, as described in <xref format="default"
pageno="false" target="RFC2317"></xref>. However, since most
residential users have neither the equipment nor the expertise to run
DNS servers, this method is unavailable to residential ISPs.</t>
<t>This is a general case of the specific case described in <xref
format="default" pageno="false" target="dDNSdelg"></xref>. All of the
same considerations still apply.</t>
</section>
<section title="Dynamically Generate PTR When Queried ("On the Fly")"
toc="default">
<t>Common practice in IPv4 is to provide PTR records for all
addresses, regardless of whether a host is actually using the address.
In IPv6, ISPs may generate PTR records for all IPv6 addresses as the
records are requested. Configuring records "on the fly" may consume
more processor resource than other methods, but only on demand. A
denial of service is therefore possible, but with rate-limiting and
normal countermeasures, this risk is no higher than with other
options.</t>
<t>An ISP using this option should generate a PTR record on demand,
and cache or prepopulate the forward (AAAA) entry for the duration of
the time-to-live of the PTR. This option has the advantage of assuring
matching forward and reverse entries, while being simpler than dynamic
DNS. Administrators should consider whether the lack of user-specified
hostnames is a drawback.</t>
<t>This method may not scale well in conjunction with DNSsec <xref
format="default" pageno="false" target="RFC4035"></xref>, because of
the additional load, but since keys may be pregenerated for zones, and
not for each record, the risk is moderate.</t>
<t>Another consideration is that the algorithm used for generating the
record must be the same on all servers for a zone. In other words, any
server for the zone must produce the same response for a given query.
Administrators managing a variety of rules within a zone might find it
difficult to keep those rules synchronized on all servers.</t>
</section>
</section>
<section title="Security Considerations" toc="default">
<section title="Using Reverse DNS for Security" toc="default">
<t>Some people think the existence of reverse DNS records, or matching
forward and reverse DNS records, provides useful information about the
hosts with those records. For example, one might infer that the
administrator of a network with properly configured DNS records was
better-informed, and by further inference more responsible, than the
administrator of a less-thoroughly configured network. For instance,
most email providers will not accept incoming connections on port 25
unless forward and reverse DNS entries match. If they match, but
information higher in the stack (for instance, mail source) is
inconsistent, the packet is questionable. These records may be easily
forged though, unless DNSsec or other measures are taken. The string
of inferences is questionable, and may become unneeded if other means
for evaluating trustworthiness (such as positive reputations) become
predominant in IPv6.</t>
<t>Providing location information in PTR records is useful for
troubleshooting, law enforcement, and geolocation services, but for
the same reasons can be considered sensitive information.</t>
</section>
<section title="DNS Security with Dynamic DNS" toc="default">
<t>Security considerations of using dynamic DNS are described in <xref
format="default" pageno="false" target="RFC3007"></xref>. DNS Security
Extensions are documented in<xref format="default" pageno="false"
target="RFC2535">RFC2535</xref>.</t>
<t>Interactions with DNSsec are described throughout this
document.</t>
</section>
<section title="Considerations for Other Uses of the DNS" toc="default">
<t>Several methods exist for providing encryption keys in the DNS. Any
of the options presented here may interfere with these key
techniques.</t>
</section>
</section>
<section title="IANA Considerations" toc="default">
<t>There are no IANA considerations or implications that arise from this
document.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<references title="Normative References">
<reference anchor="RFC883" target="http://tools.ietf.org/html/rfc883">
<front>
<title>Domain names: Implementation specification</title>
<author initials="P" surname="Mockapetris">
<organization></organization>
</author>
<date month="November" year="1983" />
</front>
<format target="http://tools.ietf.org/html/rfc883" type="HTML" />
</reference>
<reference anchor="RFC1033">
<front>
<title>Domain Administrators Operators Guide</title>
<author initials="M." surname="Lottor">
<organization></organization>
</author>
<date month="November" year="1987" />
</front>
<format target="http://tools.ietf.org/html/rfc1033" type="HTML" />
</reference>
<reference anchor="RFC1034">
<front>
<title>Domain Names - Concepts and Facilities</title>
<author initials="P" surname="Mockapetris">
<organization></organization>
</author>
<date month="November" year="1987" />
</front>
<format target="http://tools.ietf.org/html/rfc1034" type="HTML" />
</reference>
<reference anchor="RFC1912">
<front>
<title>Common DNS Operational and Configuration Errors</title>
<author initials="D" surname="Barr">
<organization></organization>
</author>
<date month="February" year="1996" />
</front>
<format target="http://tools.ietf.org/html/rfc1912" type="HTML" />
</reference>
<reference anchor="RFC2136">
<front>
<title>Dynamic Updates in the Domain Name System (DNS
UPDATE)</title>
<author initials="P" role="editor" surname="Vixie">
<organization></organization>
</author>
<author initials="S" surname="Thomson">
<organization></organization>
</author>
<author initials="Y" surname="Rekhter">
<organization></organization>
</author>
<author initials="J" surname="Bound">
<organization></organization>
</author>
<date month="April" year="1917" />
</front>
<format target="http://tools.ietf.org/html/rfc2136" type="HTML" />
</reference>
<reference anchor="RFC3007">
<front>
<title>Secure Domain Name System (DNS) Dynamic Update</title>
<author initials="B" surname="Wellington">
<organization></organization>
</author>
<date month="November" year="2000" />
</front>
<format target="http://tools.ietf.org/html/rfc3007" type="HTML" />
</reference>
<reference anchor="RFC3646">
<front>
<title>DNS Configuration options for Dynamic Host Configuration
Protocol for IPv6 (DHCPv6)</title>
<author initials="R" role="editor" surname="Droms">
<organization></organization>
</author>
<date month="December" year="2003" />
</front>
<format target="http://tools.ietf.org/html/rfc3646" type="HTML" />
</reference>
<reference anchor="RFC4035">
<front>
<title>Protocol Modifications for the DNS Security
Extensions</title>
<author initials="R" surname="Arends">
<organization></organization>
</author>
<author initials="R" surname="Austein">
<organization></organization>
</author>
<author initials="M." surname="Larson">
<organization></organization>
</author>
<author initials="D." surname="Massey">
<organization></organization>
</author>
<author initials="S." surname="Rose">
<organization></organization>
</author>
<date month="March" year="2005" />
</front>
<format target="http://tools.ietf.org/html/rfc4035" type="HTML" />
</reference>
<reference anchor="RFC4592">
<front>
<title>The Role of Wildcards in the Domain Name System</title>
<author initials="E" surname="Lewis">
<organization></organization>
</author>
<date month="July" year="2006" />
</front>
<format target="http://tools.ietf.org/html/rfc4592" type="HTML" />
</reference>
<reference anchor="RFC4702">
<front>
<title>The Dynamic Host Configuration Protocol (DHCP) Client Fully
Qualified Domain Name (FQDN) Option</title>
<author fullname="" initials="M" surname="Stapp">
<organization></organization>
</author>
<author fullname="" initials="Y" surname="Volz">
<organization></organization>
</author>
<author fullname="" initials="Y" surname="Rekhter">
<organization></organization>
</author>
<date />
</front>
</reference>
<reference anchor="RFC4826">
<front>
<title>IPv6 Stateless Address Autoconfiguration</title>
<author initials="S" surname="Thomson">
<organization></organization>
</author>
<author initials="T" surname="Narten">
<organization></organization>
</author>
<author initials="T" surname="Jinmei">
<organization></organization>
</author>
<date month="September" year="2007" />
</front>
<format target="http://tools.ietf.org/html/rfc4826" type="HTML" />
</reference>
</references>
<references title="Informative References">
<reference anchor="RFC2317">
<front>
<title>Classless IN-ADDR.ARPA delegation</title>
<author initials="H." surname="Eidnes">
<organization></organization>
</author>
<author initials="G." surname="de Groot">
<organization></organization>
</author>
<author initials="P." surname="Vixie">
<organization></organization>
</author>
<date month="March" year="1998" />
</front>
<format target="http://tools.ietf.org/html/rfc2317" type="HTML" />
</reference>
<reference anchor="RFC2535">
<front>
<title>Domain Name System Security Extensions</title>
<author initials="D." surname="Eastlake">
<organization></organization>
</author>
<date month="March" year="1999" />
</front>
<format target="http://tools.ietf.org/html/rfc2535" type="HTML" />
</reference>
<reference anchor="RFC2672">
<front>
<title>Non-Terminal DNS Name Redirection</title>
<author initials="M." surname="Crawford">
<organization></organization>
</author>
<date month="August" year="1999" />
</front>
<format target="http://tools.ietf.org/html/rfc2672" type="HTML" />
</reference>
<reference anchor="RFC4339">
<front>
<title>IPv6 Host Configuration of DNS Server Information
Approaches</title>
<author initials="J." role="editor" surname="Jeong">
<organization></organization>
</author>
<date month="February" year="2006" />
</front>
<format target="http://tools.ietf.org/html/rfc4339" type="HTML" />
</reference>
<reference anchor="RFC4472">
<front>
<title>Operational Considerations and Issues with IPv6 DNS</title>
<author initials="A." surname="Durand">
<organization></organization>
</author>
<author initials="J." surname="Ihren">
<organization></organization>
</author>
<author initials="P." surname="Savola">
<organization></organization>
</author>
<date month="April" year="2006" />
</front>
<format target="http://tools.ietf.org/html/rfc4472" type="HTML" />
</reference>
<reference anchor="rmap-consider">
<front>
<title>draft-ietf-dnsop-reverse-mapping-considerations-06</title>
<author initials="D." surname="Senie">
<organization></organization>
</author>
<author initials="A." surname="Sullivan">
<organization></organization>
</author>
<date month="March" year="2008" />
</front>
<format target="http://tools.ietf.org/html/draft-ietf-dnsop-reverse-mapping-considerations-06"
type="HTML" />
</reference>
<reference anchor="inaddr-reqd">
<front>
<title>draft-ietf-dnsop-inaddr-required-07</title>
<author initials="D." surname="Senie">
<organization></organization>
</author>
<date month="August" year="2005" />
</front>
<format target="http://tools.ietf.org/html/draft-ietf-dnsop-inaddr-required-07"
type="HTML" />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:34:50 |