4 ms·

Most parsing in web standards is. There doesn't exist a way to validate an email address since the official spec is quite complex and then email servers can jus

Most parsing in web standards is. There doesn't exist a way to validate an email address since the official spec is quite complex and then email servers can just ignore it and accept emails on addresses that shouldn't be valid. This often becomes a pain in the ass when a single piece of software is strict on the rules that everything else ignores. Officially subdomains can't have underscores in them but the browser and everything else will allow it just fine except when you try to get a certificate and lets encrypt tells you that you have an invalid domain.

onion2k 7y ago
I think that's correct, or at least helpful. The business of a browser is to get data from the internet regardless of what stupid domains people use. The browser shouldn't stop you visiting an invalid url if that url will return some data. The business of Let's Encrypt is to certify the security of a domain, which includes checking if the domain is valid. LE should stop you signing an invalid URL. That is also correct. The real culprit is the domain registrar and the DNS server software. Neither of those should be enabling invalid domains to be accessible.
- jorams 7y ago
  > The real culprit is the domain registrar and the DNS server software. Neither of those should be enabling invalid domains to be accessible. They already don't. DNS does not forbid underscores, and places hardly any restrictions on labels. Hostnames do forbid underscores, and that muddies the water quite a bit. While disallowing A-records on labels with undersores would make sense, a CNAME on a label with an underscore can point to a domain without one, and the one it points to may or may not have an A-record. It is really up to the client to decide that a domain name is invalid for their use case, but clients don't want to disallow something that appears to otherwise work fine. And so we end up in a situation where none of the specifications are truly followed.
JdeBP 7y ago
This has long been known as Gresham's Law trumping Postel's Principle. For example: * http://jdebp.uk./FGA/qmail-myths-dispelled.html#MythAboutBareLFs http://jdebp.uk./FGA/qmail-myths-dispelled.html#MythAboutBar...

onion2k 7y ago

I think that's correct, or at least helpful. The business of a browser is to get data from the internet regardless of what stupid domains people use. The browser shouldn't stop you visiting an invalid url if that url will return some data. The business of Let's Encrypt is to certify the security of a domain, which includes checking if the domain is valid. LE should stop you signing an invalid URL. That is also correct. The real culprit is the domain registrar and the DNS server software. Neither of those should be enabling invalid domains to be accessible.

jorams 7y ago
> The real culprit is the domain registrar and the DNS server software. Neither of those should be enabling invalid domains to be accessible. They already don't. DNS does not forbid underscores, and places hardly any restrictions on labels. Hostnames do forbid underscores, and that muddies the water quite a bit. While disallowing A-records on labels with undersores would make sense, a CNAME on a label with an underscore can point to a domain without one, and the one it points to may or may not have an A-record. It is really up to the client to decide that a domain name is invalid for their use case, but clients don't want to disallow something that appears to otherwise work fine. And so we end up in a situation where none of the specifications are truly followed.

JdeBP 7y ago

This has long been known as Gresham's Law trumping Postel's Principle. For example: * http://jdebp.uk./FGA/qmail-myths-dispelled.html#MythAboutBareLFs http://jdebp.uk./FGA/qmail-myths-dispelled.html#MythAboutBar...