[Opensim-dev] DNS lookup and caching

[Justin Clark-Casey]

AFAIK, this is because the viewer will not handle FQDN for at least region UDP.  This is most noticeable in the 
TeleportFinishEvent message (see OpenSim/Region/ClientStack/Linden/Caps/EventQueue/EventQueueHelper.cs) where this is 
only a SimIP slot for an IP address, not an FQDN.

I was sufficiently curious to look at why the viewer about message then displays the FQDN of the simulator (e.g. 
sim10088.agni.lindenlab.com).  On inspecting indra/newview/llfloaterabout.cpp in the viewer code it's actually doing a 
reverse lookup from the stored IP address.

One possible solution I've assessed in the past is to have OpenSimulator store different IP addresses that are served 
depending on where the viewer request originated.  Viewers coming from the LAN could be served a LAN IP for the 
simulator and viewers from the WAN a WAN IP.  This would avoid the need for 'loopback' routers.  However, the amount of 
work is not trivial (I think 6-8 weeks for someone who knows the code).

On 17/12/14 16:06, Michael Heilmann wrote:
> OpenSim Devs
>
> In the region configs, if you use a hostname instead of an IP address, Opensimulator will resolve it to an IP address
> immediately, passing the IP address to the client instead of the hostname. Looking in the code, I found a comment about
> xml-rpc and mono dns caching, but little else. Looking online, mono appears to cache DNS names for too long, and
> changing the DNS cache refresh rate is not yet implemented -- but I don't understand why resolving once and using the IP
> address instead would solve that.
>
> The MOSES Opensimulator Grid has over 100 regions on 10 hosts running on a local LAN with internet connecting clients.
> Our enterprise firewall does not allow network hairpinning (servers refer to themselves or other servers using external
> IP addresses). We have worked around this by adding a VLAN, where servers can address eachother directly using their
> external ip addresses.  This has mostly worked, but hosting an internal nameserver would be much more desirable.  We are
> also forced to rely on the IT guys in charge of the firewall and the switch to change anything, and that is less
> reliable than we want.  An internal nameserver we can do ourselves.
>
> Can anyone explain the xml-rpc / mono dns caching problem that was fixed by resolving the hostname and using the IP
> instead?  Is there a persisting reason that hostname functionality has not been restored?  Thanks
>


-- 
Justin Clark-Casey (justincc)
OSVW Consulting
http://justincc.org
http://twitter.com/justincc