| Internet-Draft | Advertising Proxy for DNS-SD SRP | July 2023 |
| Cheshire & Lemon | Expires 29 January 2024 | [Page] |
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.¶
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:[email protected]), 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.¶
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."¶
This Internet-Draft will expire on 29 January 2024.¶
Copyright (c) 2023 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.¶
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).¶
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.¶
In its simplest realization, an advertising proxy monitors the contents of a DNS zone. When a new DNS resource record is added to the zone, the advertising proxy rewrites that record, replacing the domain name of the zone with ".local," and advertises the result using mDNS on one or more network links.¶
However, more commonly, the advertising proxy function is combined with an SRP registrar. In this case, the SRP registrar and the advertising proxy service cooperate to minimize name collisions. Such a service may or may not actually respond to DNS queries.¶
When an Advertising Proxy is implemented as part of an SRP registrar (a DNS authoritative server that implements Service Registration Protocol), an SRP requestor can send registration requests for any valid DNS records to the SRP registrar. SRP supports updating the resource record types most commonly used by DNS-SD: the PTR, SRV and TXT records that describe a DNS-SD service [RFC6763], and the A and AAAA records that give the IPv4 and/or IPv6 addresses of the host on which that service can be reached.¶
Notionally, SRP service updates a DNS zone. The context in which this DNS zone exists is important in discussing the advertising proxy, however. If the DNS zone being maintained by SRP is part of the network infrastructure, there is no need for an advertising proxy. The reason for this is that we can assume that all DNS-SD implementations will discover and use infrastructure provided service discovery using the DNS protocol if it is available. Since no DNS-SD implementation relies solely on multicast DNS, providing an mDNS proxy for an existing DNS-based DNS-SD infrastructure service is unnecessary.¶
However, it's also possible for the DNS zone that SRP manages to be provided by some opportunistic service, such as a stub router [STUBNET]. A stub router may need to allow devices on the stub network to be discovered from the infrastructure link to which it is connected. If the stub router is unable to integrate its SRP-maintained DNS zone with the infrastructure, some other means of providing this service must be provided.¶
One way of providing this service discovery functionality is through an Advertising Proxy. Because the advertising proxy is advertising the content of the SRP-maintained DNS zone using mDNS, there is no need for integration with the infrastructure DNS service: services registered in the SRP DNS zone will be discoverable through mDNS.¶
An authoritative DNS zone that is not managed as part of the Advertising Proxy really can only exist as an infrastructure service. If it exists as an infrastructure service, the right way to make it available is to make it discoverable using the mechanisms described in Section 11 of [RFC6763]. Since no use case exists for this model of Advertising Proxy, we do not attempt to specify how such an Advertising Proxy could be made to work.¶
Similarly, an Advertising Proxy that, as part of its functioning, answers unicast DNS queries, would ideally be included in the DNS service provided by the infrastructure, and in this case the Advertising Proxy function would not be necessary. However, because in this case the Advertising Proxy functionality is superfluous, discussion of this topic is out of scope for this document.¶
Therefore, this document limits itself to describing how to implement an Advertising Proxy that manages service registrations using the Service Registration Protocol. We do talk about how the Service Registration Protocol database should be advertised, but not how it can be integrated into an existing DNS infrastructure.¶
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.¶
An Advertising Proxy advertises the contents of one or more DNS zones that are maintained using the Service Registration Protocol. Such a service consists of three parts, four of which are required, one of which is optional. These are:¶
The SRP registrar function, which includes:¶
The DNS authoritative server function, which may include any or all of:¶
These functions are somewhat interdependent, so while we will discuss each separately, there is no way to completely separate them. After discussing each function, we will describe the operation of the system as a whole.¶
The mDNS registrar function is an mDNS responder, as described in [RFC6762]. We use the term "mDNS registrar" rather than simply "mDNS responder" to emphasize the specific function of advertising mDNS records, as opposed to browsing or resolving services.¶
If Discovery Proxy authoritative resolution service is being offered by the Advertising Proxy, the mDNS registrar MUST support querying for services and records on the link that are not advertised by the Advertising Proxy.¶
The mDNS Registrar MUST implement the Time Since Received [TSR] record. This makes it possible to set up redundant Advertising Proxies that use SRP replication [REPLICATION] to maintain a common set of SRP zones and advertise them without SRP Updates creating conflicts. Such conflicts can occur when, for example, the IP address of a host changes and it sends an SRP update. The new IP address conflicts with the old address, which is being advertised. Without TSR, the old address will win the conflict, resulting in stale data being advertised. With TSR, the newer data supersedes the old data.¶
The Advertising Proxy function mediates between an mDNS registrar and the SRP zone database. Whenever a record is tentatively added to the SRP zone database, the Advertising Proxy registers it with the mDNS registrar. If this registration succeeds, the registration is finalized; otherwise it is rejected. The usual reason for rejection would be that the name is already taken. When records expire in the SRP zone database, the Advertising Proxy function removes those records from its mDNS advertisement.¶
Each SRP Update includes a KEY record that is applicable to every name claimed in the Update. SRP Update also includes an EDNS0 Update Lease option which may include a KEY-LEASE value that's longer than the LEASE value. In this case, the Advertising Proxy SHOULD advertise the KEY record for the duration of the KEY-LEASE, even if the other records are removed when the LEASE value has expired. The Advertising Proxy MAY advertise the KEY record even if the LEASE and KEY-LEASE values are the same, or the KEY-LEASE valid isn't specified.¶
Records advertised by the Advertising Proxy all appear in the .local domain. Consequently, these records MUST be rewritten in somewhat the opposite of the way a Discovery Proxy Section 5.5 of [RFC8766] rewrites them.¶
Each zone managed by the SRP registrar function must have a name. In some cases, SRP requestor will discover the name using the Domain Enumeration process described in Section 11 of [RFC6763]. However in most cases, since advertising proxies aren't integrated into infrastructures, the registration domain used by the SRP requestor will be the 'default.service.arpa.' domain. The SRP registrar may rewrite incoming registrations into a different zone, or retain the 'default.service.arpa.' zone name.¶
In either case, before advertising a tentative record, the Advertising Proxy function first rewrites the record. First, the owner name is transformed by replacing the zone name with '.local'. Secondly, for any RR that contains a domain name, that domain is transformed in the same way.¶
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.¶
The SRP registrar function comprises two components: the SRP protocol and the zone database (or databases). The details of the SRP protocol are described in [SRP].¶
In the context of an Advertising Proxy, the SRP protocol will be updating one or more DNS zones. It's possible, for example, for an SRP registrar to provide SRP service on more than one link, and for each link to be treated as a separate DNS zone. SRP requestors may not know what zone they are updating: they may be using 'default.service.arpa' as a placeholder rather than discovering the name of the zone to update. In this case, updates for 'default.service.arpa' will be rewritten into the name of the zone specific to a particular link. Note that this separation is not required, but is possible and may be desirable.¶
In an Advertising Proxy, when an SRP update is received, it is first validated according to the SRP specification. It is then checked for uniqueness in the context of SRP, using the SRP first-come, first-served mechanism.¶
There are two additional opportunities for conflicts with an advertising proxy, however. First, there may be more than one DNS zone that is being advertised by an advertising proxy. Because mDNS uses only the leftmost label of the domain name in its advertisements, there is no way to differentiate between two fully-qualified domain names with identical leftmost labels when advertising them using mDNS. So for example foo.bar.example.com and foo.baz.example.com would appear identical when discovered via mDNS.¶
Additionally, we can consider the set of names advertised by mDNS on a particular link as being equivalent to a DNS zone. In that sense, if a name being advertised by mDNS on a particular link has the same leftmost label as a name registered in an SRP zone (e.g., foo.local and foo.bar.example.com), there is no way to disambiguate.¶
mDNS does provide a means for detecting name conflicts. In principle, we could check with mDNS before accepting an SRP registration, for example. However, this requires treating mDNS as a sort of black box, when in fact it's a dynamic process. Relying on mDNS conflicts for this purpose works very poorly in practice. Consequently, maintenance of each SRP zone should be handled independently of other SRP zones, and independently of mDNS. The presence of names in any of these zones that are ambiguous when queried over mDNS MUST NOT be treated as a conflict for the purposes of maintaining these zones.¶
In order to deal with conflicts, then, when an mDNS conflict is seen, the advertising proxy withdraws the conflicting name. Because such conflicts can be temporary, the advertising proxy MUST attempt to re-advertise the conflicting name from time to time. [I suggest every ten minutes, what does WG think?]¶
An Advertising Proxy SHOULD answer DNS queries for the zones it manages. This is not required because in some cases it may not be possible. The zones it manages may not have names in the DNS hierarchy, for example, so even if they have locally-assigned names, answering authoritatively for these names may be problematic.¶
The primary purpose of the Advertising Proxy is to support DNS Service Discovery. In some use cases where Advertising Proxy is desirable, the mDNS function can only work on some links, while unicast DNS is the only option on others. This is the case, for example, for an Advertising Proxy operating on a stub network router.¶
In such a situation, devices on the infrastructure link will do service discovery using mDNS. However, devices on the stub network link may not be able to use mDNS, or it may be preferable that they do not. In this case, the Advertising Proxy will need to be able to provide the same information that is provided on the infrastructure link through a DNS resolver, using the DNS protocol, or, ideally, DNS Push [RFC8765].¶
Any Advertising Proxy implementing this functionality MAY use the 'default.service.arpa.' zone as a catch-all zone. A query to the 'default.service.arpa.' zone SHOULD return the same set of answers that would be returned by an mDNS query to the .local zone on a link served by the Advertising Proxy's mDNS registrar.¶
When using the 'default.service.arpa.' zone for queries, all responses that reference link-specific domains MUST be rewritten to use 'default.service.arpa.' domain instead. This includes domain names in the resource record data. Because the Advertising Proxy is required to enforce name uniqueness across all the zones it manages, this should not result in any conflicts.¶
In order to fully support the ability to query the Advertising Proxy either with mDNS or DNS, it is necessary to provide a Discovery Proxy [RFC8766]. The Discovery Proxy provides answers for link-specific domains that represent each of the links supported by the Advertising Proxy. These responses are combined with responses from zones managed by SRP to produce a complete set of answers to any query received by the Advertising Proxy over DNS or DNS Push.¶
In the case of a stub network, the Advertising Proxy may appear to devices on the stub network as an infrastructure service. This would mean that the DNS Listener on port 53 (TCP and UDP) and port 853 (TLS) could be expected to receive queries for arbitrary domain names, not just domain names for which the Advertising Proxy is authoritative.¶
Resolution of such names may not be required for devices on the stub network. For instance, if the stub network has only locally-provided IPv6 service using a ULA, devices on the stub network will not be able to contact arbitrary devices on the Internet anyway.¶
However, in cases where support for connecting to hosts outside of the scope of the Advertising Proxy is needed, the Advertising Proxy will have to provide a full service resolver (or a DNS Proxy [RFC5625]) in addition to its DNS authoritative service and Discovery Proxy service. The details of how this is configured are likely to be implementation-specific, and therefore outside the scope of this document.¶
It is possible for two mDNS responders to advertise conflicting records on the same name, but, as a consequence of a network partition or multicast packet loss, for neither server to immediately detect a conflict. When this happens, then at some later time one or the other mDNS responder will notice the conflict, and begin the conflict resolution process. The outcome of this process may be that the record advertised by the Advertising Proxy loses. In this case, the Advertising Proxy MUST handle the conflict as described in Section 2.3.¶
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 directly from the advertised data without any text-encoding translation.¶
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.¶
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.)¶
An Advertising Proxy may made data visible to eavesdroppers on the configured multicast-capable link(s).¶
This document has no IANA actions.¶