It certainly should be. Filtering user-registrable names that will end up in host names or URL paths is table stakes. You want to block names like www, admin, root, robots.txt, .well-known, _*, and so forth.
DNS allows any character you want, including underscores. Host names in URLs cannot contain underscores. Therefore any service that create subdomains for user would reject underscores, which is why they're considered de-facto reserved for special uses in DNS. I don't think the reserved nature is codified in any RFC.
It certainly should be. Filtering user-registrable names that will end up in host names or URL paths is table stakes. You want to block names like www, admin, root, robots.txt, .well-known, _*, and so forth.
DNS allows any character you want, including underscores. Host names in URLs cannot contain underscores. Therefore any service that create subdomains for user would reject underscores, which is why they're considered de-facto reserved for special uses in DNS. I don't think the reserved nature is codified in any RFC.
https://www.rfc-editor.org/info/rfc8552/
Testing [1] Works in Firefox, Helium and Curl but I do not have Chrome or Safari to test with.
[1] - https://_test.nochan.net/
This only works because it’s a wildcard certificate. Since 2019, TLS certificates must not be issued for names containing underscores <https://cabforum.org/2018/11/12/ballot-sc012-sunset-of-under...>.
1 reply →