the well-known address approach

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

At Wed, 6 Aug 2003 14:11:01 +0859, Masataka Ohta wrote:
> 
> Still, I'm less demanding than you never expect people
> have wide knowledge of archive content of other WGs.

That's a fair criticism.  I've been reluctant to attempt to summarize
the IPv6 WG's discussion of the well-known-address proposal, in part
because I was hardly a neutral party in that debate and thus would
prefer to let others form their own conclusions.  However, since
you're correct that it's unfair to say that one has to understand that
whole debate to participate in this WG's discussion of requirements,
I'll try to summarize what I remember, with the understanding that
this is just my view.  For those who have the interest and patience to
dig through the IPv6 WG archives, the relevant stuff probably starts
in April of 2002 and runs (on and off) through October 2002.

Ignoring irrelevant issues (eg, the IPv6 Site-Local swamp), I still
have concerns with the well-known address approach:

- 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.)

- 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, so there are issues with how updates get into the
  routing system, with how (and whether) the routing system reflects
  recursive name servers that die or move, and so forth.

- 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.

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

Summarizing: I think this approach is a step towards the smart
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).  So this approach might well make sense in certain kinds of
networks, but not in others, and thus it's not obvious to me that this
is the right general solution.

Hope this helps.  Folks who disagree are of course welcome to respond,
with the understanding that the goal here is still the quest to
understand the requirements for DNS discovery here in the DNSOP WG,
not recounting the history of a particular draft.
#----------------------------------------------------------------------
# To unsubscribe, send a message to <dnsop-request@cafax.se>.