# Extensions for Scalable DNS Service Discovery (dnssd) IETF 118 {#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 Chairs NOTE WELL 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 {#adopted-wg-documents} Quick status update on SRP and UL ### SRP {#srp} DS: one DISCUSS outstanding. TL: the DISCUSS is from Paul Wouters, to be done soon. https://datatracker.ietf.org/doc/draft-ietf-dnssd-srp/ https://datatracker.ietf.org/doc/draft-ietf-dnssd-update-lease/ ### Update Lease {#update-lease} DS: Approved by IESG. ### Advertising proxy {#advertising-proxy} https://datatracker.ietf.org/doc/draft-ietf-dnssd-advertising-proxy/ https://datatracker.ietf.org/meeting/118/materials/slides-118-dnssd-simplifying-advertising-proxy-00 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. (https://en.wikipedia.org/wiki/Web\_Proxy\_Auto-Discovery\_Protocol) 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 implementations. I know that the subdomains work for the hostname already, because I've tested it for demos. ## Open Issues {#open-issues} ### Multiple questions in a single packet {#multiple-questions-in-a-single-packet} https://datatracker.ietf.org/meeting/118/materials/slides-118-dnssd-multiple-dns-questions-00 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. https://www.ietf.org/archive/id/draft-bellis-dnsext-multi-qtypes-07.html see also: https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-qdcount-is-one ### Possible solution {#possible-solution} EDNS Multiple QTYPEs option (see notes above!) ## Individual Drafts {#individual-drafts} ### TSR {#tsr} 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 conflicts? TL: no, not for actual conflicts. Only for stale data. TL: the time difference is calculated. Avoids having to have accurate clocks. JC: agreed. JC: where was this implemented? TL: only for mDNS - Apple mDNSresponder. In Linux, it would be like avahi. 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 work. TL: mDNS actually assumes Ethernet for timing; doesn't work on WiFi. We may consider revving the mDNS spec. https://datatracker.ietf.org/meeting/118/materials/slides-118-dnssd-time-since-received-tsr https://datatracker.ietf.org/meeting/118/materials/slides-118-dnssd-time-since-received-tsr-slides-118-dnssd-time-since-received-tsr https://datatracker.ietf.org/doc/draft-tllq-tsr/ ### SRP Replication {#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 conflicts. (see slide 'More issues') TL: proposing to just sync with peer, then trigger the AdvProxy to publish. 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. https://datatracker.ietf.org/doc/draft-ietf-dnssd-srp-replication/ ### Closing Remarks {#closing-remarks} CB: end of agenda. Take the questions to the list about Adv Proxy and multiple-query-types. TL: AdvProxy doc was substantially updated. ED (Esko Dijk): not so well readable yet. Will provide feedback.