[dnssd] Document updates to add authors

[Ted Lemon <[e-mail]>]

I've updated two documents, draft-ietf-dnssd-advertising-proxy and draft-tlmk-infra-dnssd to add Esko Dijk and Karsten Sperling respectively as authors.

I also addressed the two outstanding issues on the TSR document in a pull request that I'm assuming Esko will approve, merge and publish prior to the cutoff. 

For draft-ietf-dnssd-advertising-proxy, the version on github has a few text fixes as well but I didn't do those in the version I just published, because I only noticed them afterwards.

I think the document right now is a bit lacking in normative specification, and could stand to be updated. It's also a bit vague about some choices, e.g. it does say the advertising proxy has to do TSR, but that's at the end of a long discussion of what can happen if it doesn't, which I think might confuse the reader.

Also, the choices about dealing with conflicts seem too vague. We kind of leave it up to the implementor, but I think that's not ideal. We also don't really explain what the implications are.

Specifically, the reason that we don't just say "respond with an SRP conflcit when we see a conflicting mDNS registration" is that a conflicting mDNS registration can be an attack or a mistake (that is, not a real name conflict), and renaming may not make sense in this case.

I think what the document should say is that when there is no conflict, the name should be registered directly under .local. When there is a conflict, PTR records should be registered under .local anyway since there can't be a conflict there, but other records should be rewritten into a local domain. What that domain should be is unclear. Right now it suggests using the srp replication dataset id, but this can change fairly frequently, which isn't ideal. We'd probably prefer that it remain fairly stable over time.

There are two cases that we might care about here: the case where there is a single dns zone being advertised, and the case where multiple zones are being advertised. This is slightly complicated in that the zone itself might not have a unique name—e.g., default.service.arpa is used by all Thread border routers, and there can be more than one Thread network operating independently adjacent to a single WiFi link, for example.

To deal with this I would suggest that we support two use cases: the case where the zone being advertised is a real DNS zone that is globally unique—that is, has a delegation from the root and can be resolved by a recursive resolver if it's able to reach the authoritative server. And the second case is where you have a network such as Thread for which the network itself has a unique identifier—in the case of Thread this is the xpanid. In that case I would suggest that the domain name be simply the xpanid run through base32 (RFC4648), with the trailing = left off. This should be relatively compact (better than hex) and would still use human-readable text.

So when using this domain, we'd see this service:

_printer._tcp.default.service.arpa. IN PTR foo._printer._tcp.default.service.arpa
foo._printer._tcp.default.service.arpa IN TXT "."
foo._printer._tcp.default.service.arpa IN SRV 0 0 1234 foo.default.service.arpa
foo.default.service.arpa IN A 169.254.123.234

translates to:

_printer._tcp.local IN PTR foo._printer._tcp.dchpw7sa2mm.local
foo._printer._tcp.dchpw7sa2mm.local IN TXT "."
foo._printer._tcp.dchpw7sa2mm.local IN SRV 0 0 1234 foo.dchpw7sa2mm.local
foo.dchpw7sa2mm.local IN A 169.254.123.234

However, if there is no existing corresponding name in .local, it translates to:

_printer._tcp.local IN PTR foo._printer._tcp.local
foo._printer._tcp.local IN TXT "."
foo._printer._tcp.local IN SRV 0 0 1234 foo.dchpw7sa2mm.local
foo.local IN A 169.254.123.234

The alternative is to just force renaming somehow in this situation. The advantage to doing this is that some consumers of mDNS may fail to correctly resolve a host if it contains a subdomain of .local. However, such a consumer of mDNS Is broken, so arguably we want it to be fixed rather than to simply endure its brokenness. This proposed solution is a good protocol choice; the question is whether we are willing to tolerate the possible challenges of backward compatibility.