Last Call Review of draft-cheshire-dnsext-multicastdns-
review-cheshire-dnsext-multicastdns-secdir-lc-eastlake-2009-12-18-00

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 at gmail.com