I’m familiar with the idea that the time associated with a DNS entry (ttl which is 1800 by default for Enough) means that a modification to this entry is likely to take that number of seconds and often more to reach the DNS resolver that I’m using. I’ve also heard that shortening this delay too much is considered bad practice and that DNS resolvers are likely to not honor ttl that are under a given value anway.
This is all and well in general, but in the context of running tests for the Enough infrastructure it is inconvenient to not know exactly how long it will take for a DNS change to be visible from Letsencrypt. For instance, when testing the Mattermost playbook, Letsencrypt is asked for a staging certificate (because one can only request a limited number of real certificates per day) and the tests wait for the Mattermost home page to come up using https.
@fpoulain came up with a clever idea to workaround the problem: whenever a test is launched, a new subdomain under tests.enough.community is created using the nsupdate ansible module and Mattermost will be available at a URL that looks like chat.ge2dqnbwgi3tanrr.test.enough.community.
This trick was implemented years ago and there is guarantee that the subdomain propagates to Letsencrypt with no delay. But it is very rare (in my experience about 1/100) that the test fails because Letsencrypt is unable to resolve chat.ge2dqnbwgi3tanrr.test.enough.community.
I would like to understand how and why this works. For no particular reason other than curiosity