So, I think the Mac OS implementation is broken if it will not
properly resolve .local when I telnet
None of those entities is responsible for top level domains. That being
said, since we don't really own "local." either, it would be nice if we
could play well in an environment that is using "local.". The original
plan was to use "local.arpa.". For various reasons, some related to
marketing and some to user experience, it was changed to "local.". We
needed a way to give a host a name that could easily be typed by a
user, could easily be recognized as a local only name, and would avoid
conflicts with DNS names. The LLMNR draft is proposing that one use an
"unqualified" DNS name or a name that is normally associated with a
machine. This has a variety of problems associated with it. There is no
such thing as an unqualified name in a DNS packet. You can not tell the
difference between a query for an "unqualified name" and a top level
domain in the DNS packet. This means that you have to pick names that
don't conflict with top level domains. You can't name your tv "tv" for
example. It is not clear why you can't do this. These names also can't
be distinguished from names that will be resolved using DNS. The
resolver has no idea which resolver to hand the query off to.
Putting mdns in the "order" creates a lot of problems. Instead of
opening that can of worms, mDNS uses the "local." top level domain to
indicate that the name has only local meaning and should be resolved
using mDNS.
I think that is a bad solution. local. can have meaning beyond the
subnet. In any AS, it is perfectly fine to route 1918 address space,
as long as it is blocked beyond the border. Of course a good dns
server admin will also block queries for PTR lookups to those
addresses at their border. http://www.caida.org/outreach/presentations/ietf0112/dns.damage.html
The order solution has a number of problems.
1) If I do a query for www.amazon.com, I don't ever want that query to
go to mDNS.
2) If I do a query for joshs-tibook.local, I don't want to have to wait
for a DNS timeout before mDNS is tried.
3) If it's just an order thing, what sort of names should be created
for a host? How do we keep those names from conflicting with names in
DNS so we can always find the local machine?
The only solution we could come up with was to use a domain that no one
else was using. It sounds like the domain we picked conflicts with your
new setup. Perhaps a domain such as "link" to differentiate from "site"
local would have been a better domain. What's done is done. For
compatibility reasons, we can not move away from ".local".
What will you do if network solutions starts vending out the "local"
top level domain?
I was not able to find any RFC or current internet draft that is
claiming lordship over the .local domain. In my opinion, mdns is
breaking DNS, and telnet'ing to a .local machine is more important to
me that Rendezvous. If it is a requirement to reserve the .local tld,
then Apple should get on the ball and write the draft and get it
turned into an RFC
Have you ever tried to work with the IETF to get something done? We've
been trying to work with the IETF. It's a lot like trying to get 200
people to agree on a restaurant for lunch. It just takes one obnoxious
guy with a loud mouth to keep everyone hungry. Nothing ever gets done
anymore, the IETF is broken. By the time the IETF gets something from a
draft to an RFC, the industry has already solved the problem and moved
on. Of course, without something like a lightweight IETF, products from
one vendor don't interoperate with one another.
-josh
_______________________________________________
rendezvous mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/rendezvous
Do not post admin requests to the list. They will be ignored.
