[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


Cc: dnsop@cafax.se
From: Mark.Andrews@isc.org
Date: Fri, 14 Nov 2003 04:14:59 +1100
In-reply-to: Your message of "Thu, 13 Nov 2003 10:28:27 MDT." <3FB3B12B.9000000@ehsco.com>
Sender: owner-dnsop@cafax.se
Subject: Re: well-known addresses / was DNS discovery


> 
> Mark.Andrews@isc.org wrote:
> 
> > 	It's not a requirement if the ONLY thing you want clients
> > 	to know about the DNS is the addresses of nameservers.  In
> > 	the real world there are lots of organisations that want
> > 	to push other configuration details out.  The proposals
> > 	you are competing with can support this.
> 
> Well... It's 'possible' to pass a search list to the resolvers as part of
> a startup negotiation, it's just not necessary, and it may even be
> determined as undesirable after some more thinking.

	No one is saying you have to supply the information.  What I am
	saying is that the *ability* to do this is crucial in some
	environments.

	I don't want my ISP to supply a search path.  I also don't
	want my ISP to depend upon that search path in there HTML
	documents.

	I have also been a network adminstator in a business.  In that
	envirionment setting search lists is important.
 
> In particular, if the logic focuses on choosing a candidate server versus
> using any available server, then the server part of the algorithm can
> require "return a list of SOAs for which you are authoritative", and the
> client algorithm can allow the resolver to use the owner names of the SOAs
> as the search list. Extending this logic a bit, it's feasible that any
> particular implementation could provide a configuration ~directive that
> filtered the domains which the server should return, thereby providing a
> way for managers to control the search list array in use by the clients.
> 
> Negotiation versus queries isn't the focus of the current WKA proposal, of
> course, but as I already said, I think that's the second necessary change
> (switching to multicast is the first; anycast is a non-starter).
> 
> -- 
> 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>.
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews@isc.org
#----------------------------------------------------------------------
# To unsubscribe, send a message to <dnsop-request@cafax.se>.

Home | Date list | Subject list