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

[Christian Couder <christian.couder@gmail.com>]

On Thu, May 12, 2022 at 6:22 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> Christian Couder <christian.couder@gmail.com> writes:
>
> > "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".

Ok, thanks for the clarification and for copying the relevant RFC
information below.

> 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).

I wonder if libcurl considers itself as a name resolution library or
not. It has a DNS cache, so maybe in some ways it is. Also however it
considers itself now, it could perhaps change in the future. Even if
the current developers are against such a change, a new RFC might be
more precise and specify something for libraries like libcurl which
could make it change.

So I am not so sure that using "invalid" is our best bet.

> Another possibility is ".test" but it is more for testing DNS, not
> application, i.e.

In a way we are testing DNS, as we are actually testing libcurl's DNS
caching and its CURLOPT_RESOLVE option (even if we also test that Git
is correctly passing the config option to libcurl at the same time).

>  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 with this we can at least expect that the way libcurl considers
itself will have no impact on our tests.

> 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.

I would think that there are risks in both cases. I am Ok with using
any of the following in the test:

BOGUS_HOST=gitbogusexamplehost.invalid # or
BOGUS_HOST=gitbogusexamplehost.test

The test passes for me either way.

> 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.

Yeah, good idea.

> > 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.

Ok, I will use "gitbogusexamplehost.invalid" in the next iteration then.