Re: Policy of IPv6 DNS Discovery

[Rob Austein <sra+dnsop@hactrn.net>]

At Sat, 02 Aug 2003 16:24:00 -0500, Eric A. Hall wrote:
> 
> I don't know if you're bundling my complaint in the latter camp or not,
> but if so that's an incorrect interpretation. My complaint is that the
> mandatory requirement introduces unnecessary complexity to the default
> scenario by interfering with the application-layer DNS service, imposes
> non-intuitive management cycles onto the service ("oh yeah, my resolver
> gets its config from this extraneous service that I forgot about because
> I'm not using it for anything else"), and is wholly unnecessary when the
> service is capable of handling it internally.
> 
> Separately, use of in-band dynamic discovery via multicast also allows
> SRV-based discovery mechanisms to bootstrap further. Those systems also
> operate outside of or run in parallel with DHCP.

No, sorry, I forgot about yours, and you're correct that it doesn't
quite fit into any of the pigeon holes in my previous message.

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.

The SRV based stuff is a different ball of wax: in that one, you're
reinventing SLP instead of reinventing DHCP :).  While one could
certainly have a fun discussion along those lines, the ZEROCONF and
DNSEXT WGs have already spent a lot of time down the LLMNR rabbit
hole, and I'm reluctant to follow them down there.

In any case, either version of what you're talking about still looks
to me like a proposal for new protocol work.  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.
#----------------------------------------------------------------------
# To unsubscribe, send a message to <dnsop-request@cafax.se>.