Internet Engineering Task Force (IETF)                       S. Cheshire
Request for Comments: 8766                                    Apple Inc.
Category: Standards Track                                       May 2020
ISSN: 2070-1721


       Discovery Proxy for Multicast DNS-Based Service Discovery

...

5.5.  Data Translation

   For the delegated rich-text and LDH subdomains, generating
   appropriate Multicast DNS queries involves translating from the
   configured DNS domain (e.g., "Building 1.example.com") on the Unicast
   DNS side to ".local" on the Multicast DNS side.

   For the delegated reverse-mapping subdomain, generating appropriate
   Multicast DNS queries involves using the appropriate API mechanism to
   indicate that a query should be performed using Multicast DNS, as
   described in Section 5.4.

   Generating appropriate Unicast DNS responses from the received
   Multicast DNS answers involves translating back from ".local" to the
   appropriate configured Unicast DNS domain as necessary, as described
   below.

   In the examples below, the delegated subdomains are as follows:

   Delegated subdomain for rich-text names       Building 1.example.com.
   Delegated subdomain for LDH names                 bldg-1.example.com.
   Delegated subdomain for IPv4 reverse mapping  113.0.203.in-addr.arpa.

   Names in Multicast DNS answers that do not end in ".local" do not
   require any translation.

   Names in Multicast DNS answers that end in ".local" are only
   meaningful on the local link, and require translation to make them
   useable by clients outside the local link.

   Names that end in ".local" may appear both as the owner names of
   received Multicast DNS answer records, and in the RDATA of received
   Multicast DNS answer records.

   In a received Multicast DNS answer record, if the owner name ends
   with ".local", then the ".local" top-level label is replaced with the
   name of the delegated subdomain as was used in the originating query.

   In a received Multicast DNS answer record, if a name in the RDATA
   ends with ".local", then the name is translated according to the
   delegated subdomain that was used in the originating query, as
   explained below.

   For queries in subdomains delegated for LDH host names, ".local"
   names in RDATA are translated to that delegated LDH subdomain.  For
   example, a query for "thing.bldg-1.example.com" will be translated to
   a Multicast DNS query for "thing.local".  If that query returns this
   CNAME record:

     thing.local.               CNAME  prnt.local.

   then both the owner name and the name in the RDATA are translated
   from ".local" to the LDH subdomain "bldg-1.example.com":

     thing.bldg-1.example.com.  CNAME  prnt.bldg-1.example.com.

   For queries in subdomains delegated for reverse mapping names,
   ".local" names in RDATA are translated to the delegated LDH
   subdomain, if one is configured, or to the delegated rich-text
   subdomain otherwise.  For example, consider a reverse mapping query
   that returns this PTR record:

     2.113.0.203.in-addr.arpa.  PTR  prnt.local.

   The owner name is not translated because it does not end in ".local".
   The name in the RDATA is translated from ".local" to the LDH
   subdomain "bldg-1.example.com":

     2.113.0.203.in-addr.arpa.  PTR  prnt.bldg-1.example.com.

   For queries in subdomains delegated for rich-text names, ".local"
   names in RDATA are translated according to whether or not they
   represent host names (i.e., RDATA names that are the owner names of A
   and AAAA DNS records).  RDATA names ending in ".local" that represent
   host names are translated to the delegated LDH subdomain, if one is
   configured, or to the delegated rich-text subdomain otherwise.  All
   other RDATA names ending in ".local" are translated to the delegated
   rich-text subdomain.  For example, consider a DNS-SD service browsing
   PTR query that returns this PTR record for IPP printing:

     _ipp._tcp.local.  PTR  My Printer._ipp._tcp.local.

   Both the owner name and the name in the RDATA are translated from
   ".local" to the rich-text subdomain:

     _ipp._tcp.Building 1.example.com.
                       PTR  My Printer._ipp._tcp.Building 1.example.com.

   In contrast, consider a query that returns this SRV record for a
   specific IPP printing instance:

     My Printer._ipp._tcp.local.  SRV  0 0 631 prnt.local.

   As for all queries, the owner name is translated to the delegated
   subdomain of the originating query, the delegated rich-text subdomain
   "Building 1.example.com".  However, the ".local" name in the RDATA is
   the target host name field of an SRV record, a field that is used
   exclusively for host names.  Consequently it is translated to the LDH
   subdomain "bldg-1.example.com", if configured, instead of the rich-
   text subdomain:

     My Printer._ipp._tcp.Building 1.example.com.
                                  SRV  0 0 631 prnt.bldg-1.example.com.

   Other beneficial translation and filtering operations are described
   below.