Advertising Proxy for DNS-SD Service Registration Protocol
draft-ietf-dnssd-advertising-proxy-04

DNSSD                                                        S. Cheshire
Internet-Draft                                                  T. Lemon
Intended status: Standards Track                              Apple Inc.
Expires: 5 September 2024                                   4 March 2024

       Advertising Proxy for DNS-SD Service Registration Protocol
                 draft-ietf-dnssd-advertising-proxy-04

Abstract

   An Advertising Proxy advertises the contents of a DNS zone, for
   example maintained using the DNS-SD Service Registration Protocol
   (SRP), using multicast DNS.  This allows legacy clients to discover
   services registered with SRP using multicast DNS.

About This Document

   This note is to be removed before publishing as an RFC.

   The latest revision of this draft can be found at https://dnssd-
   wg.github.io/draft-ietf-dnssd-advertising-proxy/draft-ietf-dnssd-
   advertising-proxy.html.  Status information for this document may be
   found at https://datatracker.ietf.org/doc/draft-ietf-dnssd-
   advertising-proxy/.

   Discussion of this document takes place on the DNSSD Working Group
   mailing list (mailto:dnssd@ietf.org), which is archived at
   https://mailarchive.ietf.org/arch/browse/dnssd/.  Subscribe at
   https://www.ietf.org/mailman/listinfo/dnssd/.

   Source for this draft and an issue tracker can be found at
   https://github.com/dnssd-wg/draft-ietf-dnssd-advertising-proxy.

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 https://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."

Cheshire & Lemon        Expires 5 September 2024                [Page 1]
Internet-Draft      Advertising Proxy for DNS-SD SRP          March 2024

   This Internet-Draft will expire on 5 September 2024.

Copyright Notice

   Copyright (c) 2024 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 (https://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 Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Conventions and Terminology Used in This Document . . . .   4
   2.  Advertising Proxy . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Mapping non-'.local.' domain names to '.local.' . . . . .   5
       2.1.1.  The DNS Dataset . . . . . . . . . . . . . . . . . . .   5
       2.1.2.  How to rewrite names  . . . . . . . . . . . . . . . .   6
       2.1.3.  Handling of address records that are not global in
               scope . . . . . . . . . . . . . . . . . . . . . . . .   8
       2.1.4.  Conflicts and Stale Data  . . . . . . . . . . . . . .   8
       2.1.5.  No Text-Encoding Translation  . . . . . . . . . . . .   9
       2.1.6.  No Support for Reconfirm  . . . . . . . . . . . . . .  10
   3.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     5.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
     5.2.  Informative References  . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   DNS-Based Service Discovery [RFC6763] [ROADMAP] was designed to
   facilitate Zero Configuration IP Networking [RFC6760] [ZC].
   When used with Multicast DNS [RFC6762] with ".local" domain names
   [RFC6761] this works well on a single link (a single broadcast
   domain).

Cheshire & Lemon        Expires 5 September 2024                [Page 2]
Internet-Draft      Advertising Proxy for DNS-SD SRP          March 2024

   However, in some applications, multicast may be a poor choice for
   advertising.  Most obviously, multicast DNS is constrained to a
   single network link, and for example in the case of stub networks
   [STUBNET], service discovery for devices on the stub network by
   devices on the infrastructure network, or vice versa, requires some
   kind of proxy.

   Also, even in single-link use cases, multicast isn't always the best
   choice.  On some network media, multicast is inefficient and/or
   unreliable.  Also, mDNS-based DNS-SD requires that each host
   providing services receive and process all mDNS service discovery
   messages, whether or not they are relevant to that host (for example,
   irrelevant service advertisements and queries for services not
   provided by the host).  For power-constrained hosts, keeping a radio
   listening all the time for these messages is prohibitively expensive.

   Ideally, in situations where multicast DNS is not the right choice,
   an obvious alternative is to use regular unicast DNS [RFC1035].
   Unfortunately, this isn't always possible: the DNS protocol relies on
   a delegation hierarchy, and on per-network DNS resolvers.

   The operational model for DNS service is that the infrastructure
   serving each network link provides a DNS resolver, and all DNS
   queries go to that resolver.  Using unicast DNS for discovery of
   services through a stub network proxy, for example, would require
   that the stub network proxy be able to somehow register with the
   infrastructure DNS service.  No standard mechanism for doing this
   currently exists.

   This document describes a new type of proxy, an Advertising Proxy,
   which can be used to address some of these issues.  An Advertising
   Proxy advertises the contents of some DNS zone (or zones) [RFC1034]
   to one or more network links using multicast DNS.  This allows the
   DNS protocol, for example using the Service Registration Protocol
   registrar function [SRP], to be used by servers to advertise their
   services, while using the permissionless model of multicast DNS to
   make those services discoverable to devices on links supported by the
   Advertising Proxy.

   One way of providing this service discovery functionality is through
   an Advertising Proxy.  An advertising proxy functions to replicate
   some or all of the contents of a DNS zone using multicast DNS.  This
   is limited by the fact that the DNS zone is a dataset, and the set of
   names discoverable in mDNS is constructed cooperatively, so the
   advertising proxy is not authoritative in the same sense that a DNS
   server is authoritative for any particular zone.  This means that in
   some cases a name that is present in the DNS zone may conflict with a
   name already published by some other mDNS responder.

Cheshire & Lemon        Expires 5 September 2024                [Page 3]
Internet-Draft      Advertising Proxy for DNS-SD SRP          March 2024

1.1.  Conventions and Terminology Used in This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.  Advertising Proxy

   The advertising proxy works by publishing records from a DNS zone
   using multicast DNS [RFC6762].  The set of records published may
   include every record in the DNS zone, or a subset determined either
   automatically or administratively.  When a record published in the
   DNS zone has the same name as a record published by some device that
   is not the advertising proxy, this will produce a conflict, and the
   advertising proxy must address this conflict.

   Although we will in some cases refer to aspects of the mDNS protocol
   in this document, it is worth emphasizing that the typical
   implementor of an advertising proxy should not expect to have to do
   their own mDNS implementation: most platforms already provide a
   library that allows records and/or services to be published using
   mDNS.  So our goal in discussing mDNS protocol details is to motivate
   choices that the implementor will make in their use of these
   libraries.

   The simplest implementation of an advertising proxy will simply act
   on some signal indicating that the DNS zone has been updated.  When
   this signal is received, the advertising proxy will terminate
   whatever mDNS registrations it is currently doing, and then iterate
   across the set of names in the zone, publishing all of the RRsets on
   each name in the DNS.

   Of course, this simple approach to an advertising proxy has some
   issues.  Multicast traffic on some link types (e.g., IEEE 802.11)
   consumes substantially more airtime than unicast traffic, so efforts
   should be made to minimize such traffic where possible.  Also, the
   act of unpublishing an advertised record can be seen by consumers of
   the information in that record as an indication that whatever host or
   service that record represents is no longer present.

   For these reasons, it is better if the advertising proxy can notice
   changes to the DNS zone, and only remove records from mDNS when they
   have been removed from the zone.  New records in the zone will be
   newly advertised, of course, just as with the previous approach.

Cheshire & Lemon        Expires 5 September 2024                [Page 4]
Internet-Draft      Advertising Proxy for DNS-SD SRP          March 2024

2.1.  Mapping non-'.local.' domain names to '.local.'

   Multicast DNS supports advertising of arbitrary names.  However, the
   mechanism by which names in the DNS hierarchy are found is DNS, not
   mDNS, with one exception: names ending in '.local.'.  Consequently,
   we can't simply publish names using mDNS with the same name that they
   have in the DNS hierarchy, because queries for those names will use
   DNS rather than mDNS.

   But what does it mean to rewrite a name?

2.1.1.  The DNS Dataset

   DNS has the concept of a "zone," which is a subset of the domain name
   hierarchy over which some DNS server or servers assert authority.
   That authority is confirmed because a name server that is
   authoritative for a zone higher in the domain name hierarchy
   publishes a delegation naming the DNS server or servers that are
   authoritative for the subdomain.

   As an example, the root ('.') zone has a set of authoritative servers
   that advertise it, and contains delegations for "top-level domains"
   like 'com.'. 'com.' is also a zone.  However, it is not necessarily
   the case that a zone exists at only one level of the DNS hierarchy.
   A zone can include more than one level.  For example, consider the
   reverse zone 'ip6.arpa.'.  Here the subdomain will generally cover at
   least an IPv6 64-bit prefix.

   So if we consider an IPv6 prefix '2001:db8:1234:5678::/64', the
   reverse zone for this will likely be
   '8.7.6.5.4.3.2.1.8.b.d.0.1.0.0.2.ip6.arpa.'.  There will most likely
   be 16 more labels below the zone cut that are still part of the zone.

   For the DNS Service Discovery use case, this is quite common.  A
   service instance name in mDNS will typically look something like
   'hostname._example._udp.<domain>.'  A hostname on the other hand will
   look like 'hostname.<domain>.'  So we need to distinguish between the
   name of the zone in which a name is advertised, the set of subdomains
   that actually represent additional domains in which names can be
   advertised, and subdomains that are part of the structure of the
   name.

   For this reason, rather than speaking of DNS zones here, it would be
   more accurate to use another term that represents the <domain> part
   of the names above.  We will use the term 'dataset' here, since this
   term is also used in the SRP Replication document [REPLICATION].

Cheshire & Lemon        Expires 5 September 2024                [Page 5]
Internet-Draft      Advertising Proxy for DNS-SD SRP          March 2024

   This means that an advertising proxy acts as a proxy for one or more
   datasets, rather than one or more zones.  Which datasets the
   advertising proxy advertises with mDNS will either be determined
   automatically, or explicitly configured.  It's entirely possible for
   the advertising proxy to act as a proxy for 'example.com.' and
   'foo.example.com.'.  Both 'example.com' and 'foo.example.com' are
   dataset names in this example.

2.1.2.  How to rewrite names

   Before advertising a record, the Advertising Proxy MUST rewrite the
   record.  This means that both the owner name of the record and any
   names that appear as part of the record must be rewritten if they are
   subdomains of the domain name of the DNS dataset.  Of course the
   owner name will always be a subdomain of the DNS dataset name, but
   this won't always be true for the content of the resource record.

   It may also make sense specifically for the PTR record to do a
   different rewrite for the owner name than for the target of the PTR
   record, depending on the way that we choose to rewrite the names.
   There are three ways that we can rewrite names, depending on the
   context:

   *  Rewrite the dataset name directly to '.local.'.  This has the
      benefit of simplicity.  When the data for which the advertising
      proxy is acting as proxy is DNSSD data, for any service that is
      being advertised, there will be a set of PTR records of the form
      '_example._transport.<domain>.'.  If we rewrite <domain> to
      'local', then a browse for the service '_example._transport' in
      the local domain will return the services being advertised.

      The downside to this approach is that it doesn\'t safely handle
      name conflicts: if there are two datasets for which one or more
      advertising proxies are acting as proxy, and each zone contains a
      device with the name 'george', then this will produce a conflict
      that can't easily be resolved: the name is necessarily unique in
      each dataset, but when the two datasets are both mapped into the
      '.local.' namespace, they are in conflict.  There is no way to
      resolve this.

      Consider an RR that might appear in a dataset with a domain name
      of 'default.service.arpa.':
      '_example._transport.default.service.arpa.  IN PTR
      hostname._example._transport.default.service.arpa.'.  This would
      be rewritten to '_example._transport.local IN PTR
      hostname._example._transport.local.'.

Cheshire & Lemon        Expires 5 September 2024                [Page 6]
Internet-Draft      Advertising Proxy for DNS-SD SRP          March 2024

   *  Use a dataset-specific subdomain of '.local.' for each dataset.
      For example, when we are maintaining the dataset using SRP, the
      SRP dataset will have a unique identifier, which we can in
      principle use here.  So the domain into which we would rewrite the
      records from this dataset would then take the binary dataset ID
      and probably encode it as hexadecimal, producing '<dataset-
      id>.local.' as the target domain.

      There is a problem with this approach however: devices browsing
      for services in '.local.' will not know to also browse in this
      subdomain of '.local.'.  In order to fix this, the owner name of
      the PTR records being advertised will have to be rewritten into
      the '.local.' domain rather than '<dataset-id>.local.'.  This is
      perfectly okay, however, since these PTR records are not required
      to be unique.

      If the domain being proxied has PTR records that are not being
      used to advertise services, and all PTR records are rewritten into
      the '.local.' domain, this could be a problem.  However, since the
      primary use case for the advertising proxy is DNS Service
      Discovery, and additionally since PTR records generally are only
      used for service discovery and reverse lookups, it should be safe
      to rewrite PTR records to '.local.' for zones that are not reverse
      lookup zones.  Reverse lookups are already documented in [RFC6762]
      and should not generally require an advertising proxy.

      As an example of the PTR rewrite, if the dataset identifier is
      5c4d2e9ab4 and the dataset domain name is default.service.arpa,
      the record '_example._transport.default.service.arpa.  IN PTR
      hostname._example._transport.default.service.arpa' would be
      rewritten to '_example._transport.local IN PTR
      hostname._example._transport.5c4d2e9ab4.local.'.

   *  Append '.local.' to the dataset's domain name.  For cases where
      there is no SRP replication dataset name, the dataset's domain
      name can be used in the same way.  The reason not to do this is
      simply that it results in a longer name, and could theoretically
      run afoul of domain name length limits.  The rewrite here would be
      from, e.g., 'hostname.default.service.arpa.' to
      'hostname.default.service.arpa.local.'.

Cheshire & Lemon        Expires 5 September 2024                [Page 7]
Internet-Draft      Advertising Proxy for DNS-SD SRP          March 2024

      As with the dataset-specific subdomain of '.local.', the owner
      name for PTR records should be rewritten directly into '.local.'.
      So for example, the service advertisement in the earlier example,
      assuming a dataset domain name of 'default.service.arpa.', would
      be rewritten from '_example._transport.default.service.arpa.  IN
      PTR hostname._example._transport.default.service.arpa' to
      '_example._transport.local IN PTR
      hostname._example._transport.default.service.arpa.local.'.

2.1.3.  Handling of address records that are not global in scope

   In some cases, the SRP requestor may register one or more address
   records for addresses that aren't valid or reachable on some link on
   which the advertising proxy could advertise them.  The Advertising
   Proxy function MAY filter out such records entirely, or MAY
   explicitly advertise such records only on the link(s) on which they
   are reachable.  This is optional because it requires the Advertising
   Proxy function to have enough information to make such a
   determination, which may not always be the case.

   Where such determinations are possible, the advertising proxy SHOULD
   NOT advertise an IPv4 or IPv6 link-local address, or any other media-
   specific link-scoped address, on any link other than the link on
   which the SRP registration was received.

   However, when a determination as to the link on which a particular
   address record is valid isn't being made, either because this
   capability isn't implemented by the advertising proxy, or because
   that information isn't available, the advertising proxy MUST
   advertise locally-scoped address.

2.1.4.  Conflicts and Stale Data

   There are two issues that can come up when advertising a DNS zone
   using mDNS that appear quite similar on the surface, but are actually
   fairly different.  These both show up as a "conflict," but in fact
   only one is actually a conflict.

   A conflict occurs when two different devices assert authority for the
   same name.  However, stale data can also appear as a conflict, even
   though there is only one device asserting authority for the data.
   The problem of stale data occurs when we have more than one
   advertising proxy replicating the same DNS dataset.

Cheshire & Lemon        Expires 5 September 2024                [Page 8]
Internet-Draft      Advertising Proxy for DNS-SD SRP          March 2024

   For actual conflicts, there is no need to do anything special.
   Either the advertising proxy will prevail, or the other mDNS service
   will.  If the advertising proxy does not prevail, it can attempt
   again to advertise the record after some reasonable interval has
   passed.  This could either be the next time the record in question is
   updated (e.g. because of an SRP lease renewal) or a fixed interval.

   mDNS specifies that conflicts should be resolved by renaming.
   Instead of continuing to try to claim the name that is in conflict,
   the advertising proxy MAY rename following the mDNS renaming method.
   In this case, the mapping between the new name and the name as it
   appears in the DNS dataset must be maintained until such time as the
   conflict no longer exists.  So this approach requires maintaining
   some state.

   If the advertising proxy renames owner names into a subdomain of
   '.local' rather than into '.local.', then actual conflicts should
   never occur, since what is being proxied is a single dataset.  So
   when we encounter an apparent conflict using these models, it can't
   be an actual conflict, but rather stale data, and then the question
   is simply what to do next.

   It should be the case in such situations that the problem will
   correct itself over time.  Some advertising proxy will win the
   apparent conflict, and so some version of the data will be findable.
   However, following the usual mDNS conflict detection strategy, it is
   most likely that a conflict will be resolved in favor of the stale
   data, not the new data.  This can result in persistent stale data
   being advertised by the advertising proxy.

   To prevent stale data winning over updated data, advertising proxies
   MUST support the Time Since Registered EDNS0 option [TSR].

2.1.5.  No Text-Encoding Translation

   As with a Discovery Proxy [RFC8766], an Advertising Proxy does no
   translation between text encodings [RFC6055].  Specifically, an
   Advertising Proxy does no translation between Punycode encoding
   [RFC3492] and UTF-8 encoding [RFC3629], either in the owner name of
   DNS records or anywhere in the RDATA of DNS records (such as the
   RDATA of PTR records, SRV records, NS records, or other record types
   like TXT, where it is ambiguous whether the RDATA may contain DNS
   names).  All bytes are treated as-is with no attempt at text-encoding
   translation.  A server implementing DNS-based Service Discovery
   [RFC6763] will use UTF-8 encoding for its unicast DNS-based record
   registrations, which the Advertising Proxy passes through without any
   text-encoding translation to the Multicast DNS subsystem.  Queries
   from peers on the configured multicast-capable interface are answered

Cheshire & Lemon        Expires 5 September 2024                [Page 9]
Internet-Draft      Advertising Proxy for DNS-SD SRP          March 2024

   directly from the advertised data without any text-encoding
   translation.

2.1.6.  No Support for Reconfirm

   For network efficiency, Multicast DNS [RFC6762] uses fairly long
   record lifetimes (typically 75 minutes).  When a client is unable to
   reach a service that it discovered, Multicast DNS provides a
   "reconfirm" mechanism that enables the client to signal to the
   Multicast DNS subsystem that its cached data may be suspect, which
   causes the Multicast DNS subsystem to reissue queries, and remove the
   stale records if the queries are not answered.

   Similarly, when using unicast service discovery with a Discovery
   Proxy [RFC8766], the DNS Push Notifications [RFC8765] protocol
   provides the RECONFIRM mechanism to signal that the Discovery Proxy
   should perform a local Multicast DNS reconfirm operation to re-verify
   the validity of the records.

   When an Advertising Proxy is used, to support legacy clients that
   only implement Multicast DNS, reconfirm operations have no effect.
   If a device uses unicast Service Registration Protocol [SRP] to
   register its services with a service registry with Advertising Proxy
   capability, and the device then gets disconnected from the network,
   the Advertising Proxy will continue to advertise those records until
   the registrations expire.  If a client discovers the service instance
   using Multicast DNS and is unable to reach it, and uses a Multicast
   DNS reconfirm operation to re-verify the validity of the records,
   then the Advertising Proxy will continue to answer on behalf of the
   departed device until the record registrations expire.  The
   Advertising Proxy has no reliable way to determine whether the
   additional Multicast DNS queries are due to a reconfirm operation, or
   due to other routine causes, like a client being rebooted, or
   disconnecting and then reconnecting to the network.  The service
   registry has no reliable automatic way to determine whether a device
   that registered records has failed or disconnected from the network.
   Particularly with sleepy battery powered devices, the service
   registry does not know what active duty cycle any given service is
   expected to provide.

Cheshire & Lemon        Expires 5 September 2024               [Page 10]
Internet-Draft      Advertising Proxy for DNS-SD SRP          March 2024

   Consequently, reconfirm operations are not supported with an
   Advertising Proxy using multicast DNS.  In cases where use of the
   reconfirm mechanism is important, clients should be upgraded to use
   the unicast DNS Push Notifications [RFC8765] protocol's RECONFIRM
   message.  This RECONFIRM message provides an unambiguous signal to
   the service registry that it may be retaining stale records.  (A
   future update to the Service Registration Protocol document [SRP]
   will consider ways that this unambiguous signal can be used to
   trigger expedited removal of stale data.)

3.  Security Considerations

   An Advertising Proxy may made data visible to eavesdroppers on the
   configured multicast-capable link(s).

4.  IANA Considerations

   This document has no IANA actions.

5.  References

5.1.  Normative References

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
              <https://www.rfc-editor.org/info/rfc1034>.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
              November 1987, <https://www.rfc-editor.org/info/rfc1035>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC6760]  Cheshire, S. and M. Krochmal, "Requirements for a Protocol
              to Replace the AppleTalk Name Binding Protocol (NBP)",
              RFC 6760, DOI 10.17487/RFC6760, February 2013,
              <https://www.rfc-editor.org/info/rfc6760>.

   [RFC6761]  Cheshire, S. and M. Krochmal, "Special-Use Domain Names",
              RFC 6761, DOI 10.17487/RFC6761, February 2013,
              <https://www.rfc-editor.org/info/rfc6761>.

   [RFC6762]  Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
              DOI 10.17487/RFC6762, February 2013,
              <https://www.rfc-editor.org/info/rfc6762>.

Cheshire & Lemon        Expires 5 September 2024               [Page 11]
Internet-Draft      Advertising Proxy for DNS-SD SRP          March 2024

   [RFC6763]  Cheshire, S. and M. Krochmal, "DNS-Based Service
              Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
              <https://www.rfc-editor.org/info/rfc6763>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8765]  Pusateri, T. and S. Cheshire, "DNS Push Notifications",
              RFC 8765, DOI 10.17487/RFC8765, June 2020,
              <https://www.rfc-editor.org/info/rfc8765>.

   [SRP]      Lemon, T. and S. Cheshire, "Service Registration Protocol
              for DNS-Based Service Discovery", Work in Progress,
              Internet-Draft, draft-ietf-dnssd-srp-25, 4 March 2024,
              <https://datatracker.ietf.org/api/v1/doc/document/draft-
              ietf-dnssd-srp/>.

   [TSR]      Lemon, T. and L. Qin, "Multicast DNS conflict resolution
              using the Time Since Received (TSR) RR", Work in Progress,
              Internet-Draft, draft-tllq-tsr-03, 13 March 2023,
              <https://datatracker.ietf.org/doc/html/draft-tllq-tsr-03>.

5.2.  Informative References

   [RFC3492]  Costello, A., "Punycode: A Bootstring encoding of Unicode
              for Internationalized Domain Names in Applications
              (IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003,
              <https://www.rfc-editor.org/info/rfc3492>.

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
              2003, <https://www.rfc-editor.org/info/rfc3629>.

   [RFC5625]  Bellis, R., "DNS Proxy Implementation Guidelines",
              BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009,
              <https://www.rfc-editor.org/info/rfc5625>.

   [RFC6055]  Thaler, D., Klensin, J., and S. Cheshire, "IAB Thoughts on
              Encodings for Internationalized Domain Names", RFC 6055,
              DOI 10.17487/RFC6055, February 2011,
              <https://www.rfc-editor.org/info/rfc6055>.

   [RFC7558]  Lynn, K., Cheshire, S., Blanchet, M., and D. Migault,
              "Requirements for Scalable DNS-Based Service Discovery
              (DNS-SD) / Multicast DNS (mDNS) Extensions", RFC 7558,
              DOI 10.17487/RFC7558, July 2015,
              <https://www.rfc-editor.org/info/rfc7558>.

Cheshire & Lemon        Expires 5 September 2024               [Page 12]
Internet-Draft      Advertising Proxy for DNS-SD SRP          March 2024

   [RFC8766]  Cheshire, S., "Discovery Proxy for Multicast DNS-Based
              Service Discovery", RFC 8766, DOI 10.17487/RFC8766, June
              2020, <https://www.rfc-editor.org/info/rfc8766>.

   [ROADMAP]  Cheshire, S., "Service Discovery Road Map", Work in
              Progress, Internet-Draft, draft-cheshire-dnssd-roadmap-03,
              23 October 2018, <https://datatracker.ietf.org/doc/html/
              draft-cheshire-dnssd-roadmap-03>.

   [REPLICATION]
              Lemon, T., Keshavarzian, A., and J. Hui, "Automatic
              Replication of DNS-SD Service Registration Protocol
              Zones", Work in Progress, Internet-Draft, draft-ietf-
              dnssd-srp-replication-01, 28 February 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-dnssd-
              srp-replication-01>.

   [STUBNET]  Lemon, T. and J. Hui, "Automatically Connecting Stub
              Networks to Unmanaged Infrastructure", Work in Progress,
              Internet-Draft, draft-ietf-snac-simple-03, 30 January
              2024, <https://datatracker.ietf.org/doc/html/draft-ietf-
              snac-simple-03>.

   [ZC]       Cheshire, S. and D. H. Steinberg, "Zero Configuration
              Networking: The Definitive Guide", O'Reilly Media, Inc.,
              ISBN 0-596-10100-7, December 2005.

Authors' Addresses

   Stuart Cheshire
   Apple Inc.
   One Apple Park Way
   Cupertino, California 95014
   United States of America
   Phone: +1 (408) 996-1010
   Email: cheshire@apple.com

   Ted Lemon
   Apple Inc.
   One Apple Park Way
   Cupertino, California 95014
   United States of America
   Phone: +1 (408) 996-1010
   Email: elemon@apple.com

Cheshire & Lemon        Expires 5 September 2024               [Page 13]