matzf
commented
5 years ago Using a hostname directly for the Public/Remote address configuration of the BorderRouters is not supported -- this might not be what you meant anyway.
So just thinking out loud; If we'd use hostnames, we would have to have a process that continuously resolves the DNS hostname and somehow updates the topology files. My understanding of how dyndns etc. work, is that they have a daemon running on the clients host which makes e.g. http requests to the ddns-service which will trigger an update of the IP in the corresponding DNS record.
Since we already have a central service (the coordinator), we can just skip the DDNS-middleman; we could add a simple API to the coordinator which updates the UserAS's public IP to the source IP of the request. A little script that runs on the user's host could regularly make this request, re-download the topology if the IP has changed and restart scion.
Just a final question: is the reduced performance the only disadvantage you see in running over a VPN? How would this look if we could use wireguard instead of OpenVPN? Generally, I think that the advantage of using VPN over a DDNS approach, would be that IP changes are transparent to scionlab, and no routers need to be restarted.
Many home users have public IP addresses but those are dynamically changing (e.g. users connected over DSL or LTE). Those users could be supported by relying on a static hostname (such as one assigned through dyndns) instead of VPN, thereby avoiding performance degradation.