DNS Best Practices

Overview

This article covers some best practices on configuring a DNS record (e.g. sftp.thorntech.com) that your SFTP clients can use to connect to your service.

Single Instance Deployment

This section covers single VM deployments of SFTP Gateway. For HA, skip to the next section.

Static IP

In the majority of SFTP deployments, SFTP clients connect to the public IP of the VM. Although typical, it's not idea.

If your clients are connecting via IP address, you need to first verify that your VM has a static IP. Otherwise, you run the risk of losing this IP address if the VM is stopped. Fortunately, the IP defaults to static in most deployments.

Note: IP addresses in Azure can be scoped to a region or availability zone, based on the Availability Options setting chosen when the VM was deployed. It's important to always deploy using No infrastructure redundancy required.

Host A record

Whenever possible, you should configure a DNS record. Typically, you would create a Host A record, which points a hostname to an IP address.

For example, you would create the following Host A record:

sftp.example.com => 1.2.3.4

The DNS record would be configured in your DNS provider, which could be Azure, or sometimes a 3rd party provider like GoDaddy or Network Solutions.

If your existing SFTP users are connecting via IP address, consider gradually migrating them over to using the DNS hostname. This will give you more flexibility down the road.

HA Deployment

An HA deployment has more moving pieces than a standalone VM. Here is a diagram showing the Load Balancer along with two VMs in the Scale Set:

Load Balancer IP Address

Typically, you would connect to the SFTP service via the static IP address on the Load Balancer. The Load Balancer will then direct your traffic to either of the VMs in the Scale Set.

You should create a DNS Host A record that points to the Load Balancer's Static IP address. For example:

sftp.example.com => 1.2.3.4

The DNS record would be configured in your DNS provider, which could be Azure, or sometimes a 3rd party provider like GoDaddy or Network Solutions.

Ephemeral IP address on the VMs

Depending on the configuration of the HA ARM template, you may have an ephemeral public IP address on each VM. These are there to help you test your first HA deployment so you can easily isolate troubleshooting to a specific VM.

You should avoid pointing any DNS records to these ephemeral public IPs, since they will change as new VMs are cycled through the Scale Set.

Ideally, you should update your configuration to remove the ephemeral public IPs on the VMs. This will force everyone to use the Load Balancer.

Time to Live (TTL)

If you plan to perform a DNS change, this will cause downtime and it should be done during a maintenance window.

In order to minimize downtime, you want to reduce the Time to Live (TTL) on any DNS records involved (i.e. the existing Host A record). Since DNS has to propagate throughout the internet, you want this change to spread as quickly as possible by reducing the TTL.

In practice, you would reduce the TTL to the lowest value allowed, and this would be performed 24 hours prior to the scheduled DNS cutover. This will allow the TTL value to propagate. When you perform the DNS cutover, your change should take effect more quickly.

Note: Remember to set your TTL values back to normal when finished. Otherwise, DNS servers will be polling your service more often than necessary.