From: Junio C Hamano <gitster@pobox.com>
To: Christian Couder <christian.couder@gmail.com>
Cc: "Carlo Marcelo Arenas Belón" <carenas@gmail.com>,
git <git@vger.kernel.org>,
"Christian Couder" <chriscool@tuxfamily.org>,
"Derrick Stolee" <derrickstolee@github.com>
Subject: Re: [PATCH v2] http: add custom hostname to IP address resolutions
Date: Thu, 12 May 2022 09:22:26 -0700 [thread overview]
Message-ID: <xmqqzgjmg1q5.fsf@gitster.g> (raw)
In-Reply-To: <CAP8UFD3UvjJzEQApiCKSknDWaTjbEMKkr17j1QN-8gwz7eWV3Q@mail.gmail.com> (Christian Couder's message of "Thu, 12 May 2022 10:52:59 +0200")
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".
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.
next prev parent reply other threads:[~2022-05-12 16:23 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-02 8:36 [PATCH] http: add custom hostname to IP address resolves Christian Couder
2022-05-02 19:04 ` Junio C Hamano
2022-05-04 10:07 ` Christian Couder
2022-05-04 14:34 ` Junio C Hamano
2022-05-05 10:48 ` Christian Couder
2022-05-05 11:16 ` Carlo Marcelo Arenas Belón
2022-05-09 15:40 ` Christian Couder
2022-05-04 10:46 ` [PATCH v2] http: add custom hostname to IP address resolutions Christian Couder
2022-05-05 11:21 ` Carlo Marcelo Arenas Belón
2022-05-12 8:52 ` Christian Couder
2022-05-12 16:22 ` Junio C Hamano [this message]
2022-05-12 18:57 ` Christian Couder
2022-05-09 15:38 ` [PATCH v3] " Christian Couder
2022-05-10 18:20 ` Carlo Arenas
2022-05-12 8:29 ` Christian Couder
2022-05-12 11:55 ` Carlo Arenas
2022-05-12 13:01 ` Patrick Steinhardt
2022-05-12 13:56 ` Carlo Arenas
2022-05-12 15:58 ` Junio C Hamano
2022-05-16 8:38 ` [PATCH v4] " Christian Couder
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqzgjmg1q5.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=carenas@gmail.com \
--cc=chriscool@tuxfamily.org \
--cc=christian.couder@gmail.com \
--cc=derrickstolee@github.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).