Re: [PATCH v2] http: add custom hostname to IP address resolutions
- From
Christian Couder <christian.couder@gmail.com>
- Date
- May 12, 2022, 18:57 UTC
- Message-ID
- <CAP8UFD2tk7ti_G0Ao_-u0g9+hm-x4gnuSjEPHbnKPan6S741Ug@mail.gmail.com>
- In-Reply-To
- <xmqqzgjmg1q5.fsf@gitster.g>
On Thu, May 12, 2022 at 6:22 PM Junio C Hamano <gitster@pobox.com> wrote:
Show 14 quoted lines
> > 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.
Show 11 quoted lines
> 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).
Show 10 quoted lines
> 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.
Show 5 quoted lines
> 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.
Show 6 quoted lines
> > 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.