Automatic Replication of DNS-SD Service Registration Protocol Zones

1.1.1. Primary authoritative DNS service

Ideally, SRP updates a primary authoritative DNS server for a particular zone. This DNS server acts as the sole source of truth for names within the DNS zone in which SRP services are published. Redundancy is provided by secondary DNS servers, if needed. However, this approach has some drawbacks.¶

First, it requires 100% availability on the part of a DNS primary authoritative server for the zone. If the primary server is not available for some period of time, new services appearing on the network cannot be registered until primary authoritative service is restored.¶

The second drawback is that there is no automatic method for managing DNS authoritative service. This means that such a service requires an operator to set it up. What it means to set up such a service is that the following capabilities are provided:¶

• An host must be available to act as a primary authoritative DNS server¶
• The zone advertised by that server must be delegated, so that the local resolver can successfully answer queries in that zone¶
• The local resolver must be able to provide local browsing domain advertisements (Section 11 of [RFC6763]).¶

1.1.2. Multicast DNS Advertising Proxy

An existing alternative to the use of DNS authoritative services for advertising SRP registrations the advertising proxy [draft-tlsc-advertising-proxy]. An advertising proxy advertises the contents of the SRP update zone using multicast DNS on links on which the need for such advertisements is anticipated. This works well for stub networks [draft-lemon-stub-networks], where services advertised on the stub network must be visible both on the stub network and on the adjacent infrastructure network, but do not generally need to be discoverable on other networks.¶

One drawback of the advertising proxy model, however, is that there is no shared database from which to advertise services registered by SRP. As a consequence, some of the guarantees provided by SRP, particularly first come, first served naming [draft-ietf-dnssd-srp]. Because advertising proxies are set up automatically on an ad-hoc basis, coordination between advertising proxies is not present, which means that if two devices claim the same name, but register with different SRP servers, the conflict is not detected until the service is advertised using mDNS. In practice, this results in frequent renaming of services, which means that consumers of services need to carefully follow each service that they use as the name changes over time.¶

An additional drawback is that, from the perspective of the SRP client, SRP service is not unified: SRP servers tend to come and go, and whenever the SRP service with which a particular client has registered goes offline, the client has to notice that this has happened, discover a new SRP server, and re-register, or else it becomes unreachable.¶

1.1.3. SRP Replication

This document describes a replication mechanism which eliminates the need for a single authoritative source of truth, as in the Primary Authoritative DNS model, while eliminating the drawbacks of the Advertising Proxy model. SRP Replication servers discover each other automatically. Each replication server maintains a copy of the SRP zone which is kept up to date on a best-effort basis.¶

SRP Replication has several benefits:¶

• As long as one SRP replication partner remains online at all times, SRP state is maintained when individual SRP replication partners go offline¶
• Name collisions when SRP clients change servers are avoided¶
• SRP service on a stub network can appear as an anycast service, so that SRP clients do not see an apparent change in servers and re-register when the server with which they most recently registered goes offline¶

2.1.1. Zone name based on network name

Network names aren't guaranteed to be unique, but tend to be unique for any given site. In the case of ad-hoc (permissionless) SRP-based service, such as an advertising proxy or an authoritative service using a locally-served zone [https://www.iana.org/assignments/locally-served-dns-zones/locally-served-dns-zones.xhtml], because the DNS zone name isn't required to be globally unique, a zone name based on the network name is an easy solution to generating a unique zone name.¶

When generating a zone name based on a network name, the zone name could be based on a locally configured global zone name, e.g. 'example.com'. It could be based on a locally-managed locally-served name, e.g. 'home.arpa'. Or it could be based on an unmanaged locally-served name, for which we propose to use the root name 'local.arpa.' For the rest of this section we will assume that the specific setting determines which of these domains will be used, and refer to whichever domain that is as DOMAIN.¶

For zone names based on the network name, the network type should be used as a differentiator, in case there are two different local network types with the same name. So, for example, 'WiFi.DOMAIN.'¶

2.1.2. Zone name based on local configuration

The above examples assume that it makes sense for each separate subnet to be its own separate zone. However, since SRP guarantees name uniqueness using the first-come, first-served mechanism, it doesn't rely on mDNS's guarantee of per-link uniqueness. Consequently, it is not required that an SRP zone be constrained to the set of services advertised on a single link. For this reason, when it is possible to know that some set of links are all managed by the same set of SRP replication partners, and a name is known for that set of links, that name can be used. To avoid possible collisions, the subdomain 'srp' is used to indicate that this zone is an SRP zone. So in this case the link name would be the locally-known shared name, followed by 'srp.DOMAIN.'¶

An example of such a scenario would be Apple's HomeKit, in which all HomeKit accessories, regardless of which home network link they are attached to, all are shared in the same namespace. Suppose the HomeKit home's name is "Example Home". In such a situation, the domain name 'Example Home.srp.DOMAIN' could be used.¶

2.1.3. Zone name based on DNS-SD discovery

Another option for naming the local SRP Replication zone would be to use DNS-SD advertisements. This is particularly useful since each SRP replication partner advertises itself using DNS-SD, so there is a convenient place to put this information. To advertise a zone name based on DNS-SD discovery, the SRP replication partner should add two fields to the TXT record of the service instance. The first field is the domain field: 'domain=name'. This indicates a proposed SRP replication zone name. The second is the join field. If 'join=yes' then other SRP replication servers are encouraged to use the domain name that appears in the domain field rather than creating a new domain.¶

2.4.2. Determining a Dataset ID

The dataset ID is a 64-bit number that identifies the set of data replicated by a set of cooperating SRPL partners. Ideally, there should be exactly one dataset ID per domain. However, it is possible for several independent sets of SRPL partners to replicate a particular domain, for example when some SRPL partners are unable to discover each other. When the SRPL partners are able to discover each other again, the sets of partners must converge on a single dataset using the dataset ID.¶

If an SRPL partner does not discover any other partners advertising the same domain in the "startup" state Section 2.4, it generates a new dataset ID when entering the "routine operation" state. SRPL partners MUST persist the highest (most significant byte or MSB) of the dataset ID in non-volatile memory. When generating a new dataset ID, the partner MUST increment the MSB of last used dataset ID to use as MSB of new dataset ID and populate the lower 56 bits randomly using a high-quality random number generator [RFC4086]. If there is no previously saved ID, then the partner randomly generates the entire 64-bit ID.¶

When multiple dataset IDs exist for a given domain, the largest dataset ID is the preferred dataset ID. Implementations MUST follow the Serial Number Arithmetic as defined in [RFC1982] when comparing two dataset IDs. When using Serial Number Arithmetic with three or more IDs, it is possible that the largest value may not be well-defined (it is possible to have three IDs each being "larger" than another one). In this case, the dataset ID that is largest using absolute value comparison is the preferred dataset ID.¶

If at any time (regardless of "startup" or "routine operation" state) an SRPL partner discovers that it is synchronizing with a non-preferred dataset ID, it MUST abandon that dataset, re-enter the "startup" state, and attempt to synchronize with the (newly discovered) preferred dataset id.¶

2.9.1. Sending candidates

When a partner receives a "send candidates" message that it is expecting to receive, it generates a candidate list from the list of known SRP clients. This list includes SRP clients that have registered directly with the partner, and SRP clients that have been received through SRP replication updates. Each candidate contains a hostname, a time offset, and a key identifier.¶

The key identifier is computed as follows:¶

uint32_t key_id(uint8_t *key_data, int key_len) {
  uint32_t key_id = 0;
  for (int i = 0; i < key_data_len; i += 4) {
    key_id += ((key_data[i] << 24) | (key_data[i + 1] << 16) |
               (key_data[i + 2] << 8) | (key_data[i + 3]));
  }
  return key_id;
}

When a partner receives a candidate message during the synchronization process, it first searches for an SRP registration with a hostname that matches the hostname in the candidate message. It then compares the key ID to the key ID in the candidate message. If the key ID doesn't match, it sends back a candidate response status of "conflict". If the key ID does match, it compares the time provided to the time the existing host entry was received. If the time of the update is later, it sends a "send host" response. If it is earlier or the same, it sends a "continue" response. If there is no matching host entry for the candidate message, the partner sends a "send host" response.¶

When a partner receives a candidate response with a status of "send host", it generates a host message, which contains the hostname, the time offset, and the SRP message that was received from the host. The partner then applies the SRP update message as if it had been received directly from the SRP client. The host update time sent by the partner is remembered as the time when the update was received from the client, for the purposes of future synchronization.¶

When a partner is finished iterating across its list of candidates, it sends a "send candidates" response.¶

When a partner receives a "send candidates" response, if it is the server, it sends its own "send candidates" message, and processes any proposed candidates.¶

When a partner that is a server receives a "send candidates" response, it goes into the "routine operation" state. When a partner that is a client sends its "send candidates" response, it goes into the "routine operation" state.¶