Including Additional Records for DNSSD in DNS Push Subscriptions

Introduction DNS Push Notifications defines a mechanism based on DNS Stateful Operations which allows DNS clients to track changes that are made to DNS RRsets () associated with specific owner () names. This allows DNS Service Discovery clients using DNS to implement long-lived queries to track the arrival of new information about DNS services. However, when a DNS Push update indicates that a service is available, the DNS Push client needs to do additional DNS lookups or create additional DNS Push queries in order to get the information required to actually use the service. This introduces additional latency and creates additional work once a DNS service has been selected: where with mDNS, we generally get all the information we need to actually use a service in the additional section of the same mDNS response that included the list of services, this is not possible with DNS Push as currently defined. This document therefore extends the DNS Push specification to specify a way to include additional data specific to DNSSD in DNS Push subscriptions.

DNS-SD additional records overview DNS Service Discovery generally consists of three steps:

Browsing for services
Choosing a service
Using a service

Services are discovered within one or more browsing domains, referred to as "Legacy Browsing Domains" in . To discover a service, we take the service name and prepend it to each legacy browsing domain, and then ask for a list of PTR records under that name. So for instance, for a printer service, the service name might be '_printer._tcp' and we might look for it in the 'services.example.com' browsing domain. So we'd subscribe to DNS Push on the name '_printer._tcp.service.example.com. Because this is a DNS Push query, the list of services needn't be static, but at any given point we may decide to actually choose one of the services and use it. This may be because of a user choice, or it may be part of some automatic process. In either case, we might choose one specific service. Or we might want to choose all services of a particular subtype. Or we might just want any service of a particular type or subtype. Consider the case where we want to choose a specific service. The user might look at the list of services discovered so far, which we update in the user interface whenever it's visible, whenever we get an add or remove event through the DNS Push subscription. When the user selects a particular printer, to use the previous example, we will then need to figure out everything that is required to connect to and actually use that printer service. To do this, we will first look for SRV and TXT records under the owner name that is contained in the target of the PTR response for that printer that we got through the DNS Push subscription. Every PTR record has a target. In the case of DNS-SD, when we are browsing, the target in the PTR record for each browse response is the name of a service instance. Each service instance will have one or more PTR and SRV records associated with it. Suppose the printer the user chose was an Acme Corp X-1000 printer, with the service instance name "Acme X-1000". We will then need DNS responses for "Acme X-1000"._printer._tcp.services.example.com. Once we have at least one PTR and at least one TXT record for that name, we can look up the IP address of the host providing the service, which will be the target hostname of the SRV record. This will require looking up both A and AAAA records. You can see that from a single convenient DNS Push query, we have graduated to as many as four additional queries, which can either be DNS Push queries or regular DNS queries. However, notice also that we didn't know in advance what name we'd use for either the TXT and SRV queries, or for the A and AAAA queries. So now we have to wait for one round trip to start the second set of queries, and another round trip to start the third set of queries. recommends that DNS servers that have support for DNS-SD include all of this information in the additional section of the DNS response. However, DNS Push explicitly forbids including responses to a DNS Push subscription with different owner names than the name provided in the original subscription.

Extensions to DNS Push When sending a DNS Push request, the DNS Push client MAY include a DNS Push Additional Request secondary TLV. This TLV indicates to the DNS Push server that it should include relevant additional records of a specified type, and specifies a limit as to the number of DNS Push responses that can trigger additional data. A DNS Push Additional Request TLV consists of:

Count - The number of records matching the original DNS Push query that are allowed to trigger additional data subscriptions.
RRtypes - One or more RRtypes.

A DNS Push subscription requests records of a particular type (or the "any" type) and a particular class, that are published with a specific owner name. Each record provided in response to a DNS Push subscription can in principle trigger the provision of additional data. In the case of a regular DNS-SD browse, the RRtype being subscribed is 'PTR', the class is 'IN', and the owner name is the service name constructed as described in . Whenever a DNS Push subscription is made that includes the DNS Push Additional Request secondary TLV, the DNS Push should include a "additional requests" data structure representing additional DNS Push subscription sets that can be added automatically based on responses to the base subscription. This can have at most the number of entries specified in Count. Each entry is a subscription set. When a DNS Push additional response is generated, the DNS Push server first checks to see if the RR in the response is of a type that has a target (e.g., SRV, PTR, NS). The DNS Push server then checks to see if there is space in this data structure for an additional subscription. If there is, it adds one using the target of the DNS Push response. The new subscription is then given its own "additional requests" data structure with the same limit. Responses to this new subscription are handled in the same way, using the "additional requests" data structure for the new subscription. To be continued...