I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. Document editors and WG chairs should treat these comments just like any other last call comments.
This informational draft specifies a multicast link-local variant of DNS which varies in a number of ways from the IETF DNS standard. Much of it is written in a style to persuade the reader of the merits of the protocol specified or head off potential complaints about it.
SECURITY COMMENTS:
The Security Considerations section seems reasonable for an informational document describing an existing link local usage. The following other sections have security implications which could be briefly mentioned or referenced in the Security Considerations section.
Section 4 mentions dependence of earlier versions on IP TTL 255 to detect link local.
Section 14 gives various details related to failing over to multicast DNS from classic DNS and having the TLD ".local" in ones search list.
Section 21.2 (Arguments for using a different port (UDP port 5353):) point out that use of 5353 is more convenient for unprivileged clients providing mDNS on systems where they could not access a low numbered port like 53. But this seems to imply some sort of security risk of making it easier for a random unauthorized client doing this.
OTHER COMMENTS:
Section 3.1/3.2. I don't want to comment on the politics of this but it strikes me as a bad idea to dilute the claim on .local. by giving a bunch of alternatives. Just stick to .local. I support its use for, well, "local" names. :-) And numeric TLDs are a really bad idea, conflicting in commonly accepted syntax with IP addresses.
Section 3.3 (Maximum Multicast DNS Name Length). As far as I know, and I've checked with experts, the answer is that the wire encoded limit is 255 bytes including the final zero value terminating byte that is the length of the root label. That's clearly what RFC 1034 says. "all label octets and label lengths" means *ALL*, including the label length for the root label. In this regard, RFC 2181 is simply confusing/confused. RFC 2181 appears to be talking about text representations of DNS names, not wire encoding. It talks about "separators", which are the periods between labels, which have nothing to do with the DNS length limit which is defined with reference to the wire encoding. So, "example.com" has 10 bytes of text labels plus 1 byte of text separator, for a text length of 11. But its wire encoding has length 13, one for the length of "example", seven for "example", one for the length of "com", three for "com", and one for the length of the root label (which is the empty label). So, when RFC 2181 talk about "the zero length name" it is talking about the number of text bytes in the root label, which is zero, not the wire encoding length, which is one.
Section 20.14 (Name Compression) is questionable. It gives advice that implementors should do name decompression in all the rdata for RRs that the implementor knows about. I guess this is not a problem but, due to the difficulty in updating every old implementation in the world when a new RR type comes along that has potentially compressable names in rdata, it just seems impractical to believe that interoperable name compression can be provided in the rdata of future RRs. Having an explicit list of RRs where such compression is done, as is also provided by Section 20.14, is fine and I think it is OK for this to differ from that for classic unicast DNS. Other/future RRs should just be handled as in RFC 3597.
Section 8 (Responding), 3rd paragraph, last line. "must not" -> "MUST NOT".
Section 9.2 (Simultaneous Probe Tie-Breaking). I was initially puzzled by all the stuff about initially comparing the class of answers. When you do a query, you only get answers for the class you queried. True, there is a qclass "*" (0x00FF) for any class, but why would you be using that? Different classes are meant to be completely disjoint spaces. Names are explicitly local to a class in DNS. However, I concluded you were just trying to compare the top bit of the rrclass field which this spec re-defines... Maybe this should be clarified.
Section 20.3 (OPCODE), the parenthetical "(only standard queries are currently supported over multicast, unless other queries are allowed by some future extension to the Multicast DNS specification)" is internally inconsistent. The allowing of something in the future has no effect on the current state. Suggest just saying "(only standard queries are currently supported over multicast)".
Section 22 (Summary of Differences Between Multicast DNS and Unicast DNS), I'm not convinced that all the listed items are actually differences. For example, defining a clear maximum legal fully qualified domain name size on the wire is the same but gratuitously different. Its 255 bytes for classic DNS and you have changed this for mDNS to 256 bytes. Is one byte really worth the inconsistency?
Section 24.1 (IPv6 Multicast Addresses by Hashing), does this actually not apply to IPv4? If it does apply to IPv4, some minor rewording of this section would be called for.
TRIVIA
Section 8 (Responding). "immediately without delay" seems a tad redundant. Three occurrences, one with a comma. Suggest using one or the other.
Section 17 (Multicast DNS and Power Management), this seems sufficiently beside the main point of the draft that it could be made an Appendix.
Second paragraph of Section 25, "administered" -> "configured". Administered could mean anything but configured sounds like you've actually set values.
Thanks,
Donald
=============================Donald E. Eastlake 3rd +1-508-634-2066 (home)
155 Beaver Street
Milford, MA 01757 USA
d3e3e3@xxxxxxxxx
_______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf