91–100 of 105 posts
I believe auth.md is also a recent example that uses .well-known
Earlier quoted context omitted.
- registrars control NS records, however these can be changed - NS records control other records - registrars can also use their own nameservers to manage your DNS
Yeah, so basically it’s fine as long as your registrar lets you set your own NS. Are there ones where you can’t do that?
No, in fact I don't. But this post wouldn't be of any help anyway. It feels like it's about nothing, there is no substance, just stating some obvious facts. Without examples that lead to some real recommendations, this whole expertise claimed by the author is of no use.
And if you read that and still feel confident that you want a well known url, he links you to the registration process.
Earlier quoted context omitted.
Also, DNS-PERSIST-01 seems to be coming soon for Let's Encrypt, which should allow even people that can't easily dynamically update their DNS records to get wildcard certs. I assume this might become more widely used than HTTP-01 challenges.
I wish someone would write a blog post about the difference between DNS registrars and DNS hosts, because I've seen people assume they need to use a registrar that has an API in order to change their DNS records programmatically. I used to assume that too.
"This Web site requires a more modern browser to operate securely; please upgrade your browser." Alternative, no SNI required https://web.archive.org/web/20260619061625if_/https://mnot.n...
It's great
Earlier quoted context omitted.
The better pattern is to use an underscore prefix like _discord-verification.domain.com If your site allows user-created subdomains it shouldn't allow leading underscore. This is reserved somehow.
Why would you want a new prefix over using record types as they were meant to be used?
1. Practically, the process for creating a new DNS record type is bureaucratic and slow.
2. New record types have a limited number, but names are unlimited as long as they are unique.
3. If the data you’re storing is perfectly compatible with an existing record type, like TXT, it seems silly to overload semantics into a new, but otherwise identical, record type. You can compare record types to variable types in a programming language. I.e. instead of having
name_t x = "foo"; /* C */
x: Name = "foo" # Python
x IN NAME "foo" ; DNS
char *name = "foo"; /* C */
name: str = "foo" # Python
_name IN TXT "foo" ; DNS
Earlier quoted context omitted.
Having all those TXT records at the domain apex like that makes the TXT query reply huge , which affects, for instance, every mail recipient who merely wants to check the SPF record. This is a bad pattern to follow.
The better pattern is to use an underscore prefix like _discord-verification.domain.com If your site allows user-created subdomains it shouldn't allow leading underscore. This is reserved somehow.
Earlier quoted context omitted.
The point of the post was that you need to add robots.txt (or similar) because it's a thing, and also tell us where they are.
> add a robots.txt Which bots will then ignore.
Earlier quoted context omitted.
The better pattern is to use an underscore prefix like _discord-verification.domain.com If your site allows user-created subdomains it shouldn't allow leading underscore. This is reserved somehow.
Why would you want a new prefix over using record types as they were meant to be used?