Usually when you create the VM, it gets its own DNS subdomain that looks like `my-new-vm-name.exe.xyz`. (I'm not affiliated with exe.dev, I just use their product). So I doubt there would be any cached requests for that particular subdomain before the VM is created.

▲

dspillett 5 hours ago | parent [-]

NXDOMAIN results and other errors have their own TTL value though, so if someone queries too early in the process you could be waiting a little while for their cache to check again. The value for this is set in the SOA record for your DNS zone.

For example, example.org/example.com seems to have TTLs set at 300s (5 minutes) for A records, but the negative caching value is 1800s (30 minutes). If your VM domain is set the same way, you could see a premature lookup causing issues for 30 minutes instead of just 5. Even the 5 minutes could be a pain if your VM spin-up process expects to be able to lookup via the name very early and will fall over if it can't.

▲

eigencoder 4 hours ago | parent [-]

I always don't know enough about DNS. This is great stuff.

If exe.dev is running their own DNS zone, then wouldn't they be setting the expiry value in the SOA record themselves? So they could set it to something short, and secondary servers are supposed to honor it, right?

	▲	dspillett an hour ago \| parent [-]
		> wouldn't they be setting the expiry value in the SOA record themselves? If they thought about it. But it is something that even people relatively experienced in DNS matters forget about until it bites them and they've spent ages diagnosing the initially odd looking problems caused.