[dnssd] Last call comments on draft-ietf-dnssd-hybrid-03

[Ted Lemon <[e-mail]>]

I’ve tried to do a thorough review of the mdns-dnssd-hybrid document--sorry it’s taken so long.

My general feeling about the document is that it’s the wrong way to solve the problem, but also the expedient way to solve the problem.   So I don’t want to stand in the way of its publication, but there are some things I’d like to see done differently if it’s possible.  I am not clear on exactly what has seen widespread implementation, so some of my comments may require overcoming a lot of inertia, but I suspect not.

What I would really like to see in the long run is a clean DNS-based solution with as much of the mDNS stuff hidden or eliminated as possible.   I do not know what the feeling of the working group is on this--maybe I’m out in left field and everybody else is happy with the proposed model.   But here’s a high level summary of what I would change:

First, the current document assumes that there is no mechanism for statefully publishing information.   This is not something that is, as far as I know, a requirement--it's just a result of the approach that the hybrid draft takes.

This approach has a couple of results.  First, it means that you have to name every link, because you have to have a delegation for every link.   This is just not going to work for homenet.   Homenet users won’t necessarily be able to cognize the thing that the word “link” refers to, and won’t be able to assign names to links, so the homenet would have to generate names, and those names wouldn’t make sense either.   So this model can’t actually support a homenet in practice, despite Markus and Steven's no doubt excellent proof-of-concept implementation.

Unfortunately, the model as currently described doesn’t offer a way out of this.   In principle, there’s no reason that you can’t have an mDNS hybrid on every wire all of which update the same DNS primary, and let services on the local wire that support DNS update as well as mDNS do the update themselves, through the mDNS proxy so that off-link attacks can be rejected.

You could just do mDNS only for publication, but my reason for not wanting that is that ideally we’d like to wean ourselves off of mDNS to the extent possible--it doesn’t scale, as this document says, and some of the text in this document tries but IMHO fails to effectively rate-limit it.   This will be a particular problem if we expose the DNSSD tree to off-site queries, which we would have to do to allow legitimate off-site use of services: if you restrict queries to 20 per second, it's not that hard to imagine running up against that limit in practice when nobody's doing anything bad.   This is particularly the case because the link-naming strategy is going to tend to push sites to use larger links than they might otherwise have done.

I think it may be possible to tweak this specification so that it _allows_ for the DNS model I just described but doesn’t require it.   Essentially whether you implement the hybrids as a cache or as a primary name server and a bunch of secondaries that will relay updates from the local network is an implementation choice, isn’t it?   But if we did that, I think it would have to be the case that the whole section on disallowing zone transfers goes away, since they could now be supported.

This is what I’d like to see happen, but I will not be deeply surprised if the working group throws rotten tomatoes at me for proposing this now.   That said, I’m hoping Stuart will do me the kindness of a sit-down this weekend or sometime on Monday before the meeting to see if there’s a middle ground to be reached.

The one thing that I’m fairly sure could be done painlessly, and that I think would make the document a lot less complicated and a lot less difficult to explain, and would also simplify implementation, would be to get rid of the two-subdomains hack.   The point of this hack as far as I can tell is to allow each wire to have a UI-presentable name.  But this is totally unnecessary--since the multilink DNSSD model is new, why not just have a well-known name under the single per-link (or whatever) subdomain that has a TXT record hanging off of it with the presentation name for the subdomain?   Then you can have a unified domain with all the presentable and non-presentable names in it, and bob’s your uncle.   This also saves you having to deal with the A-label problem for link (or shall we say "zone"?) names.

E.g., using the example in 4.3, and assuming the WKN is _textname:

      _textname.bldg1.example.com TXT “Building 1”
      My Printer._ipp._tcp.bldg1.example.com.
                                  SRV 0 0 631 prnt.bldg1.example.com.
      prnt.bldg1.example.com.     A   10.0.1.2

On to more detailed comments:

The abstract is way too wordy.   You’re trying to explain to someone who is searching why they should read the document, not explain the entirety of what the document says.   Suggestion:

 This document describes a method for extending Multicast DNS Service
  Discovery so that it can support automatic service announcement
  and discovery across multiple links.   This is accomplished using
  a hybrid DNS model, where services are discovered using Multicast
  DNS if required, and published using DNS if possible, and Multicast
  DNS otherwise.

The other text should be moved to the Introduction if it isn’t already there.

Document doesn’t appear to talk about how resolution happens in a homenet (which is sort of okay, since that the the HNSDA’s job).   However, the text in 4.1p3 says that normal delegation is used, and that won’t work in a homenet that doesn’t have a global name.   It may be worth clarifying this.   Also, what if the reverse tree for IPv4 is some kind of RFC1918 address space?   Is the process of delegating this address space discussed elsewhere in the document?

4.2.1 seems to be recapitulating RFC 6763 section 11.   Can this be streamlined by simply referencing that section?

Regarding 4.2.2, what is the prevalence of DNSSD clients that only support mDNS?   That is, how badly would it suck to not provide multicast browsing services?

Quoting:
   If a given link is using the IPv4 subnet 10.1/16, then the domain
   "1.10.in-addr.arpa" is delegated to the Hybrid Proxy for that link.

How is this accomplished?   10.in-addr.arpa is delegated to itself.   This section also does not mention how ULAs are supported, but it seems like they should be.

I think the answer to this question is that the local caching resolver that is returned by DHCP and ND should answer for all private zones, either with information or with the appropriate error, so in principle this is manageable, but of course not using DNSSEC.   It appears that the author agrees at least regarding suppression, and I suspect also with the rest, but it should be stated explicitly in the document, since what the document currently says isn’t actually possible.

This document doesn’t make any reference to the idea of using DNS update to publish DNSSD services, which is something that the original DNSSD RFC does describe (although it doesn’t explain it in detail).   I think this is an unfortunate omission, because it means that there is no recommended path forward for fixing mdns’ chattiness.

Is there any reason not to use TTL=0 for all DNS responses?

Another way to deal with embedded .local names would be to allow resolution of .local names on other links if there is no conflict.   Arguably this is better than diving into TXT records, since in general it should always work.   Seems like Stuart’s already thinking about this.

I don’t disagree with the use of LLQ as a way to improve UI responsiveness, but I think that the concern about caching on an institutional network is probably overblown.   Would be interesting to see real numbers.   We care a lot about multicast; not so much about unicast.

You shouldn’t recapitulate the procedure for discovering push/LLQ servers, and shouldn’t reference LLQ unless you intend to publish it.  It’s interesting historically, but is deader than a doornail, not work “in progress”!

SOA increment could happen whenever the cache is changed as a result of an update.  You should definitely update the serial number at least that often, don’t use zero.