Re: the well-known address approach

[Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>]

Rob Austin;

> I'll try to summarize what I remember, with the understanding that
> this is just my view.

Thank you.

> Ignoring irrelevant issues (eg, the IPv6 Site-Local swamp),

That is a reason good enough to avoid reading the archives by myself.

> I still have concerns with the well-known address approach:

Most, if not all, of the concerns is seemingly addressed by Alain
that I add my own comments.

> - How does this interact with LLMNR?  Eg, how is a node supposed to
>   know whether it should be doing LLMNR or not?  (NB: I'm no fan of
>   LLMNR, but it's out there and people are using it.)

LLMNR was another swamp, but is filled up by DNSOP. So, the LLMNR
document has made it clear how the interaction between LLMNR and
configured DNS servers, hasn't it?

However, I sill am not so sure what the precise requirement of
LLMNR is, so that some of it may be overridden by DNS
autoconfiguration, but it is not anycast-specific and is a
problem of LLMNR.

> - There are layering and administrative issues.  This approach puts
>   the DNS configuration information into the routing system.  It's not
>   immediately obvious that the local routing system and the local
>   recursive name servers are necessarily controlled by the same
>   administrators,

In anycast proposal, it is not assumed that the local routing
system and the local (or external) recursive name servers are
necessarily controlled by the same administrators.

An example is ISP controlled name servers exemplified in
my draft. But, the point should have been sunken in the
swamp of scope.

Router configuration is required to limit the scope of local
(or external) recursive name servers, which is common to all
the proposals here.

> - There are also fate sharing and coupling issues.  Using well-known
>   addresses hides the binding between the addresses and the particular
>   recursive name servers in question, which may matter if one or more
>   of the recursive name servers starts flaking out. 

>   In the "normal"
>   (not well-known-address) case, a resolver can keep track of which of
>   the recursive name servers it's using is performing, and might
>   conceivably inititate some form of recovery action (eg, probing for
>   a new set of recursive name servers) if something bad happens.  In
>   the well-known-address case, none of that is likely to work well.

Then, autoconfigured case, where hosts blindly believe anything
configured even if something bad happens, is not "normal".

Or, if one insists that a host can be autoconfigured with multiple
sets of resolvers, a host can be preconfigured with multiple sets
of anycast addresses.

> There may have been other issues, but those are the ones I remember.

So far, it is a summary of the archives and is not necessarily
your opinion, I presume.

> Summarizing: I think this approach is a step towards the smart

OK, you think, now.

> network/dumb host model beloved by telcos, and is a step away from the
> smart host/dumb network model that's traditional for Internet
> applications (this is, of course, an oversimplification, the truth is
> and always has been more complicated, but it's close enough for this
> summary).

If a set of global addresses are tied to a global servers, yes,
which is the case of current root servers.

However, anycast allows for local control of root servers and
default recursive servers, even if addresses of them have
a global scope.

So, just say, anycast.

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