draft-ietf-dnsop-isp-ip6rdns-06.txt   draft-ietf-dnsop-isp-ip6rdns-07.txt 
Network Working Group L. Howard Network Working Group L. Howard
Internet-Draft Retevia Internet-Draft Retevia
Intended status: Informational September 05, 2018 Intended status: Informational September 26, 2018
Expires: March 9, 2019 Expires: March 30, 2019
Reverse DNS in IPv6 for Internet Service Providers Reverse DNS in IPv6 for Internet Service Providers
draft-ietf-dnsop-isp-ip6rdns-06 draft-ietf-dnsop-isp-ip6rdns-07
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. considerations for ISPs in managing the IP6.ARPA zone.
Status of This Memo Status of This Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 33
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 March 9, 2019. This Internet-Draft will expire on March 30, 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 2, line 15 skipping to change at page 2, line 15
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 . . . . . . . . . . . 4 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 . . . . . . 7 2.3.2. Dynamic DNS through Residential Gateways . . . . . . 6
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 . . . . . . . . . . . . . . . . . . . . . . 9 2.4. Delegate DNS . . . . . . . . . . . . . . . . . . . . . . 8
2.5. Dynamically Generate PTR When Queried ('On the Fly') . . 9 2.5. Dynamically Generate PTR When Queried ('On the Fly') . . 9
3. Manual User Updates . . . . . . . . . . . . . . . . . . . . . 9 3. Manual User Updates . . . . . . . . . . . . . . . . . . . . . 9
4. Considerations and Recommendations . . . . . . . . . . . . . 10 4. Considerations and Recommendations . . . . . . . . . . . . . 10
5. Security and Privacy Considerations . . . . . . . . . . . . . 11 5. Security and Privacy Considerations . . . . . . . . . . . . . 11
5.1. Using Reverse DNS for Security . . . . . . . . . . . . . 11 5.1. Using Reverse DNS for Security . . . . . . . . . . . . . 11
5.2. DNS Security with Dynamic DNS . . . . . . . . . . . . . . 11 5.2. DNS Security with Dynamic DNS . . . . . . . . . . . . . . 11
5.3. Considerations for Other Uses of the DNS . . . . . . . . 11 5.3. Considerations for Other Uses of the DNS . . . . . . . . 11
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12 5.4. Privacy Considerations . . . . . . . . . . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 5.5. User Creativity . . . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 8.2. Informative References . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
[RFC1912] recommended that "every internet-reachable host should have [RFC1912] recommended that "every internet-reachable host should have
a name" and says "Failure to have matching PTR and A records can a name" and says "Failure to have matching PTR and A records can
cause loss of Internet services similar to not being registered in cause loss of Internet services similar to not being registered in
the DNS at all." While the need for a PTR record and for it to match the DNS at all." While the need for a PTR record and for it to match
is debatable as a best practice, some network services [see is debatable as a best practice, some network services [see
Section 3] still do rely on PTR lookups, and some check the source Section 4] still do rely on PTR lookups, and some check the source
address of incoming connections and verify that the PTR and A records address of incoming connections and verify that the PTR and A records
match before providing service. 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 whether customer impractical. Administrators at ISPs should consider whether customer
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.
skipping to change at page 4, line 20 skipping to change at page 4, line 20
.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 single /48 zone 2^^80 possible addresses could be configured in an single /48 zone
alone, even with automation it is impractical to write a zone with alone, even with automation it is impractical to write a zone with
every possible address entered. If 1000 entries could be written per every possible address entered. If 1000 entries could be written per
second, the zone would still not be complete after 38 trillion years. second, the zone would still not be complete 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 (StateLess Address
host comes online, and may be short-lived. Auto-Configuration) [RFC4862] when the 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." This document
document considers how to follow this advice for AAAA and PTR considers how to follow this advice for AAAA and PTR records.
records.
2. Alternatives in IPv6 2. Alternatives in IPv6
Several options exist for providing reverse DNS in IPv6. All of Several options exist for providing reverse DNS in IPv6. All of
these options also exist for IPv4, but the scaling problem is much these options also exist for IPv4, but the scaling problem is much
less severe in IPv4. Each option should be evaluated for its scaling less severe in IPv4. Each option should be evaluated for its scaling
ability, its compliance with existing standards and best practices, ability, its compliance with existing standards and best practices,
and its availability in common systems. and its availability in common systems.
2.1. Negative Response 2.1. Negative Response
Some ISP DNS administrators may choose to provide only a NXDomain Some ISP DNS administrators may choose to provide only a NXDOMAIN
response to PTR queries for subscriber addresses. In some ways, this response to PTR queries for subscriber addresses. In some ways, this
is the most accurate response, since no name information is known is the most accurate response, since no name information is known
about the host. Providing a negative response in response to PTR about the host. Providing a negative response in response to PTR
queries does not satisfy the expectation in [RFC1912] for entries to queries does not satisfy the expectation in [RFC1912] for entries to
match. Users of services which are dependent on a successful lookup match. Users of services which are dependent on a successful lookup
will have a poor experience. For instance, some web services and SSH will have a poor experience. For instance, some web services and SSH
connections wait for a DNS response, even NXDOMAIN, before connections wait for a DNS response, even NXDOMAIN, before
responding. For best user experience, then, it is important to responding. For best user experience, then, it is important to
return a response, rather than have a lame delegation. On the other return a response, rather than time out with no answer. On the other
hand, external mail servers are likely to reject connections, which hand, external mail servers are likely to reject connections, which
might be an advantage in fighting spam. DNS administrators should might be an advantage in fighting spam. DNS administrators should
consider the uses for reverse DNS records and the number of services consider the uses for reverse DNS records and the number of services
affecting the number of users when evaluating this option. affecting the number of users when evaluating this option.
2.2. Wildcard match 2.2. Wildcard match
The use of wildcards in the DNS is described in [RFC4592], and their The use of wildcards in the DNS is described in [RFC4592], and their
use in IPv6 reverse DNS is described in [RFC4472]. use in IPv6 reverse DNS is described in [RFC4472].
skipping to change at page 5, line 32 skipping to change at page 5, line 32
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.
This option should scale as well or as poorly as IPv4 dynamic DNS This option should scale as well or as poorly as IPv4 dynamic DNS
does. Dynamic DNS may not scale effectively in large ISP networks (dDNS) does. Dynamic DNS may not scale effectively in large ISP
which have no single master name server, but a single master server networks which have no single master name server, but a single master
is not best practice. The ISP's DNS system may provide a point for server is not best practice. The ISP's DNS system may provide a
Denial of Service attacks, including many attempted dDNS updates. point for Denial of Service attacks, including many attempted dDNS
Accepting updates only from authenticated sources may mitigate this updates. Accepting updates only from authenticated sources may
risk, but only if authentication itself does not require excessive mitigate this risk, but only if authentication itself does not
overhead. No authentication of dynamic DNS updates is inherently require excessive overhead. No authentication of dynamic DNS updates
provided; implementers should consider use of TSIG [RFC2845], or at is inherently provided; implementers should consider use of TSIG
least ingress filtering so updates are only accepted from customer [RFC2845], or at least ingress filtering so updates are only accepted
address space from internal network interfaces, rate limit the number from customer address space from internal network interfaces, rate
of updates from a customer per second, and consider impacts on limit the number of updates from a customer per second, and consider
scalability. UDP is allowed per [RFC2136] so transmission control is impacts on scalability. UDP is allowed per [RFC2136] so connection
not assured, though the host should expect an ERROR or NOERROR reliabilty is not assured, though the host should expect an ERROR or
message from the server [RFC2136]; TCP provides transmission control, NOERROR message from the server; 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 may want to consider user creativity if they provide
and who will provide the names. If subscribers provide hostnames, host names, as described in Section 5.4 "User Creativity."
they may provide inappropriate strings. Consider "ihate.example.com"
or "badword.customer.example.com" or
"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; the master listed in the SOA is often assumed to be a updates to; the master listed in the SOA is often assumed to be a
dDNS server, but this may not scale. 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 Router Advertisements (RAs), DHCP, etc.),
DNS Recursive Name Server and Domain Search List as described in and should provide a DNS Recursive Name Server and Domain Search List
[RFC3646] or [RFC6106]. In determining its Fully Qualified Domain as described in [RFC3646] or [RFC6106]. In determining its FQDN
Name, a host will typically use a domain from the Domain Search List. (Fully Qualified Domain Name), a host will typically use a domain
This is an overloading of the parameter; multiple domains could be from the Domain Search List. This is an overloading of the
listed, since hosts may need to search for unqualified names in parameter; multiple domains could be listed, since hosts may need to
multiple domains, without necessarily being a member of those search for unqualified names in multiple domains, without necessarily
domains. Administrators should consider whether the domain search being a member of those domains. Administrators should consider
list actually provides an appropriate DNS suffix(es) when considering whether the domain search list actually provides an appropriate DNS
use of this option. For purposes of dynamic DNS, the host would suffix(es) when considering use of this option. For purposes of
concatenate its local hostname (e.g., "hostname") plus the domain(s) dynamic DNS, the host would concatenate its local hostname (e.g.,
in the Domain Search List (e.g., "customer.example.com"), as in "hostname") plus the domain(s) in the Domain Search List (e.g.,
"hostname.customer.example.com." "customer.example.com"), as in "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").
skipping to change at page 7, line 18 skipping to change at page 7, line 11
service to hosts from a delegated prefix. ISPs should provide a DNS service to hosts from a delegated prefix. ISPs should provide a DNS
Recursive Name Server and Domain Search List to the gateway, as Recursive Name Server and Domain Search List to the gateway, as
described above and in [RFC3646] and [RFC6106]. There are two described above and in [RFC3646] and [RFC6106]. There are two
options for how the gateway uses this information. The first option options for how the gateway uses this information. The first option
is for the gateway to respond to DHCPv6 requests with the same DNS is for the gateway to respond to DHCPv6 requests with the same DNS
Recursive Name Server and Domain Search List provided by the ISP. Recursive Name Server and Domain Search List provided by the ISP.
The alternate option is for the gateway to relay dynamic DNS updates The alternate option is for the gateway to relay dynamic DNS updates
from hosts to the servers and domain provided by the ISP. Host from hosts to the servers and domain provided by the ISP. Host
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. The gateway would need to be capable of
and configured to use dynamic DNS.
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
skipping to change at page 8, line 47 skipping to change at page 8, line 41
option, and would have to either have the zones configured, or send option, and would have to either have the zones configured, or send
dDNS messages to the ISP's name server. dDNS messages to the ISP's name server.
2.3.6. Populate from RADIUS Server 2.3.6. Populate from RADIUS Server
A user may receive an address or prefix from a RADIUS [RFC2865] A user may receive an address or prefix from a RADIUS [RFC2865]
server, the details of which may be recorded via RADIUS Accounting server, the details of which may be recorded via RADIUS Accounting
[RFC2866] data. The ISP may populate the forward and reverse zones [RFC2866] data. The ISP may populate the forward and reverse zones
from the accounting data if it contains enough information. This from the accounting data if it contains enough information. This
solution allows the ISP to populate data concerning allocated solution allows the ISP to populate data concerning allocated
prefixes (as per 2.2 (wildcards)) and CPE endpoints, but as with prefixes (as per 2.2 (wildcards)) and CPE (customer premise
2.3.5 does not allow the ISP to populate information concerning equipment) endpoints, but as with 2.3.5 does not allow the ISP to
individual hosts. populate information concerning individual hosts.
2.4. Delegate DNS 2.4. Delegate DNS
For customers who are able to run their own DNS servers, such as For customers who are able to run their own DNS servers, such as
commercial customers, often the best option is to delegate the commercial customers, often the best option is to delegate the
reverse DNS zone to them, as described in [RFC2317] (for IPv4). reverse DNS zone to them, as described in [RFC2317] (for IPv4).
However, since most residential users have neither the equipment nor However, since most residential users have neither the equipment nor
the expertise to run DNS servers, this method is unavailable to the expertise to run DNS servers, this method is unavailable to
residential ISPs. residential ISPs.
skipping to change at page 9, line 27 skipping to change at page 9, line 20
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. Several DNS servers are capable of this. are requested. Several DNS servers are capable of this.
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. To reduce exposure to a denial of
to generate unique name, it can be employed on the fly in both service attack, state or storage should be limited. Alternatively,
directions. This option has the advantage of assuring matching if an algorithm is used to generate unique name, it can be employed
forward and reverse entries, while being simpler than dynamic DNS. on the fly in both directions. This option has the advantage of
Administrators should consider whether the lack of user-specified assuring matching forward and reverse entries, while being simpler
hostnames is a drawback. It may be possible to allow user-specified than dynamic DNS. Administrators should consider whether the lack of
hostnames for some records and generate others on the fly; looking up user-specified hostnames is a drawback. It may be possible to allow
a record before generating on the fly may slow responses or may not user-specified hostnames for some records and generate others on the
scale well. fly; looking up a record before generating on the fly may slow
responses or may not 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
skipping to change at page 10, line 13 skipping to change at page 10, line 9
address. Such an interface would need to be authenticated (only the address. Such an interface would need to be authenticated (only the
authorized user could add/change/delete entries). It would need to authorized user could add/change/delete entries). It would need to
specify only the host bits if the ISP changes prefixes assigned to specify only the host bits if the ISP changes prefixes assigned to
customers, and the back end would therefore need to be integrated customers, and the back end would therefore need to be integrated
with prefix assignments, so that when a new prefix was assigned to a with prefix assignments, so that when a new prefix was assigned to a
customer, the DNS service would look up user-generated hostnames and customer, the DNS service would look up user-generated hostnames and
delete the old record and create the new one. delete the old record and create the new one.
Considerations about some records being static and others dynamic or Considerations about some records being static and others dynamic or
dynamically generated (section 2.5) and the creativity of users dynamically generated (section 2.5) and the creativity of users
(section 2.3) still apply. (section 5.4) still apply.
4. Considerations and Recommendations 4. Considerations and Recommendations
There are six common uses for PTR lookups: 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. (also see privacy consideration about location).
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
skipping to change at page 11, line 11 skipping to change at page 11, line 7
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;
delegation should be avoided. delegation where no name server exists should be avoided.
5. Security and Privacy Considerations 5. Security and Privacy Considerations
5.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
skipping to change at page 12, line 5 skipping to change at page 11, line 47
[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 5.4. Privacy Considerations
Given considerations in [hostname], hostnames that provide Given considerations in [hostname], hostnames that provide
information about a user compromises that user's privacy. Some users information about a user compromises that user's privacy. Some users
may want to identify their hosts using user-specified hostnames, but may want to identify their hosts using user-specified hostnames, but
the default behavior should not be to identify a user, their the default behavior should not be to identify a user, their
location, their connectivity, or other information in a PTR record. location, their connectivity, or other information in a PTR record.
7. Acknowledgements 5.5. User Creativity
Though not precisely a security consideration, administrators may
want to 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."
6. 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, Chris Ted Lemon, Stephan Lagerholm, Steinar Haug, Mark Andrews, 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.
8. IANA Considerations 7. 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.
9. References 8. References
9.1. Normative References 8.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 13, line 27 skipping to change at page 13, line 32
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".
[RFC6763] Cheshire, S., and Krochmal, M., "DNS-Based Service [RFC6763] Cheshire, S., and Krochmal, M., "DNS-Based Service
Discovery", February 2013. Discovery", February 2013.
9.2. Informative References 8.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.
 End of changes. 27 change blocks. 
79 lines changed or deleted 88 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/