Extensions for Scalable DNS Service Discovery (dnssd) IETF 118

Working Group information
WG General Info
WG GitHub Repositories
WG Documents
AD: √Čric Vyncke
Chairs: David Schinazi, Chris Box
Links for this meeting

Thursday November 9, 2023
Session IV
17:00 - 18:30 (Prague time)
Bohemia 1/2/3


Agenda bash

DS: we had an extra side meeting earlier this week; with some good work
done. In this WG meeting and on list the consensus will be achieved on
these topics.

Note takers: Tim, Esko Dijk (backup)

Adopted WG Documents

Quick status update on SRP and UL


DS: one DISCUSS outstanding.
TL: the DISCUSS is from Paul Wouters, to be done soon.


Update Lease

DS: Approved by IESG.

Advertising proxy


SC presenting slides.
TL: adding a litle bit: had a discussion with Stuart, then realized we
could publish names under a subdomain of .local, not the TLD .local.
mDNS could be extended to do browses as well in subdomains. However, we
realized PTR records never have conflicts. So we could browse .local
(PTR records) and discover service names in a subdomain of .local (not
the TLD). This is now reflected in the document (Github version).
Service discovery just works.

Josh Cohen: if Matter uses unique IDs, how does a conflict arise?
TL: ...
SC: any conflict we see/get, in Matter, are due to the passage of time /
race conditions. So not an actual conflict, but same service/name
advertised from different entities (adv proxies).

JC: not the device name changes, but rather record data (e.g. ip
address), and there's old and new values - is that the context?
SC: yes.
JC: compares to WPAD in mid 1990s.

Esko Dijk: Needs to understand how it updates dns-sd RFC. Section 1
doesn't allow for different domain names, i.e. subdomains of .local for
SRV records, currently(?). Implementations may not support subdomains in
this way.

SC: We want matter to work, so make this work. We can check
I know that the subdomains work for the hostname already, because I've
tested it for demos.

Open Issues

Multiple questions in a single packet


SC: presenting slides
SC: explains the choices that Thread made (openthread implementation),
for QDCOUNT = 2. But that it has problems when the DNS resolver isn't
compatible with this approach.
SC: possible solution (in cooperation with Ray Bellis) - see qtypes
draft link below.
Typical use case was A/AAAA record in a single query. Not so compelling.

SC: today, with Thread in home networks, we have a compelling use case.
The draft is already going into the right direction.

DS: this would fall into dnsop naturally?
SC: ideally dnsext, but that doesn't exist anymore.

CB: does Ray want to present first before we take the queue? (Yes.)

RB (Ray Bellis): explains background of the multi-qtypes draft, ~2012.
(No slides)
It has EDNS option to request for multiple QTYPEs for same name.
You can tell whether the server did actually process the option.
There are a few edge cases defined; indicated by the bits.
The DNSSEC case is addressed in the draft.
DNSOP chair indicated it would fit there.

BO: happy to coordinate this with DNSOP. WG draft QDCOUNT=1 was just
adopted. (see link below)
RB: we can coordinate the different drafts easily.

DL: in which WG; DNSOP is best place. Be aware that there's a movement
to indicate capabilities better by resolver and by client. So modern
clients can detect modern servers, etc.

SC: we can work together in whatever WG we do this work.

TL: looked at DNSOP charter, and it encourages other WGs to do the work.
So here in dnssd WG is better!

DS: the ADs get final say.

RB: I can rev the draft as soon as I know what WG to put it in.

LP (Libor Peltan): better to make a more suitable RRTYPE, and ask to
query this single RRTYPE?

SC: Yes, makes sense, but we can't change it now anymore.

Tim Wicinski: We will abide what the working groups vibes are.
will bring this up tomorrow morning.

SC: we need to establish if we're willing to do the work here.

DS: chairs will take the action to work with the ADs.

DS: do you foresee general usage, or in Thread only?
CS: we want to migrate to single query in bw compatible way.


see also:

Possible solution

EDNS Multiple QTYPEs option
(see notes above!)

Individual Drafts


TL: it looks like there's no progress, but ... didn't get around to
making the update. One of the co-authors left Apple. Need new co-author.
(No need to be an expert. But willing to do work.)
TL: current implementation in Apple tvOS - as a DNS option.
TL: we learn as we go along, as in a research project. We learned that
fingerprinting is the wrong approach.
TL: so far we avoided sending TSR in answers, to avoid caching it. But
now we want to do that (to avoid many multicasts in probing); so we
change to EDNS0 option. (format shown on slide)
TL: next step is to try out the new format, which will work well in
combination with SRP replication and Adv Proxy together.

JC (Josh Cohen): TSR is Time Since Received, but is time compared in
TL: no, not for actual conflicts. Only for stale data.
TL: the time difference is calculated. Avoids having to have accurate
JC: agreed.
JC: where was this implemented?
TL: only for mDNS - Apple mDNSresponder. In Linux, it would be like
SC: any device with Thread radio + WiFI or Ethernet, can be a Border
Router (BR). You typically buy them for another function but will work
as BR as well.
TL: application currently is IoT, smart home. It uses SRP instead of
mDNS. (mesh networked IoT devices).
JC: these devices are basically self-appointed?
TL: the SRP requestor is the source of truth - it may talk to multiple
Border Routers at different points in time. The requestor can be
validated (due to signature).
SC: example - service might be Matter light bulb, supporting on/off
service. Controller looks for such entities. It started with a single
SRP registry on a single BR. But unlike your home gateway, the BRs may
be unplugged by users (e.g. Apple Homepod), at any time.
JC: asking what to read as background.
TL: (gives a long list of docs to read)
SC: also see thread spec, threadgroup.org.
TL: open source implementations on openthread.org.

AC (Alex Clouter): is it advertising how fresh the data is?
TL: yes, how fresh and where it came from.
AC: could use delay in response, the older, the slower the response?
TL: issue is - how long do you delay. WiFi is an issue, multicasts go
out in lockstep (blocks every ~300 ms). So random spreading doesn't
TL: mDNS actually assumes Ethernet for timing; doesn't work on WiFi. We
may consider revving the mDNS spec.




SRP Replication

TL presenting. (slide title wrong)
TL: we saw some issues, also reported by Abtin K from Google.
TL: replication may require replaying multiple of the host messages, and
it may include stale data, causing conflict. Gets better with TSR, but
it's dumb to advertsise data you know that's stale. Apple impl currently
just gives up. Google impl ignores and tries to continue. But gives
(see slide 'More issues')
TL: proposing to just sync with peer, then trigger the AdvProxy to

AK (Abtin Keshavarzian): may add communication about the sync partners,
e.g. signaling if a sync-partner went away.
TL: as discussed in SF 117. Requesting AK to help edit the document.
AK: will try.


Closing Remarks

CB: end of agenda. Take the questions to the list about Adv Proxy and

TL: AdvProxy doc was substantially updated.
ED (Esko Dijk): not so well readable yet. Will provide feedback.