| Internet-Draft | Advertising Proxy for DNS-SD SRP | April 2023 |
| Cheshire & Lemon | Expires 15 October 2023 | [Page] |
An Advertising Proxy advertises the contents of a DNS zone, for example maintained using the DNSSD 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: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.¶
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 15 October 2023.¶
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 necessarily 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 DNSSD requires that each host providing services receive and process all service discovery requests even for services they don't offer. For power-constrained hosts, keeping a radio listening all the time 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 such servers is that any particular network infrastructure provides a DNS resolver, and all DNS queries go to that resolver. So 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. This isn't usually possible.¶
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. In practice, the most common use is to register 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.¶
Although, as we've said, an Advertising Proxy can monitor a DNS zone and advertise its contents, this is not a compelling use case. The reason for this is that we can assume that all DNSSD implementations will discover and use infrastructure provided service discovery using the DNS protocol if it is available. We do not need to support a use case where a consumer of DNSSD only implements multicast DNS.¶
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. Unlike a DNS-only SRP registrar, an Advertising Proxy registrar must complete two additional uniqueness checks for any name being registered.¶
First, the name must be unique across all DNS zones that are being advertised together on the same link by the Advertising Proxy. That is, if the zone being updated is advertised on any link, then the name being registered must be unique in every zone that is being advertised on that link. If the zone is being advertised on multiple links, then for each link, the name must be unique across all the zones advertised on that link.¶
Secondly, the name must not already be being advertised via mDNS. This is easy to check: the Advertising Proxy tentatively advertises the name on all links that the corresponding zone is being advertised on. If every tentative advertisement succeeds without detecting a conflict, then the advertisement has been successful. At this point the SRP registrar can confirm with the requestor that its registration has succeeded.¶
If, on the other hand, a conflict is detected in any part of this process, then the SRP registrar informs the requestor that the name is already taken, by returning the YXDOMAIN response code.¶
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 stop advertising this record and remove it from its database. There is no way to notify the client when this happens, but when the client tries to renew its registration, the conflict can be reported.¶
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.¶