Nomad built-in DNS TTL and cache invalidation after allocation reschedule

Nomad provides an optional built-in DNS server for service and allocation name resolution under the nomad domain, with records derived from the catalog and allocation state.

API and inter-node RPC can be secured with TLS where server certificates must contain SANs matching advertised addresses and clients validate against a configured CA. DNS queries are served directly by Nomad servers and do not use the system resolver.

Configuration and defaults for DNS and TLS are component-specific and version-sensitive across major releases. An unresolved design consideration is how DNS TTL and cache invalidation interact with allocation rescheduling, and whether stale records can persist for clients until TTL expiry.

What TTL values are used for service and allocation records in the built-in DNS server, and can they be configured per service?

How does Nomad signal record removal or IP change to clients after an allocation is rescheduled, given DNS is served directly by servers?

Are there version-specific defaults for TLS verification and CA handling that affect DNS-based service discovery when TLS is enabled for the API?