> Bernard Aboba <aboba@xxxxxxxxxxxxx> writes: > > 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. > We agree that home burglary is a serious problem. This is why we > recommend that everyone hire an armed guard for their house. If your > house is monitored by armed guards, burglary is very unlikely. Given that > there is an effective security mechanism available, there's really no need > to consider simple deterrants that won't provide true security. We do have a strong tendency to let the best be the enemy pf the good, don't we? > > 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. > "No ill effects" is a horribly inaccurate description of the effects of > that design. A much more accurate description would be that Internet > hosts have used multiple name resolution mechanisms through a single API > out of necessity for more than two decades, have suffered frequent ill > effects up to and including major outages because of it, but have > struggled along with that design because there are some features provided > by it that are too useful to completely dismiss in general. That being > said, most systems attempt to avoid using those features when feasible and > attempt to make all sources of information match exactly to avoid the > serious and often hard-to-diagnose problems of conflicting information. > If you think that using /etc/hosts, NIS, and DNS at the same time on > systems to provide name resolution is a *success* story, your perceptions > of the practical problems of name resolution in Internet hosts is > drastically different than mine. You've also had to maintain far less > code to try to work around bizarre inconsistencies in gethostbyname > responses than I have. I could not agree more. This particular hairball has been a consisent source of support problems around two decades now. In fact it may have set some sort of record: I cannot think of anything else we were using 20 years ago is still causing exactly the same sorts of problems it caused back then. Ned _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf