git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
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.


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