Re: [mdnsext] mDNSext features/requirements rollup

[Andrew Sullivan <[e-mail]>]

On Thu, Feb 07, 2013 at 08:58:53AM -0500, RJ Atkinson wrote:
> Much later, on 6th February 2013, Andrew Sullivan wrote, in part:
> > 
> > It seems to me that, in Internet terms, we really have three
> > scopes:
> > 
> >     1.  my network;
> >     2.  my network_s_;
> >     3.  the Internet.
> 
> I'm not entirely clear on Andrew's terminology, but my guess
> is that by (1) he means this subnet/link and (2) the set of
> inter-connected subnets/links at my site/building/home/campus.

I was being deliberately vague partly because of the whole
do-what-I-mean flavour of this set of problems, but I think the
distinctions you're making are probably good enough
operationalizations for our purposes.

> The claim above is not obviously true for several reasons:
> 
> A) Split-horizon DNS deployments have been around since
>    the 1990s at least.  THese are widely deployed.  Few
>    problems have arisen in practice, as a percentage of
>    split-horizon deployments.  Yes, problems could arise,
>    for example if a human misconfigures something, but
>    it isn't inherent in a split-horizon DNS deployment.

Problems have in fact arisen.  The root DNS servers receive a large
amount of traffic for names that don't exist and that are clearly
leakage of split horizon queries and of local-scope queries (*.local)
that have escaped.  One of the reasons the SiteFinder idea caused so
much anguish was that, while wilcards in some other TLDs had worked
for some time, .com turned out to be special in that failed queries
were implicitly assumed to be inside .com (so local-use-only DNS names
worked just fine before SiteFinderDay, but suddenly all got resolved
inside .com on SiteFinderDay).  From the point of view of end users,
there are no problems; from the point of view of the Internet
infrasrtucture, there are plenty of problems.

> B) The current work here on (2) is extending mDNS rather than
>    putting a bunch of *.LOCAL data into the unicast DNS system
>    (which in many ways is a different system entirely, although
>    they have compatible namespaces).

Except that all the clients need to work as though the mDNS (".local")
names and the Internet DNS names are part of a single naming
continuum.  This fact is why .local names leak out to the Internet.
In the case of the current mDNS, at the very least it's possible to
identify (just from network topology) the border one shouldn't
traverse.  The same is not true in case (2): there's just no way to
infer the scope of the site of inter-connected links at "my site",
because we don't have a way to identify that.  (In some ways, we are
walking in sideways to the same problem people have experienced in the
DNS -- attempting to infer organizational boundaries from delegation
boundaries, or trying to infer "my domain" from the search path or
other such tricks used by standard resolver libraries.)

I've been musing over one possible strategy: to use the DNS to assert
some network boundaries.  But I haven't worked out the details of how
this might help.  Maybe a clue for mDNS responders?  That seems to
foil the whole zeroconf point of all this, though.

> I don't agree with the idea of eliminating .LOCAL or
> similar scoped domains or information advertised in those
> domains.  Its unrealistic to believe that a typical home
> deployment will use global-scope DNS naming for devices
> not intended to be accessible from outside the home.

Well, obviously we can't ditch this: it's widely deployed.  Also IMO
it's not realistic to expect local-scope names to work across network
boundaries.  So we're now arguing about whose scope gets to be called
"local" :)

Best,

A

-- 
Andrew Sullivan
[e-mail]