Hi Voice users,
I have just recently updated DNS for the site I've been helping a group set up on Voice to use a custom domain, and I had some questions out of curiosity.
What I did for the cutover wa:
1. Set the new domain name in the Voice '/admin/site-domain/' page, which shows "Wrong IP Address - check domain settings" as expected
2. Switch the DNS back to use GoDaddy (the registrar) from a thirdparty DNS service
3. Set the A record at the root of the domain to the Voice static IP address, adding a 600 second TTL for it (10 minutes)
4. Wait...
5. Realise the instructions mention specifically adding a record for `www` instead of or as well as the root of the domain, add one for as well
6. Wait...
Currently, querying my own default DNS with dig or querying specific nameservers like @1.1.1.1 and @8.8.8.8 report the Voice IP address for both the domain root and `www`, but the checks in Voice still say "Wrong IP Address - check domain settings".
I imagine this will sort itself out with time, but I am wondering if:
* Voice is specifically checking for A records for "www" or if an A record at the domain root is sufficient suffice
* It's better to set the new domain name within the site admin settings *before* creating the new record or after - I wonder if setting it in advance caused it to cache the old result with an abnormally long TTL
It does not really matter much for us, there are very few visitors for the website so a bit of downtime doesn't do any harm... but I am a little curious about the details of this DNS configuration and whether is a specific order of operations that would make the changeover smoother.
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