Hello!
Your process is pretty much textbook. I always recommend adding the domain into the site settings before updating the DNS. And as for the 'www' thing - this is really up to you, as to whether you want your site at 'www.example.com' or just 'example.com'.
As you note, there will be a delay between you updating the DNS settings and the "Wrong IP Address" message disappearing, due to cache timeouts.
While the domain is in this state, Voice won't automatically redirect visitors to the domain, but it will still show your site (instead of the main e-voice site) if the domain is used.
Once it spots that the DNS is correct, then anyone visiting your site on the e-voice domain will be automatically redirected to the preferred custom domain. It will also soon after that automatically create an SSL certificate, and once installed it will default to using https always.
Thanks
Joe
Hi Joe, thanks for your reply.
My impression was that DNS resolvers should respect the TTL (time to live) value set on the record in question, and refuse to issue a cached answer once the time of their original query had expired. The TTL on the old records that I was replacing was 2 minutes, and the TTL on my new records was 10 minutes. That meant I thought there was likely to be a misconfiguration somewhere when it took 15 - 20 hours for Voice's IP check to pass.
The main issue this caused me in practice is that the old website my group switched away from onto Voice had HSTS set up - the security setting that means visitors are given a scary browser warning if they are directed to a non-encrypted website on the same domain.
It goes a bit against general web security best practices, but if I was carrying out a DNS switcheroo from a non-Voice site onto a Voice one again, I would probably disable disable HSTS or even HTTPS entirely on the original site if I had access to it.
The reason I say that is that having HSTS enabled put me in an awkward situation where reverting the site to the old record would prevent Voice ever being able to validate and issue the SSL cert, but keeping the domain pointed to Voice's servers meant any visitors would hit a scary browser warning which lots of browsers don't let you bypass. I've had to debug quite a few certificate problems in my day and so could make the assumption that what you described was what was going on when from browser security warning (the Voice webserver configuration is using my new domain but the SSL-issuing part isn't caught up yet), but I think this situation could be quite confusing to users without a technical background.
Yeah HSTS is a bit of a pain here for visitors, as yes browsers will insist on having https - and as you say, Voice can't really try to get a certificate until it knows that the DNS is correct. Well I suppose in theory it could, but if we did lots of letsencrypt requests that failed we would probably get blocked once the DNS started working!
The Voice servers are using the standard DNS resolver provided by our hosting company (UpCloud), I'm not aware that it has longer timeouts than any other!
Note also that Voice doesn't constantly check - so you would find you get a faster switch if you click the Recheck button periodically. So, update DNS, wait 10 minutes, Recheck, repeat until it says OK!
There would still be a short delay before the SSL cert is created, but it should be a lot les than 15-20 hours!
Another option for a seamless switch would be to use a service like CloudFlare for the SSL provision on the old site, then switch this over to the Voice site once it's ready. Configure the custom domain in the normal way the point CloudFlare to the Voice IP address. This is a bit less tested, but it does work, and in theory would have zero downtime, as you aren't waiting for Voice to create the certificate.
Thanks
Joe