We have a bunch of hostnames in wikimedia.org that are similar to: text-lb.eqiad.wikimedia.org. These have never been meant for user requests in URIs, and with our HTTPS redirects and certificates they can't legitimately serve requests anyways. They serve two basic purposes:
- They're the matching forward-DNS for reverse lookups of our real service IPs, so that DNS can tell you which datacenter a service IP maps to.
- When trying to debug or test things that are datacenter-specific, these hostnames are useful in scenarios like curl -k -v -H 'Host: en.wikipedia.org' https://text-lb.esams.wikimedia.org/. This lets one bypass geographic routing/failover and test on a specific DC. The -k there lets curl ignore that the certificate is invalid for the URI's hostname.
They're still kind of "ugly" though, in that they are hostnames which exist in our domains, in our authdns, there are HTTP[S] listeners reachable at the IPs of those hostnames, and they're not legal for our certificates. It would be better to replace them all with names like text-lb-eqiad.wikimedia.org. Then we wouldn't need -k, and we wouldn't need a little asterisk-explanation every time we say that everything in all of our domains are legitimately HTTPS/redirect/preload -compatible.
We'll probably have to add the new names first, fix up reverse DNS to point at the new names, then go through a slow process of fixing documentation/debugging links here there and everywhere, and wait a while before removing the old ones to reduce confusion.