| Internet-Draft | DNS Push DNSSD Additionals | March 2024 |
| Lemon & Ma | Expires 5 September 2024 | [Page] |
This document extends DNS Push Notifications by providing ways for DNS Push subscribers to track additional data as well as direct answers to DNS questions. This is analogous to the support for additional data specified for multicast DNS, for example.¶
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 5 September 2024.¶
Copyright (c) 2024 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 Push Notifications [RFC8765] defines a mechanism based on DNS Stateful Operations [RFC8490] which allows DNS clients to track changes that are made to DNS RRsets (Section 4 of [RFC7719]) associated with specific owner (Section 4 of [RFC7719]) names.¶
This allows DNS Service Discovery [RFC6763] clients using DNS [RFC1035] 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 therefure extends the DNS Push specification to specify a way to include additional data specific to DNSSD [RFC6763] in DNS Push subscriptions.¶
DNS Service Discovery generally consists of three steps:¶
Services are discovered within one or more browsing domains, referred to as "Legacy Browsing Domains" in [RFC6763]. 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 weill 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.¶
Section 12 of [RFC6763] 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.¶
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:¶
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 Section 4 of [RFC6763].¶
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 add 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 subcription. 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 contineud...¶
TBD.¶
TBD.¶