From: Junio C Hamano <firstname.lastname@example.org> To: Christian Couder <email@example.com> Cc: "Carlo Marcelo Arenas Belón" <firstname.lastname@example.org>, git <email@example.com>, "Christian Couder" <firstname.lastname@example.org>, "Derrick Stolee" <email@example.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: <firstname.lastname@example.org> (raw) In-Reply-To: <CAP8UFD3UvjJzEQApiCKSknDWaTjbEMKkr17j1QN-8gwz7eWV3Q@mail.gmail.com> (Christian Couder's message of "Thu, 12 May 2022 10:52:59 +0200") Christian Couder <email@example.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://firstname.lastname@example.org/) > > 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 \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [PATCH v2] http: add custom hostname to IP address resolutions' \ /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
Code repositories for project(s) associated with this 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).