endpoint discovery from reverse DNS [Re: other comments on draft-nielsen-v6ops-3GPP-zeroconf-goals-00. txt

[Pekka Savola <pekkas@netcore.fi>]

These can certainly be argued many ways, and hopefully these issues 
can be captured in a revision of palet-tun-auto-disc..

On Fri, 5 Nov 2004, Alain Durand wrote:
> > As to the attributes of the reverse lookup schemes, one might say a few 
> > good / bad sides, like:
> >   - bad side is that requires a lot of records
>
>   not an issue as they can be generated with script.

Still, doing so either requires that script be invented and 
(re-)written by every DNS admin, or be distributed with DNS servers.
The script is probably very trivial, yes, but this is an ease-of-use 
factor.

If we want to make it extremely simple to set up these services this 
could be a small minus.

> >   - increases the number of required lookups
>
> Not necessarily. Think CNAME and additional section.

CNAMEs in reverse tree?  Granted.  Hopefully no DNS servers would 
break with such unanticipated usage.

> >   - on the other side, allows more flexible, IP-specific configuration
> >
> > Also, two particular more generic issues, AFAIR, which could be discussed a 
> > bit more might be:
> >
> >   - the "granularity" of the discovery process, i.e., how precisely and 
> > easily should you be able to modify the results of the lookup, e.g., tune 
> > that hosts A..B within a single administrative domain should discover X, 
> > hosts B..C should discover Y, etc. (for example, when using DNS, one way to 
> > achieve this would be split-faced DNS, or looking up stuff from the 
> > reverses like Alain proposes).
>
> In practice, I think this is an important operational issue.

Yes, it could be; depends a lot on how the network has been set up, 
who are in charge of the deployment of the tunnel endpoint (routing 
people, DNS people, or ...)

> >   - the manageability domain of the host.  It can be argued that IP 
> > addresses are often more "local" than host names.  A search path could 
> > include even all of the enterprise, all over the world, while customizing 
> > the lookup results (above) based on the IP address might go closer to the 
> > administrative domains.
>
> Search path are just plain wrong. As I explained several times, 
> internally at Sun, we have domains that span the planet and many 
> hosts are configured with several domains in their search path.

I don't see anything fundamentally *wrong* with the search path usage. 
Yes, under certain set-ups, it is difficult to discover *really* the 
closest relay just by using the DNS, but that's where routing can 
help.  Multiple searchpaths provide simple fallbacks as well.

> > It could also be argued that this may not be all that severe a problem 
> > here, if DNS is combined with anycast (provided that split DNS is not 
> > used).  Even if node X gets the same IP address everywhere by looking up 
> > x_srv.example.com, x_srv.example.com can be anycasted, set up everywhere 
> > using the same IP address.
>
> That makes the asumption that we know how to limit the propagation 
> of anycast routes within large domains. This is certainly doable, 
> but the associated complexity is large.

This seems simple routing basics.  Actually, you probably even don't 
need to propagate any host routes across different areas of a large 
domain.  Everyone just uses the same address to configure the 
topo/geographically distributed tunnel boxes, and it will go towards 
the closest one, either through a host route, or following the default 
route.

(Truth in advertising,) I see only a couple of minor problems with 
this:
 - if the number of boxes grows huge, beyond e.g. half a dozen, a 
large number of identically numbered boxes might get difficult, 
debugging-wise.  But as this is just a transition mechanism, it should 
be OK..
 - if the enterprise is divided to multiple autonomous systems or 
similar routing constructs, and you'd wish to deploy some boxes in 
those, and some out of them, the ingress filtering between the borders 
of those routing domains might get a bit complicated (might need to 
add one ACL line as an exception), depending on which IP address pool 
the address was taken from.

--
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings