Skip to main content

IPv6 Router Advertisement Options for DNS Configuration
draft-ietf-6man-rdnss-rfc6106bis-15

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 8106.
Authors Jaehoon Paul Jeong , Soohong Daniel Park , Luc Beloeil , Syam Madanapalli
Last updated 2017-01-27 (Latest revision 2017-01-17)
Replaces draft-jeong-6man-rdnss-rfc6106-bis
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state Submitted to IESG for Publication
Document shepherd Fernando Gont
Shepherd write-up Show Last changed 2016-09-21
IESG IESG state Became RFC 8106 (Proposed Standard)
Consensus boilerplate Yes
Telechat date (None)
Responsible AD Suresh Krishnan
Send notices to "Fernando Gont" <fgont@si6networks.com>, bob.hinden@gmail.com, otroan@employees.org
IANA IANA review state IANA OK - Actions Needed
IANA action state RFC-Ed-Ack
RFC Editor RFC Editor state EDIT
Details
draft-ietf-6man-rdnss-rfc6106bis-15
field is set to a multiple of 8 octets to accommodate
                   all the domain names in the field of Domain Names of
                   DNS Search List.

     Lifetime      32-bit unsigned integer.  The maximum time in
                   seconds (relative to the time the packet is received)
                   over which these DNSSL domain names MAY be used for
                   name resolution.  The Lifetime value has the same
                   semantics as with the RDNSS option.  That is,
                   Lifetime SHOULD by default be at least
                   3 * MaxRtrAdvInterval.  A value of all one bits
                   (0xffffffff) represents infinity.  A value of zero
                   means that the DNSSL domain names MUST no longer be
                   used.

     Domain Names of DNS Search List
                   One or more domain names of DNS Search List that MUST
                   be encoded as described in Section 3.1 of [RFC1035].
                   By this technique, each domain name is represented as
                   a sequence of labels ending in a zero octet, defined
                   as domain name representation.  For more than one
                   domain name, the corresponding domain name
                   representations are concatenated as they are.  Note
                   that for the simple decoding, the domain names MUST
                   NOT be encoded in a compressed form, as described in
                   Section 4.1.4 of [RFC1035].  Because the size of this
                   field MUST be a multiple of 8 octets, for the minimum
                   multiple including the domain name representations,
                   the remaining octets other than the encoding parts of
                   the domain name representations MUST be padded with
                   zeros.

5.3.  Procedure of DNS Configuration

   The procedure of DNS configuration through the RDNSS and DNSSL
   options is the same as with any other ND option [RFC4861].

5.3.1.  Procedure in IPv6 Hosts

   When an IPv6 host receives DNS options (i.e., RDNSS and DNSSL
   options) through RA messages, it processes the options as follows:

   o  The validity of DNS options is checked with the Length field; that
      is, the value of the Length field in the RDNSS option is greater
      than or equal to the minimum value (3), and satisfies that (Length
      - 1) % 2 == 0.  The value of the Length field in the DNSSL option
      is greater than or equal to the minimum value (2).  Also, the
      validity of the RDNSS option is checked with the "Addresses of

Jeong, et al.             Expires July 21, 2017                 [Page 8]
Internet-Draft             IPv6 DNS RA Options              January 2017

      IPv6 Recursive DNS Servers" field; that is, the addresses should
      be unicast addresses.

   o  If the DNS options are valid, the host SHOULD copy the values of
      the options into the DNS Repository and the Resolver Repository in
      order.  Otherwise, the host MUST discard the options.  Refer to
      Section 6 for the detailed procedure.

   In the case where the DNS information of RDNSS and DNSSL can be
   obtained from multiple sources, such as RA and DHCP, the IPv6 host
   SHOULD keep some DNS options from all sources.  Unless explicitly
   specified for the discovery mechanism, the exact number of addresses
   and domain names to keep is a matter of local policy and
   implementation choice as a local configuration option.  However, in
   the case of multiple sources, the ability to store a total of at
   least three RDNSS addresses (or DNSSL domain names) from the multiple
   sources is RECOMMENDED.  The DNS options from Router Advertisements
   and DHCP SHOULD be stored into the DNS Repository and Resolver
   Repository so that information from DHCP appears there first and
   therefore takes precedence.  Thus, the DNS information from DHCP
   takes precedence over that from RA for DNS queries.  On the other
   hand, for DNS options announced by RA, if some RAs use the Secure
   Neighbor Discovery (SEND) protocol [RFC3971] for RA security, they
   MUST be preferred over those that do not use SEND.  Also, DNS options
   announced by RA via SEND MUST be preferred over those announced by
   un-authenticated DHCP [RFC3118].  Refer to Section 7 for the detailed
   discussion on SEND for DNS RA options.

5.3.2.  Warnings for DNS Options Configuration

   There are two warnings for DNS options configuration: (i) warning for
   multiple sources of DNS options and (ii) warning for multiple network
   interfaces.  First, in the case of multiple sources for DNS options
   (e.g., RA and DHCP), an IPv6 host can configure its IP addresses from
   these sources.  In this case, it is not possible to control how the
   host uses DNS information and what source addresses it uses to send
   DNS queries.  As a result, configurations where different information
   is provided by different mechanisms for autoconfiguration may lead to
   problems.  Therefore, the network administrator needs to carefully
   configure different DNS options in the multiple mechanisms for
   autoconfiguration in order to minimize the impact of such problems
   [DHCPv6-SLAAC].

   Second, if different DNS information is provided on different network
   interfaces, this can lead to inconsistent behavior.  The IETF worked
   on solving this problem for both DNS and other information obtained
   by multiple interfaces [RFC6418][RFC6419], and standardized the
   solution for RDNSS selection for multi-interfaced nodes in [RFC6731],

Jeong, et al.             Expires July 21, 2017                 [Page 9]
Internet-Draft             IPv6 DNS RA Options              January 2017

   which is based on DHCP.

6.  Implementation Considerations

   The implementation considerations in this document include the
   following three: (i) DNS repository management, (ii) synchronization
   between DNS server list and resolver repository, and (iii)
   synchronization between DNS search list and resolver repository.

   Note:  The implementations that are updated according to this
      document will still interoperate with the existing implementations
      according to [RFC6106].  This is because the main change of this
      document is the increase of the default Lifetime of DNS options,
      considering lossy links.

6.1.  DNS Repository Management

   For DNS repository management, the following two data structures
   SHOULD be synchronized with the resolver repository: (i) DNS Server
   List that keeps the list of RDNSS addresses and (ii) DNS Search List
   that keeps the list of DNS search domain names.  Each entry in these
   two lists consists of a pair of an RDNSS address (or DNSSL domain
   name) and Expiration-time as follows:

   o  RDNSS address for DNS Server List: IPv6 address of the Recursive
      DNS Server which is available for recursive DNS resolution service
      in the network advertising the RDNSS option.

   o  DNSSL domain name for DNS Search List: DNS suffix domain name
      which is used to perform DNS query searches for short, unqualified
      domain names.

   o  Expiration-time for DNS Server List or DNS Search List: The time
      when this entry becomes invalid.  Expiration-time is set to the
      value of the Lifetime field of the RDNSS option or DNSSL option
      plus the current time.  Whenever a new RDNSS option with the same
      address (or DNSSL option with the same domain name) is received on
      the same interface as a previous RDNSS option (or DNSSL option),
      this field is updated to have a new Expiration-time.  When the
      current time becomes larger than Expiration-time, this entry is
      regarded as expired, so it should not be used any more.  Note that
      the DNS information for the RDNSS and DNSSL options need not be
      dropped if the expiry of the RA router lifetime happens.  This is
      because these options have their own lifetime values.

Jeong, et al.             Expires July 21, 2017                [Page 10]
Internet-Draft             IPv6 DNS RA Options              January 2017

6.2.  Synchronization between DNS Server List and Resolver Repository

   When an IPv6 host receives the information of multiple RDNSS
   addresses within a network (e.g., campus network and company network)
   through an RA message with RDNSS option(s), it stores the RDNSS
   addresses (in order) into both the DNS Server List and the Resolver
   Repository.  The processing of the RDNSS consists of (i) the
   processing of RDNSS option(s) included in an RA message and (ii) the
   handling of expired RDNSSes.  The processing of RDNSS option(s) is as
   follows:

      Step (a): Receive and parse the RDNSS option(s).  For the RDNSS
      addresses in each RDNSS option, perform Steps (b) through (d).

      Step (b): For each RDNSS address, check the following: If the
      RDNSS address already exists in the DNS Server List and the RDNSS
      option's Lifetime field is set to zero, delete the corresponding
      RDNSS entry from both the DNS Server List and the Resolver
      Repository in order to prevent the RDNSS address from being used
      any more for certain reasons in network management, e.g., the
      termination of the RDNSS or a renumbering situation.  That is, the
      RDNSS can resign from its DNS service because the machine running
      the RDNSS is out of service intentionally or unintentionally.
      Also, under the renumbering situation, the RDNSS's IPv6 address
      will be changed, so the previous RDNSS address should not be used
      any more.  The processing of this RDNSS address is finished here.
      Otherwise, go to Step (c).

      Step (c): For each RDNSS address, if it already exists in the DNS
      Server List and the RDNSS option's Lifetime field is not set to
      zero, then just update the value of the Expiration-time field
      according to the procedure specified in the third bullet of
      Section 6.1.  Otherwise, go to Step (d).

      Step (d): For each RDNSS address, if it does not exist in the DNS
      Server List, register the RDNSS address and Lifetime with the DNS
      Server List and then insert the RDNSS address as the first one in
      the Resolver Repository.  In the case where the data structure for
      the DNS Server List is full of RDNSS entries (that is, has more
      RDNSSes than the sufficient number discussed in Section 5.3.1),
      delete from the DNS Server List the entry with the shortest
      Expiration-time (i.e., the entry that will expire first).  The
      corresponding RDNSS address is also deleted from the Resolver
      Repository.  For the ordering of RDNSS addresses in an RDNSS
      option, position the first RDNSS address in the RDNSS option as
      the first one in the Resolver Repository, the second RDNSS address
      in the option as the second one in the repository, and so on.
      This ordering allows the RDNSS addresses in the RDNSS option to be

Jeong, et al.             Expires July 21, 2017                [Page 11]
Internet-Draft             IPv6 DNS RA Options              January 2017

      preferred according to their order in the RDNSS option for the DNS
      name resolution.  The processing of these RDNSS addresses is
      finished here.

   The handling of expired RDNSSes is as follows: Whenever an entry
   expires in the DNS Server List, the expired entry is deleted from the
   DNS Server List, and also the RDNSS address corresponding to the
   entry is deleted from the Resolver Repository.

6.3.  Synchronization between DNS Search List and Resolver Repository

   When an IPv6 host receives the information of multiple DNSSL domain
   names within a network through an RA message with DNSSL option(s), it
   stores the DNSSL domain names (in order) into both the DNS Search
   List and the Resolver Repository.  The processing of the DNSSL
   consists of (i) the processing of DNSSL option(s) included in an RA
   message and (ii) the handling of expired DNSSLs.  The processing of
   DNSSL option(s) is the same with that of RDNSS option(s) in Section
   6.2.

7.  Security Considerations

   In this section, we analyze security threats related to DNS options
   and then suggest recommendations to cope with such security threats.

7.1.  Security Threats

   For the RDNSS option, an attacker could send an RA with a fraudulent
   RDNSS address, misleading IPv6 hosts into contacting an unintended
   DNS server for DNS name resolution.  Also, for the DNSSL option, an
   attacker can let IPv6 hosts resolve a host name without a DNS suffix
   into an unintended host's IP address with a fraudulent DNS Search
   List.  These attacks are similar to ND attacks specified in [RFC4861]
   that use Redirect or Neighbor Advertisement messages to redirect
   traffic to individual addresses of malicious parties.

   However, the security of these RA options for DNS configuration does
   not affect ND protocol security [RFC4861].  This is because learning
   DNS information via the RA options cannot be worse than learning bad
   router information via the RA options.  Therefore, the vulnerability
   of ND is not worse and is a subset of the attacks that any node
   attached to a LAN can do.

7.2.  Recommendations

   The Secure Neighbor Discovery (SEND) protocol [RFC3971] is designed
   as a security mechanism for ND.  In this case, ND can use SEND to
   allow all the ND options including the RDNSS and DNSSL options to be

Jeong, et al.             Expires July 21, 2017                [Page 12]
Internet-Draft             IPv6 DNS RA Options              January 2017

   automatically signed with digital signatures.

   It is common for network devices such as switches to include
   mechanisms to block unauthorized ports from running a DHCPv6 server
   to provide protection from rogue DHCPv6 servers [RFC7610].  That
   means that an attacker on other ports cannot insert bogus DNS servers
   using DHCPv6.  The corresponding technique for network devices is
   RECOMMENDED to block rogue Router Advertisement messages including
   the RDNSS and DNSSL options from unauthorized nodes [RFC6104]
   [RFC6105].

   An attacker may provide a bogus DNS Search List option in order to
   cause the victim to send DNS queries to a specific DNS server when
   the victim queries non-FQDNs (fully qualified domain names).  For
   this attack, the DNS resolver in IPv6 hosts can mitigate the
   vulnerability with the recommendations mentioned in [RFC1535],
   [RFC1536], and [RFC3646].

8.  IANA Considerations

   The RDNSS option defined in this document uses the IPv6 Neighbor
   Discovery Option type assigned by the IANA as follows:

                 Option Name                   Type
                 Recursive DNS Server Option   25

   The DNSSL option defined in this document uses the IPv6 Neighbor
   Discovery Option type assigned by the IANA as follows:

                 Option Name                   Type
                 DNS Search List Option        31

   These options are registered in the "Internet Control Message
   Protocol version 6 (ICMPv6) Parameters" registry [ICMPv6].

9.  Acknowledgements

   This document has greatly benefited from inputs by Robert Hinden,
   Pekka Savola, Iljitsch van Beijnum, Brian Haberman, Tim Chown, Erik
   Nordmark, Dan Wing, Jari Arkko, Ben Campbell, Vincent Roca, Tony
   Cheneau, Fernando Gont, Jen Linkova, Ole Troan, Mark Smith, Tatuya
   Jinmei, Lorenzo Colitti, Tore Anderson, David Farmer, Bing Liu, and
   Tassos Chatzithomaoglou.  The authors sincerely appreciate their
   contributions.

   This document was supported by Institute for Information &
   communications Technology Promotion (IITP) grant funded by the Korea
   government (MSIP) [10041244, Smart TV 2.0 Software Platform].

Jeong, et al.             Expires July 21, 2017                [Page 13]
Internet-Draft             IPv6 DNS RA Options              January 2017

10.  References

10.1.  Normative References

   [RFC2119]       Bradner, S., "Key words for use in RFCs to Indicate
                   Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4861]       Narten, T., Nordmark, E., Simpson, W., and H.
                   Soliman, "Neighbor Discovery for IP version 6
                   (IPv6)", RFC 4861, September 2007.

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

   [RFC1035]       Mockapetris, P., "Domain Names - Implementation and
                   Specification", STD 13, RFC 1035, November 1987.

   [RFC4007]       Deering, S., Haberman, B., Jinmei, T., Nordmark, E.,
                   and B. Zill, "IPv6 Scoped Address Architecture",
                   RFC 4007, March 2005.

10.2.  Informative References

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

   [RFC3315]       Droms, R., Bound, J., Volz, B., Lemon, T., Perkins,
                   C., and M. Carney, "Dynamic Host Configuration
                   Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.

   [RFC3736]       Droms, R., "Stateless Dynamic Host Configuration
                   Protocol (DHCP) Service for IPv6", RFC 3736,
                   April 2004.

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

   [RFC6106]       Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
                   "IPv6 Router Advertisement Options for DNS
                   Configuration", RFC 6106, November 2010.

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

   [RFC3971]       Arkko, J., Kempf, J., Zill, B., and P. Nikander,
                   "SEcure Neighbor Discovery (SEND)", RFC 3971,

Jeong, et al.             Expires July 21, 2017                [Page 14]
Internet-Draft             IPv6 DNS RA Options              January 2017

                   March 2005.

   [RFC3118]       Droms, R. and W. Arbaugh, "Authentication for DHCP
                   Messages", RFC 3118, June 2001.

   [RFC6104]       Chown, T. and S. Venaas, "Rogue IPv6 Router
                   Advertisement Problem Statement", RFC 6104,
                   February 2011.

   [RFC6105]       Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C.,
                   and J. Mohacsi, "IPv6 Router Advertisement Guard",
                   RFC 6105, February 2011.

   [RFC7610]       Gont, F., Liu, W., and G. Van de Velde, "DHCPv6-
                   Shield: Protecting against Rogue DHCPv6 Servers",
                   RFC 7610, August 2015.

   [RFC1535]       Gavron, E., "A Security Problem and Proposed
                   Correction With Widely Deployed DNS Software",
                   RFC 1535, October 1993.

   [RFC1536]       Kumar, A., Postel, J., Neuman, C., Danzig, P., and S.
                   Miller, "Common DNS Implementation Errors and
                   Suggested Fixes", RFC 1536, October 1993.

   [DHCPv6-SLAAC]  Liu, B., Jiang, S., Gong, X., Wang, W., and E. Rey,
                   "DHCPv6/SLAAC Interaction Problems on Address and DNS
                   Configuration",
                   draft-ietf-v6ops-dhcpv6-slaac-problem-07 (work in
                   progress), August 2016.

   [RFC6418]       Blanchet, M. and P. Seite, "Multiple Interfaces and
                   Provisioning Domains Problem Statement", RFC 6418,
                   November 2011.

   [RFC6419]       Wasserman, M. and P. Seite, "Current Practices for
                   Multiple-Interface Hosts", RFC 6419, November 2011.

   [RFC6731]       Savolainen, T., Kato, J., and T. Lemon, "Improved
                   Recursive DNS Server Selection for Multi-Interfaced
                   Nodes", RFC 6731, December 2012.

   [ICMPv6]        ICMPv6 Parameters Registry, "http://www.iana.org/
                   assignments/icmpv6-parameters/
                   icmpv6-parameters.xhtml#icmpv6-parameters-5".

Jeong, et al.             Expires July 21, 2017                [Page 15]
Internet-Draft             IPv6 DNS RA Options              January 2017

Appendix A.  Changes from RFC 6106

   The following changes were made from RFC 6106 "IPv6 Router
   Advertisement Options for DNS Configuration":

   o  This document allows a higher default value of the lifetime of the
      DNS RA options than RFC 6106 in order to avoid the frequent expiry
      of the options on links with a relatively high rate of packet
      loss, and also making additional clarifications.  The lifetime's
      lower bound of 2 * MaxRtrAdvInterval was shown to lead to the
      expiry of these options on links with a relatively high rate of
      packet loss.  This revision relaxes the lower bound and sets a
      higher default value of 3 * MaxRtrAdvInterval to avoid this
      problem.

   o  The generation of Router Solicitation to ensure that the RDNSS
      information is fresh before the expiry of the RDNSS option is
      removed in order to prevent multicast traffic on the link from
      increasing.

   o  The addresses for recursive DNS servers in the RDNSS option can be
      not only global addresses, but also link-local addresses.  The
      link-local addresses for RDNSSes should be registered into the
      resolver repository along with the corresponding link zone
      indices.

   o  RFC 6106 recommended that the number of RDNSS addresses that
      should be learned and maintained through the RDNSS RA option
      should be limited to three.  This document removes that
      recommendation, thus the number of RDNSS addresses to maintain is
      determined by an implementer's local policy.

   o  RFC 6106 recommended that the number of DNS search domains that
      should be learned and maintained through the DNSSL RA option
      should be limited to three.  This document removes that
      recommendation, thus when the set of unique DNSSL values are not
      equivalent, none of them may be ignored for hostname lookups
      according to an implementer's local policy.

   o  The guidance of the specific implementation for the
      synchronization of the DNS Repository and Resolver Repository on
      the kernel space and user space is removed.

   o  The usage of the keywords of SHOULD and RECOMMENDED in RFC 2119 is
      removed in the recommendation of using SEND for secure ND.
      Instead of using these keywords, SEND is specified as only a
      possible solution for secure ND.

Jeong, et al.             Expires July 21, 2017                [Page 16]
Internet-Draft             IPv6 DNS RA Options              January 2017

Authors' Addresses

   Jaehoon Paul Jeong
   Department of Software
   Sungkyunkwan University
   2066 Seobu-Ro, Jangan-Gu
   Suwon, Gyeonggi-Do  16419
   Republic of Korea

   Phone: +82 31 299 4957
   Fax:   +82 31 290 7996
   EMail: pauljeong@skku.edu
   URI:   http://iotlab.skku.edu/people-jaehoon-jeong.php

   Soohong Daniel Park
   Software R&D Center
   Samsung Electronics
   Seoul R&D Campus D-Tower, 56, Seongchon-Gil, Seocho-Gu
   Seoul  06765
   Republic of Korea

   EMail: soohong.park@samsung.com

   Luc Beloeil
   France Telecom R&D
   42, rue des coutures
   BP 6243
   14066 CAEN Cedex 4
   France

   Phone: +33 2 40 44 97 40
   EMail: luc.beloeil@orange-ftgroup.com

   Syam Madanapalli
   iRam Technologies
   #H304, Shriram Samruddhi, Thubarahalli
   Bangalore - 560066
   India

   EMail: smadanapalli@gmail.com

Jeong, et al.             Expires July 21, 2017                [Page 17]