Using FQDNs to specify providers

[Saklad5]

While underscore-prefixed TXT records are a considerable improvement over placing everything in the root domain, I think it would be best to go a step further.

The usual method of preventing name collision is an IANA registry, as proposed in #8. However, that would be wildly impractical for this purpose, as basically anyone could have a reason to validate control of a domain.

I propose incorporating a relevant domain, controlled by the provider requesting validation, into the name of a provider. A similar approach is already used in numerous standards, such as OpenPGP user notation.

[provider FQDN]._validation.[hostmaster FQDN]

This eliminates a wide swath of issues: the format, meaning, applicability, and scope of the TXT record can be left to the discretion of the provider, and additional namespaces can be specified trivially.

This structure lends itself naturally to the proposed DNAME record mentioned in #26: a hostmaster wishing to redirect certain validation records could place a DNAME anywhere in that sequence, even scoping it by provider.

[Saklad5]

Some examples of how this would work:

Google Workspace

workspace.google.com._validation.example.com.   IN   TXT "TOKENDATA"

Apple Custom Email Domain

mail.icloud.com._validation.example.com.   IN   TXT "TOKENDATA"

Apple Pay Merchant Verification

example-merchant-identifier.applepay.apple.com._validation.example.com.   IN   TXT "TOKENDATA"

Example One-Time Validation

activation-only.provider.example._validation.example.com.   IN   TXT "expiry=2023-10-12;token=TOKENDATA"

Example Indefinite Validation

continued-service.provider.example._validation.example.com.   IN   TXT "TOKENDATA"

---

As you can see, providers could use this approach to include purpose-specific information such as the identifier being linked, the product it is applicable to, the type of validation, and anything else they choose.

At the same time, the only underscored node name that would need to be registered with IANA is _validation.

[moonshiner]

I'm a big fan of the underscore-prefix TXT records (and the simple registry).

I'm okay with the idea of creating such a name, and encouraging folks to use it. I find _validation to be a bit vague to its purpose. I notice that many vendors use wording such as "-domain-verification" - domain-verification is more obvious its use

[ShivanKaul]

Thanks for this @Saklad5, and apologies for following up so late.

In the draft we're currently using _feature1._foo-challenge.example.com. IN TXT "TOKENDATA" for this purpose, or to modify the Apple Pay domain verification example given in https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-domain-verification-techniques/issues/28#issuecomment-1242772381: _applepay.apple-challenge.example.com. IN TXT "TOKENDATA"

To me they seem equivalent, but perhaps folks have other opinions?

I am curious though as to why example-merchant-identifier label is needed in your example. Wouldn't it be sufficient to just have applepay.apple.com._validation.example.com in the Name according to the convention you're describing?

[Saklad5]

To me they seem equivalent, but perhaps folks have other opinions?

The issue here is that there can be different scopes of validation. Even within Apple, there are entirely distinct things that the validation may be meant for, and an attacker might be able to exploit the collision. Unless you want to make a registry for labels like apple-challenge, tying it to a domain controlled by the provider seems the best approach.

I am curious though as to why example-merchant-identifier label is needed in your example.

This is for the same reason: it narrows what the validation applies to. In that example, the domain is validating that it is connected to a specific merchant in the specific context of Apple Pay.

---

In the not-implausible scenario of requiring revalidation on a regular basis (like with ACME), the domain holder would likely wish to automate the process using RFC 2136 (DDNS). When granting access to the zone, making the scope this narrow alleviates the risk of compromise considerably, as the credentials used to update the record cannot be exploited to accomplish something else (such as connecting the domain to an attacker's merchant ID).

With ACME's dns-01 challenge, you can accomplish something similar using CAA record tags like accounturi.

[Saklad5]

Here's another scenario: imagine a Mastodon fork added the ability to tie users to signed DNS zones by adding a TXT record. Keybase offers a similar system, and Mastodon already allows you to validate control of a webpage using HTML, so this is not implausible.

Any domain can be a Mastodon server, and a user's handle is not necessarily scoped to that server either. For instance, a user @delegated@example.com might want their account with mastodon.example to prove control of example.net. Something like mastodon-challenge wouldn't make sense, as other forks of Mastodon may use a different format and there may be multiple servers running the same fork. The distinguishing factor must be the domain of the provider. There may be many accounts trying to establish control as well: each employee of a startup might want to prove their personal account is connected to the company website, for example. To avoid an abundance of TXT records in one DNS request (especially since this would be perpetual), the handle should be part of the label as well.

delegated._example.com._user.mastodon.example._validation.example.net.   IN   TXT "Name of Relationship on Profile"

Not only does this make it fairly easy to establish a relatively complicated relationship, this also allows the zone owner to dictate the precise nature of that relationship.