Code change:
…ument, dealing with issue
handling different views (7.0) .... some would like to have different views, This document deals with the view that the Internet gets from the CPE(s) only.

Related discussion:
text: 7. <del> The Homenet Zone provides information about the home network.  Some users may be tempted to have provide responses dependent on the origin of the DNS query.  More specifically, some users may be tempted to provide a different view for DNS queries originating from the home network and for DNS queries coming from the Internet.  Each view could then be associated with a dedicated Homenet Zone. <!--Regarding {{fig-naming-arch}}, an example of an implementation of two distinct view could be the Homenet Zone that describes the homenet view and the Public Homenet Zone that contains the Internet view, with these two zones being different.--> Note that this document does not specify how DNS queries originating from the home network are addressed to the Homenet Zone.  This could be done via hosting the DNS resolver on the HNA for example. This section is not normative. sec-reasons details why some nodes may only be reachable from the home network and not from the global Internet. sec-consequences briefly describes the consequences of having distinct views such as a "home network view" and an "Internet view".  Finally, sec-guidance provides guidance on how to resolve names that are only significant in the home network, without creating different views. 7.1. The motivation for supporting different views is to provide different answers dependent on the origin of the DNS query, for reasons such as: 1: An end user may want to have services not published on the Internet.  Services like the HNA administration interface that provides the GUI to administer your HNA might not seem advisable to publish on the Internet.  Similarly, services like the mapper that registers the devices of your home network may also not be desirable to be published on the Internet.  In both cases, these services should only be known or used by the network administrator.  To restrict the access of such services, the home network administrator may choose to publish these pieces of information only within the home network, where it might be assumed that the users are more trusted than on the Internet.  Even though this assumption may not be valid, at least this may reduce the surface of any attack. 2: Services within the home network may be reachable using non global IP addresses.  IPv4 and NAT may be one reason.  On the other hand IPv6 may favor link-local or site-local IP addresses.  These IP addresses are not significant outside the boundaries of the home network.  As a result, they MAY be published in the home network view, and SHOULD NOT be published in the Public Homenet Zone. 7.2. Enabling different views leads to a non-coherent naming system. Depending on where resolution is performed, some services will not be available.  This may be especially inconvenient with devices with multiple interfaces that are attached both to the Internet via a 3G/4G interface and to the home network via a WLAN interface. Devices may also cache the results of name resolution, and these cached entries may no longer be valid if a mobile device moves between a homenet connection and an internet connection e.g. a device temporarily loses wifi signal and switches to 3G. Regarding local-scope IP addresses, such devices may end up with poor connectivity.  Suppose, for example, that DNS resolution is performed via the WLAN interface attached to the HNA, and the response provides local-scope IP addresses, but the communication is initiated on the 3G/4G interface.  Communications with local-scope addresses will be unreachable on the Internet, thus aborting the communication.  The same situation occurs if a device is flip / flopping between various WLAN networks. Regarding DNSSEC, if the HNA does not sign the Homenet Zone and outsources the signing process, the two views are different, because one is protected with DNSSEC whereas the other is not.  Devices with multiple interfaces will have difficulty securing the naming resolution, as responses originating from the home network may not be signed. For devices with all its interfaces attached to a single administrative domain, that is to say the home network, or the Internet.  Incoherence between DNS responses may still also occur if the device is able to perform DNS resolutions both using the DNS resolving server of the home network, or one of the ISP.  DNS resolution performed via the HNA or the ISP resolver may be different than those performed over the Internet. 7.3. As documented in sec-consequences, it is RECOMMENDED to avoid different views.  If network administrators choose to implement multiple views, impacts on devices' resolution SHOULD be evaluated. As a consequence, the Homenet Zone is expected to be an exact copy of the Public Homenet Zone.  As a result, services that are not expected to be published on the Internet SHOULD NOT be part of the Homenet Zone, local-scope addresses SHOULD NOT be part of the Homenet Zone, and when possible, the HNA SHOULD sign the Homenet Zone. The Homenet Zone is expected to host public information only.  It is not the scope of the DNS service to define local home network boundaries.  Instead, local scope information is expected to be provided to the home network using local scope naming services. mDNS RFC6762 DNS-SD RFC6763 are two examples of these services.  Currently mDNS is limited to a single link network.  However, future protocols are expected to leverage this constraint as pointed out in RFC7558. 7.4. </del> This section is focused on the Homenet Reverse Zone. Firstly, all considerations for the Homenet Zone apply to the Homenet