Subject: Re: [dnssd] WGLC on draft-ietf-dnssd-hybrid-03

From: Tim Chown <[email-masked]>
Date: Sat, 2 Apr 2016 13:25:09 +0100

Hi,

Ralph and I will take further comments to the list in advance of the dnssd meeting on Monday.

Comments of the form ‘this is ready to ship’ are also very useful.

Tim

> On 17 Mar 2016, at 22:36, Tim Chown <[email-masked]> wrote:
> 
> Dear dnssd WG participants,
> 
> We are initiating a WG Last Call today on draft-ietf-dnssd-hybrid-03, as can be found at https://tools.ietf.org/html/draft-ietf-dnssd-hybrid-03 <https://tools.ietf.org/html/draft-ietf-dnssd-hybrid-03>.
> 
> The call runs for two weeks, and will thus close on Thursday 31st March.
> 
> Please send any comments (including indications of support for progression of the document as is) to the [email-masked] <mailto:[email-masked]> list. This draft will not be advanced for publication unless there is sufficient response and support from the WG.  And, of course, any substantive comments on the draft are strongly encouraged as well. We are aware of a small number of minor outstanding comments from the list, but will consider these as part of the WGLC process.
> 
> We will discuss the comments arising from the WGLC in the WG meeting in BA on Monday 4th April.
> 
> Abstract
> 
>    Performing DNS-Based Service Discovery using purely link-local
>    Multicast DNS enables discovery of services that are on the local
>    link, but not (without some kind of proxy or similar special support)
>    discovery of services that are outside the local link.  Using a very
>    large local link with thousands of hosts facilitates service
>    discovery, but at the cost of large amounts of multicast traffic.
> 
>    Performing DNS-Based Service Discovery using purely Unicast DNS is
>    more efficient and doesn't require excessively large multicast
>    domains, but requires that the relevant data be available in the
>    Unicast DNS namespace.  This can be achieved by manual DNS
>    configuration (as has been done for many years at IETF meetings to
>    advertise the IETF Terminal Room printer) but this is labor
>    intensive, error prone, and requires a reasonable degree of DNS
>    expertise.  The Unicast DNS namespace can be populated with the
>    required data automatically by the devices themselves, but that
>    requires configuration of DNS Update keys on the devices offering the
>    services, which has proven onerous and impractical for simple devices
>    like printers and network cameras.
> 
>    Hence, to facilitate efficient and reliable DNS-Based Service
>    Discovery, a compromise is needed that combines the ease-of-use of
>    Multicast DNS with the efficiency and scalability of Unicast DNS.
> 
> 
> Thanks,
> 
> Ralph and Tim
> dnssd WG co-chairs
> 
> 
> 
>

---

From: Markus Stenberg <[email-masked]>
Date: Sat, 2 Apr 2016 20:47:43 +0300

I was on vacation during WGLC (good timing - I was leaving home when it started, lost my laptop charger early on the trip and by the time I got home official WGLC window was done). Disclaimer: This is a beer-powered remotely participating hobbyist commentary based on reading my own earlier comments + draft deltas, and does not consititute a full review. Sorry.

Anyway..

Section 1 - isn’t this scheme essentially aiming at causing more multicast duplication too? (e.g. given ‘home’ DNS-SD browse domain, if we send unicast for each sublink.home, we wind up with N multicasts per single logical request).

Section 4.5.1 - I wonder about positive TTL limiting. Because if device ‘moves’, it most likely will either
a) have two different names (foo.link1.home, foo.link2.home), or
b) one name with two addresses (foo.link1.home A 192.168.1.1, foo.link1.home A 192.168.1.2).

Happy Eyeballs-ish should take care of either in practise, so I am against positive TTL limiting. Negative TTL limiting makes sense except in some DoS scenarios which can be circumvented to some degree by e.g. limiting total # of multicasts send by hybrid proxy over time interval per link or something.

Overall, I find the text bit too prescriptive (‘do it this way’), as it forbids you from having a service that e.g. only supports printer and apple TV services, and proactively queries for them rarely => no need for extra traffic by whatever occurs on wire, and the content could be even pushed to e.g. normal DNS-SD using DNS Update or equivalent ( draft-lemon-homenet-naming-architecture-00.txt has strawman proposal about this, and I thought about it years ago too but never got around to implementing or specifying it ). Another scheme would be completely passive node that did clever things with e.g. L2 availability to detect when stuff drops off link ‘fast enough’.

Second major missing piece from my point of view is the section 6.4 paragraph 2 - stitching together of zones. As it is, the single logical request => N multicasts propagation sounds somewhat undesirable to me.

While not having reread the whole thing again (see sorry above), my earlier nits are mostly addressed, I cannot find anything particularly broken (see disclaimer about beer), and I think it is ‘ready’ for some  definition of ready. I would not personally want it as a choice for any large network though, due to it forcing exactly one operating model for the mdns->dnssd translation which I am no longer convinced is actually optimal. For home network purposes this works, but I would be leery of saying this is ’the way to do it’ without some simulation results in e.g. enterprise or university deployment scenarios.

Cheers,

-Markus

---

From: Ralph Droms <[email-masked]>
Date: Sat, 2 Apr 2016 16:38:11 -0300

I have a technical issue with draft-ietf-dnssd-hybrid-03 that, in my opinion, requires come clarification.

Section 4.3 describes how a Hybrid Proxy processes a received Unicast DNS query.  I understand, in principle, that the Hybrid Proxy consults its local mDNS cache to construct a response to the Unicast DNS Query.  The last paragraph begins with:

   Naturally, the existing Multicast DNS caching mechanism is used to
   avoid issuing unnecessary Multicast DNS queries on the wire.

I've re-read section 5.2 of RFC 6762, "Multicast DNS".  Based on section 5.2 of RFC 6762 and section 4.3 of draft-ietf-dnssd-hybrid-03, I would not be able to justify the specific ways in which the Hybrid Proxy cache is used and any requirements for the Hybrid Proxy to issue an mDNS query to refresh its cache.  That is, I can't determine if the Hybrid Proxy always issues an mDNS query based on a received Unicast DNS query to initially populate its cache, or if the Hybrid Proxy can construct its response based solely on its cache in some circumstances, or there is some other behavior.

- Ralph

> On Mar 17, 2016, at 7:36 PM 3/17/16, Tim Chown <[email-masked] <mailto:[email-masked]>> wrote:
> 
> _______________________________________________
> dnssd mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/dnssd

---

From: Tom Pusateri <[email-masked]>
Date: Sat, 2 Apr 2016 17:22:30 -0300

I think this is answered in the details of section 4.6 Answer Aggregation and it depends on if a subscription exists or not.

Tom

> On Apr 2, 2016, at 4:38 PM, Ralph Droms <[email-masked]> wrote:
> 
>> https://www.ietf.org/mailman/listinfo/dnssd <https://www.ietf.org/mailman/listinfo/dnssd>
> 
> [email-masked]

---

From: Dave Thaler <[email-masked]>
Date: Sun, 3 Apr 2016 15:51:38 +0000

My comments...

Section 1:
>    up the dot-local  host names of peers on the same home network, and

s/dot-local/".local"/
for consistency with ".home" in quotes later in the same section

Section 3:
>   Existing clients that support DNS-Based Service Discovery over
>   Unicast DNS (Mac OS X 10.4 and later, including iPhone, iPad, and
>   Bonjour for Windows ) work with Hybrid Proxy.

Suggest removing parenthetical clause since this is not a complete list.
E.g., Windows 10 supports DNS-SD over unicast DNS. Rather than 
trying to have a complete list which might be obsolete by the time
the RFC is published, it's easier to omit.

Section 4.2.2:
>    for the following Multicast DNS Domain Enumeration queries issues  by

s/issues/issued/

Section 4.4:
> In other words, the Hybrid Proxy becomes the 
>   authoritative name server for the reverse mapping domain.

This says "the" (singular) authoritative server.
Is it limited to only one per link?   What if it goes down?

Section 4.5:
>   Generating the appropriate Multicast DNS queries involves, at the
>   very least, translating from the configured DNS domain
>   (e.g., "Building 1.example.com") on the Unicast DNS side to "local"
>   on the Multicast DNS side.
>
>   Generating the appropriate Unicast DNS responses involves translating
>   back from "local" to the configured DNS Unicast domain.

If the unicast query contains an xn-A-label, should the translation
convert it to a U-label on the multicast side?

Section 4.5.1:
>    reasonble  to expect it to take on the order of ten seconds for a

Typo "reasonble"

Section 4.5.2:
> Similarly, for sites that
>   have multiple private address realms [RFC1918], private addresses
>   from one private address realm should not  be communicated to clients
>   in a different private address realm.

Should "should not" be MUST NOT or SHOULD NOT?
I'm guessing MUST NOT.

Section 4.6:
>   DNS device taking even longer than that (e.g, a device that is not

Missing period after "e.g"

Section 5:
Two notes exist that should be removed before submitting to the IESG:
>   [Author's note: Or maybe it could just be zero?]
...
>   [Author's note: Discussion of these recommendations is requested.]

Section 6.1:
> When you  Press Cmd-P on your Mac, or
>   select AirPrint on your iPad or iPhone, and the Terminal room
>   printers appear, that is because your client is sending unicast DNS
>   queries to the IETF DNS servers.

The use of 2nd person implies that the audience of the document is just
IETF attendees.  Suggest use of third-person instead.

Section 8.2:
>   become visibile  in a domain such as "My House.example.com" that might

Typo " visibile "

Section 8.3:
> For Wi-Fi links the Multicast DNS subsystem SHOULD NOT
>   issue more than 20 Multicast DNS query packets per second.

This does mean that an attacker that can generate >20 unicast queries (e.g., 
for names that don't exist) per second can DOS valid queries for names not
in the cache.   This should be pointed out since 8.3 is the section on DOS.

Section 11:
> [Partial list; more names to be added.]

Another note to be removed before submission to IESG.

Dave

From: dnssd [mailto:[email-masked]] On Behalf Of Tim Chown
Sent: Thursday, March 17, 2016 3:37 PM
To: [email-masked]
Subject: [dnssd] WGLC on draft-ietf-dnssd-hybrid-03

Dear dnssd WG participants,
We are initiating a WG Last Call today on draft-ietf-dnssd-hybrid-03, as can be found at https://tools.ietf.org/html/draft-ietf-dnssd-hybrid-03.

Please send any comments (including indications of support for progression of the document as is) to the [email-masked] list. This draft will not be advanced for publication unless there is sufficient response and support from the WG.  And, of course, any substantive comments on the draft are strongly encouraged as well. We are aware of a small number of minor outstanding comments from the list, but will consider these as part of the WGLC process.

Abstract

Thanks,

Ralph and Tim
dnssd WG co-chairs