> They also haven't correctly signed off the e-mail with --. No matter, this is hardly the first case of a company that can't correctly send e-mail these days. Note this is meant to be hyphen, hyphen, space, but I can't figure out how to get Markdown to not eat that last space.
I've been looking for a while, and I can't find a single plaintext email formatting guide that specifies exactly how to format a signature. Even RFC1855 doesn't cover this topic. How is anyone supposed to find this information? Anyone who cares so precisely about plaintext email formatting should publish a style guide, because obviously this information has been lost to time. No wonder nobody knows how to send an email, no one is interested in telling anyone how to.
> Also, DNS propagation is a myth.
Since when? Is this another hyper-specific nitpick? Ignoring TTLs is still a thing, and accidentally burning yourself by setting too high of a TTL is still a thing.
Ah, that explains it. We're supposed to remember conventions from the Usenet days. I am sad to report that Usenet users are in their 50s and 60s now, so someone will need to pass the torch or this information will be lost to time!
Snarkiness aside, I genuinely appreciate that email formatting was documented somewhere, even if it turns out that signature rules were just a convention and not a MUST in that RFC2646 document (as I would have expected given how forcefully people say it is the correct way)
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.
> 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:
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.
First time, eh? I remeber namecheap had problems 10 years ago when they upgraded interface and something was wrong with dns srv records. So i had to move out to gandi at time
I always manage my dns via own servers(currently using Powerdns).
these webuis always miss recordtypes or try to parse them before giving it to tge dns servers.
Not really. You kinda come off as a twatwaffle in the way you interact with front line support folks who are unlikely to even know what an RFC is, let alone have read one.
Who the hell uses their registrar as their primary name server anyway?
I was working on a CAA implementation and wanted to use one of my domains (at Namecheap) to test. This was around 5 years ago. I had the same frustrating experience with support. I understand front line support personelle might not know what the heck an RFC is, but you'd think this would be a case when escalating to the next level would be warranted. I felt like they weren't even reading half of my message. I switched to different nameservers, and that worked fine in my case. I did eventually move over to Porkbun, but not for that reason.
Okay, this is a nitpick, but:
> They also haven't correctly signed off the e-mail with --. No matter, this is hardly the first case of a company that can't correctly send e-mail these days. Note this is meant to be hyphen, hyphen, space, but I can't figure out how to get Markdown to not eat that last space.
I've been looking for a while, and I can't find a single plaintext email formatting guide that specifies exactly how to format a signature. Even RFC1855 doesn't cover this topic. How is anyone supposed to find this information? Anyone who cares so precisely about plaintext email formatting should publish a style guide, because obviously this information has been lost to time. No wonder nobody knows how to send an email, no one is interested in telling anyone how to.
> Also, DNS propagation is a myth.
Since when? Is this another hyper-specific nitpick? Ignoring TTLs is still a thing, and accidentally burning yourself by setting too high of a TTL is still a thing.
Some discussion here:
https://comp.mail.misc.narkive.com/TSEnT0kU/rfc-compliant-si...
Ah, that explains it. We're supposed to remember conventions from the Usenet days. I am sad to report that Usenet users are in their 50s and 60s now, so someone will need to pass the torch or this information will be lost to time!
Snarkiness aside, I genuinely appreciate that email formatting was documented somewhere, even if it turns out that signature rules were just a convention and not a MUST in that RFC2646 document (as I would have expected given how forcefully people say it is the correct way)
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.
First time, eh? I remeber namecheap had problems 10 years ago when they upgraded interface and something was wrong with dns srv records. So i had to move out to gandi at time
I always manage my dns via own servers(currently using Powerdns). these webuis always miss recordtypes or try to parse them before giving it to tge dns servers.
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.
Not really. You kinda come off as a twatwaffle in the way you interact with front line support folks who are unlikely to even know what an RFC is, let alone have read one.
Who the hell uses their registrar as their primary name server anyway?
I was working on a CAA implementation and wanted to use one of my domains (at Namecheap) to test. This was around 5 years ago. I had the same frustrating experience with support. I understand front line support personelle might not know what the heck an RFC is, but you'd think this would be a case when escalating to the next level would be warranted. I felt like they weren't even reading half of my message. I switched to different nameservers, and that worked fine in my case. I did eventually move over to Porkbun, but not for that reason.
Plugging Infomaniak, the rare large registrar that has competent customer support.