draft-ietf-dnsop-isp-ip6rdns-02.txt   draft-ietf-dnsop-isp-ip6rdns-03.txt 
Network Working Group L. Howard Network Working Group L. Howard
Internet-Draft Charter Internet-Draft Retevia
Intended status: Informational July 18, 2016 Intended status: Informational March 4, 2017
Expires: January 19, 2017 Expires: September 5, 2017
Reverse DNS in IPv6 for Internet Service Providers Reverse DNS in IPv6 for Internet Service Providers
draft-ietf-dnsop-isp-ip6rdns-02 draft-ietf-dnsop-isp-ip6rdns-03
Abstract Abstract
In IPv4, Internet Service Providers (ISPs) commonly provide IN- In IPv4, Internet Service Providers (ISPs) commonly provide IN-
ADDR.ARPA information for their customers by prepopulating the zone ADDR.ARPA information for their customers by prepopulating the zone
with one PTR record for every available address. This practice does with one PTR record for every available address. This practice does
not scale in IPv6. This document analyzes different approaches and not scale in IPv6. This document analyzes different approaches and
considerations for ISPs in managing the ip6.arpa zone for IPv6 considerations for ISPs in managing the ip6.arpa zone for IPv6
address space assigned to many customers. address space assigned to many customers.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 January 19, 2017. This Internet-Draft will expire on September 5, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Reverse DNS in IPv4 . . . . . . . . . . . . . . . . . . . 3 1.1. Reverse DNS in IPv4 . . . . . . . . . . . . . . . . . . . 3
1.2. Reverse DNS Considerations in IPv6 . . . . . . . . . . . 3 1.2. Reverse DNS Considerations in IPv6 . . . . . . . . . . . 4
2. Alternatives in IPv6 . . . . . . . . . . . . . . . . . . . . 4 2. Alternatives in IPv6 . . . . . . . . . . . . . . . . . . . . 4
2.1. Negative Response . . . . . . . . . . . . . . . . . . . . 4 2.1. Negative Response . . . . . . . . . . . . . . . . . . . . 4
2.2. Wildcard match . . . . . . . . . . . . . . . . . . . . . 5 2.2. Wildcard match . . . . . . . . . . . . . . . . . . . . . 5
2.3. Dynamic DNS . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Dynamic DNS . . . . . . . . . . . . . . . . . . . . . . . 5
2.3.1. Dynamic DNS from Individual Hosts . . . . . . . . . . 6 2.3.1. Dynamic DNS from Individual Hosts . . . . . . . . . . 6
2.3.2. Dynamic DNS through Residential Gateways . . . . . . 6 2.3.2. Dynamic DNS through Residential Gateways . . . . . . 7
2.3.3. Automatic DNS Delegations . . . . . . . . . . . . . . 7 2.3.3. Automatic DNS Delegations . . . . . . . . . . . . . . 7
2.3.4. Generate Dynamic Records . . . . . . . . . . . . . . 8 2.3.4. Generate Dynamic Records . . . . . . . . . . . . . . 8
2.3.5. Populate from DHCP Server . . . . . . . . . . . . . . 8 2.3.5. Populate from DHCP Server . . . . . . . . . . . . . . 8
2.3.6. Populate from RADIUS Server . . . . . . . . . . . . . 8 2.3.6. Populate from RADIUS Server . . . . . . . . . . . . . 8
2.4. Delegate DNS . . . . . . . . . . . . . . . . . . . . . . 8 2.4. Delegate DNS . . . . . . . . . . . . . . . . . . . . . . 9
2.5. Dynamically Generate PTR When Queried ('On the Fly') . . 9 2.5. Dynamically Generate PTR When Queried ('On the Fly') . . 9
3. Considerations and Recommendations . . . . . . . . . . . . . 9 3. Manual User Updates . . . . . . . . . . . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 4. Considerations and Recommendations . . . . . . . . . . . . . 10
4.1. Using Reverse DNS for Security . . . . . . . . . . . . . 10 5. Security and Privacy Considerations . . . . . . . . . . . . . 11
4.2. DNS Security with Dynamic DNS . . . . . . . . . . . . . . 11 5.1. Using Reverse DNS for Security . . . . . . . . . . . . . 11
4.3. Considerations for Other Uses of the DNS . . . . . . . . 11 5.2. DNS Security with Dynamic DNS . . . . . . . . . . . . . . 11
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 5.3. Considerations for Other Uses of the DNS . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
Best practice is that "Every Internet-reachable host should have a [RFC1912] recommended that "every internet-reachable host should have
name" [RFC1912] that is recorded with a PTR resource record in the a name" and says "Failure to have matching PTR and A records can
.ARPA zone, and "PTR's should use official names and not aliases" cause loss of Internet services similar to not being registered in
[RFC1033]. Some network services perform a PTR lookup on the source the DNS at all." While the need for a PTR record and for it to match
address of incoming packets before performing services. is debatable as a best practice, some network services [see
Section 3] still do rely on PTR lookups, and some check the source
address of incoming connections and verify that the PTR and A records
match before providing service.
Individual Internet users in the residential or consumer scale, Individual Internet users in the residential or consumer scale,
including small and home businesses, are constantly joining or moving including small and home businesses, are constantly joining or moving
on the Internet. For large Internet service providers who serve on the Internet. For large Internet service providers who serve
residential users, maintenance of individual PTR records is residential users, maintenance of individual PTR records is
impractical. Administrators at ISPs should consider the need for PTR impractical. Administrators at ISPs should consider whether customer
records and evaluate methods for responding to reverse DNS queries in PTR records are needed, and if so, evaluate methods for responding to
IPv6. reverse DNS queries in IPv6.
1.1. Reverse DNS in IPv4 1.1. Reverse DNS in IPv4
ISPs that provide access to many residential users typically assign ISPs that provide access to many residential users typically assign
one or a few IPv4 addresses to each of those users, and populate an 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 IN-ADDR.ARPA zone with one PTR record for every IPv4 address. Some
ISPs also configure forward zones with matching A records, so that ISPs also configure forward zones with matching A records, so that
lookups match. For instance, if an ISP Example.com aggregated lookups match. For instance, if an ISP Example.com aggregated
192.0.2.0/24 at a network hub in Town in the province of AnyWhere, 192.0.2.0/24 at a network hub in Town in the province of AnyWhere,
the reverse zone might look like: the reverse zone might look like:
1.2.0.192.IN-ADDR.ARPA. IN PTR 1.user.town.AW.example.com. 1.2.0.192.IN-ADDR.ARPA. IN PTR 1.string.region.example.com.
2.2.0.192.IN-ADDR.ARPA. IN PTR 2.user.town.AW.example.com. 2.2.0.192.IN-ADDR.ARPA. IN PTR 2.string.region.example.com.
3.2.0.192.IN-ADDR.ARPA. IN PTR 3.user.town.AW.example.com. 3.2.0.192.IN-ADDR.ARPA. IN PTR 3.string.region.example.com.
. .
. .
. .
254.2.0.192.IN-ADDR.ARPA. IN PTR 254.user.town.AW.example.com. 254.2.0.192.IN-ADDR.ARPA. IN PTR 254.string.region.example.com.
The conscientious Example.com might then also have a zone: The conscientious Example.com might then also have a zone:
1.user.town.AW.example.com. IN A 192.0.2.1 1.string.region.example.com. IN A 192.0.2.1
2.user.town.AW.example.com. IN A 192.0.2.2 2.string.region.example.com. IN A 192.0.2.2
3.user.town.AW.example.com. IN A 192.0.2.3 3.string.region.example.com. IN A 192.0.2.3
\. \.
\. \.
\. \.
254.user.town.AW.example.com. IN A 192.0.2.254 254.string.region.example.com. IN A 192.0.2.254
Many ISPs generate PTR records for all IP addresses used for Many ISPs generate PTR records for all IP addresses used for
customers, and many create the matching A record. customers, and many create the matching A record.
1.2. Reverse DNS Considerations in IPv6 1.2. Reverse DNS Considerations in IPv6
A sample entry for 2001:0db8:0f00:0000:0012:34ff:fe56:789a might be: A sample entry for 2001:0db8:0f00:0000:0012:34ff:fe56:789a might be:
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 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.town.AW.example.com. .IP6.ARPA. IN PTR 1.string.region.example.com.
ISPs will often delegate an IPv6 prefix to their customers. Since ISPs will often delegate an IPv6 prefix to their customers. Since
2^^80 possible addresses could be configured in an example 2^^80 possible addresses could be configured in an example
2001:db8:f00/48 zone alone, even with automation it is impractical to 2001:db8:f00/48 zone alone, even with automation it is impractical to
write a zone with every possible address entered. If 1000 entries write a zone with every possible address entered. If 1000 entries
could be written per second, the zone would still not be complete could be written per second, the zone would still not be complete
after 38 trillion years. after 38 trillion years.
Furthermore, it is often impossible to associate host names and Furthermore, it is often impossible to associate host names and
addresses, since the 64 bits in the Interface Identifier portion of addresses, since the 64 bits in the Interface Identifier portion of
skipping to change at page 6, line 4 skipping to change at page 6, line 7
scalability. UDP is allowed per [RFC2136] so transmission control is scalability. UDP is allowed per [RFC2136] so transmission control is
not assured, though the host should expect an ERROR or NOERROR not assured, though the host should expect an ERROR or NOERROR
message from the server [RFC2136]; TCP provides transmission control, message from the server [RFC2136]; TCP provides transmission control,
but the updating host would need to be configured to use TCP. but the updating host would need to be configured to use TCP.
Administrators should consider what domain will contain the records, Administrators should consider what domain will contain the records,
and who will provide the names. If subscribers provide hostnames, and who will provide the names. If subscribers provide hostnames,
they may provide inappropriate strings. Consider "ihate.example.com" they may provide inappropriate strings. Consider "ihate.example.com"
or "badword.customer.example.com" or or "badword.customer.example.com" or
"celebrityname.committed.illegal.acts.example.com." "celebrityname.committed.illegal.acts.example.com."
There is no assurance of uniqueness if multiple hosts try to update There is no assurance of uniqueness if multiple hosts try to update
with the same name ("mycomputer.familyname.org"). There is no with the same name ("mycomputer.familyname.org"). There is no
standard way to indicate to a host what server it should send dDNS standard way to indicate to a host what server it should send dDNS
updates to. updates to; the master listed in the SOA is often assumed to be a
dDNS server, but this may not scale.
2.3.1. Dynamic DNS from Individual Hosts 2.3.1. Dynamic DNS from Individual Hosts
In the simplest case, a residential user will have a single host In the simplest case, a residential user will have a single host
connected to the ISP. Since the typical residential user cannot connected to the ISP. Since the typical residential user cannot
configure IPv6 addresses and resolving name servers on their hosts, configure IPv6 addresses and resolving name servers on their hosts,
the ISP should provide address information conventionally (i.e., the ISP should provide address information conventionally (i.e.,
their normal combination of RAs, DHCP, etc.), and should provide a their normal combination of RAs, DHCP, etc.), and should provide a
DNS Recursive Name Server and Domain Search List as described in DNS Recursive Name Server and Domain Search List as described in
[RFC3646] or [RFC6106]. In determining its Fully Qualified Domain [RFC3646] or [RFC6106]. In determining its Fully Qualified Domain
skipping to change at page 9, line 15 skipping to change at page 9, line 22
residential ISPs. residential ISPs.
This is a general case of the specific case described in This is a general case of the specific case described in
Section 2.3.3. All of the same considerations still apply. Section 2.3.3. All of the same considerations still apply.
2.5. Dynamically Generate PTR When Queried ('On the Fly') 2.5. Dynamically Generate PTR When Queried ('On the Fly')
Common practice in IPv4 is to provide PTR records for all addresses, Common practice in IPv4 is to provide PTR records for all addresses,
regardless of whether a host is actually using the address. In IPv6, regardless of whether a host is actually using the address. In IPv6,
ISPs may generate PTR records for all IPv6 addresses as the records ISPs may generate PTR records for all IPv6 addresses as the records
are requested. Configuring records "on the fly" may consume more are requested. Several DNS servers are capable of this.
processor resource than other methods, but only on demand. A denial
of service is therefore possible, which may be mitigated with rate-
limiting and normal countermeasures.
An ISP using this option should generate a PTR record on demand, and 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 cache or prepopulate the forward (AAAA) entry for the duration of the
time-to-live of the PTR. Similarly, the ISP would prepopulate the time-to-live of the PTR. Similarly, the ISP would prepopulate the
PTR following a AAAA query. Alternatively, if an algorithm is used PTR following a AAAA query. Alternatively, if an algorithm is used
to generate unique name, it can be employed on the fly in both to generate unique name, it can be employed on the fly in both
directions. This option has the advantage of assuring matching directions. This option has the advantage of assuring matching
forward and reverse entries, while being simpler than dynamic DNS. forward and reverse entries, while being simpler than dynamic DNS.
Administrators should consider whether the lack of user-specified Administrators should consider whether the lack of user-specified
hostnames is a drawback. hostnames is a drawback. It may be possible to allow user-specified
hostnames for some records and generate others on the fly; looking up
a record before generating on the fly may slow responses or may not
scale well.
This method may not scale well in conjunction with DNSsec [RFC4035], DNSsec [RFC4035] signing records on the fly may increase load;
because of the additional load, but since keys may be pregenerated unsigned records can indicate that these records are less trusted,
for zones, and not for each record, the risk is moderate. Signing which might be acceptable.
records on the fly may increase load, and may not scale; unsigned
records can indicate that these records are less trusted, which might
be acceptable.
Another consideration is that the algorithm used for generating the Another consideration is that the algorithm used for generating the
record must be the same on all servers for a zone. In other words, 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 any server for the zone must produce the same response for a given
query. Administrators managing a variety of rules within a zone query. Administrators managing a variety of rules within a zone
might find it difficult to keep those rules synchronized on all might find it difficult to keep those rules synchronized on all
servers. servers.
3. Considerations and Recommendations 3. Manual User Updates
There are five common uses for PTR lookups: It is possible to create a user interface, such as a web page, that
would allow end users to enter a hostname to associate with an
address. Such an interface would need to be authenticated (only the
authorized user could add/change/delete entries). It would need to
specify only the host bits if the ISP changes prefixes assigned to
customers, and the back end would therefore need to be integrated
with prefix assignments, so that when a new prefix was assigned to a
customer, the DNS service would look up user-generated hostnames and
delete the old record and create the new one.
Considerations about some records being static and others dynamic or
dynamically generated (section 2.5) and the creativity of users
(section 2.3) still apply.
4. Considerations and Recommendations
There are six common uses for PTR lookups:
Rejecting mail: A PTR with a certain string or missing may indicate Rejecting mail: A PTR with a certain string or missing may indicate
"This host is not a mail server," which may be useful for rejecting "This host is not a mail server," which may be useful for rejecting
probable spam. The absence of a PTR leads to the desired behavior. probable spam. The absence of a PTR leads to the desired behavior.
Serving ads: "This host is probably in town.province." An ISP that Serving ads: "This host is probably in town.province." An ISP that
does not provide PTR records might affect somebody else's does not provide PTR records might affect somebody else's
geolocation. geolocation.
Accepting SSH connections: The presence of a PTR may be inferred to Accepting SSH connections: The presence of a PTR may be inferred to
mean "This host has an administrator with enough clue to set up mean "This host has an administrator with enough clue to set up
forward and reverse DNS." This is a poor inference. forward and reverse DNS." This is a poor inference.
Log files: Many systems will record the PTR of remote hosts in their Log files: Many systems will record the PTR of remote hosts in their
log files, to make it easier to see what network the remote host uses log files, to make it easier to see what network the remote host uses
when reading logs later. when reading logs later.
Traceroute: The ability to identify an interface and name of any Traceroute: The ability to identify an interface and name of any
intermediate node or router is important for troubleshooting. intermediate node or router is important for troubleshooting.
Service discovery: [RFC6763] specifies "DNS-based Service Discovery"
and section 11 specifically describes how PTRs are used.
As a general guideline, when address assignment and name are under As a general guideline, when address assignment and name are under
the same authority, or when a host has a static address and name, the same authority, or when a host has a static address and name,
AAAA and PTR records should exist and match. For residential users, AAAA and PTR records should exist and match. For residential users,
if these four use cases are important to the ISP, the administrator if these four use cases are important to the ISP, the administrator
will then need to consider how to provide PTR records. will then need to consider how to provide PTR records.
The best accuracy would be achieved if ISPs delegate authority along The best accuracy would be achieved if ISPs delegate authority along
with address delegation, but residential users rarely have domain with address delegation, but residential users rarely have domain
names or authoritative name servers. names or authoritative name servers.
Dynamic DNS updates can provide accurate data, but there is no Dynamic DNS updates can provide accurate data, but there is no
standard way to indicate to residential devices where to send standard way to indicate to residential devices where to send
updates, if the hosts support it, and if it scales. updates, if the hosts support it, and if it scales.
An ISP has no knowledge of its residential users' hostnames, and An ISP has no knowledge of its residential users' hostnames, and
therefore can either provide a wildcard response or a dynamically therefore can either provide a wildcard response or a dynamically
generated response. A valid negative response (such as NXDomain) is generated response. A valid negative response (such as NXDomain) is
a valid response, if the four cases above are not essential; lame a valid response, if the four cases above are not essential; lame
delegation should be avoided. delegation should be avoided.
4. Security Considerations 5. Security and Privacy Considerations
4.1. Using Reverse DNS for Security 5.1. Using Reverse DNS for Security
Some people think the existence of reverse DNS records, or matching Some people think the existence of reverse DNS records, or matching
forward and reverse DNS records, provides useful information about forward and reverse DNS records, provides useful information about
the hosts with those records. For example, one might infer that the the hosts with those records. For example, one might infer that the
administrator of a network with properly configured DNS records was administrator of a network with properly configured DNS records was
better-informed, and by further inference more responsible, than the better-informed, and by further inference more responsible, than the
administrator of a less-thoroughly configured network. For instance, administrator of a less-thoroughly configured network. For instance,
most email providers will not accept incoming connections on port 25 most email providers will not accept incoming connections on port 25
unless forward and reverse DNS entries match. If they match, but unless forward and reverse DNS entries match. If they match, but
information higher in the stack (for instance, mail source) is information higher in the stack (for instance, mail source) is
inconsistent, the packet is questionable. These records may be inconsistent, the packet is questionable. These records may be
easily forged though, unless DNSsec or other measures are taken. The easily forged though, unless DNSsec or other measures are taken. The
string of inferences is questionable, and may become unneeded if string of inferences is questionable, and may become unneeded if
other means for evaluating trustworthiness (such as positive other means for evaluating trustworthiness (such as positive
reputations) become predominant in IPv6. reputations) become predominant in IPv6.
Providing location information in PTR records is useful for Providing location information in PTR records is useful for
troubleshooting, law enforcement, and geolocation services, but for troubleshooting, law enforcement, and geolocation services, but for
the same reasons can be considered sensitive information. the same reasons can be considered sensitive information.
4.2. DNS Security with Dynamic DNS 5.2. DNS Security with Dynamic DNS
Security considerations of using dynamic DNS are described in Security considerations of using dynamic DNS are described in
[RFC3007]. DNS Security Extensions are documented in [RFC4033]. [RFC3007]. DNS Security Extensions are documented in [RFC4033].
Interactions with DNSsec are described throughout this document. Interactions with DNSsec are described throughout this document.
4.3. Considerations for Other Uses of the DNS 5.3. Considerations for Other Uses of the DNS
Several methods exist for providing encryption keys in the DNS. Any Several methods exist for providing encryption keys in the DNS. Any
of the options presented here may interfere with these key of the options presented here may interfere with these key
techniques. techniques.
5. Acknowledgements 6. Privacy Considerations
Given considerations in [hostname], hostnames that provide
information about a user compromises that user's privacy. Some users
may want to identify their hosts using user-specified hostnames, but
the default behavior should not be to identify a user, their
location, their connectivity, or other information in a PTR record.
7. Acknowledgements
The author would like to thank Alain Durand, JINMEI Tatuya, David The author would like to thank Alain Durand, JINMEI Tatuya, David
Freedman, Andrew Sullivan, Chris Griffiths, Darryl Tanner, Ed Lewis, Freedman, Andrew Sullivan, Chris Griffiths, Darryl Tanner, Ed Lewis,
John Brzozowski, Chris Donley, Wes George, Jason Weil, John Spence, John Brzozowski, Chris Donley, Wes George, Jason Weil, John Spence,
Ted Lemon, Stephan Lagerholm, Steinar Haug, Mark Andrews, and Chris Ted Lemon, Stephan Lagerholm, Steinar Haug, Mark Andrews, and Chris
Roosenraad, Fernando Gont, John Levine, and many others who discussed Roosenraad, Fernando Gont, John Levine, and many others who discussed
and provided suggestions for this document. and provided suggestions for this document.
6. IANA Considerations 8. IANA Considerations
There are no IANA considerations or implications that arise from this There are no IANA considerations or implications that arise from this
document. document.
7. References 9. References
7.1. Normative References 9.1. Normative References
[RFC1033] Lottor, M., "Domain Administrators Operators Guide", [RFC1033] Lottor, M., "Domain Administrators Operators Guide",
November 1987. November 1987.
[RFC1912] Barr, D., "Common DNS Operational and Configuration [RFC1912] Barr, D., "Common DNS Operational and Configuration
Errors", February 1996. Errors", February 1996.
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)", April 1917. "Dynamic Updates in the Domain Name System (DNS UPDATE)", April 1917.
skipping to change at page 12, line 41 skipping to change at page 13, line 24
Domain Name (FQDN) Option". Domain Name (FQDN) Option".
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", September 2007. Address Autoconfiguration", September 2007.
[RFC4941] "Privacy Extensions for Stateless Address Autoconfiguration [RFC4941] "Privacy Extensions for Stateless Address Autoconfiguration
in IPv6". in IPv6".
[RFC6106] "IPv6 Router Advertisement Options for DNS Configuration". [RFC6106] "IPv6 Router Advertisement Options for DNS Configuration".
7.2. Informative References [RFC6763] Cheshire, S., and Krochmal, M., "DNS-Based Service
Discovery", February 2013.
9.2. Informative References
[RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN- [RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN-
ADDR.ARPA delegation", March 1998. ADDR.ARPA delegation", March 1998.
[RFC4472] Durand, A., Ihren, J., and P. Savola, "Operational [RFC4472] Durand, A., Ihren, J., and P. Savola, "Operational
Considerations and Issues with IPv6 DNS", April 2006. Considerations and Issues with IPv6 DNS", April 2006.
[RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in
Customer Premises Equipment (CPE) for Providing Residential IPv6 Customer Premises Equipment (CPE) for Providing Residential IPv6
Internet Service", January 2011. Internet Service", January 2011.
[inaddr-reqd] Senie, D., "draft-ietf-dnsop-inaddr-required-07", [inaddr-reqd] Senie, D., "draft-ietf-dnsop-inaddr-required-07",
August 2005. August 2005.
[rmap-consider] Senie, D. and A. Sullivan, "draft-ietf-dnsop- [rmap-consider] Senie, D. and A. Sullivan, "draft-ietf-dnsop-
reverse-mapping-considerations-06", March 2008. reverse-mapping-considerations-06", March 2008.
Author's Address [hostname] Huitema, C., Thaler, D., and R. Winter, "draft-ietf-
intarea-hostname-practice", February 2017.
Author's Address
Lee Howard Lee Howard
Charter Retevia
13820 Sunrise Valley Dr. Fairfax, VA 22032
Herndon, VA 20171
USA USA
Email: lee.howard@charter.com Email: lee@asgard.org
 End of changes. 40 change blocks. 
63 lines changed or deleted 98 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/