I would be very interested in understanding what technical errors I made and I
would appreciate if you would share the details with me, perhaps off-line.
The message sent to the IETF list contains several major technical errors,
including:
a. Confusing DNS resolver behavior with the behavior of LLMNR
implementations. The sending of .local queries to the global DNS, while
potentially a serious problem, results from the behavior of existing DNS
resolver implementations. This problem exists today on the vast
majority of Internet hosts, which do not implement either mDNS or
LLMNR. Given this, putting language into the LLMNR specification
to "fix" an orthogonal issue makes no sense.
Even fixing the issue in another IETF specification could prove sticky,
because it can be argued that the IANA has authority over the allocation of
new TLDs such as ".local" not the IETF, which is why the DNSEXT WG
recommended early on that the ".local.arpa" domain be used instead of
".local".
b. Confusion between security issues and namespace separation. In
peer-to-peer name resolution protocols, it is possible for a responder to
demonstrate ownership of a name, via mechanisms such as DNSSEC. It is
also possible for a responder to demonstrate membership in a trusted
group, such as via TSIG or IPsec. If DNSSEC is available, spoofing
attacks are not possible, and querying for FQDNs does not expose the
sender to additional vulnerabilities. Both the mDNS and LLMNR
specifications agree on this point.
c. Lack of consideration of existing practice. Internet hosts have used
multiple name resolution mechanisms based on a single API for more than
two decades, with no ill effects. For example, *NIX systems have utilized
/etc/host files, NIS and DNS; Windows systems utilize LMHOSTS, DNS and
NetBIOS. The issue of integration of multiple name services is dealt
within multiple RFCs, including RFC 1001 which defines NetBIOS and
describes how it coexists with DNS and RFC 2937, which describes the Name
Service Search Option for DHCP. In practice, hundreds of millions of
Internet hosts use these mechanisms every day. If you type "http://foo/";
in the browser of a Windows host, a DNS query for "foo" is not sent over
the wire; only a NetBIOS query is sent. This is not rocket science.
Please remember, though, that most of my note was not meant to express my own
technical opinion, it was an attempt to summarize the issues that were raised
by others in this discussion.
The job of an IESG member is not to repeat mistatements, it is to use their
judgement. In this and other instances, the IESG appears to have lost sight
of its mission. The best interest of the Internet community lies not in
blocking the publication of documents that fall outside today's orthodoxy,
but rather in providing information to the Internet community. In this case,
that interest would be best served by publishing *all* documents
relating to mDNS and LLMNR, especially the ones that the DNSEXT WG has found
most objectionable (such as DNS-SD, and Bill Manning's DISCOVER OPCODE draft).
I must admit that at one point, I did not see value in funding the RFC
Editor to publish documents outside of the IETF process, via the RFC
Editor Individual Submission route, described in RFC 3932. However, now
it has become abundantly evident that this represents an important
safety mechanism that needs to be preserved going forward.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf