-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAksOSkkACgkQkDLqNwOhpPg5PACfaUMmPV/IB5+AzDQ2rDlmQsnc nBkAnAv3WG5fdRoi41EKIWcyx/3oQblB =k2RH -----END PGP SIGNATURE----- _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf