Domain: multicastdns.org
Stories and comments across the archive that link to multicastdns.org.
Comments · 8
-
Re:I know I am stating the obvious
Clearly, you've never heard of Multicast DNS which is convenient for IPv4 networks as well as IPv6 ones. If you must use an IPv6 address to access a device on your local network, you can also use a link-local address which is at least as easy to remember as an IPv4 one.
Or the totally simple approach: say that your IPv6 range is 2001:db8:0:1::/64
You want to FTP something from a laptop with an FTP server which has an address of 2001:db8:0:1:747f:698f:adf7:fd83, but that's too hard to remember.So add an IP address of 2001:db8:0:1::21 to your laptop. Do the transfer, remove the address. Easy!
-
Re:I know I am stating the obvious
No. Because those are handled by DNS-servers now. If you expect us not to bother with IPs in an age where every single device on the face of the Earth has its unique, globally routable address, you're going to have to give us a DNS that handles them all.
IPv6-accessible sites need AAAA records just as IPv4-accessible sites need A records. You don't need AAAA records for every IPv6 node any more than you need an A record for every IPv4 node.
Even if I want to FTP to the PC in the other room from my laptop, I'd have to type the full v6 address (back to square minus one), a shorter NAT-ted-mangled address of some sort (back to square one), or a device name. As the addresses are globally routed, there needs to be a global DNS record for that PC and my laptop, otherwise we're back to addresses...
Clearly, you've never heard of Multicast DNS which is convenient for IPv4 networks as well as IPv6 ones. If you must use an IPv6 address to access a device on your local network, you can also use a link-local address which is at least as easy to remember as an IPv4 one.
-
multicast, and overflowing by network congestion
What if your favorite DNS server happens to use a multicast address, and for some strange routing reasons, your queries get routed to the other side of the world... perhaps through the Med, every now and then? Or if you even happend to be an mDNS early adopter/tester/developer/..., and the same happens? And even if you didn't look so far, network links get congested, and traffic could easily overflow to peering networks, and this could very well mean, that ISP A and ISP B, both in the US, transmit packets through Asia or Europe as a congestion-avoidance measure. As a matter of fact, it happens quite frequently (and the other way around too).
-
Re:As usual, other considerations...
Oh yeah, Bonjour is totally undocumented:
- Zeroconf, the internationally standardized RFC 3927 upon which Bonjour is based, isn't documented at all
- Nor are Multicast DNS (mDNS) and DNS Service Discovery (DNS-SD), the open standards which make up Apple's Bonjour implementation
Apple also has nearly no Bonjour end user, developer, or technical overview documentation, and certainly doesn't make the source code, or even a binary Windows version, available.
And yeah, products like iTunes, Apple TV, local host discovery, all HP and many other network printers, and similar totally don't use Bonjour, so it's ok to block it.
The lack of documentation alone might make one want to block it! -
Re:Hmmm...
An Apple employee (Stuart Cheshire) is one of the authors of the RFC(s) related to mDNS, etc.
mDNSResponder originated from Apple. -
Re:So let's see...
Rendezvous is based on a few underlying services: Dynamic Configuration of IPv4 Link-Local Addresses, Multicast DNS, and DNS-based Service Discovery.
Dynamic Configuration of IPv4 Link-Local Addresses: In the absence of a DHCP server, the machine is able to configure itself with an IP address in a reserved range such that it doesn't clash with other IP addresses configured by other machines on the same network in a similar manner.
Multicast DNS: Multicast DNS Responder services on each machine respond to multicast queries for their DNS information.
DNS-based Service Discovery: Querying for the existence of services (HTTP, FTP, SSH, etc.) via DNS.
So, in a sense, "everything is a DNS/DHCP/Directory server" but only for the information and services provided by that particular machine. -
Re:New bugs, ease breaking havoc on your LAN
mDNS isn't crap, it's cool, something like it been needed for a long time, and it's going through the IETF standards process. Apple's not "hijacking" anything. If you believe that using
.local is a mistake, then you can bring up your concerns on the appropriate IETF working group. The IETF standardization process is completely open; anyone can join the mailing list and voice their concerns and get things changed. Look here for info on mDNS and the related IETF working groups you can join. -
Very nice ideaI was also suprised that Apple did not activate this for personal web sharing. It is nice that somebody corrected it. This said, in my case, the hack does not work correctly: it seems the advertised local address has a period after the
.local domain, so the browser can't find the actual web server.I really hope that rendez-vous technologies get ported to other Unixes soon. For instance, multicast DNS is really nice in LANs where IP addresses are assigned via DHCP. You can simply type something like ssh server.local and it works. When you use laptops, it is really a killer feature.