-----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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf