[dnssd] Review of draft-ietf-dnssd-hybrid-00

[Tom Pusateri <[e-mail]>]

I thought before a new version was released, I would go ahead and do another detailed review of the hybrid proxy draft.

Abstract 2nd paragraph
======================
	"Performing DNS-Based Service Discovery using purely Unicast DNS is more efficient”
	I’m sure it is more efficient in some ways and not as efficient in other ways. Also, it obviously depends on the underlying link layer and the transport protocol and security layers. I don’t think a general statement of unicast being more efficient than multicast is possible.

Introduction 3rd paragraph
==========================
	Similarly, "since even on a single link multicast traffic is expensive”. Again, it is expensive in some ways and more efficient in other ways.

Section 2 3rd paragraph
=======================
	There is a pointer to [802.5] with no matching reference. Add http://xml2rfc.ietf.org/public/rfc/bibxml2/reference.IEEE.802-5.1995.xml

Section 3 1st paragraph
=======================
	After describing in the previous section what is meant by “on the same link”, Section 3 says unicast DNS domain names are assigned to "each physical link”. The word physical should be removed. Another way to say this may to use “each IP subnet” which could be included in section 2 as well.

Section 3 2nd paragraph
=======================
	"This Hybrid Proxy function could be performed by a router on that link, or, with appropriate VLAN configuration, a single Hybrid Proxy could have a logical presence on, and serve as the Hybrid Proxy for, many links”
	This wording is a little awkward and makes it seem as though multiple VLANs are required for a Hybrid Proxy to serve many links.

Section 3.2
===========
The acronym LDH (Letter, Digit, Hyphen) is not defined or referenced anywhere. A reference to Section 2.2 of RFC 5890 should be included.

Section 3.3 2nd paragraph
=========================
The example IP addresses should use documentation IPv4 address ranges as specified in RFC 5737.

Section 3.3 4th paragraph
=========================
	"(In the Apple "/usr/include/dns_sd.h" APIs, using ForceMulticast indicates that the DNSServiceQueryRecord() call should perform the query using Multicast DNS.)”
	The significance of this reference is not apparent.

Section 3.4.1 2nd paragraph
===========================
	needs updating for DNS Push Notifications

Section 3.4.2
=============
	Since hybrid proxies can never know all of the possible records in the subdomain, it is not possible to build NSEC next record relations. Therefore, all NSEC records learned over mDNS (typically in the Additional Section) should be filtered in unicast DNS responses sent by the hybrid proxy.

Section 3.4.3 4th paragraph
===========================
	"violations optional” should be "violations are optional"

Section 3.5 2nd paragraph
=========================
	needs updating for DNS Push Notifications

Section 3.5.1
=============
	If the hybrid proxy implements LLQ or DNS Push, it should advertise its own SRV records for LLQ and/or DNS Push through mDNS on the shared IP subnet.

Section 3.5 5th paragraph, 2nd bullet
=====================================
	"No LLQ option; at least one answer in cache: Send response right away to minimize delay.
	(Reasoning: Given RRSet TTL harmonisation, if the proxy has one Multicast DNS answer in its cache, it can reasonably assume that it has all of them.)”
	Because of Probing (section 8.1) and Announcing (section 8.3) in RFC 6762, isn’t it possible that a hybrid proxy could have one answer in its cache but not all answers?

Section 4.2 2nd paragraph
=========================
	needs updating for DNS Push Notifications

Section 4.3
===========
	Since stitching together multiple .local domains isn’t specified, it seems premature to say it’s not implemented, both in the same paragraph.

Section 5 1st paragraph
=======================
	"For this reason, each physical link may have *two* unrelated ".local." zones, one for IPv4 and one for IPv6.”
	The word “physical” is used again here but I would prefer to see IP subnet or just link without the “physical” since you defined what link meant.

Section 5 2nd paragraph
=======================
	Although this section doesn’t specifically say so, it seems to be saying do not use the same subdomain name for IPv4 and IPv6 on the same link. Since we want to encourage IPv6 proliferation and yet it will be difficult to withdraw IPv4, I would rather say it is assumed that if you assign the same subdomain name to both IPv4 and IPv6 subnets on the same link, you are assuming that the clients on the link can handle this scenario. If you have IPv4-only hosts or IPv6-only hosts, then assign different names to prevent learning about services that you won’t be able to reach. This leaves the choice up to the administrator.

Section 6.1
===========
	"If greater security is desired, then the Hybrid Proxy mechanism should not be used, and something with stronger security should be used instead, such as authenticated secure DNS Update”
	It would seem that there are other ways to provide greater security with the hybrid proxy including DNSSEC record signatures of the service records, as an example, and so the hybrid proxy could still be used if greater security is desired.

Section 6.2
===========
	"The privacy of this information may be protected using techniques like firewalls and split-view DNS, as are customarily used today to protect the privacy of corporate DNS information.”
	The hybrid proxy could also only provide sensitive records to authenticated users. But this is a general DNS problem and not a problem specific to the hybrid proxy. A reference to the work in DPRIVE that outlines DNS privacy issues might be appropriate: draft-ietf-dprive-problem-statement-04

Section 6.3
===========
	"Multicast traffic is expensive”
	I would like this to either say "Multicast traffic can be expensive” or “Multicast DNS is expensive”.
	Multicast traffic is not always expensive.
	Also, since multicast can mean link-layer multicast, link-local IP multicast, or routed IP multicast, the document should be more specific here and with other uses of multicast.

	"For Wi-Fi links the Multicast DNS subsystem SHOULD NOT	issue more than 20 Multicast DNS query packets per second.”
	On a campus with lots of unicast queries, this number seems arbitrary. Is there some justification or maybe a rule of thumb here?

Missing
=======
	The hybrid proxy should respond to SOA requests for the subdomain in order for LLQ and DNS Push discovery to work correctly.
	However, if there are multiple hybrid proxies providing answers for the same IP subnet, only one of them can be the SOA and so a method is needed for coordination between the proxies.

	As mentioned above in 3.5.1, multiple hybrid proxies can discover each other if they implement LLQ or DNS Push and so the one with the lowest IP address could be the SOA or some similar tie-breaking mechanism without having to configure a priority that has to be exchanged.

Other
=====
	If no DNS server is present (like in a home network), but there are multiple IP subnets connected to the home gateway, and only mDNS queries are made on each subnet, is this scenario covered by the hybrid proxy? Or is this just a form of mDNS translation that is not currently documented by any IETF standard?