4 ms·
I did the same, but used https://error.invalid/ https://error.invalid/, as that URL is guaranteed to never resolve.
by kuschku 9y ago
I did the same, but used https://error.invalid/ https://error.invalid/, as that URL is guaranteed to never resolve.
- icebraining 9y agoCurious; I didn't know about that TLD: https://en.wikipedia.org/wiki/.invalid https://en.wikipedia.org/wiki/.invalid
- jwilk 9y agoUnfortunately, it is not. https://tools.ietf.org/html/rfc6761#section-6.4 https://tools.ietf.org/html/rfc6761#section-6.4 > Name resolution APIs and libraries SHOULD recognize "invalid" names as special and SHOULD always return immediate negative responses. Name resolution APIs SHOULD NOT send queries for "invalid" names to their configured caching DNS server(s). It's only SHOULD, not MUST. And in fact, the glibc resolver (and I bet also other major implementations) does send such queries to the DNS server.
- kuschku 9y ago> And in fact, the glibc resolver (and I bet also other major implementations) does send such queries to the DNS server. Using the glibc resolver as baseline is a bad idea, it’s broken beyond hope. Try resolving http://-emmawatson.tumblr.com/ http://-emmawatson.tumblr.com/, which is a valid URL under newer standards, and works on all other systems. The Glibc authors refuse to merge patches fixing this, because they disagree with the standard.