draft-ietf-dnsop-isp-ip6rdns-05.txt   draft-ietf-dnsop-isp-ip6rdns-06.txt 
Network Working Group L. Howard Network Working Group L. Howard
Internet-Draft Retevia Internet-Draft Retevia
Intended status: Informational April 25, 2018 Intended status: Informational September 05, 2018
Expires: October 27, 2018 Expires: March 9, 2019
Reverse DNS in IPv6 for Internet Service Providers Reverse DNS in IPv6 for Internet Service Providers
draft-ietf-dnsop-isp-ip6rdns-05 draft-ietf-dnsop-isp-ip6rdns-06
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.
address space assigned to many customers.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 October 27, 2018. This Internet-Draft will expire on March 9, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 16 skipping to change at page 3, line 14
PTR records are needed, and if so, evaluate methods for responding to PTR records are needed, and if so, evaluate methods for responding to
reverse DNS queries in 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 one region, the reverse zone might
the reverse zone might look like: look like:
1.2.0.192.IN-ADDR.ARPA. IN PTR 1.string.region.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.string.region.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.string.region.example.com. 3.2.0.192.IN-ADDR.ARPA. IN PTR 3.string.region.example.com.
. .
. .
skipping to change at page 4, line 13 skipping to change at page 4, line 13
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.string.region.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 single /48 zone
2001:db8:f00/48 zone alone, even with automation it is impractical to alone, even with automation it is impractical to write a zone with
write a zone with every possible address entered. If 1000 entries every possible address entered. If 1000 entries could be written per
could be written per second, the zone would still not be complete 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
the address are frequently assigned using SLAAC [RFC4862] when the the address are frequently assigned using SLAAC [RFC4862] when the
host comes online, and may be short-lived. host comes online, and may be short-lived.
[RFC1912] is an informational document that says "PTR records must [RFC1912] is an informational document that says "PTR records must
point back to a valid A record" and further that the administrator point back to a valid A record" and further that the administrator
should "Make sure your PTR and A records match." [RFC1912] This should "Make sure your PTR and A records match." [RFC1912] This
document considers how to follow this advice for AAAA and PTR document considers how to follow this advice for AAAA and PTR
skipping to change at page 5, line 21 skipping to change at page 5, line 19
While recording all possible addresses is not scalable, it may be While recording all possible addresses is not scalable, it may be
possible to record a wildcard entry for each prefix assigned to a possible to record a wildcard entry for each prefix assigned to a
customer. Consider also that "inclusion of wildcard NS RRSets in a customer. Consider also that "inclusion of wildcard NS RRSets in a
zone is discouraged, but not barred." [RFC4035] zone is discouraged, but not barred." [RFC4035]
This solution generally scales well. However, since the response This solution generally scales well. However, since the response
will match any address in the wildcard range (/48, /56, /64, etc.), a 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 forward DNS lookup on that response given will not be able to return
the same hostname. This method therefore fails the expectation in the same hostname. This method therefore fails the expectation in
[RFC1912] for forward and reverse to match. DNSsec [RFC4035] [RFC1912] for forward and reverse to match. DNSSEC [RFC4035]
scalability is limited to signing the wildcard zone, which may be scalability is limited to signing the wildcard zone, which may be
satisfactory. satisfactory.
2.3. Dynamic DNS 2.3. Dynamic DNS
One way to ensure forward and reverse records match is for hosts to One way to ensure forward and reverse records match is for hosts to
update DNS servers dynamically, once interface configuration (whether update DNS servers dynamically, once interface configuration (whether
SLAAC, DHCPv6, or other means) is complete, as described in SLAAC, DHCPv6, or other means) is complete, as described in
[RFC4472]. Hosts would need to provide both AAAA and PTR updates, [RFC4472]. Hosts would need to provide both AAAA and PTR updates,
and would need to know which servers would accept the information. and would need to know which servers would accept the information.
skipping to change at page 6, line 35 skipping to change at page 6, line 31
listed, since hosts may need to search for unqualified names in listed, since hosts may need to search for unqualified names in
multiple domains, without necessarily being a member of those multiple domains, without necessarily being a member of those
domains. Administrators should consider whether the domain search domains. Administrators should consider whether the domain search
list actually provides an appropriate DNS suffix(es) when considering list actually provides an appropriate DNS suffix(es) when considering
use of this option. For purposes of dynamic DNS, the host would use of this option. For purposes of dynamic DNS, the host would
concatenate its local hostname (e.g., "hostname") plus the domain(s) concatenate its local hostname (e.g., "hostname") plus the domain(s)
in the Domain Search List (e.g., "customer.example.com"), as in in the Domain Search List (e.g., "customer.example.com"), as in
"hostname.customer.example.com." "hostname.customer.example.com."
Once it learns its address, and has a resolving name server, the host 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 must perform an SOA lookup on the IP6.ARPA record to be added, to
find the owner, eventually to find the server authoritative for the find the owner, eventually to find the server authoritative for the
zone (which might accept dynamic updates). Several recursive lookups zone (which might accept dynamic updates). Several recursive lookups
may be required to find the longest prefix which has been delegated. may be required to find the longest prefix which has been delegated.
The DNS administrator must designate the Primary Master Server for The DNS administrator must designate the Primary Master Server for
the longest match required. Once found, the host sends dynamic AAAA the longest match required. Once found, the host sends dynamic AAAA
and PTR updates using the concatenation defined above and PTR updates using the concatenation defined above
("hostname.customer.example.com"). ("hostname.customer.example.com").
In order to use this alternative, hosts must be configured to use In order to use this alternative, hosts must be configured to use
dynamic DNS. This is not default behavior for many hosts, which is dynamic DNS. This is not default behavior for many hosts, which is
skipping to change at page 7, line 26 skipping to change at page 7, line 26
behavior is unchanged; the host sends the same dynamic updates, behavior is unchanged; the host sends the same dynamic updates,
either to the ISP's server (as provided by the gateway), or to the either to the ISP's server (as provided by the gateway), or to the
gateway for it to forward. gateway for it to forward.
2.3.3. Automatic DNS Delegations 2.3.3. Automatic DNS Delegations
An ISP may delegate authority for a subdomain such as An ISP may delegate authority for a subdomain such as
"customer12345.town.AW.customer.example.com" or "customer12345.town.AW.customer.example.com" or
"customer12345.example.com" to the customer's gateway. Each domain "customer12345.example.com" to the customer's gateway. Each domain
thus delegated must be unique within the DNS. The ISP may also then 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, 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." 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 Then the customer could provide updates to their own gateway, with
forward and reverse. However, individual hosts connected directly to forward and reverse. However, individual hosts connected directly to
the ISP rarely have the capability to run DNS for themselves; the ISP rarely have the capability to run DNS for themselves;
therefore, an ISP can only delegate to customers with gateways therefore, an ISP can only delegate to customers with gateways
capable of being authoritative name servers. If a device requests a capable of being authoritative name servers. If a device requests a
DHCPv6 Prefix Delegation, that may be considered a reasonably DHCPv6 Prefix Delegation, that may be considered a reasonably
reliable indicator that it is a gateway, rather than an individual reliable indicator that it is a gateway, rather than an individual
host. It is not necessarily an indicator that the gateway is capable host. It is not necessarily an indicator that the gateway is capable
of providing DNS services, and therefore cannot be relied upon as a of providing DNS services, and therefore cannot be relied upon as a
way to test whether this option is feasible. In fact, this kind of way to test whether this option is feasible. In fact, this kind of
skipping to change at page 9, line 37 skipping to change at page 9, line 37
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. It may be possible to allow user-specified hostnames is a drawback. It may be possible to allow user-specified
hostnames for some records and generate others on the fly; looking up 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 a record before generating on the fly may slow responses or may not
scale well. scale well.
DNSsec [RFC4035] signing records on the fly may increase load; DNSSEC [RFC4035] signing records on the fly may increase load;
unsigned records can indicate that these records are less trusted, unsigned records can indicate that these records are less trusted,
which might be acceptable. 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.
skipping to change at page 11, line 29 skipping to change at page 11, line 29
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.
5.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.
5.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.
6. Privacy Considerations 6. Privacy Considerations
Given considerations in [hostname], hostnames that provide Given considerations in [hostname], hostnames that provide
 End of changes. 12 change blocks. 
20 lines changed or deleted 18 lines changed or added

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