# IETF 115: Extensions for Scalable DNS Service Discovery WG ## Tuesday 2022-11-08 15:00 GMT/UTC in Kensington 1, West Wing, 3rd floor Minute taker: Eric Kinnear ## Advertising Proxy for DNS-SD Service Registration Protocol [draft-ietf-dnssd-advertising-proxy-01](https://datatracker.ietf.org/doc/draft-ietf-dnssd-advertising-proxy-01/) Ted Lemon: (see slides) Slide 6 Esko Dijk: I think that sounds good, I also proposed something in the email. Ted: If the client wants a comprehensive set of answers, they should be doing DNS Push, not regular UDP queries. Esko: Yup Slide 8 Esko Dijk: RFC 8375 defines home.arpa. I read that to mean that it covers the entire home network. You could do this with a single SRP server that's authoritiative for home.arpa. Neighbor with same name is a different zone. Ted: These are locally served, so in principle you're not on your neighbor's network, so you never ask them. Esko: Right, ideally it doesn't conflict that way. home.arpa is already defined. Being able to do this more granularly, like if you had multiple stub networks, then you might need new names for that. I do not totally follow what you mean for "this link" -- isn't that .local? Ted: Yeah, .local usually means use mDNS, do we want to overload that to say "do it with DNS if you're not using mDNS". It seems like maybe it is the right thing to do, but if so we need to say that. Esko: You could have something for identifying all stub networks and the adjacent infrastructure link. Ted: In Thread, we're using something for that, but we have multiple advertising proxies with multiple Thread networks, and they'll all be advertising into the .local zone with a big pile of stuff, but is that really what we want to do? Stuart Cheshire: RFC 6762 says that if a name ends in ".local", you look it up with multicast to a link local address. We can change that to say "do that, or the equivalent thing that gets the same answers", or we can say no it needs to be different. It's kind of a coin toss, we can do either. Ted: Right, and if you have a multi-link home network, then .local means a different thing based on the link. In theory, it would be better to have something that doesn't change meaning based on what you're connected to. For home.arpa, some of my pushback was based on homenet experience, looking at multi-link home network. Unclear that that's highly deployable. Idea was that each link on the home network would be a sub-domain of home.arpa, so yes you're in home.arpa but it's subdivided. Also, it's only for homes, using home.arpa seems wrong for a commercial environment. Esko: Wanted to ask a question about default.service.arpa. SRP says that's an alias that should be mapped to something else, what is that something else by default if not configured? Ted: Says it's okay to use default.service.arpa and you could just ask questions of that directly. David Schinazi: (as individual) Agree with Ted about home.arpa, it comes with a bunch of baggage. Names are cheap, this is standards track document, needs IAB approval. I'm One of Them. Will not be a problem. Any time we have a choice to reuse something or define something new, for me the distinguishing factor is what people will do when it shows up on an old box, is the existing behavior going to be correct and sufficient, or will it cause weird breakage. My gut feeling here is that we want the old device to send it over unicast, not only multicast on the local link. Ted: The old device is probably just going to do a multicast DNS query. David: Yes, if you pick .local. But not if you do something else. Ted: Good point. We already support doing legacy service discovery, pretty much everybody: Windows, Mac, Linux, Android. Depends on distro for linux. If you have a device with multiple interfaces, then .local means different things on different interfaces. We support that on macOS by returning the , but that's an additional complication. Éric Vyncke: Best to avoid using .arpa because it may leak out. Ted: The reason we use default.service.arpa is because we expect the -bis to get that allocation. Home.arpa and service.arpa will go to the blackhole servers. That should be okay, and on a Thread network it will never escape that network. David: What's the alternative. Éric: We can try to go through all the hoops we went through for .local Ted: It sounds like you're arguing for the same thing we were arguing for when we asked for .home. IAB decided it wasn't really the trouble with arguing that with ICANN. Éric: Register this zone before it's used in actual code at least, please. David: Thanks. The tradeoff here is that you end up hitting the root instead of the .arpa server. Chrome was the biggest botnet on the internet. Chrome's fault that it was 90% of the load on the root servers. We turned that off. Stuart: To Éric's point, the IANA registry exists for a reason. It's an accident of history where things progressed at different rates. If we decide to do something else, we can change it, we ship software updates and we're open to changing that. There's a side meeting tomorrow to discuss special use domain names and how they're allocated and managed. Please attend if interested, and read the (short) draft beforehand. David: Side meeting is 10:30a in Richmond 6 Lars-Johan Liman: Chrome issue is different because they were random and could not be cached. That's not the same case as what we're talking about here. Also, the arpa servers are identical to the root name servers. We do now have the option to delegate that elsewhere, but still the same thing for now. Less concern as a root server operator because it can be cached. This will be discussed tomorrow, please listen in and come talk about it. Consider talking to the DNS directorate. Ted: Discussion in dnsops today as well around this area. Slide 9 Esko: Some things (avahi) are not being maintained, issues are not being fixed. Ted: Discussion around adding more maintainers. Also talking about putting into systemd. Hopefully work will continue. Esko: Important to agree on a new place to maintain it. Stuart: Quick comment on this topic, since it coems up a lot: When we're using an advertising proxy to make Thread devices visible on Wi-Fi, the Thread link-local addresses are clearly not reachable since it's a different link. For other use cases, if you're just on Wi-Fi and migrating to unicast from multicast, you might be discovering something that's actually on the same link. My preference is to give the client all the addresses and let the client pick. Others sometimes want to prefilter it to avoid confusion on the client. Some very embedded networking stacks are more restricted in their abilities to choose the right address. Ted: I think one thing that's important is to not make constrained devices do Happy Eyeballs. I think the SRP registrar ought to be able to handle this, but that depends on where it is: if in a stub network router, then it knows where it came from and it's easy to tell what to do. If you've got a home router that supports SRP and it's advertising it on the link, then the Thread Border Routers would defer to the main one. Wouldn't know for any given query if the link local address would work or not, so that's hard. David: (no hats) Happy eyeballs on not super constrained devices is great, if you have a very constrained device it's probably going to pick the first one. You might be able to get out of it is by playing with the ordering. Ted: One thing to keep in mind is that we're used to mDNS doing this and we expect mDNS to improve things. Here, we don't know, but probably fine if we're clever about how we order things. Mark Andrews: What we really need to do is get rid of unscoped addresses. Scoped addresses give a name and that identifies the link, and the RA has a link name in it. Devices can look at the RAs and filter everything that doesn't match what the RA is saying is the name of the link. I've floated this a couple of times in v6ops or 6man, but we keep coming across this problem. We can do this with A records as well. RFC1918 addresses, too. You can put the addresses in the DNS and have the end device make sensible choices about what's reachable or theoretically reachable. We have a method of naming things that are unique, it's called the DNS. Ted: Two things about that: (1) I'm not convinced that having a new record is the right solution to this, maybe the discussion earlier about how to name links was the right way to go. Not saying you're wrong in general. (2) naming links is actually a really hard problem, let's be honest about that too. Mark: Agreed, but we should have a way to make that unique, we should be able to work that out within your organization. Ted: Remember that there's not necessarily an organization. Mark: But within your home. Pick a random number. Ted: Who does that? Mark: Let the CPE do that. David: Not in scope for DNS-SD Mark: Agreed, but it's something the IETF needs to address, because it keeps coming up. David: I'll let you sync up with Éric, or AD, who might be able to help you find a WG or to bring a draft to dispatch. ## Service Registration Protocol for DNS-Based Service Discovery [draft-ietf-dnssd-srp](https://datatracker.ietf.org/doc/draft-ietf-dnssd-srp/) ## An EDNS0 option to negotiate Leases on DNS Updates [draft-ietf-dnssd-update-lease-03](https://datatracker.ietf.org/doc/draft-ietf-dnssd-update-lease-03/) ## Discussion topics ### Interaction between a DNS server and Discovery Proxy co-hosted on same device. Esko's question Ted's reply Naming of “default” DNS zone in a home network. Esko: With the SRP draft, we introduce the concept of a DNS zone in a home network, other than “.local” zone(s) which we already had. However SRP doesn’t discuss the naming of this zone / zones. draft-lemon-srp-replication section 2.1 does discuss this but leaves still lot of options. Shouldn’t we be able to define a single “default” home network zone for this, e.g. “home.arpa.” in RFC 8375, or “local.arpa.”, or “.service.arpa.”? Then SRP servers in the same home can sync with others in the same zone. Suppression of link-local addresses in mDNS responses. Esko: Against RFC 6762 requirements. Any implications from this, or actions we may take? ## Individual Drafts ### Automatic Replication of DNS-SD Service Registration Protocol Zones [draft-lemon-srp-replication-02](https://datatracker.ietf.org/doc/draft-lemon-srp-replication-02/) ### Multicast DNS conflict resolution using the Time Since Received (TSR) RR [draft-tllq-tsr-02](https://datatracker.ietf.org/doc/draft-tllq-tsr-02/) (Both drafts above, combined) Allows us to lose a server without losing a zone, as long as at least one server survives. David: We have talked about this, and we were waiting to progress the adopted documents before adopting this. Now that those have moved forward a bit, we think there's bandwidth, but we are planning to hold an adoption call soon assuming there's interest. Anyone object, please explain why. (silence) Look to the list for that, there will be lots of space to discuss there. Ted: Can we get an early allocation for codepoints. Éric: Looking forward to request after adoption. David: For TSR, I think we have the bandwidth as well. Concern that it's only Apple folks on it. If you're interested in joining onto this document, this is a great place to get started and please come and talk to Ted and Stuart. We'd like to see some additional folks and a very clear expression of interest before an adoption call.