Re: Policy of IPv6 DNS Discovery

["Eric A. Hall" <ehall@ehsco.com>]

on 8/2/2003 5:11 PM Rob Austein wrote:

> If I understand it correctly, the simple version of what you propose
> (just using multicast to find recursive name servers, nothing else)
> substitutes one multicast-based discovery protocol for another
> multicast-based discovery protocol.  Since it's quite possible to
> co-locate a DHCP-lite "server" inside the same "process" (or whatever
> fate sharing unit a server host uses) as the recursive name server,
> the fate sharing comparision comes out as a wash when one looks at it
> closely.  So one's left arguing about relatively trivial engineering
> details like packet formats and port numbers.

There's also the operational overhead differences. You'll still have to
manage static pre-configured lists of servers, for example, while there
wouldn't be any such lists with the multicast DNS 'CONFIG' model. Since
any server that responded to the request would be a candidate, managing
the list would essentially boil down to adding and deleting servers (or
enabling and disabling recursion on those servers), and the new list of
servers would self-identifies on the next query seamlessly.

Granted, there would be some administration in terms of ensuring that
multicast filters were working properly, but this is less than the
requirements for DHCP.

> The SRV based stuff is a different ball of wax: in that one, you're
> reinventing SLP instead of reinventing DHCP :). 

I wasn't advocating any additional work for SRV. I was making the point
that SRV-based configurations only requires a working resolver, and that
the multicast CONFIG approach gets that minimal level of service working
*from inside DNS* as well. So again, for those services which use SRV,
using a DNS-based configuration service makes it simpler since everything
~needed would be in the resolver code, with no external services needed.

> In any case, either version of what you're talking about still looks
> to me like a proposal for new protocol work.

A new DNS opcode and some behavioral rules.

> We're still trying to
> determine whether -any- new protocol work is needed, so this, like the
> RA-based and ND-based proposals, isn't really in scope at the moment.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

#----------------------------------------------------------------------
# To unsubscribe, send a message to <dnsop-request@cafax.se>.