[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 draft-ietf-dnsop-isp-ip6rdns

Internet Engineering Task Force                                L. Howard
Internet-Draft                                         Time Warner Cable
Intended status: Informational                                 A. Durand
Expires: March 13, 2011                                          Comcast
                                                       September 9, 2010


           Reverse DNS in IPv6 for Internet Service Providers
                      draft-howard-isp-ip6rdns-04

Abstract

   In IPv4, Internet Service Providers (ISPs) commonly provide IN-
   ADDR.ARPA. information for their customers by prepopulating the zone
   with one PTR record for every available address.  This practice does
   not scale in IPv6.  This document analyzes different approaches for
   ISPs to manage the ip6.arpa zone for IPv6 address space assigned to
   many customers.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on March 13, 2011.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of



Howard & Durand          Expires March 13, 2011                 [Page 1]


Internet-Draft        Reverse DNS in IPv6 for ISPs        September 2010


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Reverse DNS in IPv4  . . . . . . . . . . . . . . . . . . .  3
     1.2.  Reverse DNS Considerations in IPv6 . . . . . . . . . . . .  4
   2.  Alternatives in IPv6 . . . . . . . . . . . . . . . . . . . . .  5
     2.1.  No Response  . . . . . . . . . . . . . . . . . . . . . . .  5
     2.2.  Wildcard match . . . . . . . . . . . . . . . . . . . . . .  5
     2.3.  Dynamic DNS  . . . . . . . . . . . . . . . . . . . . . . .  5
       2.3.1.  Dynamic DNS from Individual Hosts  . . . . . . . . . .  6
       2.3.2.  Dynamic DNS through Residential Gateways . . . . . . .  7
       2.3.3.  Dynamic DNS Delegations  . . . . . . . . . . . . . . .  7
       2.3.4.  Generate Dynamic Records . . . . . . . . . . . . . . .  8
       2.3.5.  Populate from DHCP Server  . . . . . . . . . . . . . .  8
     2.4.  Delegate DNS . . . . . . . . . . . . . . . . . . . . . . .  8
     2.5.  Dynamically Generate PTR When Queried ("On the Fly") . . .  8
   3.  Recommendations  . . . . . . . . . . . . . . . . . . . . . . .  9
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
     4.1.  Using Reverse DNS for Security . . . . . . . . . . . . . .  9
     4.2.  DNS Security with Dynamic DNS  . . . . . . . . . . . . . . 10
     4.3.  Considerations for Other Uses of the DNS . . . . . . . . . 10
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     6.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
     6.2.  Informative References . . . . . . . . . . . . . . . . . . 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12









Howard & Durand          Expires March 13, 2011                 [Page 2]


Internet-Draft        Reverse DNS in IPv6 for ISPs        September 2010


1.  Introduction

   Best practice[RFC1033]is that "Every Internet-reachable host should
   have a name"[RFC1912]that is recorded with a PTR resource record in
   the IN-ADDR.ARPA zone.  Many network services perform a PTR lookup on
   the source address of incoming packets before performing services.

   Some of the most common uses for reverse DNS include:

   o  Building trust.  An administrator who spends time and effort
      properly maintaining DNS records might be assumed to spend time
      and effort on other maintenance, so the network might be more
      trustworthy.

   o  Validating other data.  Information from reverse DNS may be
      compared to information higher in the stack (for instance, mail
      originator), with a lower trustworthiness if they are dissimilar.

   o  Some degree of location information can often be inferred, since
      most administrators create reverse zones corresponding to
      aggregation points, which often correspond with geographical
      areas.  This information is useful for geolocation services and
      for law enforacement.

   Individual Internet users in the residential or consumer scale,
   including small and home businesses, are constantly joining or moving
   on the Internet.  For large Internet service providers who serve
   residential users, maintenance of individual PTR records for is often
   impractical.  Administrators of ISPs should evaluate methods for
   responding to reverse DNS queries in IPv6.

1.1.  Reverse DNS in IPv4

   Internet service providers (ISPs) that provide access to many
   residential users typically assign one or a few IPv4 addresses to
   each of those users, and populate an IN-ADDR.ARPA zone with one PTR
   record for every IPv4 address.  Some ISPs also configure forward
   zones with matching A records, so that lookups match.  For instance,
   if an ISP Example.com aggregated 192.0.2.0/24 at a network hub in
   Anytown in the province of AnyWhere, the reverse zone might look
   like:

         1.2.0.192.IN-ADDR-ARPA.  IN PTR 1.user.anytown.AW.example.com.

         2.2.0.192.IN-ADDR-ARPA.  IN PTR 2.user.anytown.AW.example.com.






Howard & Durand          Expires March 13, 2011                 [Page 3]


Internet-Draft        Reverse DNS in IPv6 for ISPs        September 2010


         3.2.0.192.IN-ADDR-ARPA.  IN PTR 3.user.anytown.AW.example.com.

         .

         .

         .

         254.2.0.192.IN-ADDR-ARPA.  IN PTR
         254.user.anytown.AW.example.com.

   The conscientious Example.com might then also have a zone:

         1.user.anytown.AW.example.com.  IN A 192.0.2.1

         2.user.anytown.AW.example.com.  IN A 192.0.2.2

         3.user.anytown.AW.example.com.  IN A 192.0.2.3

         .

         .

         .

         254.user.anytown.AW.example.com.  IN A 192.0.2.254

   Many ISPs generate PTR records for all IP addresses used for
   customers, and many create the matching A record.

1.2.  Reverse DNS Considerations in IPv6

   The length of individual addresses makes manual zone entries
   cumbersome.  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
         .IP6.ARPA.  IN PTR 1.user.anytown.AW.example.com.

   Since 2^^80 possible addresses could be configured in the 2001:db8:
   f00/48 zone alone, it is impractical to write a zone with every
   possible address entered.  If 1000 entries could be written per
   second, the zone would still not be complete after 38 trillion years.

   Furthermore, since the 64 bits in the host portion of the address are
   frequently assigned using SLAAC[RFC4862]when the host comes online,
   it is not possible to know which addresses may be in use ahead of
   time.



Howard & Durand          Expires March 13, 2011                 [Page 4]


Internet-Draft        Reverse DNS in IPv6 for ISPs        September 2010


   [RFC1912]is an informational document that says "PTR records must
   point back to a valid A record" and further that the administrator
   should "Make sure your PTR and A records match."[RFC1912]DNS
   administrators of residential ISPs should consider how to follow this
   advice for AAAA and PTR RRs in the residential ISP.


2.  Alternatives in IPv6

   Several options existing for providing reverse DNS in IPv6.  All of
   these options also exist for IPv4, but the scaling problem is much
   less severe in IPv4.  Each option should be evaluated for its scaling
   ability, its compliance with existing standards and best practices,
   and its availability in common systems.

2.1.  No Response

   Some ISP DNS administrators may choose to provide only a NXDomain
   response to PTR queries for subscriber addresses.  Providing a
   negative response in response to PTR queries does not satisfy the
   expectation in[RFC1912]for entries to match.  Users of services which
   are dependent on a successful lookup will have a poor experience.
   DNS administrators should consider the uses described above and the
   number of services affecting the number of users when evaluating this
   option.

2.2.  Wildcard match

   The use of wildcards in the DNS is described in[RFC4592], and their
   use in IPv6 reverse DNS is described in[RFC4472].

   While recording all possible addresses is not scalable, it may be
   possible to record a wildcard entry for each prefix assigned to a
   customer.  Consider also that "inclusion of wildcard NS RRSets in a
   zone is discouraged, but not barred."[RFC4035]

   This solution generally scales well.  However, since the response
   will match any address in the wildcard range (/48, /56, /64, etc.), a
   forward DNS lookup on that response given will not be able to return
   the same hostname.  This method therefore fails the expectation in
   [RFC1912] for forward and reverse to match.  DNSsec [RFC4035]
   scalability is limited to signing the wildcard zone, which may be
   satisfactory.

2.3.  Dynamic DNS

   One way to ensure forward and reverse records match is for hosts to
   update DNS servers dynamically, once interface configuration (whether



Howard & Durand          Expires March 13, 2011                 [Page 5]


Internet-Draft        Reverse DNS in IPv6 for ISPs        September 2010


   SLAAC, DHCPv6, or other means) is complete, as described in[RFC4472].
   Hosts would need to provide both AAAA and PTR updates, and would need
   to know which servers would accept the information.

   This option should scale as well or as poorly as IPv4 dynamic DNS
   does.  Dynamic DNS may not scale effectively in large ISP networks
   which have no single master name server.  The ISP's DNS system may
   provide a point for Denial of Service attacks, including many
   attempted dDNS updates.  Accepting updates only from authenticated
   sources may mitigate this risk, but only if authentication itself
   does not require excessive overhead.  No authentication of dynamic
   DNS updates is inherently provided; implementers should consider use
   of TSIG[RFC2535], or at least ingress filtering so updates are only
   accepted from customer address space from internal network
   interfaces.  UDP is allowed per[RFC2136]so transmission control is
   not assured, though the host should expect an ERROR or NOERROR
   message from the server[RFC2136]; TCP provides transmission control,
   but the updating host would need to be configured to use TCP.

   Administrators should consider what domain will contain the records,
   and who will provide the names.  If subscribers provide hostnames,
   they may provide inappropriate strings.  Consider "ihate.example.com"
   or "badword.customer.example.com" or
   "celebrityname.committed.illegal.acts.example.com."

2.3.1.  Dynamic DNS from Individual Hosts

   In the simplest case, a residential user will have a single host
   connected to the ISP.  Since the typical residential user cannot
   configure IPv6 addresses and resolving name servers on their hosts,
   the ISP should provide address information conventionally (i.e.,
   their normal combination of RAs, DHCP, etc.), and should provide a
   DNS Recursive Name Server and Domain Search List via DHCPv6 as
   described in[RFC3646].  In determining its Fully Qualified Domain
   Name, hosts typically use a domain from the Domain Search List.  This
   is an overloading of the parameter; multiple domains could be listed,
   since hosts may need to search for unqualified names in multiple
   domains, without necessarily being a member of those domains.
   Administrators should consider whether the domain search list
   actually provides an appropriate DNS suffix(es) when considering use
   of this option.  For purposes of dynamic DNS, the host would
   concatenate its local hostname (e.g., "hostname") plus the domain(s)
   in the Domain Search List (e.g., "customer.example.com"), as in
   "hostname.customer.example.com."

   Once it learns its address, and has a resolving name server, the host
   must perform an SOA lookup on the ip6.arpa record to be added, to
   find the owner, which will lead to the SOA record.  Several recursive



Howard & Durand          Expires March 13, 2011                 [Page 6]


Internet-Draft        Reverse DNS in IPv6 for ISPs        September 2010


   lookups may be required to find the longest prefix which has been
   delegated.  The DNS administrator must designate the Primary Master
   Server for the longest match required.  Once found, the host sends
   dynamic AAAA and PTR updates using the concatenation defined above
   ("hostname.customer.example.com").

   In order to use this alternative, hosts must be configured to use
   dynamic DNS.  This is not default behavior for many hosts, which is
   an inhibitor for the large ISP.

2.3.2.  Dynamic DNS through Residential Gateways

   Residential customers may have a gateway, which may provide DHCPv6
   service to hosts from a delegated prefix.  ISPs should provide a DNS
   Recursive Name Server and Domain Search List to the gateway, as
   described above and in[RFC3646].  There are two options for how the
   gateway uses this information.  The first option is for the gateway
   to respond to DHCPv6 requests with the same DNS Recursive Name Server
   and Domain Search List provided by the ISP.  The alternate option is
   for the gateway to relay dynamic DNS updates from hosts to the
   servers and domain provided by the ISP.  Host behavior is unchanged;
   they should provide updates to the ISP's servers as described above.

2.3.3.  Dynamic DNS Delegations

   An ISP may delegate authority for a subdomain such as
   "customer12345.anytown.AW.customer.example.com" or
   "customer12345.example.com" to the customer's gateway.  Each domain
   thus delegated must be unique within the DNS.  The ISP may also then
   delegate the ip6.arpa zone for the prefix delegated to the customer,
   as in (for 2001:db8:f00::/48) "0.0.f.0.8.b.d.0.1.0.0.2.ip6.arpa."
   Then the customer could provide updates to their own gateway, with
   forward and reverse.  However, individual hosts connected directly to
   the ISP rarely have the capability to run DNS for themselves;
   therefore, an ISP can only delegate to customers with gateways
   capable of being authoritative name servers.  If a device requests a
   DHCPv6 Prefix Delegation, that may be considered a reasonably
   reliable indicator that it is a gateway, rather than an individual
   host.  It is not necessarily an indicator that the gateway is capable
   of providing DNS services, and therefore cannot be relied upon as a
   way to test whether this option is feasible.

   If the customer's gateway is the name server, it provides its own
   information to hosts on the network, as normally done for enterprise
   networks, and as described in[RFC2136].

   An ISP may elect to provide authoritative responses as a secondary
   server to the customer's primary server.



Howard & Durand          Expires March 13, 2011                 [Page 7]


Internet-Draft        Reverse DNS in IPv6 for ISPs        September 2010


   To implement this alternative, users' residential gateways must be
   capable of acting as authoritative name servers capable of dynamic
   DNS updates.

2.3.4.  Generate Dynamic Records

   An ISP's name server that receives a dynamic forward or reverse DNS
   update may create a matching entry.  Since a host capable of updating
   one is generally capable of updating the other, this should not be
   required, but redundant record creation will ensure a record exists.
   ISPs implementing this method should check whether a record already
   exists before accepting or creating updates.

   This method is also dependent on hosts being capable of providing
   dynamic DNS updates, which is not default behavior for many hosts.

2.3.5.  Populate from DHCP Server

   A ISP's DHCPv6 server may populate the forward and reverse zones when
   the DHCP request is received, if the request contains enough
   information.[RFC4702]

   However, this method will only work for a single host address; the
   ISP's DHCP server would not have enough information to update all
   records for a prefix delegation.  If the zone authority is delegated
   to a home gateway which used this method, the gateway could update
   records for residential hosts.  To implement this alternative, users'
   residential gateways must support the FQDN DHCP option.

2.4.  Delegate DNS

   For customers who are able to run their own DNS servers, such as
   commercial customers, often the best option is to delegate the
   reverse DNS zone to them, as described in[RFC2317].  However, since
   most residential users have neither the equipment nor the expertise
   to run DNS servers, this method is unavailable to residential ISPs.

   This is a general case of the specific case described
   inSection 2.3.3.  All of the same considerations still apply.

2.5.  Dynamically Generate PTR When Queried ("On the Fly")

   Common practice in IPv4 is to provide PTR records for all addresses,
   regardless of whether a host is actually using the address.  In IPv6,
   ISPs may generate PTR records for all IPv6 addresses as the records
   are requested.  Configuring records "on the fly" may consume more
   processor resource than other methods, but only on demand.  A denial
   of service is therefore possible, but with rate-limiting and normal



Howard & Durand          Expires March 13, 2011                 [Page 8]


Internet-Draft        Reverse DNS in IPv6 for ISPs        September 2010


   countermeasures, this risk is no higher than with other options.

   An ISP using this option should generate a PTR record on demand, and
   cache or prepopulate the forward (AAAA) entry for the duration of the
   time-to-live of the PTR.  This option has the advantage of assuring
   matching forward and reverse entries, while being simpler than
   dynamic DNS.  Administrators should consider whether the lack of
   user-specified hostnames is a drawback.

   This method may not scale well in conjunction with DNSsec[RFC4035],
   because of the additional load, but since keys may be pregenerated
   for zones, and not for each record, the risk is moderate.

   Another consideration is that the algorithm used for generating the
   record must be the same on all servers for a zone.  In other words,
   any server for the zone must produce the same response for a given
   query.  Administrators managing a variety of rules within a zone
   might find it difficult to keep those rules synchronized on all
   servers.


3.  Recommendations

   The best option is for ISPs to delegate authority along with address
   delegation.  Where users do not operate authoritative name servers,
   the next best option is dynamic DNS updates.  Where dynamic DNS is
   impractical, the next best option is to dynamically generate PTR
   records when queried.


4.  Security Considerations

4.1.  Using Reverse DNS for Security

   Some people think the existence of reverse DNS records, or matching
   forward and reverse DNS records, provides useful information about
   the hosts with those records.  For example, one might infer that the
   administrator of a network with properly configured DNS records was
   better-informed, and by further inference more responsible, than the
   administrator of a less-thoroughly configured network.  For instance,
   most email providers will not accept incoming connections on port 25
   unless forward and reverse DNS entries match.  If they match, but
   information higher in the stack (for instance, mail source) is
   inconsistent, the packet is questionable.  These records may be
   easily forged though, unless DNSsec or other measures are taken.  The
   string of inferences is questionable, and may become unneeded if
   other means for evaluating trustworthiness (such as positive
   reputations) become predominant in IPv6.



Howard & Durand          Expires March 13, 2011                 [Page 9]


Internet-Draft        Reverse DNS in IPv6 for ISPs        September 2010


   Providing location information in PTR records is useful for
   troubleshooting, law enforcement, and geolocation services, but for
   the same reasons can be considered sensitive information.

4.2.  DNS Security with Dynamic DNS

   Security considerations of using dynamic DNS are described
   in[RFC3007].  DNS Security Extensions are documented inRFC2535
   [RFC2535].

   Interactions with DNSsec are described throughout this document.

4.3.  Considerations for Other Uses of the DNS

   Several methods exist for providing encryption keys in the DNS.  Any
   of the options presented here may interfere with these key
   techniques.


5.  IANA Considerations

   There are no IANA considerations or implications that arise from this
   document.


6.  References

6.1.  Normative References

   [RFC1033]  Lottor, M., "Domain Administrators Operators Guide",
              November 1987.

   [RFC1034]  Mockapetris, P., "Domain Names - Concepts and Facilities",
              November 1987.

   [RFC1912]  Barr, D., "Common DNS Operational and Configuration
              Errors", February 1996.

   [RFC2136]  Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
              "Dynamic Updates in the Domain Name System (DNS UPDATE)",
              April 1917.

   [RFC2845]  Vixie, P., Gudmundsson , O., Eastlake 3rd , D., and B.
              Wellington, "Secret Key Transaction Authentication for DNS
              (TSIG)", May 2000.

   [RFC3007]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
              Update", November 2000.



Howard & Durand          Expires March 13, 2011                [Page 10]


Internet-Draft        Reverse DNS in IPv6 for ISPs        September 2010


   [RFC3646]  Droms, R., Ed., "DNS Configuration options for Dynamic
              Host Configuration Protocol for IPv6 (DHCPv6)",
              December 2003.

   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Protocol Modifications for the DNS Security
              Extensions", March 2005.

   [RFC4592]  Lewis, E., "The Role of Wildcards in the Domain Name
              System", July 2006.

   [RFC4702]  Stapp, M., Volz, Y., and Y. Rekhter, "The Dynamic Host
              Configuration Protocol (DHCP) Client Fully Qualified
              Domain Name (FQDN) Option".

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", September 2007.

   [RFC883]   Mockapetris, P., "Domain names: Implementation
              specification", November 1983,
              <http://tools.ietf.org/html/rfc883>.

6.2.  Informative References

   [RFC2317]  Eidnes, H., de Groot, G., and P. Vixie, "Classless IN-
              ADDR.ARPA delegation", March 1998.

   [RFC2535]  Eastlake, D., "Domain Name System Security Extensions",
              March 1999.

   [RFC2672]  Crawford, M., "Non-Terminal DNS Name Redirection",
              August 1999.

   [RFC4339]  Jeong, J., Ed., "IPv6 Host Configuration of DNS Server
              Information Approaches", February 2006.

   [RFC4472]  Durand, A., Ihren, J., and P. Savola, "Operational
              Considerations and Issues with IPv6 DNS", April 2006.

   [inaddr-reqd]
              Senie, D., "draft-ietf-dnsop-inaddr-required-07",
              August 2005.

   [rmap-consider]
              Senie, D. and A. Sullivan,
              "draft-ietf-dnsop-reverse-mapping-considerations-06",
              March 2008.




Howard & Durand          Expires March 13, 2011                [Page 11]


Internet-Draft        Reverse DNS in IPv6 for ISPs        September 2010


Authors' Addresses

   Lee Howard
   Time Warner Cable
   13820 Sunrise Valley Drive
   Herndon, VA  20171
   US

   Email: lee.howard@twcable.com


   Alain Durand
   Comcast
   1 Comcast center
   Philadelphia, PA  19103
   US

   Phone:
   Email: alain_durand@cable.comcast.com
































Howard & Durand          Expires March 13, 2011                [Page 12]


Html markup produced by rfcmarkup 1.121, available from https://tools.ietf.org/tools/rfcmarkup/