Advertising Proxy for DNS-SD Service Registration Protocol
Apple Inc.
One Apple Park Way
Cupertino
California
95014
United States of America
+1 (408) 996-1010
cheshire@apple.com
Apple Inc.
One Apple Park Way
Cupertino
California
95014
United States of America
+1 (408) 996-1010
elemon@apple.com
INT
DNSSD
Multicast DNS
DNS-Based Service Discovery
An Advertising Proxy allows a device
that accepts service registrations using
Service Registration Protocol (SRP)
to make those registrations visible
to legacy clients that only implement Multicast DNS.
Introduction
DNS-Based Service Discovery
was designed to facilitate Zero Configuration IP Networking
.
When used with Multicast DNS
with ".local" domain names
this works well on a single link (a single broadcast domain).
There is also a desire to have
DNS-Based Service Discovery
work between multiple links
that aren't part of the same broadcast domain
.
Even within a single Wi&nbhy;Fi broadcast domain
it is beneficial to reduce multicast traffic,
because, in comparison to Wi&nbhy;Fi unicast traffic,
Wi&nbhy;Fi multicast is inefficient, slow, and unreliable
.
There are three complementary ways that this move
towards decreased reliance on multicast is achieved.
One variant is pure end-to-end unicast,
with services
using unicast Service Registration Protocol
to register with a service registry,
and clients
using unicast DNS Push Notification subscriptions
over DNS Stateful Operations
to communicate with the service registry
to discover and track changes
to those registered services.
A second variant is a hybrid approach
that facilitates legacy devices
that only implement link-local Multicast DNS
(like your ten-year-old network laser printer)
having their services discovered by remote clients
using a unicast DNS Push Notifications session
to a Discovery Proxy
.
The third variant, documented here,
is a logical complement to the second variant.
It enables legacy clients
(that only implement link-local Multicast DNS)
to discover services registered (using unicast)
with a service registry.
The service registry accepts service registrations
using unicast Service Registration Protocol
,
and makes those service registrations visible,
both to remote clients using unicast DNS Push Notifications
and, using the Advertising Proxy mechanism documented here,
to local clients using Multicast DNS
.
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
when, and only when, they appear in all capitals, as shown here.
Advertising Proxy
An Advertising Proxy can be
a component of any DNS authoritative server,
though it logically makes most sense as a component of
a service registry
(a DNS authoritative server that implements
Service Registration Protocol
).
A client can send registration requests
for any valid DNS records to a service registry,
though in practice the most common use is to
register the PTR, SRV and TXT records that
describe a DNS-SD service
,
and the A and AAAA records that give the IPv4 and IPv6 addresses
of the target host where that service can be reached.
When a service registry accepts
a registration request for DNS records,
a service registry that implements an Advertising Proxy
also advertises equivalent records
using Multicast DNS on one or more configured local
multicast-capable interfaces.
An Advertising Proxy could also advertise
on one or more configured remote multicast-capable interfaces
using a Multicast DNS Relay
.
For the purposes of this document,
a local multicast-capable interface directly attached to the host
and
a remote multicast-capable interface connected via a relay
are considered to be equivalent.
Name Conflicts
In the event that an SRP client attempts to register
a record with a name that was already created in that
registry by a different SRP client,
or is otherwise disallowed by policy,
a name conflict is reported and the new
client is required to choose a new name.
Similarly, Multicast DNS implements
first-come-first-served name allocation.
When a registered record is advertised using
Multicast DNS it may suffer a name conflict if a
conflicting Multicast DNS record with that name
already exists on that link.
In the case of network failure and subsequent recovery, Multicast DNS
can also signal name conflicts at a later time
during the life of a record registration.
For example, if the network link is partitioned at the
time of record registration, the name conflict may not
be discovered until later when the partition is healed.
Specifically, a name conflict can occur:
- During the SRP validation process, because
another SRP client has already registered the same name.
- Immediately while the Advertising Proxy
is registering the name, if the Multicast DNS
uniqueness probes detect a conflicting record.
- After the name has been successfully registered,
but before the response has been sent to the client.
- After the initial response has been sent to the client.
In the first three cases, the client can be notified
of the conflict at the time of registration,
and is expected to choose a new name.
In the last case, SRP clients must be coded defensively
to handle the case where an apparently successful
record registration is later determined to be in conflict,
just as existing Multicast DNS clients have to be
coded defensively to handle late conflicts gracefully.
With a sleepy SRP client there may be no way to
notify it of the conflict until it next re-registers.
In the case of late conflicts, the service registry with
Advertising Proxy capability is responsible for selecting
a temporary new name to be used until the client renews.
When the client next renews, the service registry
informs the client of the new name the service registry
selected on its behalf. The client can choose to accept
that new name, or select a new name of its own choosing.
The registration process has several steps.
First the hostname claimed by the SRP client must be registered.
Once this has succeeded, the Advertising Proxy can register
all of the service instances that point to that hostname.
When all of these registrations have succeeded, the
service registry can finally send its response to the SRP client.
If any of them fail,
they must all be removed and the client notified of the failure.
If the failure is a result of a name conflict, the response
code should be YXDOMAIN. Other SRP failures are documented
in the SRP specification. Any other failures not contemplated
in the SRP specification return SERVFAIL.
Name Conflicts in Managed Namespaces
In some cases, the name conflict resolution behavior described above is neither needed nor desirable. For instance, when the set of expected SRP clients is known to include only clients added with some kind of commissioning or on-boarding protocol that guarantees that hostnames are unique, it may cause serious problems to rename such a device.
In this situation, the Advertising Proxy behavior should be different: it should be assumed that all names registered with SRP that survive SRP's first-come, first-serve name conflict detection are indeed as intended. Any conflict that may be discovered as a result of advertising those names using mDNS can be assumed to either be an error or an attack, and there is no benefit to renaming such a device: it will not be usable under its new name.
In this case, the Advertising Proxy simply performs normal SRP first-come, first-serve naming and then updates its local idea of the SRP namespace. This update is then reflected in mDNS. If a conflict is detected, the Advertising Proxy schedules a new attempt to claim the name at some time in the future: long enough that these re-attempts to not generate excessive multicast traffic, but short enough that an accidental conflict is cured in a reasonable timeframe.
The downside to this approach is that if the device on the multicast network persists in claiming the name, the SRP client that claimed it will be unreachable. Networks that use Advertising Proxies configured to behave in this way should provide a way to rename the device that is suffering the conflict. However, if the failure is the result of a malicious attack by a device on the multicast network, that device will have to be identified and removed before the attack can be eliminated.
In order to address this problem, it may be advisable to provide with a way for the advertising proxy to inform the mDNS service that it should continue to advertise the name that is in conflict, rather than ceasing to do so when the conflict is detected.
Data Translation
As with a Discovery Proxy
some translation needs to be performed before the
Advertising Proxy makes the registered unicast data
visible using Multicast DNS.
Specifically,
the unicast DNS domain name suffix configured
for Advertising Proxy use
is stripped off and replaced
with the top-level label "local".
No Text-Encoding Translation
As with a Discovery Proxy
,
an Advertising Proxy does no translation between
text encodings
.
Specifically, an Advertising Proxy does no
translation between Punycode encoding
and UTF-8 encoding
,
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
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.
No Address Suppression
Unlike a Discovery Proxy
,
an Advertising Proxy does not need to selectively suppress
link-local
or other addresses.
Since the clients of the service registry are registering
their records in a unicast DNS namespace, there is a presumption
they they will only register addresses with sufficient scope
to be usable by the anticipated clients.
No further filtering or suppression
by the service registry is required.
In most cases it is acceptable for devices registering
with a service registry to register all of their
available addresses, and a client implementing
Happy Eyeballs
connecting to that service will automatically
select an appropriate address to use.
No Support for Reconfirm
For network efficiency,
Multicast DNS
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 ,
the DNS Push Notifications 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
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.
In cases where use of the reconfirm mechanism
is important, clients should be upgraded to use the unicast
DNS Push Notifications 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
will consider ways that this unambiguous signal
can be used to trigger expedited removal of stale data.)
Security Considerations
An Advertising Proxy may made data visible
to eavesdroppers on the configured multicast-capable link(s).
IANA Considerations
This document has no IANA actions.
References
Normative References
Informative References
Zero Configuration Networking: The Definitive Guide
O'Reilly Media, Inc.