Static IP Rotation

[emohandesi]

Is there an existing issue that is already proposing this?

• I have searched the existing issues

Application

Outline Manager

What are you trying to do? What is your use case?

Rotate the IP of the VPN server so that the server's IP detection becomes harder for censorship authorities.
This issue has been suggested in Jigsaw-Code/outline-apps#1862 and a bunch of other issues, but none of them discuss the details of doing it. Here, we have explained the details of its implementation.

Is your feature request related to a problem? Please describe it.

No response

Describe the solution you'd like.

Summary

The server's IP rotates among a bunch of predefined IPs. Three methods have been suggested to achieve this goal as described below.

1. Domain Registrar's IP Update
   In this method, the server is identified using a domain such as sub1.mydomain.com. A bunch of predetermined IPs along with a time period are given to the install_server.sh script so that a parallel process can be run on the VPN server that changes which IP the domain points to in a round robin fashion.
2. Dynamic key storage update
   The IP of the server is updated in the dynamic key. The information to access the dynamic key and update its information is added to the install_server.sh script so that a parallel process can be run on the VPN server that changes the server IP address inside the dynamic access key.
3. Create an authoritative DNS Resolver
   An authoritative DNS resolver server is installed on the VPN server that resolves sub1.mydomain.com to a bunch of predetermined IPs based on the time period it is called. The domain name has to be given to the install_server.sh script when the VPN server is being created.

Conditions

All Methods

• All the IPs should belong to the same server. If different servers are used, then a new mechanism is needed to make sure the keys are copied from the main server to the others.

Domain Registrar's IP Update

• An API is needed from the cloud provider that manages the domain. The API is different for different cloud providers. This feature can be written for Cloudflare and then extended to cover other cloud providers such as AWS, Google, etc. There might also be a way to generalize the way the domain is handled so that just the API is needed, and the script would work on all cloud providers.

Dynamic key storage update

• The API for updating the access key is needed.

Authoritative DNS Resolver

• The domain registrar needs to be updated and point to the IP of the server for the authoritative DNS resolver of the domain.

Details

Domain Registrar's IP Update

• The following parameters are needed for a Cloudflare domain in order to point it to another IP:

Paramers: {ZONE_ID, RECORD_ID, API_TOKEN, NEW_IP_ADDRESS}

curl -X PUT "https://api.cloudflare.com/client/v4/zones/<ZONE_ID>/dns_records/<RECORD_ID>" \
  -H "Authorization: Bearer <API_TOKEN>" \
  -H "Content-Type: application/json" \
  --data '{
    "type": "A",
    "name": "sub1.mydomain.com",
    "content": "NEW_IP_ADDRESS",
    "ttl": 1,
    "proxied": false
  }'

The above curl command needs to be run every period to point to another IP in the list of IPs in a round-robin fashion.

• The Cloudflare parameters, rotation period, and the list of IPs can be given as input parameters to the install_server.sh script. The IPs can be separated by semicolons.

  --hostname             The domain name to be used to access the management API and access keys (this is already implemented)
  --ip-rotation-period   The period to point the domain name
  --ips                  The list of IPs to rotate among them, separated by semicolons
  --cloudflare-zone-id   The zone ID used when doing IP rotation in Cloudflare
  --cloudflare-record-id The record ID used when doing IP rotation in Cloudflare
  --cloudflare-api-token The API Token used when doing IP rotation in Cloudflare

Cons

1. All the information mentioned above, such as zone ID, record ID, and API token, needs to be collected from Cloudflare and be given to the install script.
2. The parameters for setting the domain for different domain registrars are different and are not necessarily the same, and therefore, need to be implemented separately.

Dynamic key storage update

Cons

1. The information for updating different storage providers such AWS or Google Docs is different and therefore, different code needs to be written for different providers.

Authoritative DNS Resolver

Cons

1. The user needs to manually log in to the domain registrar and update the name servers to point to the authoritative resolver's IP.

Additional Work

• Change the Outline Manager app so that IP rotation can be added to it even after the server is created.

Describe alternatives you've considered

The IP rotation can be done manually, but it is not a good replacement for this.

[fortuna]

I think a better approach will be to have the original domain delegate a subdomain to an authoritative resolver that runs in the Outline server. That way you only touch your DNS provider once to delegate the domain, and you can do all the updates in the Outline server. This avoids the issue of each DNS provider having a different API.

[fortuna]

For authoritative servers, some options include bind9 or PowerDNS. For example:
https://www.digitalocean.com/community/tutorials/how-to-configure-bind-as-a-private-network-dns-server-on-ubuntu-20-04

This Go library allows you to implement your own server: https://pkg.go.dev/github.com/miekg/dns#ServeMux

[emohandesi]

For authoritative servers, some options include bind9 or PowerDNS. For example: https://www.digitalocean.com/community/tutorials/how-to-configure-bind-as-a-private-network-dns-server-on-ubuntu-20-04

This Go library allows you to implement your own server: https://pkg.go.dev/github.com/miekg/dns#ServeMux

Thank you so much for adding this information. I updated this issue and suggested the 3 options that we have, along with the cons of each method.