Extraneous configurations MUST have invalid DNS names?

[ekr]

Suggested in AD review.

[ekr]

Also, should we provide guidance on how to select these names. Paul writes:

Should it use known-invalid DNS names, eg "invalid:com", or some randomized
long valid but unlikely DNS name? Guidaance would be useful.

[ekr]

@bemasc

[bemasc]

This text is from @davidben here: #569 (comment)

The goal of this recommendation is to catch clients who are not respecting the "mandatory" bit and force them to fail hard. To do this, the server provides an ECHConfig that is syntactically well-formed but unusable (due to a reserved mandatory extension).

Using a syntactically invalid domain name would defeat the purpose, because clients would discard the ECHConfig without inspecting the extensions. Instead, the server should choose a public_name that is syntactically valid but for which it is not authoritative.

@davidben notes that a name under .invalid would work. This would be a fine choice so long as clients don't carry special logic to detect and reject these names.

[seanturner]

At IETF 121, decided to use .invalid.