That's mDNS, which is not the DNS, just an insecure local discovery
protocol based on DNS wire messages. Surely mDNS is out of odd scope here.
Nico
On Friday, March 6, 2015, John C Klensin <john-ietf(_at_)jck(_dot_)com> wrote:
--On Friday, March 06, 2015 07:28 +0100 Patrik Fältström
<paf(_at_)frobbit(_dot_)se <javascript:;>> wrote:
Thanks for the comments. While digesting them, I have one
comment:
On 6 mar 2015, at 07:14, John C Klensin <john-ietf(_at_)jck(_dot_)com
<javascript:;>>
wrote:
Generally, while I think you should warn that URI records may
cause some risks that do not exist with, e.g., conventional
name to address mappings (note that the "downgrade attack or
not" considerations above would apply equally well to:
foo.example.com. IN A 10.2.0.44
being diverted into a response of
foo.example.com. IN A 10.0.0.6
(which would be, historically, a likely upgrade attack, but it
has nothing to do with URI records but is equally preventable
by an integrity check.))
As long as there is a warning, I really don't care very much
what you say, but whatever you do say should be as accurate as
possible.
I also see tons of zeroconf stuff (Apple Bonjour) using DNS
already today in the geographically local context without much
DNSSEC.
I think that strengthens the argument for some Applicability
Statement action about DNS-related threats, trust models, and
attacks that integrity checks do or do not protect against
rather than trying to push too much off on this particular
document. I still don't have a strong opinion about where the
optimal boundaries lies, but I don't think it is rational for
the IETF to not do the A/S work but then hold up individual
documents because they don't contain all of the discussion that
A/S might contain.
That said, if the IETF considers it to be a valid implementation
of DNSSEC to have the closest-to-user validating system be an
ISP-based forwarder rather than a machine on the user's LAN,
there isn't a lot of point in building DNSSEC capability into
zeroconf stuff that is mostly applicable intra-LAN or otherwise
within a trust perimeter that the DNSSEC validator is outside of.
Put differently, any time a DNSSEC-based trust model comes down
to "trust your ISP", then it is pointless overhead for any of us
who already know our ISPs can't be trusted. And _that_ is why
I'm reluctant to see it oversold in circumstances like the
current document.
john