draft-ietf-dnsop-isp-ip6rdns-00.txt   draft-ietf-dnsop-isp-ip6rdns-01.txt 
Network Working Group L. Howard Network Working Group L. Howard
Internet-Draft Time Warner Cable Internet-Draft Time Warner Cable
Intended status: Informational October 16, 2015 Intended status: Informational December 22, 2015
Expires: April 18, 2016 Expires: June 24, 2016
Reverse DNS in IPv6 for Internet Service Providers Reverse DNS in IPv6 for Internet Service Providers
draft-ietf-dnsop-isp-ip6rdns-00 draft-ietf-dnsop-isp-ip6rdns-01
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 April 18, 2016. This Internet-Draft will expire on June 24, 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 3, line 9 skipping to change at page 3, line 9
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 the need for PTR
records and evaluate methods for responding to reverse DNS queries in records and evaluate methods for responding to reverse DNS queries in
IPv6. 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.user.town.AW.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.user.town.AW.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.user.town.AW.example.com.
skipping to change at page 9, line 22 skipping to change at page 9, line 22
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. Configuring records "on the fly" may consume more
processor resource than other methods, but only on demand. A denial processor resource than other methods, but only on demand. A denial
of service is therefore possible, which may be mitigated with rate- of service is therefore possible, which may be mitigated with rate-
limiting and normal countermeasures. 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.
This method may not scale well in conjunction with DNSsec [RFC4035], This method may not scale well in conjunction with DNSsec [RFC4035],
because of the additional load, but since keys may be pregenerated because of the additional load, but since keys may be pregenerated
for zones, and not for each record, the risk is moderate. Signing for zones, and not for each record, the risk is moderate. Signing
records on the fly may increase load, and may not scale; unsigned records on the fly may increase load, and may not scale; unsigned
records can indicate that these records are less trusted, which might records can indicate that these records are less trusted, which might
be acceptable. 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. Considerations and Recommendations
There are four common uses for PTR lookups: There are five common uses for PTR lookups:
Reject 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.
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
skipping to change at page 10, line 48 skipping to change at page 10, line 48
delegation should be avoided. delegation should be avoided.
4. Security Considerations 4. Security Considerations
4.1. Using Reverse DNS for Security 4.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 better-informed, and by further inference more responsible, than the
the administrator of a less-thoroughly configured network. For administrator of a less-thoroughly configured network. For instance,
instance, most email providers will not accept incoming connections most email providers will not accept incoming connections on port 25
on port 25 unless forward and reverse DNS entries match. If they unless forward and reverse DNS entries match. If they match, but
match, but information higher in the stack (for instance, mail information higher in the stack (for instance, mail source) is
source) is inconsistent, the packet is questionable. These records inconsistent, the packet is questionable. These records may be
may be easily forged though, unless DNSsec or other measures are easily forged though, unless DNSsec or other measures are taken. The
taken. The string of inferences is questionable, and may become string of inferences is questionable, and may become unneeded if
unneeded if other means for evaluating trustworthiness (such as other means for evaluating trustworthiness (such as positive
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 4.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].
skipping to change at page 12, line 46 skipping to change at page 12, line 46
[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 7.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.
[RFC2535] Eastlake, D., "Domain Name System Security Extensions",
March 1999.
[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. Author's Address reverse-mapping-considerations-06", March 2008.
Lee Howard Time Warner Cable 13820 Sunrise Valley Drive Herndon, VA
20171 US
Email: lee.howard@twcable.com
Author's Address Author's Address
Lee Howard Lee Howard
Time Warner Cable Time Warner Cable
13820 Sunrise Valley Dr. 13820 Sunrise Valley Dr.
Herndon, VA 20171 Herndon, VA 20171
USA USA
Email: lee.howard@twcable.com Email: lee.howard@twcable.com
 End of changes. 13 change blocks. 
31 lines changed or deleted 23 lines changed or added

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