bmanning@vacation.karoshi.com wrote:
On Fri, Oct 23, 2009 at 12:22:52AM +1300, Perry Lorier wrote:
You could imagine extending this to other services such as NTP, but I'm not sure that you really would want to go that far, perhaps using DNS to lookup "_ntp._udp.local IN SRV" or similar to find your local NTP servers.
Another obvious approach might be to have a service discovery protocol where you send to a "service discovery" multicast group a message asking "wheres the nearest nameserver(s)?" then nameserver implementations could listen on this multicast group and reply. Again shared fate. This does have the downside of people running rogue nameservers and needing a "ServiceDiscovery-Guard" feature for switches....
ah... well - if your a router centric person, then you want to put everything into the tools you know and love.
Generally I don't think of myself as a router centric person ;)
if your a dns centric person, then you put everything in the DNS.
This has always sounded like a nice solution to me, however, DNS is starting to look a little long in the tooth, overloading it with more and more semantics seems to be pushing it well beyond it's design envelope. (EDNS0?)
I point you to the "DISCOVER' opcode (experimental) in the DNS and the use of DNS over multicast for doing service discovery (e.g. Apples Bonjour)... Most of that is already designed/deployed and in pretty widespread use... over IPv4 or IPv6.
Yup, they're good ways to discover some local resources. To my understanding mDNS works over the local subnet, unless you're going to start having your routers run as mDNS relays (is there any standards for this? How do you stop mDNS relays from creating loops and broadcast storms?). mDNS works over a a single multicast group with a single port 5353 which makes it hard to filter different types of services (People on this switch can announce their iTunes sharing, but they're not allowed to announce a local DNS server) without DPI, you're more likely to find network engineers just filter the entire multicast group breaking it for other purposes If you're not going to have mDNS forwarders on your routers, then you're going to need to reconfigure your entire configuration on every segment as well. (IMHO) there are different types of configuration: * Network related (routes, addressing). RA's seem to do a fairly good job at at least 80% of this. * Network provided services, such as DNS, NTP. Well known anycast addresses seems to be (IMHO) the best way to advertise these. Currently you need DHCPv6 to get this information. * Application settings (web proxy, local outgoing SMTP relay, default printer location, local SIP/RTP proxy, local home/intranet page, what the current local timezone rules are). This seems to be currently done by a variety of adhoc protocols, usually bundled over well known DNS names with HTTP, often replicating the same information in a wide range of different places in different formats. This seems an ugly solution, but I have no other suggestions. I'm sure there are several RFCs/Drafts around somewhere that tries to solve this. * Ephemeral end user provided services, which is already provided today by the well documented, and deployed mDNS. in theory you can kinda pick and choose between those, for instance you can run just mDNS on a network without RA's or DHCPv6 and things will work (for the limited value of work that involves only whatever the ephemeral services are being announced). You can run RA's by themselves, and your bittorrent will work fine.
And yes, its not RA/ND, or DHCP... its another configuration protocol and its not quite vendor specific. The best thing is, it pushes the smarts closer to the edge (the end device) and this makes me happy.
Theres a general issue of access control. While I like a very smart edge, you don't want some ""misinformed"" user turning on a feature and suddenly having the rest of your network ending up using it.
Personally I like the first option (anycast addresses) better, you can control who has access to your IGP and if your IGP is down, then for all intents and purposes your recursive nameservers are offline too :)
everyone to their own taste.
Yup. There are different systems, they have different tradeoffs. Pick the one that trades off things you don't care about for things you do care about. :)