Re: [PATCH v2] http: add custom hostname to IP address resolutions

From: Junio C Hamano <gitster@pobox.com>
Date: May 12, 2022, 16:22 UTC
Message-ID: <xmqqzgjmg1q5.fsf@gitster.g>
In-Reply-To: <CAP8UFD3UvjJzEQApiCKSknDWaTjbEMKkr17j1QN-8gwz7eWV3Q@mail.gmail.com>

Christian Couder <christian.couder@gmail.com> writes:

Show 8 quoted lines

> "Perhaps invent a totally bogus domain name, map that to
> localhost ::1, run a test server locally, and try to clone from that
> bogus domain?"
>
> (See: https://lore.kernel.org/git/xmqqfslrycvp.fsf@gitster.g/)
>
> I think "a totally bogus domain name" refers to something other than
> "example.com".

I meant a domain that should not be used for purposes other than being examples in the real world, including "example.com".

But RFC6761, which is an update to RFC2606, describes a set of properties that make .invalid nice domain to use, including:

 1.  Users are free to use "invalid" names as they would any other
     domain names.  Users MAY assume that queries for "invalid"
     names will always return NXDOMAIN responses.

 3.  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).
       
Another possibility is ".test" but it is more for testing DNS, not
application, i.e.

 1.  Users are free to use these test names as they would any other
     domain names.  However, since there is no central authority
     responsible for use of test names, users SHOULD be aware that
     these names are likely to yield different results on different
     networks.

 3.  Name resolution APIs and libraries SHOULD NOT recognize test
     names as special and SHOULD NOT treat them differently.  Name
     resolution APIs SHOULD send queries for test names to their
     configured caching DNS server(s).

so for a code like what we are discussing, which would not want the names to be shown to DNS and yield any IP address, ".test" makes a poorer "bogus domain name" than ".invalid", I think.

By the way, we seem to have references to .xz top-level domain, which appeared only in earlier drafts of what became RFC2606 (which was updated by RFC6761) in both documentation pages and tests. At some point we may want to update the former to ".example" and the latter to ".invalid" as a clean-up.

> Also "example.com" does seem to resolve to an IP address and even has
> an HTTP(S) server on it, while I think the purpose of the test would
> be to check that there is not even a valid DNS resolution when the new
> option is not used.

Yup, that makes ".invalid" a better candidate, I think.

Thanks.