For what it's worth, I used to post to Usenet a lot in my teens, and I'm only 34 now :)

On the subject of signatures, slater's reply is a good starting point. It is not specified in a formal standard, but it is a widely accepted convention, and the only widely practiced convention for using signature blocks in e-mail -- when you configure e-mail signatures in any MUA that supports them, this is how they will append them.

See also https://en.wikipedia.org/wiki/Signature_block#Email_signatur... and the section immediately following.

> Since when? Is this another hyper-specific nitpick? Ignoring TTLs is still a thing

Implementations that choose to ignore the standard on this subject could hardly expect to have their behaviour be described as anything positive. It is a thing, and it causes a lot of frustration, and it's still entirely unrelated to the meaning of the word propagation; nor is it responsible for the negative outcomes most people would ascribe to this.

> and accidentally burning yourself by setting too high of a TTL is still a thing.

This is caching working as designed.

What people are actually talking about when they say "DNS propagation" is the unforseen impact of negative caching. For example, when you look up a record that does not exist, your caching recursor of choice will remember that it does not exist. The lifetime of this is determined by the final field (the "minimum TTL") in the SOA record of the closest parent.

For a concrete example, imagine you purchase the "totallyreal.org" domain name and immediately create an A and AAAA record at its apex, pointing to a webserver you already operate, ready to serve a website immediately. However, you enter its address into your web browser before the registrar has completed the registration. The MTTL field in the SOA record for "org." is 3600 (seconds). This means your recursor will remember that "totallyreal.org" does not exist for another hour. You will be unable to look it up for this amount of time, giving you the impression that domain registrations can take an hour or more to "propagate", when in reality they take maybe a minute after payment clears, if you're unlucky. However, anyone else in the world not using that recursor will be able to look it up immediately after it does actually exist, far before you can.

Another example would be creating a CAA record (as in this case), when you do not already have a CAA RRset at the name in question. You then immediately ask an unauthorised CA to issue you a certificate, before whatever artificially-induced delay has passed between your DNS host of choice's web admin panel or REST interface or whatever and the backend nameserver(s) that actually answer the queries has passed. The CA dutifully performs the CAA query, the DNS hosting provider has not actually inserted the records into their nameservers yet, and the CA gets no records in response. They will then of course be happy to issue a certificate for your domain even though you do not want them to.

You can avoid these situations by running a non-recursive query against the domain's chosen nameservers directly, waiting until you get the positive answer you're expecting before doing a lookup via a caching recursor, or anything else that additionally caches records like a web browser.

Some public recursor operators also provide a service to flush the cache for a given domain. For example, Google Public DNS provides this:

https://developers.google.com/speed/public-dns/cache

This can be helpful in a pinch. In the first scenario above, if you were using Google as your recursor (8.8.8.8, 8.8.4.4, 2001:4860:4860::8888, 2001:4860:4860::8844), this would let you resolve the domain you just bought but are now unable to. You wouldn't have to wait for the hour.

What Namecheap are saying in the e-mail with CAA record propagation is instead that if you were updating an RRset (rather than creating one where one did not already exist), then, due to the TTL on the existing RRset, you are correct that the new value would not be visible to everyone immediately, and you might be best served by waiting.

However, this has nothing to do with propagation, and is merely caching working as designed. You do not have to wait for it to propagate; as soon as it is inserted into the authoritative nameserver, anyone in the world can look up its current value, immediately. What they can't do (usually) is sidestep their recursor's cache, either for a record that did exist already and is still in the cache, or for a record that did not exist at the time it was looked up and is still in the negative cache. It's not that the recursor notices the TTL has expired after a while and proactively fetches a new value, nor do the authoritative nameservers reach out to any recursors and say "by the way, here's an updated value for ..."; there is no propagation either way when a user (or a user agent) is in the loop.

The only actual propagation is the insertion of the record into the set of authoritative nameservers, and this is, the overwhelmingly vast majority of the time, practically immediate. The highest I've ever seen on CloudFlare was about 4 seconds, and standing up this blog was completed before I could even confirm it with a dig command. Even IXFRs on top-level domains, which predate the year 2000, used to create new domain names, were able to accomplish this within about a dozen seconds. Advising people to wait several minutes or even hours for it is counterproductive.

Some TLD operators have seen the light in this regard; for example, the MTTLs for "net." and "com." are both 15 minutes. A far more reasonable value.

I would do that if I could (I have done that in the past for other domains, and I am doing that right now for a subdomain of the domain in question).

The domain itself is not mine; I only have enough access to maintain its records.

I've been wanting to make a blog for a while now. This incident is as good a source of material as any.

Using CAA Records with Namecheap