Internet-Draft DNS Push DNSSD Additionals March 2024
Lemon & Ma Expires 5 September 2024 [Page]
Internet Engineering Task Force
Intended Status:
Standards Track
T. Lemon
Apple Inc.
D. Ma

Including Additional Records for DNSSD in DNS Push Subscriptions


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.

Status of This Memo

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

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.

Table of Contents

1. Introduction

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.

1.1. DNS-SD additional records overview

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 '' browsing domain. So we'd subscribe to DNS Push on the name '

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" 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.

1.2. 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:

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...

2. Security Considerations


3. IANA Considerations


4. Informative References

5. Normative References

Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, , <>.
Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, , <>.
Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", RFC 7719, DOI 10.17487/RFC7719, , <>.
Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S., Lemon, T., and T. Pusateri, "DNS Stateful Operations", RFC 8490, DOI 10.17487/RFC8490, , <>.
Pusateri, T. and S. Cheshire, "DNS Push Notifications", RFC 8765, DOI 10.17487/RFC8765, , <>.

Authors' Addresses

Ted Lemon
Apple Inc.
One Apple Park Way
Cupertino, California 95014
United States of America
Di Ma
Floor 21, Block B, Greenland Center
Beijing, 100102