Subject: Re: Last Call: draft-cheshire-dnsext-multicastdns (Multicast DNS) to Informational RFC

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Thu, 26 Nov 2009 10:28:41 +0100

Hi,

I have reviewed draft (-08) and support it, on the Informational track.

(apologies for any duplicates as I tried to send this unsubscribed)

Review comments.

* The NSEC type is used for negative responses (from a discussion in
DNSEXT).  However, the draft specifies that only the bitmap for types
0-255 is to be included.  I feel this is overly constrained.  The
restriction may prove burdensome, also since those types are not really
in use anyway (except DLV), the effect of the rule is very low.  Is this
for backwards compatibility?  If it is for packet size, well, TXT
records can be large too and are not disallowed either.

* The document is verbose, but well written.

* The rule that .local names MUST be sent to mdns(port 5353).  I feel
this is a little too strong, there are sites out there that have set ups
with .local in their unicast DNS.  Propose: SHOULD.

* The mdns resolver is highly integrated into the device it is on, with
an 'active interest and notification API'-recommended, with interface
changes (up down netmasks) and sleep-wake cycle information used.  Thus
this is very different from unicast DNS, whose servers are more
independent.  The rule to do punycode (unicast) to utf8 (multicast)
conversion does not make the codebase smaller.

* There is a line about the use of DNSSEC when mdns is used during a
unicast DNS outage.  The sentiment about protecting against forged
answers is fine (this issue is handled well in general), but I think
building a chain of trust towards DNSSEC-attested data is going to be
very hard when unicast DNS is down.

* I noted that the TC flag on unicast still means TCP fallback but this
does not work in all cases.  It is of course very useful to get large
replies to legacy (unicast) queriers.  Case: the other hosts can see a
multicast query, and the full answer cannot be sent on multicast (due to
size, even with TC=1 on multicast for message concatenation), the other
hosts conclude there is no answer after timeout.  The unicast response
to the querier does have the required effect, but only for the original
querier.  This is probably not an issue since such large (9kb RR rdata)
records are not common.  A response that would trigger TCP connections
from all multicast hosts on the network is probably not such a good idea
:-)  Some multicast error response, SERVFAIL for that query, so the
other hosts do not modify their cache? (since existing code ignores
rcode!=0, this is probably backwards compatible)

* It may be prudent to have in conflict resolution a line that says that
if repeated conflicted announcements of unique records are observed by
another host, then the host SHOULD consider itself to have lost (and
rename itself).  Or put differently: if a particular host on the network
keeps causing conflicts, get out of the way, even if the spec says you
should have won, because this avoids packet-chatter on the network.

Best regards,
   Wouter

---

From: Dave Cridland <[email-masked]>
Date: Thu, 26 Nov 2009 11:38:29 +0000

> should have won, because this avoids packet-chatter on the network.

Wouldn't this lead to a potential attack by deliberately introducing  
a conflict and taking over a name? Currently, it's possible to take  
over a name by advertising, for example, an A record for a name with  
a higher IP address - since you can easily advertise a name with an  
arbitarily high IP address, this is fairly easy to do, but it'd be  
far simpler just to ignore the probe protcol entirely, as that leads  
to a more seamless takeover of a particular name in most  
circumstances.

Of course, DNSSEC might help here, but presumes that either a  
participant has the ability to sign RRs online, or else is a silent  
partner with a preconfigured trust anchor. (In general, I find the  
comments in the document about DNSSEC somewhat hand-wavy, but I admit  
I lack much knowledge about DNSSEC). Still, if all participants have  
access to the private key for DNSSEC, that provides a significant  
number of possible attack points, I'd have thought - I'm assuming  
here that things like your network printer need to be configured with  
the private key, which may not be the case.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Wed, 25 Nov 2009 10:52:33 +0100

Hi,

Review comments.

Best regards,
   Wouter

---

From: Stuart Cheshire <[email-masked]>
Date: Mon, 30 Nov 2009 14:23:39 -0800

> with .local in their unicast DNS.  Propose: SHOULD.

I think you may be misreading this.

A statement of "MUST do X" does not imply "MUST NOT do NOT X".

A host implementing Multicast DNS, performing a Multicast DNS query,  
MUST send that query to the Multicast DNS port, or it won't work.  
There's no "SHOULD" about it. An implementation cannot choose to send  
the Multicast DNS query to a different port and expect it to work.

A host implementing Multicast DNS generally implements a variety of  
other name resolution mechanisms like standard unicast DNS, NetBIOS,  
a local "/etc/hosts" file, etc., and names can be looked up via those  
mechanisms too. Indeed, you will find that if you install iTunes on  
your PC, even at a site that's set up a private DNS server for  
"local", the sky does not fall. What happens is that Windows (and Mac  
OS X too) look up dot-local names both ways.

Looking up names more than one way is not as efficient as it could  
be, and it might be better if we didn't have to do that, but it does  
work.

I will add some text explaining this.

Stuart Cheshire <[email-masked]>
* Wizard Without Portfolio, Apple Inc.
* Internet Architecture Board
* www.stuartcheshire.org